3 handshakes and 4 waves

Link layer MTU Maximum Transmission Unit 1500 ?MISS Maximum Segmentation

TCP layer Data ?tcp +Data

TCP+MISS+id2

D1<MISS

ip +TCP +D1+id2

tcp+D1+id2

tcp passes one segment (D1) passes successfully passes second segment (D2) ? Data number id1

Packet alive timer ?2h After 2h no acknowledgement from other party ? Probe packets are sent after every 75 seconds Send 10 times or no response, then fail

UDP (User Datagram Protocol)-SMS

Just send, do not confirm whether the other party receives it or not

Encapsulate the data and the source and destination into a packet, do not need to establish a connection

Each packet is limited to 64K

Because there is no need to establish a connection, it is unreliable. It is an unreliable protocol because it does not require a connection

It does not require a connection to be established and is fast

Application scenarios: live video streaming, gaming LOL

TCP (Transmission Control Protocol)

A connection is established to form a channel for transmitting the data

Large data transfers are carried out within the connection (there is no limitation on the size of the data)

The connection is completed through three handshakes. Connection completed through three handshakes, is a reliable protocol, safe delivery

Connection must be established, will be slightly less efficient

Data link layer Cannot be larger than 1500 bytes Too much data must be sliced

We know that when network data transmission is performed between application layer programs, on the sender side, the data will be transmitted down the protocol stack from the application layer, through TCP/IP layer, and then through the link layer, and then through TCP/IP layer. IP layer, and then sent out via the link layer, while on the receiving

side, the order is reversed, with data being received via the link layer, and then transmitted up the stack, through the IP/TCP layer, and finally read by the application layer program.

When the IP layer transfers data to the link layer, it often does a piecemeal operation, and for most link layers, it has a maximum transmission unit (MTU), which indicates the size of the amount of data that can be sent, and it is determined by the hardware. For example, the MTU for Ethernet is 1500 bytes. When the amount of data that the IP layer transmits to the link layer is greater than its MTU, then the IP layer splits the data into slices that are smaller than the MTU of the link layer, and transmits them to the link layer to be sent. However, for different transport layer protocols (TCP/UDP), the need for slicing or dicing at the IP layer varies

Slicing at the TCP Layer

For TCP, it is important to avoid slicing as much as possible. For TCP, it avoids sharding as much as possible. Because if the IP layer is sharded, if one of the slices of data is lost, for the reliability of the TCP protocol, it will increase the chance of retransmission of packets, and can only retransmit the entire TCP packet (the packet before IP sharding), because the TCP layer does not know the details of sharding at the IP layer, and does not care about it.

When the TCP layer retransmits a TCP packet, it also has a direct impact on the performance of the application layer, especially when the application uses blocking IO for reads and writes. To understand this, we first need to know what an application layer program does when it writes data to the TCPIP stack.

In an application layer program, we can have our own send buffer, and the TCP layer itself has a send buffer of its own, typically 8k in size by default, which can be set or read via SO_SNDBUF. When we write data from the application layer to the TCP layer, we are actually copying the data from the application layer's send buffer to the TCP layer's send buffer. When the TCP layer's send buffer is full or the network is idle, the TCP layer will pass the data in its buffer to the link layer's send queue through the IP layer. If the TCP layer's transmit buffer is full and the application layer's data has not been written, the kernel hangs the write system call and does not return it to the application layer program until all of the application layer's data has been copied into the TCP layer's buffer. Since the TCP layer wants to ensure packet reliability, i.e., to retransmit packets when they are lost, the TCP layer needs to temporarily save the outgoing TCP packet data in its transmit buffer for possible subsequent retransmissions after sending the TCP packet to the network.

With this in mind, if IP slices the data from the TCP layer, it is possible for the application layer program to hang at the write system call, causing performance degradation.

How the TCP layer avoids fragmentation at the IP layer

First, let's look back at the three handshakes that TCP uses to establish a connection:

In these handshakes, in addition to confirming the SYN chunks, the two ends of the communication negotiate a value, MSS, which is used to tell the other side the size of the TCP chunks that can be sent. This value is generally taken as the MTU size of its link layer minus the TCP header size and the IP header size. MSS = MTU - TCP header size - IP header size.? The MTU value can be learned by asking the link layer. When both ends confirm the MSS for communication, when the TCP layer transmits data to the IP layer, if the size of the TCP layer buffer is larger than the MSS, then the TCP layer will cut the data in its send buffer into MSS-sized packets for transmission. Since the MSS is calculated by subtracting the TCP head size and IP head size from the MTU, the MSS must be smaller than the MTU, then to the IP layer can avoid IP layer fragmentation.

Segmentation at the UDP layer

What if we had used the UDP protocol instead of TCP? Would there be sharding at the IP layer? Since UDP is not required to guarantee reliability, then it does not save sent packets, and the reason why TCP saves sent packets is because of retransmissions. So UDP itself does not have a send buffer like TCP. This leads to the fact that when a write system call is made to UDP, the data from the application layer is actually transferred directly to the IP layer, and since the IP layer itself will not have a buffer, the data will be written directly to the output queue of the link layer. In this case, will the IP layer slice the data from UDP? This depends on the size of the UDP datagram. If the size of the UDP datagram is larger than the MTU of the link layer, then the IP layer will directly slice it and send it to the link layer's output queue, and vice versa, it will not slice it and send it directly to the link layer's output queue with the IP header.

TCP/UDP experiment

After reading the theory, let's practice to see if it matches the above theory.

For TCP, it is trying to avoid fragmentation as much as possible. Assuming that the size of the data we send to the TCP layer is 2748 bytes, this size is significantly larger than the size of the data sent by the link layer, in this case

Let's look at the data from the TCP layer, the IP will not be fragmented.

From the first figure, it seems that the 2748 bytes of the application layer are segmented at the TCP layer, layered with two TCP segments, one 1460 bytes and one 1288 bytes. Then when it comes to the IP layer, naturally it is not being segmented.

As you can see from the second image, in both TCP segments, at serial number 3, the IP header field (Don ' t Fragment) is set to tell the IP layer not to fragment this data.

And for the MSS size negotiation, we can see that in the image below, which shows the first SYN TCP segment sent out by TCP CLIENT:

For UDP, assuming that a UDP packet we want to send has a size of 1,600 bytes, when it's actually distributed out over UDP/IP, will it be be sliced and diced? Look at the following image: ?

From the image above, we can see that the size of the packet we sent is 1600 bytes (at serial number 1), and at the UDP layer, the length is 1608 bytes (at serial number 2), where the 8 bytes are the length of the UDP header field, and at the IP layer (at serial number 3), we can clearly see that the IP slices the UDP packet, with one of 1480 bytes and one of 128 bytes. One is 1480 bytes in size and one is 128 bytes.

Differences:

1. IP fragmentation is generated because of the MTU at the network layer; TCP segmentation is generated because of the MSS.

2. IP fragmentation is done by the network layer, and also reorganized at the network layer; TCP segmentation is done at the transport layer, and reorganized at the transport layer.? //Transparency

3. For Ethernet, the MSS is 1460 bytes, and the MUT tends to be larger than the MSS.

? Therefore, the use of TCP protocol for data transmission is not caused by IP fragmentation. If the data is too large, it will only segment the data at the transport layer, and will not need to be fragmented at the IP layer.

And we often refer to IP fragmentation is caused by the UDP transport protocol, because the UDP transport protocol does not limit the size of the transmitted datagram.