SO_RCVBUF SO_SNDBUFTCP socket has a send buffer and a receive buffer in the kernel, regardless of whether the process reads the socket, the data sent to the end is received through the kernel and cached in the socket's kernel receive buffer. Read the work done is to copy the data from the kernel buffer to the user's buffer in the application layer, that's all. The simplest case (and the general case) of sending the data into the socket's kernel send buffer, and send will return on the upper level. When Send returns, The data is not necessarily sent to the peer, and send simply copies the data from the application layer buffer into the socket's kernel and sends the buffer. UDP socket has a receive buffer, no send buffer, UDP does not guarantee that the data must be sent successfully, so as long as there is data on the hair, regardless of whether the other party can receive correctly, so do not buffer, do not need to send buffer. The receive buffers are used by TCP and UDP to cache the data on the network. Save until the application process is read. For TCP, if the application process has not been read and the buffer is full, the action that occurs is to notify the window in the peer TCP protocol to close. This is the implementation of the sliding window. Ensure that the TCP socket receive buffer does not overflow, This ensures that TCP is reliably transmitted. Because the other party is not allowed to emit more than the size of the advertised window. This is TCP traffic control, if the other side ignores the window size and issue more than the window size of the data, then the receiver TCP will discard it. UDP: When the socket receive buffer is full, The new datagram cannot enter the receive buffer, and the datagram is discarded. UDP is no traffic control; a fast sender can easily overwhelm a slow receiver, causing the receiver's UDP drop datagram to occur. So_rcvlowat So_sndlowat Each set of interfaces has a receiving low water level and a send low water level . receive low water: For TCP sockets, the data in the receive buffer must reach the specified number, and the kernel notifies the process "readable". For example, trigger Select or Epoll, return "socket interface readable" . send low water level: For TCP socket interface, and receive low water level one reason . Understanding Receive low water: if the application does not call recv () to read the data of the socket's accept buffer, the accept buffer data will keep the note in the accept buffer, so the accept buffer will certainly result in the acceptance buffer overflow as it receives more data from the send-side send buffer. So set a accept low water level, when the Epoll supervisor hears that the data of the receiving buffer of a socket exceeds the accepted low water level, then triggers the read-ready so that the Epoll loop returns and begins processing the read I/O event.Receive low water: The default is 1 bytes to understand send low water: If the application does not call send () to copy the data in the application buff into the socket send buffer, then as the data from the send buffer is sent through the TCP protocol to the kernel, Finally, the data of the socket send buffer is getting less and more, the available space is more and more, and finally the sending buffer is more than the low water level, then Epoll hears the socket writable so that the Epoll loop returns and begins processing the write I/O event. Send low water: Default is 2048 bytes So_ REUSEADDR This socket option notifies the kernel that if the port is busy but the TCP state is in Time_wait, the port can be reused. If the port is busy and the TCP state is in a different state, the port is reused with an error message indicating "Address is already in use." The SO_REUSEADDR option is useful when the service program stops and wants to restart immediately, while the new socket still uses the same port. It must be realized that any non-expected data arrival at this time may cause confusion in the service program, but it is only a possibility, In fact, it's impossible. A socket consists of a related five-tuple, protocol, local address, local port, remote address, remote port. SO_REUSEADDR only indicates that local local addresses, local ports can be reused, and the entire related five-tuple is uniquely determined. Therefore, the service program after restarting may receive non-expected data. You must use the SO_REUSEADDR option carefully. so_reuseporthttps://my.oschina.net/miffa/blog/390931so_linger This option specifies how close the function is to the connection-oriented protocol (for example, TCP). The kernel default close operation returns immediately, and if there is data remaining in the socket buffer, the system will try to send the data to the other side.
Common summary of TCP
