Lesson
TCP, UDP and Ports
Learning objective
Compare TCP and UDP, explain sockets/ports, and trace connection establishment, reliability, flow, and closure at a foundational level.
Learning objective
Compare TCP and UDP, use ports and sockets to identify conversations, and trace connection establishment, reliable delivery, flow control, and closure.
Why transport protocols exist
IP delivers a packet to a host, but a host may run a browser, DNS client, messaging app, and many services at once. A transport protocol adds application-to-application delivery. TCP and UDP place source and destination ports inside the IP packet so the receiving operating system can continue the decision.
Segments, datagrams, ports, and sockets
A TCP transport unit is commonly called a segment; a UDP transport unit is a datagram. A port is a 16-bit number in the transport header, not a physical connector. A socket is an operating-system communication endpoint described by protocol, local address, and local port; a connected conversation also includes its remote address and port.
Source and destination ports, multiplexing, and demultiplexing
The destination port helps the receiving host find a listening or receiving application. The source port identifies the sender's side and is often an ephemeral client port. Multiplexing lets many applications share the network stack; demultiplexing uses protocol and endpoint information to deliver each arrival to the correct socket. The full conversation is distinguished by protocol plus source and destination IP addresses and ports.
TCP and UDP header essentials
Both headers carry source and destination ports plus a checksum. TCP additionally carries sequence and acknowledgement numbers, flags, a receive window, and options because it manages a byte stream and connection state. UDP carries length and checksum around a message-oriented datagram with a smaller transport contract. Smaller does not mean UDP is always faster, and TCP's transport reliability does not guarantee application-level success.
Interactive TCP Connection Journey
Follow successful setup, data, loss and retransmission, graceful closure, explicit refusal, and timeout. Watch the direction, flags, sequence and acknowledgement values, receive window, and both endpoint states update together.
TCP Connection Journey
Step 1 of 4: Client sends SYN
The client proposes initial sequence number 1000.
| Field | Value |
|---|---|
| Flags | SYN |
| Sequence number | 1000 |
| Acknowledgement number | Not present |
| Payload | 0 bytes |
| Receive window | 64240 |
Observed state: Client sends SYN
Sequence numbers, acknowledgements, and ordered delivery
TCP numbers bytes. A segment beginning at sequence 1001 with 100 payload bytes covers bytes 1001 through 1100; acknowledgement 1101 says the receiver next expects byte 1101. The receiver can reorder arrived ranges before presenting a continuous byte stream. An ACK proves transport receipt through a byte position, not that the application processed the data successfully.
Loss, retransmission, and duplicates
When acknowledgement evidence does not advance, TCP may retransmit the missing sequence range. If an original copy was merely delayed, both copies can arrive; sequence numbers let the receiver discard duplicate bytes rather than deliver them twice. Retransmission improves delivery but cannot promise that a connection will eventually succeed.
Flow control and the receive window
The receiver advertises how much additional data it can currently buffer in the receive window. The sender limits unacknowledged data accordingly so it does not overwhelm that receiver. This is flow control between endpoints; congestion control, which responds to network conditions, belongs to deeper study.
Graceful closure and resets
FIN and ACK close each sending direction gracefully because TCP is full duplex. RST ends or rejects a connection abruptly. A reachable host with no TCP listener commonly returns RST, but a timeout is different: no response was observed, so loss, filtering, routing, return-path, or host conditions remain possible.
Interactive TCP vs UDP and Port Delivery
Trace TCP and UDP arrivals through header inspection and socket lookup. Compare listening applications, two ephemeral client conversations, and closed destinations. A TCP host may return RST; a UDP host may return ICMP Port Unreachable, while filtering or policy can instead leave the sender observing silence.
TCP vs UDP and Port Delivery
Step 1 of 4: Transport unit arrives
TCP carries source and destination ports inside the IP packet.
Transport tuple: TCP 192.0.2.10:49152 → 198.51.100.20:443
| Field | Value |
|---|---|
| Source port | 49152 |
| Destination port | 443 |
| Flags | SYN |
| Sequence | 1000 |
TCP port 443 → null
Common service ports and ephemeral ports
These defaults are clues, not immutable rules. Clients normally choose temporary ephemeral source ports while servers listen on known service ports.
| Service | Foundational transport and port | | --- | --- | | HTTP | TCP 80 | | HTTPS | TCP 443; modern HTTP can also use QUIC over UDP | | DNS | UDP or TCP 53, depending on the exchange | | DHCP | UDP 67 and 68 | | SSH | TCP 22 | | SMTP | TCP 25 for foundational server-to-server delivery | | NTP | UDP 123 |
Choosing TCP or UDP carefully
Choose based on the application's delivery contract. TCP supplies connection state, ordered bytes, acknowledgements, retransmission, and flow control. UDP supplies independent datagrams and leaves ordering, recovery, pacing, and session behavior to the application when needed. Either can perform well or poorly depending on the workload, implementation, path, and higher-layer design.
Free account
Continue this lesson for free
Unlock the remaining explanation, Wireshark checks, quizzes, interview answers, and saved progress. No payment required.
Continue with Google or email