Network protocols

A network protocol is a set of rules that define how data is transmitted and received between systems.

Among the most commonly used protocols in system design interviews and real-world applications are TCP, UDP, and HTTP.

TCP is connection-oriented, requiring a handshake before data transfer begins.

The handshake process involves three steps:

1. The client sends a SYN (synchronize) message to the server.
2. The server replies with a SYN-ACK (synchronize-acknowledge) message.
3. The client sends an ACK (acknowledge) message, completing the connection.

TCP ensures reliable delivery through two core mechanisms:

• Sequence numbers: Allow receivers to identify and discard duplicate packets and reorder out-of-sequence data.
• Acknowledgments: The receiver sends an ACK to confirm receipt of data up to a specific byte.

The sender maintains a record of each packet it transmits and tracks a timer from when the packet was sent.

If the timer expires and no ACK is received, the sender retransmits the packet.

TCP guarantees that all data arrives in the correct order as it was sent.

When packets arrive out of order, TCP buffers them until all data can be properly reordered.

Data corruption during transmission is prevented using checksums.

The sender computes a checksum and includes it with the data.

The receiver independently computes the checksum.

If both checksums match, the data is considered uncorrupted.

TCP implements flow control to prevent overwhelming the receiver.

The receiver informs the sender of how much data it can accept.

When the receiver’s buffer fills, it signals the sender to stop sending.

TCP also uses congestion control algorithms to regulate data flow.

These prevent senders from flooding the network with data, which could trigger congestion collapse.

Congestion control manages the rate of data entering the network.

Flow control prevents the sender from overwhelming the receiver’s buffer.

TCP prioritizes data accuracy over speed.

It is optimized for reliable delivery, often resulting in relatively low transmission delays.

This makes TCP ideal for applications where data integrity is critical.

UDP is connectionless—data is sent without establishing a connection or verifying the receiver’s state.

As a result, packets may be lost during transmission.

UDP does not provide delivery guarantees, acknowledgments, or retransmissions.

It does not ensure data order.

If two messages are sent, their arrival order cannot be predicted.

UDP lacks both flow and congestion control.

The application layer must manage data transmission rates.

UDP provides data integrity via checksums.

It supports two types of message delivery:

• Broadcast: A single datagram is sent to all hosts on a local network.
• Multicast: A single datagram is delivered to a specific group of recipients.

The key difference is:

• Broadcast sends data to every host on the network.
• Multicast sends data only to intended recipients.

UDP offers no guarantees of delivery, ordering, or duplication protection.

Because it lacks many of TCP’s features, UDP is simpler and faster.

It is best suited for real-time applications where speed outweighs reliability.

UDP prioritizes low latency over packet reliability. It does not guarantee delivery, order, or error recovery.

Applications include live video and audio streaming, online gaming, and device discovery on networks.

These use cases tolerate occasional packet loss because latency is critical.

HTTP is a request-response protocol. A client sends a request to a server.

The server performs an action—like fetching an HTML file—and returns a response.

Older HTTP versions use TCP as the underlying transport.

HTTP3 uses the QUIC protocol as its transport.

QUIC runs on top of UDP but provides reliable delivery.

It includes acknowledgments, retransmissions, ordering, flow control, and congestion control.

QUIC aims to match TCP’s reliability with significantly lower latency.

Older HTTP versions close the connection after one request-response pair.

Creating a new connection for each request is inefficient.

It increases CPU usage due to the TCP handshake process.

Newer HTTP versions use persistent connections.

A single TCP connection can serve multiple requests.

Multiplexing allows multiple HTTP requests to be sent over one persistent TCP connection.

Requests are sent without waiting for responses.

Responses arrive in arbitrary order.

Without multiplexing, requests are sent sequentially.

The client waits for each response before sending the next.

Multiplexing enables concurrent request firing on a single connection.

Opening multiple connections allows parallel requests.

However, multiple connections are resource-intensive.

They consume memory and processing power on both client and server.

Content can be compressed on the server before transmission.

This reduces transfer latency and increases throughput.

An HTTP request includes:

• An HTTP method (e.g., GET, POST)
• A resource path (e.g., /index.html)
• An optional query string (e.g., ?id=123)
• The HTTP version (e as 1.1)
• Request headers (e.g., User-Agent)
• An optional message body

An HTTP response includes:

• HTTP version
• Status code (e.g., 200, 404)
• Status message (e.g., 'OK', 'Not Found')
• Response headers
• An optional message body (the actual resource)

Later in the course, we will explore how network protocols function in distributed systems.