Unix/Linux编程：socket编程时，如何应对小数据包的传输

调用数据发送接口之后…

socket编程时，可以通过write或者send来进行数据流的发送。

但是，调用这些接口并不意味着数据被真正发送到网络上，它们只是从应用程序被拷贝到了系统内核的套接字缓冲区中，或者说是发送缓冲区中，等待协议栈的处理。至于这些数据是什么时候被发送出去的，对应用程序来说，是无法预知的。对这件事情真正负责的，是运行于操作系统内核的TCP协议栈实现模块

流量控制和生产者-消费者模型

我们可以把理想中的TCP协议想象成一队运输货物的货车，运送的货物就是TCP数据包，这些货车把数据报从发送端运送到接收端，就这样不断周而复始。

我们仔细想一下，货物到达接收端之后，是需要卸货处理、登记入库的，接收端限于自己的处理能力和仓库规模，是不可能让这队货车以不可控的速度发货的。接收端肯定会和发送端不断地进行信息同步，比如接收端通知发送端：“后面那 20 车你给我等等，等我这里腾出地方你再继续发货。”

这其实就是发送窗口和接收窗口的本质，可以理解为TCP的生产者-消费者模型。

发送窗口和接收窗口是TCP连接的双方，一个作为生产者，一个作为消费者，为了达到一致协同的生产-消费速率，而产生的算法模型的实现。

说白了，作为TCP发送端，也就是生产者，不能忽略TCP的接收端，也就是消费者的实际状态，不管不顾的把数据包都传输过来。如果都传输过来，消费者来不及消费，必然会丢弃；而丢弃反过来使得生产者又重传，发送更多的数据包，最后导致网络崩溃。

拥塞控制和数据传输

TCP的生产者-消费者模型，只是在考虑单个连接的数据传递，但是，TCP数据包是需要经过网卡、交换机、核心路由器等一系列的网络设备的，网络设备本身的能力也是有限的，当多个连接的数据包同时在网络上传送时，势必会发生带宽争抢、数据丢失等，这样，TCP就必须考虑多个连接共享在有限的带宽上，兼顾效率和公平性的控制，这就是拥塞控制的本质。‘

举个形象一点的例子，有一个货车行驶在半夜三点的大路上，这样的场景是断然不需要拥塞控制的。

我们可以把网络设备形成的网络信息高速公路和生活中实际的高速公路做个对比。正是因为有多个 TCP 连接，形成了高速公路上的多队运送货车，高速公路上开始变得熙熙攘攘，这个时候，就需要拥塞控制的接入了。

在TCP协议中，拥塞控制是通过拥塞窗口来完成的，拥塞窗口的大小会随着网络状况实时调整。

拥塞控制常用的算法有“慢启动”，它通过一定的规则，慢慢的将网络发送数据的速率增加到一个阈值。超过这个阈值之后，慢启动就结束了，另一个叫做“拥塞避免”的算法登场。在这个阶段，TCP会不断的探测网络状况，并随之不断调整拥塞窗口的大小。

在任何一个时刻，TCP发送缓冲区的数据能否真正发送出去，至少取决于两个因素，一个是当前的发送窗口大小，另一个是拥塞窗口大小，而TCP协议中总是取两者中最小值作为判断依据，比如当前发送的字节为 100，发送窗口的大小是 200，拥塞窗口的大小是 80，那么取 200 和 80 中的最小值，就是 80，当前发送的字节数显然是大于拥塞窗口的，结论是不能发送出去。

这里千万要分清楚发送窗口和拥塞窗口的区别：

• 发送窗口反应了作为单TCP连接、点对点之间的流量控制模型，它是需要和接收端一起共同协调来调整大小的
• 拥塞窗口反应了作为多个TCP连接共享带宽的拥塞控制模型，它是发送端独立的根据网络状况来动态调整的

问题：在任何一个时刻里，TCP 发送缓冲区的数据是否能真正发送出去，用了“至少两个因素”这个说法，那除了之前引入的发送窗口、拥塞窗口之外，还有什么其他因素吗？

我们来考虑下面几个场景：

