vlambda博客
学习文章列表

本文将从上层介绍Linux上的TCP/IP栈是如何工作的，特别是socket系统调用和内核数据结构的交互、内核和实际网络的交互。写这篇文章的部分原因是解释监听队列溢出(listen queue overflow)是如何工作的，因为它与我工作中一直在研究的一个问题相关。

建好的连接怎么工作

先从建好的连接开始介绍，稍后将解释新建连接是如何工作的。

内核管理的每一个TCP文件描述符都是一个struct, 它记录TCP相关的信息(如序列号、当前窗口大小等等)，以及一个接收缓冲区(receive buffer,或者叫receive queue)和一个写缓冲区(write buffer,或者叫write queue)，后面我会交替使用术语buffer和queue。如果你对更多细节感兴趣，可以在Linux内核的net/sock.h中看到socket结构的实现。

当一个新的数据包进入网络接口（NIC）时，通过被NIC中断或通过轮询NIC的方式通知内核获取数据。通常内核是由中断驱动还是处于轮询模式取决于网络通信量；当NIC非常繁忙时，内核轮询效率更高，但如果NIC不繁忙，则可以使用中断来节省CPU周期和电源。Linux称这种技术为NAPI，字面意思是“新的api”。

当内核从NIC获取数据包时，它会对数据包进行解码，并根据源IP、源端口、目标IP和目标端口找出与该数据包相关联的TCP连接。此信息用于查找与该连接关联的内存中的struct sock。假设数据包是按顺序的到来的，那么数据有效负载就被复制到套接字的接收缓冲区中。此时，内核将执行read(2)或使用诸如select(2)或epoll_wait(2)等I/O多路复用方式系统调用，唤醒等待此套接字的进程。

当用户态的进程实际调用文件描述符上的read(2)时，它会导致内核从其接收缓冲区中删除数据，并将该数据复制到此进程调用read(2)所提供的缓冲区中。

发送数据的工作原理类似。当应用程序调用write(2)时，它将数据从用户提供的缓冲区复制到内核写入队列中。随后，内核将把数据从写队列复制到NIC中，并实际发送数据。如果网络繁忙，如果TCP发送窗口已满，或者如果有流量整形策略等等，从用户实际调用write(2)开始，到向NIC传输数据的实际时间可能会有所延迟。

这种设计的一个结果是，如果应用程序读取速度太慢或写入速度太快，内核的接收和写入队列可能会被填满。因此，内核为读写队列设置最大大小。这样可以确保行为不可控的应用程序使用有限制的内存量。例如，内核可能会将每个接收和写入队列的大小限制在100KB。然后每个TCP套接字可以使用的最大内核内存量大约为200KB（因为与队列的大小相比，其他TCP数据结构的大小可以忽略不计）。

读语义

如果接收缓冲区为空，并且用户调用read(2)，则系统调用将被阻塞，直到数据可用。

如果接收缓冲区是非空的，并且用户调用read(2)，系统调用将立即返回这些可用的数据。如果读取队列中准备好的数据量小于用户提供的缓冲区的大小，则可能发生部分读取。调用方可以通过检查read(2)的返回值来检测到这一点。

如果接收缓冲区已满，而TCP连接的另一端尝试发送更多的数据，内核将拒绝对数据包进行ACK。这只是常规的TCP拥塞控制。

写语义

如果写入队列未满，并且用户调用写入，则系统调用将成功。如果写入队列有足够的空间，则将复制所有数据。如果写入队列只有部分数据的空间，那么将发生部分写入，并且只有部分数据将被复制到缓冲区。调用方通过检查write(2)的返回值来检查这一点。

如果写入队列已满，并且用户调用写入write(2)），则系统调用将被阻塞。

新建连接的工作机制

在上一节中，我们看到了已建立的连接如何使用接收和写入队列来限制为每个连接分配的内核内存量。使用类似的技术也用来限制为新连接保留的内核内存量。

从用户态的角度来看，新建立的TCP连接是通过在监听套接字上调用accept(2)来创建的。监听套接字是使用listen(2)系统调用的套接字。

