TCP选项之TCP_CORK和TCP_NODELAY

TCP_CORK TCP_NODELAY

这两个选项是互斥的，打开或者关闭TCP的nagle算法，下面用场景来解释

典型的webserver向客户端的应答，应用层代码实现流程粗略来说，一般如下所示：

  if（条件1）{

     向buffer_last_modified填充协议内容“Last-Modified: Sat, 04 May 2012 05:28:58 GMT”；

     send（buffer_last_modified）；

  }

 

   if（条件2）{

     向buffer_expires填充协议内容“Expires: Mon, 14 Aug 2023 05:17:29 GMT”；

     send（buffer_expires）；

   }

 

   。。。

   if（条件N）{

     向buffer_N填充协议内容“。。。”；

     send（buffer_N）；

   }

 

对于这样的实现，当前的http应答在执行这段代码时，假设有M（M<=N）个条件都满足，那么会有连续的M个send调用，那是不是下层会依次向客户端发出M个TCP包呢？答案是否定的，包的数目在应用层是无法控制的，并且应用层也是不需要控制的。

我用下列四个假设场景来解释一下这个答案

由于TCP是流式的，对于TCP而言，每个TCP连接只有syn开始和fin结尾，中间发送的数据是没有边界的，多个连续的send所干的事情仅仅是：

假如socket的文件描述符被设置为阻塞方式，而且发送缓冲区还有足够空间容纳这个send所指示的应用层buffer的全部数据，那么把这些数据从应用层的buffer，拷贝到内核的发送缓冲区，然后返回。

 

假如socket的文件描述符被设置为阻塞方式，但是发送缓冲区没有足够空间容纳这个send所指示的应用层buffer的全部数据，那么能拷贝多少就拷贝多少，然后进程挂起，等到TCP对端的接收缓冲区有空余空间时，通过滑动窗口协议（ACK包的又一个作用----打开窗口）通知TCP本端：“亲，我已经做好准备，您现在可以继续向我发送X个字节的数据了”，然后本端的内核唤醒进程，继续向发送缓冲区拷贝剩余数据，并且内核向TCP对端发送TCP数据，如果send所指示的应用层buffer中的数据在本次仍然无法全部拷贝完，那么过程重复。。。直到所有数据全部拷贝完，返回。

请注意，对于send的行为，我用了“拷贝一次”，send和下层是否发送数据包，没有任何关系。

 

假如socket的文件描述符被设置为非阻塞方式，而且发送缓冲区还有足够空间容纳这个send所指示的应用层buffer的全部数据，那么把这些数据从应用层的buffer，拷贝到内核的发送缓冲区，然后返回。

 

假如socket的文件描述符被设置为非阻塞方式，但是发送缓冲区没有足够空间容纳这个send所指示的应用层buffer的全部数据，那么能拷贝多少就拷贝多少，然后返回拷贝的字节数。多涉及一点，返回之后有两种处理方式：

1.死循环，一直调用send，持续测试，一直到结束（基本上不会这么搞）。

2.非阻塞搭配epoll或者select，用这两种东西来测试socket是否达到可发送的活跃状态，然后调用send（高性能服务器必需的处理方式）。

 

综上，以及请参考《TCP选项之SO_RCVBUF和SO_SNDBUF》，你会发现，在实际场景中，你能发出多少TCP包以及每个包承载多少数据，除了受到自身服务器配置和环境带宽影响，对端的接收状态也能影响你的发送状况。

 

至于为什么说“应用层也是不需要控制发送行为的”，这个说法的原因是：

软件系统分层处理、分模块处理各种软件行为，目的就是为了各司其职，分工。应用层只关心业务实现，控制业务。数据传输由专门的层面去处理，这样应用层开发的规模和复杂程度会大为降低，开发和维护成本也会相应降低。

 

再回到发送的话题上来：）之前说应用层无法精确控制和完全控制发送行为，那是不是就是不控制了？非也！虽然无法控制，但也要尽量控制！

如何尽量控制？现在引入本节主题----TCP_CORK和TCP_NODELAY。

cork:塞子，塞住

nodelay：不要延迟

 

TCP_CORK：尽量向发送缓冲区中攒数据，攒到多了再发送，这样网络的有效负载会升高。简单粗暴地解释一下这个有效负载的问题。假如每个包中只有一个字节的数据，为了发送这一个字节的数据，再给这一个字节外面包装一层厚厚的TCP包头，那网络上跑的几乎全是包头了，有效的数据只占其中很小的部分，很多访问量大的服务器，带宽可以很轻松的被这么耗尽。那么，为了让有效负载升高，我们可以通过这个选项指示TCP层，在发送的时候尽量多攒一些数据，把他们填充到一个TCP包中再发送出去。这个和提升发送效率是相互矛盾的，空间和时间总是一堆冤家！！

TCP_NODELAY：尽量不要等待，只要发送缓冲区中有数据，并且发送窗口是打开的，就尽量把数据发送到网络上去。

 

很明显，两个选项是互斥的。实际场景中该怎么选择这两个选项呢？再次举例说明

webserver,，下载服务器（ftp的发送文件服务器），需要带宽量比较大的服务器，用TCP_CORK。

涉及到交互的服务器，比如ftp的接收命令的服务器，必须使用TCP_NODELAY。默认是TCP_CORK。设想一下，用户每次敲几个字节的命令，而下层在攒这些数据，想等到数据量多了再发送，这样用户会等到发疯。这个糟糕的场景有个专门的行话来形容-----粘（nian拼音二声）包。