Introduction to Ethernet, IP, TCP, HTTP

The Role of TCP Protocol

The Internet consists of a set of protocols, of which TCP is only one layer, with its own division of labor.

(Image description: TCP is the upper layer of the Ethernet protocol and IP protocol, and the lower layer of the application layer protocol.

The lowest layer, Ethernet, specifies how electronic signals are composed into packets and addresses point-to-point communication within a subnet.

(Image caption: The Ethernet protocol solves point-to-point communication in a LAN.)

However, the Ethernet protocol does not solve how multiple LANs can interoperate, which is solved by the IP protocol.

(Image caption: IP protocol can connect multiple LANs.)

The IP protocol defines its own set of address rules, called IP addresses. It implements the routing function, allowing host A on one LAN to send messages to host B on another LAN.

(Image description: A router is based on the IP protocol. LANs are connected to each other by routers.)

The principle of routing is very simple. All routers in the market have many network ports behind them to access multiple network cables. There is a routing table inside the router, which specifies that the A-segment IP address goes to exit one, and the B-segment address goes to exit two. ...... Through this set of "signposts", the packet forwarding is realized.

(Image caption: The routing table of this machine indicates to which interface the packets with different IP destinations are to be sent.

The IP protocol is only an address protocol and does not guarantee the integrity of packets. If the router loses a packet (for example, if the cache is full, a new incoming packet is lost), it needs to discover which packet was lost and how to resend that packet. This relies on the TCP protocol.

Simply put, the TCP protocol is used to ensure the integrity and reliability of data communication and to prevent packet loss.

To learn more about Ethernet products, click here.

TCP Packet Size

The size of an Ethernet packet is fixed, initially at 1518 bytes, and later increased to 1522 bytes. Of these, 1500 bytes is the payload and 22 bytes is the header.

The IP packet has its own header information inside the Ethernet packet load, which requires at least 20 bytes, so the IP packet load is at most 1480 bytes.

(Image illustration: IP packet inside an Ethernet packet, TCP packet inside an IP packet.)

The TCP packet is inside the load of the IP packet. It requires a minimum of 20 bytes for its header information, so the maximum load of a TCP packet is 1480 - 20 = 1460 bytes. Since IP and TCP protocols often have additional headers, the TCP load is actually about 1400 bytes.

Therefore, a 1500-byte message requires two TCP packets. A major improvement in the HTTP/2 protocol is that it compresses the HTTP protocol headers so that an HTTP request can be placed in a single TCP packet rather than split into multiple packets, which increases speed.

(Image illustration: Ethernet packet load is 1500 bytes, TCP packet load is around 1400 bytes.)

The numbering of TCP packets (SEQ)

A packet of 1400 bytes, then a large amount of data sent at once, must be divided into multiple packets. For example, for a 10MB file, more than 7100 packets need to be sent.

When sending, the TCP protocol numbers each packet (sequence number, or SEQ) so that the receiving party can restore them in order. In case of packet loss, it is possible to know which packet was lost.

The number of the first packet is a random number. For ease of understanding, it will be referred to here as packet number 1. Assuming that this packet has a load length of 100 bytes, it can be deduced that the next packet should be numbered 101. This means that each packet gets two numbers: its own number, and the number of the next packet. The receiver thus knows in what order they should be restored to the original file.

(Image caption: The current packet's number is 45943, and the next packet's number is 46183, from which we can see that the packet's load is 240 bytes.)

TCP packet assembly

After receiving TCP packets, the assembly and reduction is done by the operating system. The application does not handle TCP packets directly.

For the application, it does not need to care about the details of data communication. Unless the line is abnormal, the received data is always complete. The data that the application needs is placed inside the TCP packet and has its own format (e.g., HTTP protocol).

TCP does not provide any mechanism to indicate the size of the original file; this is specified by the application layer protocol. The HTTP protocol, for example, has a header message Content-Length that indicates the size of the message body. For the operating system, it is a continuous process of receiving TCP packets and assembling them in order, no less than one packet.

The operating system does not deal with the data inside the TCP packets. Once the TCP packets are assembled, they are passed on to the application, and the TCP packet contains a port parameter that specifies the application to be passed on to listen to that port.

(Image illustration: The system forwards the assembled data to the appropriate application based on the port in the TCP packet. (In the picture above, port 21 is the FTP server, port 25 is the SMTP service, and port 80 is the web server.

The application receives the assembled raw data, and the browser, for example, reads out a segment of data correctly according to the Content-Length field of the HTTP protocol. This also means that a single TCP communication can include multiple HTTP communications.

Slow Start and ACK

The faster the server sends packets, the better, preferably all at once. However, send it too fast, there is a risk of packet loss. Small bandwidth, router overheating, cache overflow, and many other factors can lead to packet loss. If the line is not good, the faster you send, the more packets will be lost.

The ideal state is to reach the highest rate that the line allows. But how do we know what the ideal rate is for the other line? The answer is to try slowly.

The TCP protocol is designed with a slow start mechanism in order to achieve unity in efficiency and reliability. At the beginning, it sends slowly, and then adjusts the rate according to the packet loss: if no packet is lost, it is sent faster; if packet is lost, it is sent slower.

The Linux kernel has set (constant TCP_INIT_CWND) that when communication starts, the sender sends 10 packets at once, i.e., the size of the "send window" is 10. Then it stops, waits for an acknowledgement from the receiver, and then continues sending.

By default, the receiver sends an acknowledgement message for every two TCP packets it receives. The English word for "acknowledgement" is acknowledgement, so this acknowledgement message is referred to as ACK.

The ACK carries 2 pieces of information.

The number of the next packet to be received

The remaining capacity of the receiver's receive window

With these two pieces of information, plus the latest number of the packet it has already sent, the sender can estimate the approximate reception rate of the receiver and reduce or increase the transmission rate. This is called the "sending window", and the size of this window is variable.

(Image caption: Each ACK carries the number of the next packet, and the remaining capacity of the receive window. Both sides send ACKs.)

Note that since TCP communication is bidirectional, both sides need to send ACKs. the window size for both sides, most likely, is not the same. Also, the ACK is just a few simple fields that are usually combined with data and sent in a single packet.

(Image description: The above diagram shows 4 communications. In the first communication, the packet number sent by host A to host B is 1 and the length is 100 bytes, so the ACK number of host B in the second communication is 1 + 100 = 101, and the packet number of host A in the third communication is also 101. (Therefore, the ACK of the third communication to host A is 201, and the packet number of the fourth communication to host B is also 201.

Even for a connection with a large bandwidth and a good line, TCP always starts slowly with 10 packets and tries to reach the maximum transmission rate only after some time. This is the slow start of TCP.

Packet Loss Handling

The TCP protocol can guarantee the integrity of data communication, how is this done?

As mentioned earlier, each packet comes with the number of the next packet. If the next packet is not received, then the ACK number will not change.

For example, packet number 4 is now received, but packet number 5 is not received. the ACK then records that it expects to receive packet number 5. After some time, packet #5 is received, then the next round of ACKs will update the numbering. If packet 5 is still not received, but packet 6 or 7 is received, then the number in the ACK does not change and always shows packet 5. This can lead to a large number of ACKs with duplicate content.

If the sender finds that it has received three consecutive duplicate ACKs, or if it has timed out and has not received any ACKs, it will acknowledge the packet loss, i.e., packet number 5 is missing, and thus send the packet again. By this mechanism, TCP guarantees that no packet will be lost.

(Image illustration: Host B does not receive packet #100 and will send the same ACK consecutively, triggering Host A to resend packet #100.)

Reference Links

Network protocols for programmers who know at least one programming language