TCP transmission information always misses, and then how to deal with the missing information in the next transmission?
Although TCP is a more stable information transmission protocol than UDP, it also messes up the data sequence. During development, if you use localhost to connect to the server, there is no problem at all. However, some port mapping tools are used to map the server port to the external network. When testing, problems always occur. After debugging, it is found that the data sent from the server will always be disordered. The first time I received incomplete information, the second time I received a part of the information that was missing from the last time. Is this a mac issue or a port mapping issue or a home broadband issue or a code issue or my issue? What to do? Is there such a problem with mainstream software on the market? If so, how is it handled?
If the debug I mentioned here is a debug embedded in the application, the data is out of order. There is no doubt that this is a bug implemented by the operating system TCP / IP protocol stack. The TCP protocol standard must ensure that the data is submitted to the receiver's application in the order in which it was sent!
If this debug tool works at the TCP level or below, such as TCPDUMP, Wireshark, it is normal to find data chaos. Because TCP packets are shuttled on the Internet, they are transported in the car of IP packets. The flow of IP packets on the Internet will encounter packet loss, out-of-order, and repeated duplication, so TCP packets (passengers) sitting in the car of IP packets will have the same experience!
The client process and server process on the same host use localhost (127.0.0.1) to communicate, TCP packets do not enter the network, and even the local network card does not touch, but the data in the process buffer is copied. This copy operation is reliable Extremely high performance (infinitely close to 100%), and almost no packet loss, out-of-order, and duplicate replication occur. So even if there is a bug in the TCP implementation, there will never be an error when doing a buffer copy!
The above text answers the questions in the article, and interested readers can continue reading for a more detailed explanation. Every time I see the problem of TCP transmission, I always want to use a scene with a high degree of similarity in life to explain it to students who have not understood it. I have used a courier company to transport parcels and a water pipe to transport byte streams. But I find it inappropriate to use these metaphors.
For example, express delivery will cause readers to misunderstand: the sender sends 10 parcels, and the recipient must receive 10 parcels. The real TCP transport is often like this: The sender's application sends 10 batches of data through the send () function. Will it really produce 10 TCP packets?
It is possible to generate 10 TCP packets, or it may be 9, 8, 6, or 5. . . As for several, but it depends on the size of the data and the MSS size of TCP, which is beyond the control of the application.
It is possible for TCP to split the data of one batch of applications into another batch, or to combine the data of two or more batches into one batch. This is a high degree of autonomy achieved by TCP! But there is an absolute bottom line: TCP will not mess up the order of the bytes. The bytes that come first will definitely come first, even if they are split and merged into different batches!
When this TCP packet is shuttled on the Internet, disorder will occur. The receiving TCP will reorder the packets based on the TCP packet number and place them in the TCP buffer. In the end, the receiver uses the Recv () function to take it away. The Recv () reads the number of bytes because the Recv () input parameter is the number of bytes.
The interface Recv () provided by TCP to the receiver is like a tap of a water pipe. The user can take 1 byte, 2 bytes, 100 bytes, 1000 bytes at a time, provided that there is More bytes, otherwise even if the faucet (Recv ()) is turned on, there may not be so many bytes flowing out, or even completely empty.
All these metaphors are for the purpose of visualizing a concept that cannot be seen or touched. If you don't think it is very visual, you can directly read the RFC 793 protocol document!
The above is the news sharing from the PASSHOT. I hope it can be inspired you. If you think today' s content is not too bad, you are welcome to share it with other friends. There are more latest Linux dumps, CCNA 200-301 dumps and CCNP Written dumps waiting for you.
Comments