调用数据发送接口以后的事

比如使用 write 或者 send 方法来进行数据流的发送。调用这些接口并不意味着 数据被真正发送到网络上，其实，这些数据只是从应用程序中被拷贝到了 系统内核的套接字缓冲区中，或者说是发送缓冲区中，等待协议栈的处理。至于这些数据是什么时候被发送出去的，对应用程序来说，是无法预知的。

拥塞控制和数据传输

在任何一个时刻，TCP 发送缓冲区的数据是否能真正发送出去，至少取决于两个因素，一个是当前的发送窗口大小，另一个是拥塞窗口大小，而 TCP 协议中总是取两者中最小值作为判断依据。
  • 发送窗口：反应了作为单TCP连接、点对点之间的流量控制模型，它是需要和接收端一起共同协调来调整大小的；
  • 拥塞窗口：反应了作为多个TCP连接、共享带宽的拥塞控制模型，它是发送端独立地根据网络状况来动态调整的。

一些有趣的场景

第一个场景：接收端处理得急不可待，比如刚刚读入了 100 个字节，就告诉发送端：“喂，我已经读走 100 个字节了，你继续发”。
第一个场景也被叫做糊涂窗口综合症，这个场景需要在接收端进行优化。也就是说，接收端不能在接收缓冲区空出一个很小的部分之后，就急吼吼地向发送端发送窗口更新通知，而是需要在自己的缓冲区大到一个合理的值之后，再向发送端发送窗口更新通知。这个合理的值，由对应的 RFC 规范定义。
第二个场景：是所谓的“交互式”场景，这种情况下，我们在屏幕上敲打了一个命令，等待服务器返回结果，这个过程需要不断和服务器端进行数据传输。这里最大的问题是，每次传输的数据可能都非常小，比如敲打的命令“pwd”，仅仅三个字符。这就好比，每次叫了一辆大货车，只送了一个小水壶。
第二个场景需要在发送端进行优化。这个优化的算法叫做 Nagle 算法，Nagle 算法的本质其实就是限制大批量的小数据包同时发送，为此，它提出，在任何一个时刻，未被确认的小数据包不能超过一个。这里的小数据包，指的是长度小于最大报文段长度 MSS 的 TCP 分组。这样，发送端就可以把接下来连续的几个小数据包存储起来，等待接收到前一个小数据包的 ACK 分组之后，再将数据一次性发送出去。
第三个场景：是从接收端来说的。接收端需要对每个接收到的 TCP 分组进行确认，也就是发送 ACK 报文，但是 ACK 报文本身是不带数据的分段，如果一直这样发送大量的 ACK 报文，就会消耗大量的带宽。因为 TCP 报文、IP 报文固有的消息头是不可或缺的。
第三个场景，也是需要在接收端进行优化，这个优化的算法叫做延时 ACK。延时 ACK 在收到数据后并不马上回复，而是累计需要发送的 ACK 报文，等到有数据需要发送给对端时，将累计的 ACK捎带一并发送出去。当然，延时 ACK 机制，不能无限地延时下去，否则发送端误认为数据包没有发送成功，引起重传，反而会占用额外的网络带宽。

禁用 Nagle 算法

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

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

可以通过对套接字的修改来关闭 Nagle 算法。
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);  struct iovec {
    void *iov_base;     /* starting address of buffer */
    size_t　iov_len;     /* size of buffer */
};”

集中写的例子：
int main(int argc, char **argv) {
    if (argc != 2) {
        error(1, 0, "usage: tcpclient <IPaddress>");
    }

    int socket_fd;
    socket_fd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in server_addr;
    bzero(&server_addr, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_port = htons(SERV_PORT);
    inet_pton(AF_INET, argv[1], &server_addr.sin_addr);

    socklen_t server_len = sizeof(server_addr);
    int connect_rt = connect(socket_fd, (struct sockaddr *) &server_addr, server_len);
    if (connect_rt < 0) {
        error(1, errno, "connect failed ");
    }

    char buf[128];
    struct iovec iov[2];

    char *send_one = "hello,";
    iov[0].iov_base = send_one;
    iov[0].iov_len = strlen(send_one);
    iov[1].iov_base = buf;
    while (fgets(buf, sizeof(buf), stdin) != NULL) {
        iov[1].iov_len = strlen(buf);
        // int n = htonl(iov[1].iov_len);

        if (writev(socket_fd, iov, 2) < 0)
            error(1, errno, "writev failure");
    }
    exit(0);
}
6 - 20 行：  建套接字，建立连接；
24 - 33 行：使用了 iovec 数组，分别写入了两个不同的字符串，一个是“hello,”，另一个通过标准输入读入；

启动服务器端程序，在客户端依次输入 “world” 和 “network” ：
world
network
服务器端接收到了 iovec 组成的新的字符串： 
received 12 bytes: hello,world
received 14 bytes: hello,network
原理：在调用 writev 操作时，会自动把几个数组的输入 合并成一个有序的字节流，然后发送给对端。

总结

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

思考题

1. 针对最后呈现的 writev 函数，你可以查一查 Linux 下一次性最多允许数组的大小是多少？
Linux下一次性最多允许1024个数组
2. TCP拥塞控制算法 是一个非常重要的研究领域，请你查阅下最新的有关这方面的研究，看看有没有新的发现？
BBR算法，这个算法 在网络包填满路由器缓冲区之前 就触发流量控制，而不在丢包后才触发，有效的降低了延迟。