Linux高性能网络编程：TCP底层的收发过程

今天探索高性能网络编程，但是我觉得在谈系统API之前可以先讲一些Linux底层的收发包过程，如下这是一个简单的socket编程代码：

int main() {
    ... 

    fd = socket(AF_INET, SOCKET_STREAM, 0);
    bind(fd, ...);
    listen(fd, ...);

    // 如何建立连接
    ...
    afd = accept(fd, ...);

    // 如何接收数据
    ...
    read(afd, ...);

    // 如何发送数据
    ...
    send(afd, ...);

    // 如何关闭连接
    ...
    close(fd);
    ...
}

第一部分：如何建立连接

​我们知道TCP/IP协议族划分了应用层、TCP传输层、IP网络层、链路层（以太层驱动）。

如上图看应用层，通常在网络编程中我们需要调用accept的API建立TCP连接，那TCP如何做的呢？

​从上图的流程可以看到：

（1）client端发起TCP握手，发送syn包；

（2）内核收到包以后先将当前连接的信息插入到网络的SYN队列；

（3）插入成功后会返回握手确认（SYN+ACK）；

（4）client端如果继续完成TCP握手，回复ACK确认；

（5）内核会将TCP握手完成的包，先将对应的连接信息从SYN队列取出；

（6）将连接信息丢入到ACCEPT队列；

（7）应用层sever通过系统调用accept就能拿到这个连接，整个网络套接字连接完成；

那基于这个图，我想问问读者这里会有什么问题么？ 细心的读者应该可以看出：

1、这里有两个队列，必然会有满的情况，那如果遇到这种情况内核是怎么处理的呢？

（1）如果SYN队列满了，内核就会丢弃连接；

（2）如果ACCEPT队列满了，那内核不会继续将SYN队列的连接丢到ACCEPT队列，如果SYN队列足够大，client端后续收发包就会超时；

（3）如果SYN队列满了，就会和（1）一样丢弃连接；

2、如何控制SYN队列和ACCEPT队列的大小？

（1）内核2.2版本之前通过listen的backlog可以设置SYN队列（半连接状态SYN_REVD）和ACCEPT队列（完全连接状态ESTABLISHED）的上限；

（2）内核2.2版本以后backlog只是表示ACCEPT队列上限，SYN队列的上限可以通过/proc/sys/net/ipv4/tcp_max_syn_backlog设置；

3、server端通过accept一直等，岂不是会卡住收包的线程？

在linux网络编程中我们都会追求高性能，accept如果卡住接收线程，性能会上不去，所以socket编程中就会有阻塞和非阻塞模式。

（1）阻塞模式下的accept就会卡住，当前线程什么事情都干不了；

（2）非阻塞模式下，可以通过轮询accept去处理其他的事情，如果返回EAGAIN，就是ACCEPT队列为空，如果返回连接信息，就是可以处理当前连接；

相关视频推荐

tcpip，accept，11个状态，细枝末节的秘密，还有哪些你不知道

dpdk从tcp/ip协议栈开始，准备好linux环境一起开始

10道面试必问的经典网络八股文，让你在面试中逼格满满

免费学习地址：c/c++ linux服务器开发/后台架构师

需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享

​

第二部分：接收数据

​（1）当网卡接收到报文并判断为TCP协议后，将会调用到内核的tcp_v4_rcv方法，如果数据按顺序收到S1数据包，则直接插入receive队列中；

（2）当收到了S3数据包，在第1步结束后，应该收到S2序号，但是报文是乱序进来的，则将S3插入out_of_order队列（这个队列存储乱序报文）；

（3）接下来收到S2数据包，如第1步直接进入receive队列，由于此时out_of_order队列不像第1步是空的，所以引发了接来的第4步；

（4）每次向receive队列插入报文时都会检查out_of_order队列，如果遇到期待的序号S3，则从out_of_order队列摘除，写入到receive队列；

（5）现在应用程序开始调用recv方法；

（6）经过层层封装调用，接收TCP消息最终会走到tcp_recvmsg方法；

（7）现在需要拷贝数据从内核态到用户态，如果receive队列为空，会先检查SO_RCVLOWAT这个阀值（0表示收到指定的数据返回，1表示只要读取到数据就返回，系统默认是1），如果已经拷贝的字节数到现在还小于它，那么可能导致进程会休眠，等待拷贝更多的数据；

（8）将数据从内核态拷贝到用户态，recv返回拷贝数据的大小；

（9）为了选择降低网络包延时或者提升吞吐量，系统提供了tcp_low_latency参数，如果为0值，用户暂时没有读数据则数据包进入prequeue队列，提升吞吐量，否则不使用prequeue队列，进入tcp_v4_do_rcv，降低延时；

第三部分：发送数据

​（1）假设调用send方法来发送大于一个MSS（比如2K）的数据；

（2）内核调用tcp_sendmsg，实现复制数据，写入队列和组装tcp协议头；

（3）在调用tcp_sendmsg先需要在内核获取skb，将用户态数据拷贝到内核态，内核真正执行报文的发送，与send方法的调用并不是同步的，即send方法返回成功，也不一定把IP报文都发送到网络中了。因此，需要把用户需要发送的用户态内存中的数据，拷贝到内核态内存中，不依赖于用户态内存，也使得进程可以快速释放发送数据占用的用户态内存。但这个拷贝操作并不是简单的复制，而是把待发送数据，按照MSS来划分成多个尽量达到MSS大小的分片报文段，复制到内核中的sk_buff结构来存放；

（4）将数据拷贝到发送队列中tcp_write_queue；

（5）调用tcp_push发送数据到IP层，这里主要滑动窗口，慢启动，拥塞窗口的控制和判断是否使用Nagle算法合并小报文（上一篇已经有介绍）；

（6）组装IP报文头，通过经过iptables或者tcpdump等netfilter模块过滤，将数据交给邻居子系统（主要功能是查找需要发送的MAC地址，发送arp请求，封装MAC头等）；

（7）调用网卡驱动程序将数据发送出去；

第四部分：关闭连接

关闭连接就是TCP挥手过程，我们都知道TCP连接是一种可靠的连接，那如何才能完整可靠的完成关闭连接呢？linux系统提供了两个函数：

• close对应tcp_close方法，通过减少socket的引用次数实现关闭，仅当引用计数为0时才会触发tcp_close；

• shutdown对应tcp_shutdown方法，不关心socket被引用次数，直接关闭对应的连接；

​（1）shutdown可携带一个参数，取值有3个，分别意味着：只关闭读、只关闭写、同时关闭读写；

（2）若shutdown的是半打开的连接，则发出RST来关闭连接；

（3）若shutdown的是正常连接，那么关闭读其实与对端是没有关系的；

（4）若参数中有标志位为关闭写，那么下面做的事与close是一致的，发出FIN包，告诉对方本机不会再发消息了；

第五部分：思考题

基于本文留几个思考题。

（1）发送方法返回成功后，数据一定发送到了TCP的对端么？ （调用了IP层的方法返回后，也未必就保证此时数据一定发送成功）

（2）1个socket套接字可能被多个进程在使用，出现并发访问时，内核是怎么处理这种状况的？

（3）若socket为默认的阻塞套接字，调用recv方法传入的len参数，如果网络包的数据小于len，recv会返回么？

（4）当socket被多进程或者多线程共享时，关闭连接时有何区别？