Role of the Transport Layer#

The transport layer provides end-to-end communication between applications on different hosts. It multiplexes connections using ports and (in TCP’s case) ensures reliable delivery.

flowchart TD
    App1["Web Browser (port 443)"] --> TL["Transport Layer"]
    App2["SSH Client (port 22)"] --> TL
    App3["DNS Client (port 53)"] --> TL
    TL --> NL["Network Layer (IP)"]

TCP (Transmission Control Protocol)#

Reliable, ordered, connection-oriented. Used when every byte must arrive correctly.

Three-Way Handshake#

sequenceDiagram
    participant C as Client
    participant S as Server
    
    C->>S: SYN (seq=100)
    S->>C: SYN-ACK (seq=300, ack=101)
    C->>S: ACK (seq=101, ack=301)
    Note over C,S: Connection established

TCP Features#

TCP Connection Teardown#

sequenceDiagram
    participant C as Client
    participant S as Server
    
    C->>S: FIN (I'm done sending)
    S->>C: ACK
    S->>C: FIN (I'm done too)
    C->>S: ACK
    Note over C: TIME_WAIT (2×MSL)

TIME_WAIT: Client waits ~60s to ensure the final ACK arrives. This is why you see many TIME_WAIT connections on busy servers.

TCP States#

stateDiagram-v2
    [*] --> LISTEN: Server binds port
    LISTEN --> SYN_RECEIVED: Receive SYN
    SYN_RECEIVED --> ESTABLISHED: Receive ACK
    ESTABLISHED --> FIN_WAIT_1: Send FIN
    FIN_WAIT_1 --> FIN_WAIT_2: Receive ACK
    FIN_WAIT_2 --> TIME_WAIT: Receive FIN
    TIME_WAIT --> [*]: Timeout

UDP (User Datagram Protocol)#

Unreliable, unordered, connectionless — but minimal overhead.

┌──────────┬──────────┬──────────┬──────────┐
│ Src Port │ Dst Port │  Length  │ Checksum │  ← 8 bytes total
└──────────┴──────────┴──────────┴──────────┘
│              Payload                        │
└─────────────────────────────────────────────┘

No handshake, no acknowledgment, no retransmission, no ordering.

TCP vs UDP Comparison#

When to Use Each#

Ports#

Ports identify specific applications on a host (0-65535):

Common Ports#

Socket = IP + Port#

A connection is uniquely identified by a 5-tuple:

(Protocol, Source IP, Source Port, Destination IP, Destination Port)
(TCP, 192.168.1.10, 52431, 93.184.216.34, 443)

TCP Performance Considerations#

Window Size and Throughput#

Throughput ≤ Window Size / Round-Trip Time

Example: 64KB window, 100ms RTT
  64KB / 0.1s = 640 KB/s (only 5 Mbps!)

TCP Window Scaling (RFC 1323) allows windows up to 1GB.

Nagle’s Algorithm#

Buffers small writes to reduce packet count. Can cause latency for interactive protocols — disable with TCP_NODELAY.

Keep-Alive#

Detects dead connections by sending periodic probes:

Client ←→ Server
         [no data for 2 hours]
Client → Keep-alive probe
Server → ACK (still alive)

Troubleshooting#

# Check listening ports
ss -tlnp                    # TCP listening, with process
ss -ulnp                    # UDP listening

# Check established connections
ss -tnp                     # TCP connections with process

# Check for TIME_WAIT accumulation
ss -s                       # summary statistics

# Test port connectivity
nc -zv host 443             # TCP connect test
nc -zu host 53              # UDP test

Key Takeaways#

1. TCP = reliable (web, APIs, databases), UDP = fast (DNS, streaming, gaming)
2. Three-way handshake establishes TCP connections (SYN → SYN-ACK → ACK)
3. Ports identify applications — know the common ones (22, 80, 443, 5432)
4. TIME_WAIT is normal — it ensures clean connection closure
5. A socket is IP:Port — the 5-tuple uniquely identifies a connection
6. ss -tlnp is your go-to for checking what’s listening