1. The origin and solution of TCP packet dip
By default, the TCP connection will start the delayed transmission algorithm (Nagle algorithm), buffer them before sending the data, if there are multiple data sent in a short time, they will be buffered together for one transmission (buffer size see socket.bufferSize), so Can reduce the performance of IO consumption.
If it is to transfer files, then there is no need to deal with the problem of bagging at all, just put together one package. But if it is multiple pieces of information, or data for other purposes, then the packet must be processed.
You can refer to an example that has been widely spread. Send two consecutive calls to send data1 and data2 at both ends. There are several common situations at the receiving end:
-
A: Receive data1 first, then data2.
-
B: First receive part of the data of data1, and then receive the remaining part of data of data1 and all the data of data2.
-
C: First received all the data of data1 and some data of data2, and then received the remaining data of data2.
-
D: All data of data1 and data2 have been received at one time.
Among them, B, C, and D are our common dipping conditions. For the problem of dipping, common solutions are:
-
Allow a waiting time before sending multiple times : just wait for a while for the next send, which is suitable for scenarios where the interaction frequency is particularly low. The disadvantage is also obvious. For more frequent scenes, the transmission efficiency is too low, but there is almost no need to deal with it.
-
Turn off the Nagle algorithm : Turn off the Nagle algorithm. In Node.js, you can turn off the Nagle algorithm through the socket.setNodelay() method, so that every send is sent directly without buffering. This method is more suitable for scenarios where the data sent every time is relatively large (but not as large as the file) and the frequency is not particularly high. If the amount of data sent each time is relatively small and the frequency is particularly high, turning off Nagle is purely self-defeating martial arts. In addition, this method is not suitable for poor network conditions, because the Nagle algorithm performs packet merging on the server side, but if the client’s network condition is not good in a short period of time, or the application layer can’t transfer the TCP data in time for some reasons recv (recv function: both the client and the server application use the recv function to receive data from the other end of the TCP connection), which will cause multiple packets to be buffered on the client side and become contaminated. (If you are communicating in a stable computer room, then this probability is relatively small and you can choose to ignore it)
-
Packing/unpacking : Packing/unpacking is a common solution in the industry. That is, before sending each data packet, place some characteristic data before/after it, and then divide each data packet according to the characteristic data when the data is received.
2. Why does UDP not stick to packets
-
The TCP protocol is a stream-oriented protocol, and UDP is a message-oriented protocol. The UDP segment is a piece of information, and the application must extract data in units of messages, not any byte of data at a time.
-
UDP has a protected message boundary , and there is a message header (message source address, port, etc.) in each UDP packet, so that it is easy to distinguish and process for the receiving end. The transmission protocol treats data as an independent message for transmission on the Internet, and the receiver can only receive independent messages. The receiving end can only receive one data packet sent by the sending end at a time. If the size of the received data is smaller than the data size sent by the sending end at one time, a part of the data will be lost, that is, the receiving end will not receive it twice.