"Go" tcp segment with IP shard

Original:: HTTPS://WWW.JIANSHU.COM/P/F9A5B07D99A2

-------------------------------------------------------------------------------------

1, first, according to Ethernet II type Ethernet frame format can be learned that the Ethernet II type Ethernet frame of the minimum length of 64 bytes, the maximum length of 1518 bytes. (There is also a 7-byte preamble sync? +1-byte frame start delimiter is necessary for all types of Ethernet frame formats)

There are four types of Ethernet frame formats, and the Ethernet II type Ethernet frame format is the type of frame format that I found in the current network using Wireshark after grasping the packet.

Ethernet II Ethernet II frame format I have a problem at the beginning, according to the TCP/IP transport flow can be known that the HTTP response message is loaded into the TCP packet data area, the TCP message is loaded into the IP packet data area, and the final IP message is loaded into the data area of the Ethernet frame. Why does the data area of an Ethernet frame have a maximum length of 1500 bytes, and the HTTP message is eventually placed in the data area of the Ethernet frame without limiting the size of the HTTP message? 2, when the Wireshrak grabbed the packet will find a lot of length of 1514 TCP messages, but this and Ethernet frame data area maximum length of 1518 bytes What is the correlation? And what is this TCP length of 1460 instead of 1500? Image.png

The maximum length of an IP packet in an Ethernet package is 1500 bytes, which means that the Ethernet maximum frame length should be the Ethernet header plus 1500, plus a 7-byte preamble and a 1-byte frame start delimiter, Specifically: 7-byte preamble synchronization +1-byte frame start delimiter + 6-byte destination mac+6 byte of the source mac+2 byte of the frame type +1500+4 byte CRC checksum.
According to the above, the maximum frame should be 1526 bytes, but in fact the maximum frame we get is 1514 bytes, why not 1526 bytes? The reason is that when the data frame arrives at the network card, in the physical layer of the Internet cards to first remove the leading synchronization code and frame start delimiter, and then the frame for CRC check, if the frame checksum is wrong, discard this frame. If the checksum is correct, it determines whether the destination hardware address of the frame conforms to its own receiving condition (the destination address is its physical hardware address, broadcast address, multicast hardware address to be received, etc.), and if so, the frame is delivered to the "device driver" for further processing. At this point, our capture software can catch the data, so the capture software caught is to remove the leading synchronization code, frame start delimiter, CRC check data, the maximum value is 6+6+2+1500=1514.
Again, the structure inside the TCP message.
A complete packet format is the data frame {IP packet {TCP or UDP packet {data}}}, as described above {IP packet {TCP or UDP packet {data}}} portion maximum is 1500 bytes. Then according to the current IPV4 agreement, there are the following provisions:
IP Header, version: 4, contains source, destination IP, header checksum, TTL, etc., total 20 bytes. The TCP header, which contains the source, destination port, a series of pointers, flags, checksums, and so on, amounts to 20 bytes, so the actual available data is 1500-20-20=1460 bytes.

The above explains the origins of 1514 and 1460 in the clutch. In short, 1514 refers to the Ethernet frame to remove the maximum length after some sign bit, 1460 refers to the data area of the Ethernet frame to remove the TCP and IP header can store the maximum data length, that is, the entire HTTP request or response message. 3, finally to answer why the Ethernet frame data area maximum length of 1500 bytes, and the HTTP message is ultimately placed in the data area of the Ethernet frame, but does not limit the size of the HTTP message?

TCP Segmentation and IP sharding
When we learn the TCP/IP protocol, we know that if the TCP message segment is very long, it will be fragmented at the time of sending, and when it is accepted, the same IP datagram will occur when the length exceeds a certain value, and the Shard will be re-reorganized at the receiving end.

Let's look at two concepts that are closely related to TCP segment segmentation and IP datagram fragmentation.

MTU (maximum transmission unit)
The MTU is already mentioned, which is a limitation of the network in the link layer to the data frame, still taking Ethernet as an example, the MTU is 1500 bytes. An IP datagram is transmitted over Ethernet, and if its length is greater than the MTU value, it is necessary to make a shard transfer so that the length of each piece of datagram is less than the MTU. The IP datagram for a shard transfer does not necessarily arrive in order, but the information in the IP header allows these datagrams to be assembled sequentially. The fragmentation and reassembly of IP datagrams is done in the network layer.

MSS (maximum segment size)
MSS is a concept in TCP (the first option field). MSS is the maximum data segment that TCP packets can transmit each time, and the length of TCP segment is larger than MSS, it is necessary to segment transmission. The TCP protocol usually negotiates the MSS values of both sides when establishing the connection, each of which has the MSS option to advertise its desired reception (MSS option only appears in the SYN segment, which is the first two times the TCP three handshake). MSS value is generally the MTU value minus two header size (need to subtract the size of the IP packet header 20Bytes and TCP data Segment header 20Bytes), so if the link layer Ethernet, MSS value is often 1460. While the standard MTU on the Internet (the smallest MTU, the link layer network is x2.5) is 576, then if not set, the default value of MSS is 536 bytes. Many times, the value of MSS is best to take a multiple of 512. The segmentation and recombination of TCP message segments is done at the transport level.

There is a problem here, it is natural to understand that the reason for the TCP segment is the MTU, because there is always mss<=mtu, it is obvious that each segment of TCP packet after the MSS,IP and the length of the IP header cannot exceed the MTU, Therefore, there is no need for IP fragmentation at the network level. Therefore, the TCP packet segment rarely occurs with IP shards.

Again, UDP datagrams, because UDP datagrams do not fragment themselves, so when the length exceeds the MTU, the network layer will be IP shards. Similarly, ICMP (in the network layer) also has an IP shard condition.

Summary: UDP does not fragment, it is divided by IP. TCP will fragment, of course, no IP to divide!

In addition, after the IP datagram is fragmented, only the first piece with the UDP header or ICMP header, the remaining shards only the IP header, after the end of the endpoint based on the information in the IP header and re-network layer reorganization. TCP headers are in each segment of the packet, and the TCP header is reorganized at the transport layer after the endpoint. Once the IP datagram is fragmented, it will only be reorganized after it arrives at the destination, not to other network protocols, and the next station will be reorganized.

Finally, for the datagram of the IP shard, the entire datagram is re-transmitted even if only one piece of data is lost (since there is a retransmission, the transport layer uses a retransmission protocol, such as the TCP protocol). This is because the IP layer itself does not have a time-out retransmission mechanism------is responsible for timeouts and retransmissions by higher-level (such as TCP). When a segment from a TCP packet (in a piece of IP datagram) is lost, TCP will re-send the entire TCP segment after timeout, which corresponds to an IP datagram (there may be multiple IP shards), and there is no way to retransmit only one data shard in the datagram.

Therefore, there is no limit to the size of the HTTP message, because in the transport layer has been a TCP to the HTTP message has been segmented, reached the destination address and then all the TCP segments are reorganized.

The following is an HTTP packet that, if the HTTP message is too large, will be automatically segmented by TCP, the process is transparent to the application layer.

Image.png Image.png

Late Song Y
Links: https://www.jianshu.com/p/f9a5b07d99a2
Source: Pinterest
The copyright of the book is owned by the author, and any form of reprint should be contacted by the author for authorization and attribution.

"Go" tcp segment with IP shard