accept(2)的原型采用一个套接字和两个字段来存储另一端套接字的信息。accept(2)返回的值是一个整数，表示新建立连接的文件描述符：

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

listen(2)的原型采用了一个套接字文件描述符和一个backlog参数：

int listen(int sockfd, int backlog);

backlog是一个参数，当用户没有足够快地调用accept(2)时，它控制内核将为新连接保留多少内存。

例如，假设您有一个阻塞的单线程HTTP服务器，每个HTTP请求大约需要100毫秒。在这种情况下，HTTP服务器将花费100毫秒处理每个请求，然后才能再次调用accept(2)。这意味着在最多10个 rps 的情况下不会有排队现象。如果内核中有10个以上的 rps，则有两个选择。

内核的第一个选择是根本不接受连接。例如，内核可以拒绝对传入的SYN包进行ACK。更常见的情况是，内核将完成TCP三次握手，然后使用RST终止连接。不管怎样，结果都是一样的：如果连接被拒绝，就不需要分配接收或写入缓冲区。这样做的理由是，如果用户空间进程没有足够快地接受连接，那么正确的做法是使新请求失败。反对这样做的理由是，这太粗暴(aggressive)，尤其是如果新的连接爆发(bursty)的时候。

内核的第二个选择是接受连接并为其分配一个套接字结构（包括接收/写入缓冲区），然后将套接字对象排队以备以后使用。下次用户调用accept(2)将立即获得已分配的套接字, 而不是阻塞系统调用。

支持第二种方式的理由是，当处理速率或连接速率趋向于爆发时，它过于“宽宏大量”。例如，在我们刚才描述的服务器中，假设有10个新连接同时出现，然后这一秒中没有更多的连接出现。如果内核将新连接排队，那么在第这一秒中所有的请求都会被处理。如果内核采用拒绝新的连接的策略，那么即使进程本来能够满足请求速率的，也只有一个连接会成功。

不过有两个反对排队的论点。第一个问题是，过多的排队会导致分配大量的内核内存。如果内核正在分配带有大接收缓冲区的数千个套接字，那么内存使用量可能会快速增长，而用户空间进程甚至可能无法处理所有这些请求。另一个反对排队的论点是，它使应用程序在连接的另一端（客户机）看起来很慢。客户机将看到它可以建立新的TCP连接，但是当它尝试使用它们时，服务器似乎响应非常慢。所以建议在这种情况下，最好是让新的连接失败，因为这样可以提供更明显的服务器不正常的反馈。此外，如果服务器严重破坏了新的连接，客户机就可以知道要退让(back off)；这是另一种拥塞控制形式。

监听队列(listen queue)和溢出

正如您可能怀疑的那样，内核实际上结合了这两种方法。内核将会对新连接进行排队，但只是一定数量的连接。内核将排队的连接数量由listen(2)的backlog参数控制。通常此值设置为相对较小的值。在Linux上，socket.h 将 somaxconn 的值设置为128，在kernel 2.4.25之前，这是允许的最大值。现在最大值是在/proc/sys/net/core/somaxconn中指定的，但是通常您会发现程序使用somaxconn（或更小的硬编码值）。

当监听队列填满时，新连接会被拒绝。这称为监听队列溢出。您可以通过读取/proc/net/netstat并检查ListenOverflows的值来观察情况。这是整个内核的全局计数器。据我所知，您无法获得每个监听套接字的监听溢出统计信息。

在编写网络服务器时，监控监听溢出非常重要，因为监听溢出不会从服务器的角度触发任何用户可见的行为。服务器将愉快地accept(2)每日的连接，而不返回任何连接被丢弃的迹象。例如，假设您为Python应用程序使用Nginx作为代理服务器。

如果python应用程序太慢，则可能导致nginx listen套接字溢出。当发生这种情况时，您将在nginx日志中看不到任何关于这一点的指示，您将一直看到200状态代码，像往常一样。因此，如果您只是监视应用程序的HTTP状态代码，您将无法看到阻止请求转发到应用程序的TCP错误。