声明
本文绝大部分内容参考了：https://cloud.tencent.com/developer/article/1666211
一、建好的连接怎么工作
内核管理的每一个TCP文件描述符都对应于一个struct sock结构体, 用于记录TCP相关的信息(如序列号、当前窗口大小等等)，以及一个接收缓冲区(receive buffer,或者叫receive queue)和一个写缓冲区(write buffer,或者叫write queue)，后面我会交替使用术语buffer和queue。(见net/sock.h)
当一个新的数据包进入网络接口（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);
详细的内容，可以查看：《linux手册翻译——listen(2)》和《linux手册翻译——accept(2)》
对于listen(2)的backlog参数，用于控制内核将为新连接保留多少内存。
例如，假设有一个阻塞的单线程HTTP服务器，每个HTTP请求大约需要100毫秒。在这种情况下，HTTP服务器将花费100毫秒处理每个请求，然后才能再次调用accept(2)。这意味着在最多10个 rps 的情况下不会有排队现象。如果内核中有10个以上的 rps，则有两个选择:
不接受连接
例如，内核可以拒绝对传入的SYN包进行ACK。更常见的情况是，内核将完成TCP三次握手，然后使用RST终止连接。不管怎样，结果都是一样的：如果连接被拒绝，就不需要分配接收或写入缓冲区。这样做的理由是，如果用户空间进程没有足够快地接受连接，那么正确的做法是使新请求失败。但是这种做法太粗暴(aggressive)，尤其是新连接爆发(bursty)的时候。接受连接并为其分配一个套接字结构（包括接收/写入缓冲区），然后将套接字对象排队以备以后使用
此时调用accept(2)将立即获得已分配的套接字。这样做就可以提前将连接的socket给准备好，也不会出现拒绝连接的情况，但是可能会造成占用大量的内核内存。
此外，这会使应用程序在连接的另一端（客户机）看起来很慢。客户机将看到它可以建立新的TCP连接，但是当它尝试使用它们时，服务器似乎响应非常慢。所以在这种情况下，让新的连接失败，提供更明显的服务器不正常的反馈。
监听队列(listen queue)和溢出
显然，最好的方法就是中庸之道了：允许一定数量的新连接进行排队。
内核将排队的连接数量由listen(2)的backlog参数控制。通常此值设置为相对较小的值。在Linux上，socket.h 将 somaxconn 的值设置为128，在kernel 2.4.25之前，这是允许的最大值。现在最大值是在/proc/sys/net/core/somaxconn中指定的。参见《linux手册翻译——listen(2)》NOTES部分的讨论。
当监听队列填满时，新连接会被拒绝。这称为监听队列溢出。通过读取/proc/net/netstat并检查ListenOverflows的值来观察情况。注意这是整个内核的全局计数器。目前还无法获得每个监听套接字的监听溢出统计信息。
在编写网络服务器时，监控监听溢出非常重要，因为监听溢出不会从服务器的角度触发任何用户可见的行为。服务器执行accept(2)连接，不会返回任何连接被丢弃的信息。
例如，使用Nginx作为Python应用程序的代理服务器，如果python应用程序太慢，则可能导致nginx listen套接字的监听队列溢出。当发生这种情况时，在nginx日志中看不到任何关于这一点的指示，将一直看到200状态代码。因此，如果只是监视应用程序的HTTP状态代码，将无法看到拒绝连接的TCP错误。