TCP and UDP sticky message protection boundaries

In the socket network program, TCP and UDP are both connection-oriented and non-connection-oriented. So TCP's socket programming, send and receive both sides (client and server side) must have one by one pairs of sockets, so the sender in order to send a number of packets to the receiver, more effective to the other side, using the optimization method (Nagle algorithm), will be a small number of intervals and small amount of data, Merge into a large block of data and then seal the packet. In this way, the receiving end, it is difficult to distinguish between, must provide a scientific mechanism for unpacking.

For UDP, the merge optimization algorithm for blocks is not used. Thus, in fact, it is currently believed that because UDP supports a one-to-many pattern, the receiver's skbuff (socket buffer) uses a chained structure to record each UDP packet that arrives, with a message header (message source address) in each UDP packet. Port, etc., so that it is easy to differentiate between the receiving end

Protecting message boundaries and streams

So what is protecting message boundaries and streams?

The protection of the message boundary means that the transport protocol transmits the data as a separate message on the Internet, and the receiving end can only receive independent messages. That is, there is a protection message boundary, and the receiving end can only receive one packet from the sending end at a time. and the stream-oriented refers to the unprotected message protection boundary, if the sender sends the data continuously, the receiving end may receive two or more packets in a single receive action.

Let's say for instance, for example, we send three packets in a row, 2k, 4k, 8k, each of which has reached the receiver's network stack, and if you use the UDP protocol, no matter how much we use the receiving buffer to receive the data, we must have

Three times to receive the action, only to be able to receive all packets received. Instead of using the TCP protocol, we can receive all packets at once by setting the buffer size above 14k. Only one receive action is required.

This is because the UDP protocol protects the message boundary so that every message is independent. While streaming transmits data as a stream of data, he does not think that data is a single message.

So a lot of people are using the TCP protocol to communicate, it is not clear that TCP is based on streaming, and when data is sent continuously, they often know that TCP loses packets. It's not, because when they use a buffer that is big enough, they might receive two or more packets at a time, And many people tend to ignore this, only parsing the first packet, and other packets that have been received are ignored. So if you want to do this kind of network programming, you must pay attention to this point.

Conclusion:

According to the above, it can be understood that TCP in order to ensure reliable transmission, minimize the additional overhead (each contract to verify), so the use of streaming, stream-oriented transmission, compared to message-oriented transmission, can reduce the number of packets sent. Thus reducing the extra pins. However, for programs with frequent data transmissions, TCP may be easy to glue. Of course, on the receiving end of the program, if the machine load is heavy, will also be in the receiving buffer sticky packet. This will require additional unpacking at the receiving end, adding to the workload. Therefore, this is particularly suitable for data requirements of reliable transmission, but do not need too frequent transmission of the occasion (two operation interval of 100ms, specifically by the TCP waiting to send the interval determined, depending on the kernel of the socket in the writing)

and UDP, because of the message-transmission, it hooks all incoming messages to the receiving queue of the buffer, so it is more convenient to extract the data, but it does not have a sticky packet mechanism, so when the amount of data being sent is small, the payload of the packet is smaller, Also increases the number of sent system send overhead (system calls, write hardware, etc.) and receive overhead. Therefore, it should be best to set the packet length of a more appropriate packet to send UDP data. (The maximum UDP payload is 1472, so it's best to transmit data that is close to this number each time, especially for large chunks of data like video, audio, etc.

, while reducing handshake to ensure real-time streaming media.