Tcp_nodelay and tcp_cork

FirstCode:
Int flag = 1;
Int result = setsockopt (sock,/* socket affected */
Ipproto_tcp,/* Set option at TCP level */
Tcp_nodelay,/* Name of option */
(Char *) & flag,/* The cast is historical
Cruft */
Sizeof (INT);/* length of option value */
If (result note: tcp_nodelay requires header files
Tcp_nodelay does not use NagleAlgorithmThe packet will not be spliced into a large package and then sent. directly sending the packet will make the user experience very good.
Tcp_nodelay and tcp_cork both play an important role in network connection behavior. Many Unix systems have implemented the tcp_nodelay option. However,
Tcp_cork is unique to Linux systems and is relatively new. It is first implemented in kernel version 2.4. In addition, other UNIX system versions have similar functions,
It is worth noting that the tcp_nopush option on a system derived from BSD is actually part of the specific implementation of tcp_cork.
Tcp_nodelay and tcp_cork basically control the "Nagle" of the package. The meaning of Nagle here is that the Nagle algorithm is used to assemble a smaller package into a larger frame.
John Nagle is the inventor of the Nagle algorithm, which is named after him. He tried this method for the first time in 1984 to solve Network Congestion of Ford Motor Corporation.
Question (for more information, see ietf rfc 896 ). He solved the so-called silly window syndrome, which is called "stupid window syndrome" in Chinese.
It means that, because of common terminal applicationsProgramA packet is sent every time a key operation is generated. In typical cases, a packet will have a data load of one byte and 40 bytes long
Packet header, resulting in 4000% overload, which can easily cause network congestion.
Nagle became a standard and was immediately implemented on the Internet. It has now become the default configuration, but in our opinion, in some cases, turning this option off is also
Yes. Now let's assume that an application sends a request to send small pieces of data. We can choose to send data immediately or wait for more data to be generated.
And then send the two policies again. If we send data immediately, our interactive and customer/server applications will be greatly benefited. For example, when we are sending
When a short request is waiting for a large response, the related overload is lower than the total amount of data transmitted, and the response time is faster if the request is sent immediately. To
You can set the tcp_nodelay option of the socket to disable the Nagle algorithm.
In another case, we need to wait until the data size reaches the maximum to send all the data through the network. This data transmission method is beneficial to the communication performance of a large amount of data. Typical applications
Is the file server. The application of the Nagle algorithm causes problems in this case. However, if you are sending a large amount of data, you can set the tcp_cork option to disable Nagle,
The method is the opposite of tcp_nodelay.
Note: Both tcp_nodelay and tcp_cork disable the Nagle algorithm, but they behave differently.
After tcp_cork is set, some frames are not sent. All parts of the queued frames can be sent only after being cleared. Prepare the data header or network throughput before calling sendfile (2)
Optimization is useful. In the current implementation, when tcp_cork is set, it will block 200 ms. After the blocking time, the data will be automatically transmitted. This option is after 2.5.71.
It can be used with tcp_nodelay.
Summary:
Set Tcp_cork Before sending a series of data that shoshould be considered as a single message and set Tcp_nodelay  
Before sending short messages that shoshould be sent immediately.
Refer:
Http://blog.csdn.net/hide1713/archive/2008/09/25/2978107.aspx
Http://bbs.chinaunix.net/viewthread.php? Tid = 64174 & extra = & page = 1
Http://articles.techrepublic.com.com/5100-10878_11-1050878.html
Http://www.baus.net/on-tcp_cork
Http://blog.chinaunix.net/u2/72383/showart_1408991.html
Http://lists.xiph.org/pipermail/icecast/2005-December/010188.html
Http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.0/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Application_Tuning_and_Deployment-TCP_NODELAY_and_Small_Buffer_Writes.html