The two transport protocols, and why an application picks one over the other.

Both TCP and UDP use checksums to detect data corruption:

1. The sender computes a checksum value from the data using a defined algorithm and attaches it alongside the data.

2. The data + checksum travel together across the network.

3. The receiver re-runs the same algorithm on the received data and compares the result against the attached checksum.

4. If they match, the data is assumed intact; if not, it's flagged as corrupted.

• When data is sent, a timer starts.

• An acknowledgement (ACK) from the receiver stops the timer, confirming successful delivery.

• If no ACK arrives before the timer expires, a retransmission is triggered.

• Problem: if data was actually received but the ACK itself was lost, naive retransmission would cause duplicate data.

• Solution: sequence numbers let the receiver recognize and discard duplicates, and reassemble data in the correct order even if packets arrive out of sequence.

• Data may or may not be delivered — no acknowledgements, no retransmission

• Data may be received out of order, damaged, or duplicated — UDP doesn't fix any of that itself

• Still uses a checksum, but doesn't act on a failure beyond detecting it

• Why use it anyway: it's much faster, because it skips all the handshake/acknowledgement/retransmission overhead

Common uses: video conferencing, online gaming, and DNS lookups — all cases where speed matters more than guaranteed perfect delivery (a slightly garbled video frame is fine; waiting for a perfect retransmitted one isn't).

Total header size: 8 bytes, split into four 2-byte fields:

4 fields × 2 bytes = 8 bytes header (16 bits each × 4 = 64 bits = 8 bytes)

• Application layer hands TCP large amounts of raw data; TCP divides it into chunks, adds headers and a checksum to each

• Tracks two critical things: data that doesn't arrive (via timers/retransmission) and data order (via sequence numbers)

• Congestion control — dynamically adjusts how much data is sent based on network conditions, to avoid overwhelming the network

Before any actual data flows, TCP establishes a connection using a three-step exchange:

Client → SYN (seq=x) → Server

Server → SYN-ACK (seq=y, ack=x+1) → Client

Client → ACK (seq=x+1, ack=y+1) → Server

1. SYN — client sends a synchronization flag with an initial sequence number, requesting a connection.

2. SYN-ACK — server acknowledges and sends its own sequence number back (a mathematically derived next value).

3. ACK — client acknowledges the server's sequence number, and the connection is now fully established — data can now flow bidirectionally.