• 第一个场景：接收端处理得急不可耐，比如感刚刚读入了100个字节，就告诉发送端：“喂，我已经读走 100 个字节了，你继续发”，在这种情况下，发送端应该怎么做呢？
• 第二个场景：交互式场景中，比如我们使用telnet登录到一台服务器上，或者使用SSH和远程的服务器交互，这种情况下，我们在屏幕上敲打了一个命令，等待服务器返回结果，这个结构需要不断和服务端进行数据传输。这里最大的问题是，每次传输的数据可能都非常小，比如敲打的命令“pwd”，仅仅三个字符。这意味着什么？这就好比，每次叫了一辆大货车，只送了一个小水壶。在这种情况下，发送端该怎么做才合理呢？
• 第三个场景：从接收端的角度来看，接收端需要对每个接收到的TCP分组进行确认，也就是发送ACK报文，但是ACK报文本身是不带数据的分段，如果一直这样发送大量的ACK报文，就会消耗大量的带宽。之所以会这样，是因为TCP报文、IP报文固有的消息头是不可或缺的，比如两端的地址、端口号、时间戳、序列号等信息，在这种情况下，合理的做法又是什么呢？

TCP之所以复杂，就是因为TCP需要考虑的因素较多。像上面这几种场景，都是TCP需要考虑的情况，一句话概述就是如何有效地利用网络带宽。

• 第一个场景也叫做糊涂窗口综合征，这个场景需要在接收端进行优化。也就是说，接收端不能在接收缓冲区空出一个很小的部分之后，就急吼吼地向发送端发送窗口更新通知，而是需要在自己的缓冲区大到一个合理的值之后，再向发送端发送窗口更新通知。这个合理的值，由对应的 RFC 规范定义。
• 第二个场景需要在发送端进行优化。这个优化的方法叫做nagle算法，nagle算法的本质其实就是限制大批量的小数据包同时发送，为此，它提出，在任何一个时刻，未被确认的小数据包不能超过一个。这里的小数据包，指的是长度小于最大报文段长度MSS的TCP分组。这丫昂，发送端就可以把接下来连续的几个小数据包存储起来，等待接收到前一个小数据包的ACK分组之后，再将数据一次性发送出去
• 第三方场景需要在接收端进行优化，这个优化的算法叫做延时ACK。延时ACK在收到数据行并不马上回复，而是累计需要发送的ACK报文，等待有数据需要发送给对端时，将累计的ACK捎带一并发出去。当然，延时ACK机制，不能无限的延时下去，否则发送端误认为数据包没有发送成功，引起重传，反而会占用额外的网络带宽

禁用 Nagle 算法

有没有发现一个很奇怪的组合，即 Nagle 算法和延时 ACK 的组合。

这个组合为什么奇怪呢？举个例子：

• 比如，客户端分两次将一个请求发送出去，由于请求的第一部分的报文未被确认，Nagle 算法开始起作用；同时延时 ACK 在服务器端起作用，假设延时时间为 200ms，服务器等待 200ms 后，对请求的第一部分进行确认；接下来客户端收到了确认后，Nagle 算法解除请求第二部分的阻止，让第二部分得以发送出去，服务器端在收到之后，进行处理应答，同时将第二部分的确认捎带发送出去。

• 从上图可以看到，Nagle 算法和延时确认组合在一起，增大了处理时延，实际上，两个优化彼此在阻止对方。

也就是说，有些情况下Nagle算法并不适用，比如对时延敏感的应用。

幸运的是，我们可以通过对套接字的修改来关闭Nale算法

int on = 1; 
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void *)&on, sizeof(on)); 

值得注意的是，除非我们对此有十足的把握，否则不要轻易改变默认的TCP Nagle算法。因为在现代操作系统中，针对Nagle算法和延迟ACK的优化已经非常成熟了，有可能在禁用了Nagle算法之后，性能问题反而更加严重。

将写操作合并

其实在前面的例子中，如果我们能够将一个请求一次性发送出去，而不是分开两部分独立发送，结果会好很多。所以，在写数据之前，将数据合并到缓冲区，批量发送出去，这是一个比较好的做法。不过，有时候数据会存储在两个不同的缓存中，对此，我们可以使用如下的方法来进行数据的读写操作，从而避免Nagle算法引发的副作用

ssize_t writev(int filedes, const struct iovec *iov, int iovcnt)
ssize_t readv(int filedes, const struct iovec *iov, int iovcnt);

这两个函数的第二个参数都是指向某个 iovec 结构数组的一个指针，其中 iovec 结构定义如下：

struct iovec {
    
    
void *iov_base; /* starting address of buffer */
size_t　iov_len; /* size of buffer */
};”

在调用 writev 操作时，会自动把几个数组的输入合并成一个有序的字节流，然后发送给对端

总结

• 发送窗口用来控制发送接收端的流量；阻塞窗口用来控制多条连接公平使用的有限带宽
• 小数据包加剧了网络带宽的浪费，为了解决这个问题，引入了如 Nagle 算法、延时 ACK 等机制。
• 在程序设计方面，不要多次频繁的发送小报文，如果有，可以使用writev批量发送