Taken linhaifeng Park blog:
https://www.cnblogs.com/linhaifeng/articles/6129246.html#_label9
1. What is the stick package
Notes: Only TCP packet sticky phenomenon, UDP never stick package, why, listen to me explain
First of all we need to have a socket send and receive messages principle
Transmitting end may be a K transmission data a K, the receiving side application can two K two K to withdraw data, of course, also possible to first withdraw 3K or 6K data, or only once withdraw a few bytes of data, in other words, the application sees the data as a whole, or that is a stream (stream), a message how many bytes the application is not visible, so the TCP protocol is a stream-oriented protocol, which is easy the reason stick package problem. While UDP is a message-oriented protocol, each segment is a UDP message, in the application must extract the data units of the message can not be extracted any one-byte data, and it is different from TCP. How to define news? That the other side may be disposable write / send data as a message, to be understood that when the other send a message, no matter what the underlying tile segment, TCP protocol layer will sort the data segments constituting the entire message after completion presented in the kernel buffer.
For example tcp socket-based client to upload files to the server, send the file content is in accordance with a section of the stream of bytes sent, I looked at the receiver, did not know of bytes of the file stream where to start, where to stop
The so-called stick package problems mainly because the receiver does not know the limits between the message, does not know how many bytes of data caused by the time extraction.
Further, due to the sender stick package is itself caused by the TCP protocol, TCP to improve the transmission efficiency, the sender often collect enough data before sending a TCP segment. If successive send data are rarely needed, usually based on TCP optimization algorithms to the data transmission time a TCP segment out after the synthesis, so that the receiving side receives the data packet sticky.
- TCP (transport control protocol, the Transmission Control Protocol) is connection-oriented and stream-oriented, high reliability service. The receiver and transmitter (client and server) must have eleven pairs of socket, therefore, in order to transmit end a plurality of packets addressed to the receiving end, other more efficient to send, using the optimization method (the Nagle Algorithm), the times, at intervals smaller and smaller amount of data the data combined into a large block of data, then the packet. In this way, the receiving end, it is hard to tell the difference, and must provide scientific unpacking mechanism. I.e., non-oriented communication message stream is protected boundaries.
- UDP (user datagram protocol, User Datagram Protocol) is a connectionless, message-oriented, providing efficient service. The combined use of the optimization algorithm does not support block ,, since UDP is a many mode, the receiving end of the skbuff (socket buffer) using the chain structure to record the arrival of each UDP packet in each UDP We have a package (information source address and port) message header, so that, for the receiving side, it is easy to distinguish the process. That message is a message-oriented communication protected boundaries.
- tcp is based on the data stream, so messages sent and received can not be empty, which requires all add empty message handling mechanism in the client and server to prevent jamming program, which is based on udp datagram, even if you enter empty content (direct carriage return), it was not an empty message, udp protocols will help you package the message headers, a little experiment
udp The recvfrom is blocked, a recvfrom (x) must only sendinto (y), ended all x bytes of data even if completed, if y> x data is lost, which means that will not stick udp packet, but it will lose the data, unreliable
Tcp protocol data is not lost, did not receive complete package, the next reception, will continue to continue to receive the last, had always end will clear the buffer contents upon receipt ack. The data is reliable, but will stick package.
Stick package will occur in both cases.
1. The transmitting side need to wait until the buffer is full sent out, resulting in stick package (data transmission time interval is short, the data is small, to join together to produce stick package)
Server
#_*_coding:utf-8_*_ __author__ = 'Linhaifeng' import socket BUFSIZE=1024 ip_port=('127.0.0.1',8080) s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) res=s.connect_ex(ip_port) s.send('hello'.encode('utf-8')) s.send('feng'.encode('utf-8'))
2. The recipient does not receive timely packet buffer, resulting in multiple packet receive (a piece of data sent by the client, the server received only a small portion of the server the next time or the time received from the buffer to get the last legacy data generating stick package)
# _ * _ Coding: UTF-_ * _. 8 __author__ = ' Linhaifeng ' from Socket Import * for ip_port = ( ' 127.0.0.1 ' , 8080 ) tcp_socket_server = Socket (AF_INET, SOCK_STREAM) tcp_socket_server.bind (for ip_port) tcp_socket_server.listen ( . 5 ) conn, addr = tcp_socket_server.accept () data1 = conn.recv (2) # once did not receive complete data2 = conn.recv (10) # next time received, will first take the old data, and then take the new Print ( ' -----> ',data1.decode('utf-8')) print('----->',data2.decode('utf-8')) conn.close() 服务端
#_*_coding:utf-8_*_ __author__ = 'Linhaifeng' import socket BUFSIZE=1024 ip_port=('127.0.0.1',8080) s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) res=s.connect_ex(ip_port) s.send('hello feng'.encode('utf-8'))
The occurrence of unpacking
When the length of the transmission side buffer is larger than the MTU of the network card, the data will be transmitted tcp split into several data packets sent.
A supplementary question: Why is the reliable transmission tcp, udp is unreliable transmission
Tcp-based data transmission, please refer to my other article http://www.cnblogs.com/linhaifeng/articles/5937962.html,tcp during data transfer, the sender sends the data to put its own cache, then the cache control protocol data sent to the peer, the peer returns an ack = 1, a transmitting side data buffer is clean, the peer returns ack = 0, the re-transmission data, so reliable tcp
Udp and transmitting data, the peer returns an acknowledgment message is not therefore unreliable
Supplementary two: send (byte stream) and the recv (1024) and sendall
recv means 1024 specified in a 1024-byte data out from the cache
The byte stream is to send into the hexyl side cache, then the cache is controlled by a protocol to send the content to the end, if the size of the byte stream to be transmitted is greater than the remaining buffer space, then the data is lost, it will cycle with sendall send calls, data is not lost
II. Solution