Networking / Basic: packet paths and addressing / Lesson 5

Compare TCP, UDP, and service endpoints

Understand ports, streams, datagrams, connection setup, and application-level completion before selecting or diagnosing a transport.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish TCP byte streams from UDP datagrams.
Explain endpoint tuples and transport versus application success.
Recognize the responsibilities of protocols built over UDP.

Ports identify transport contexts

A conversation is identified by protocol and endpoint information, often described by source/destination addresses and ports. The same numeric port in TCP and UDP names different transport spaces. A listening socket binds a local address and port, while an outbound client commonly uses an ephemeral source port. A port number alone does not authenticate a service or guarantee a particular application protocol. Proxies and translation can change tuples between observation points. Keep both direction and protocol in the record so two unrelated flows are not accidentally merged by a simplistic port-only analysis.

TCP preserves ordered bytes, not messages

TCP provides an ordered byte-stream service with reliability mechanisms between endpoints. It does not preserve the boundaries of application write calls. A receiver can obtain part of a logical message or several messages together, so the application needs framing such as a length field or a defined delimiter. A successful send operation does not necessarily mean the peer application processed or durably committed the data. Connection setup and transport acknowledgements are lower milestones. Define application acknowledgement and retry behavior according to the actual operation rather than assuming TCP alone supplies exactly-once business execution.

python Reconstruct synthetic delimiter-framed stream messages

chunks = [b'HEL', b'LO\nBY', b'E\n']
buffer = b''.join(chunks)
messages = buffer.split(b'\n')[:-1]
print([message.decode('ascii') for message in messages])

Expected output

['HELLO', 'BYE']

Chunk boundaries cut across logical messages. The offline fixture yields two messages only after applying the declared newline framing; it opens no socket.

UDP leaves more responsibility to its application

UDP sends datagrams with message boundaries but does not itself promise delivery, ordering, retransmission, or congestion control equivalent to TCP. An application using UDP must decide which losses are acceptable, how to detect duplicates or stale data, and how to avoid harmful uncontrolled sending. UDP is not synonymous with insecure or unreliable application behavior: protocols can add authentication, reliability, and congestion control above it. Conversely, adding a retry loop without a bound can amplify congestion. Choose a transport from application needs, path behavior, and protocol design rather than a slogan that one is always faster.

Read lengths at the correct protocol boundary

The UDP header includes source port, destination port, length, and checksum fields. Its length covers the UDP header and payload, not every lower-layer header. Parsing a declared byte fixture can teach byte order and field boundaries without constructing or transmitting a real packet. Real validation also considers truncation, checksums, IP version, and encapsulation; a tiny unpack example is not a complete network parser. Keep that limitation explicit, and reject a malformed fixture rather than trusting length fields blindly when building a real authorized analysis tool.

python Decode a synthetic UDP header offline

import struct
header = struct.pack('!HHHH', 53000, 53, 12, 0)
source, destination, length, checksum = struct.unpack('!HHHH', header)
print(f'src={source} dst={destination} payload={length - 8}')

Expected output

src=53000 dst=53 payload=4

The network-byte-order fixture declares four payload bytes. The zero checksum field is illustrative data, not a claim that this header is valid for every IP version or ready for transmission.

Separate refusal, timeout, reset, and application rejection

A refused connection, a silent timeout, a reset, and an HTTP error describe different observations. None automatically names a firewall or a single faulty machine. A transport can be established while authentication or the application fails, and UDP silence may be expected for a protocol that does not answer every datagram. Preserve the exact endpoint tuple, time, and expected exchange. Compare synthetic state models first, then ask which authorized evidence would distinguish listener absence, policy, path loss, or application behavior. This lesson neither contacts endpoints nor scans ports.

Common errors and fixes

One TCP read is treated as one message

Why it happens: Stream chunks were confused with application framing.
How to fix it: Implement the protocol’s explicit message boundary.
Prevent it next time: Test split and combined message chunks.

UDP retries have no bound

Why it happens: Loss recovery ignored congestion and duplication.
How to fix it: Use a protocol-defined bounded recovery design.
Prevent it next time: Treat transport selection as a full protocol decision.

TCP acknowledgement is called durable application success

Why it happens: Transport receipt was confused with business completion.
How to fix it: Require the application’s documented acknowledgement.
Prevent it next time: Define retry and idempotency semantics explicitly.

Check your understanding

1. A sender writes two messages and the receiver reads one combined chunk. Is TCP broken?

Show worked solution

No. TCP presents ordered bytes and may combine or split writes. The application must parse its framing to recover the two logical messages. Tests should vary chunk boundaries independently of message boundaries.

2. What must a reliable protocol over UDP add beyond datagram boundaries?