Socket和TCP连接过程解析
Posted Linux就该这么学
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Socket和TCP连接过程解析相关的知识，希望对你有一定的参考价值。
本文主要说明的是TCP连接过程中，各个阶段对套接字的操作，希望能对没有网络编程基础的人理解套接字是什么、扮演的角色有所帮助。
一. 背景
1.完整的套接字格式{protocol,src_addr,src_port,dest_addr,dest_port}。
2.TCP协议栈维护着两个socket缓冲区：send buffer和recv buffer。
要通过TCP连接发送出去的数据都先拷贝到send buffer，可能是从用户空间进程的app buffer拷入的，也可能是从内核的kernel buffer拷入的，拷入的过程是通过send()函数完成的，由于也可以使用write()函数写入数据，所以也把这个过程称为写数据，相应的send buffer也就有了别称write buffer。不过send()函数比write()函数更有效率。
最终数据是通过网卡流出去的，所以send buffer中的数据需要拷贝到网卡中。由于一端是内存，一端是网卡设备，可以直接使用DMA的方式进行拷贝，无需CPU的参与。也就是说，send buffer中的数据通过DMA的方式拷贝到网卡中并通过网络传输给TCP连接的另一端：接收端。
当通过TCP连接接收数据时，数据肯定是先通过网卡流入的，然后同样通过DMA的方式拷贝到recv buffer中，再通过recv()函数将数据从recv buffer拷入到用户空间进程的app buffer中。
3.两种套接字：监听套接字和已连接套接字。
已连接套接字是在监听到TCP连接请求并三次握手后，通过accept()函数返回的套接字，后续进程/线程就可以通过这个已连接套接字和客户端进行TCP通信。
为了区分socket()函数和accept()函数返回的两个套接字描述符，有些人使用listenfd和connfd分别表示监听套接字和已连接套接字，挺形象的，下文偶尔也这么使用。
下面就来说明各种函数的作用，分析这些函数，也是在连接、断开连接的过程。
二. 连接的具体过程分析
2.1 socket()函数
socket()函数的作用就是生成一个用于通信的套接字文件描述符sockfd(socket() creates an endpoint for communication and returns a descriptor)。这个套接字描述符可以作为稍后bind()函数的绑定对象。
2.2 bind()函数
{protocal,src_addr,src_port}
2.3 listen()函数和connect()函数
顾名思义，listen()函数就是监听已经通过bind()绑定了addr+port的套接字的。监听之后，套接字就从CLOSE状态转变为LISTEN状态，于是这个套接字就可以对外提供TCP连接的窗口了。
2.3.1 深入分析listen()
不管使用select()还是poll()模式(至于epoll的不同监控方式就无需多言了)，在进程/线程(监听者)监听的过程中，它阻塞在select()或poll()上。直到有数据(SYN信息)写入到它所监听的sockfd中(即recv buffer)，监听者被唤醒并将SYN数据拷贝到用户空间中自己管理的app buffer中进行一番处理，并发送SYN+ACK，这个数据同样需要从app buffer中拷入send buffer(使用send()函数)中，再拷入网卡传送出去。这时会在连接未完成队列中为这个连接创建一个新项目，并设置为SYN_RECV状态。然后再次使用select()/poll()方式监控着套接字listenfd，直到再次有数据写入这个listenfd中监听者才被唤醒，如果这次写入的数据是ACK信息，则将数据拷入到app buffer中进行一番处理后，把连接未完成队列中对应的项目移入连接已完成队列，并设置为ESTABLISHED状态，如果这次接收的不是ACK，则肯定是SYN，也就是新的连接请求，于是和上面的处理过程一样，放入连接未完成队列。这就是监听者处理整个TCP连接的循环过程。
当未完成连接队列满了，监听者被阻塞不再接收新的连接请求，并通过select()/poll()等待两个队列触发可写事件。当已完成连接队列满了，则监听者也不会接收新的连接请求，同时，正准备移入到已完成连接队列的动作被阻塞。在Linux 2.2以前，listen()函数有一个backlog的参数，用于设置这两个队列的最大总长度，从Linux 2.2开始，这个参数只表示已完成队列的最大长度，而/proc/sys/net/ipv4/tcp_max_syn_backlog则用于设置未完成队列的最大长度。/proc/sys/net/core/somaxconn则是硬限制已完成队列的最大长度，默认为128，如果backlog大于somaxconn，则backlog会被截断为等于该值。
当连接已完成队列中的某个连接被accept()后，表示TCP连接已经建立完成，这个连接将采用自己的socket buffer和客户端进行数据传输。这个socket buffer和监听套接字的socket buffer都是用来存储TCP收、发的数据，但它们的意义已经不再一样：监听套接字的socket buffer只接受TCP连接请求过程中的syn和ack数据;而已建立的TCP连接的socket buffer主要存储的内容是两端传输的"正式"数据，例如服务端构建的响应数据，客户端发起的Http请求数据。
netstat命令的Send-Q和Recv-Q列表示的就是socket buffer相关的内容，以下是man netstat的解释：
Recv-Q Established: The count of bytes not copied by the user program connected to this socket. Listening: Since Kernel 2.6.18 this column contains the current syn backlog.Send-Q Established: The count of bytes not acknowledged by the remote host. Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.
对于监听状态的套接字，Recv-Q表示的是当前syn backlog，即已完成队列中当前的连接个数，Send-Q表示的是syn backlog的最大值，即已完成连接队列的最大连接限制个数;
对于已经建立的tcp连接，Recv-Q列表示的是recv buffer中还未被用户进程拷贝走的数据大小，Send-Q列表示的是远程主机还未返回ACK消息的数据大小。之所以区分已建立TCP连接的套接字和监听状态的套接字，就是因为这两种状态的套接字采用不同的socket buffer，其中监听套接字更注重队列的长度，而已建立TCP连接的套接字更注重收、发的数据大小。
[root@xuexi ~]# netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 ::1:25 :::* LISTEN
[root@xuexi ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:22 *:*
LISTEN 0 100 127.0.0.1:25 *:*
LISTEN 0 128 :::80 :::*
LISTEN 0 128 :::22 :::*
LISTEN 0 100 ::1:25 :::*
注意，Listen状态下的套接字，netstat的Send-Q和ss命令的Send-Q列的值不一样，因为netstat根本就没写上已完成队列的最大长度。因此，判断队列中是否还有空闲位置接收新的tcp连接请求时，应该尽可能地使用ss命令而不是netstat。
2.3.2 syn flood的影响
解决syn flood的方法有多种，例如，缩小listen()维护的两个队列的最大长度，减少重发syn+ack的次数，增大重发的时间间隔，减少收到ack的等待超时时间，使用syncookie等，但直接修改tcp选项的任何一种方法都不能很好兼顾性能和效率。所以在连接到达监听者线程之前对数据包进行过滤是极其重要的手段。
2.4 accept()函数
accpet()函数的作用是读取已完成连接队列中的第一项(读完就从队列中移除)，并对此项生成一个用于后续连接的套接字描述符，假设使用connfd来表示。有了新的连接套接字，工作进程/线程(称其为工作者)就可以通过这个连接套接字和客户端进行数据传输，而前文所说的监听套接字(sockfd)则仍然被监听者监听。
例如，prefork模式的httpd，每个子进程既是监听者，又是工作者，每个客户端发起连接请求时，子进程在监听时将它接收进来，并释放对监听套接字的监听，使得其他子进程可以去监听这个套接字。多个来回后，终于是通过accpet()函数生成了新的连接套接字，于是这个子进程就可以通过这个套接字专心地和客户端建立交互，当然，中途可能会因为各种io等待而多次被阻塞或睡眠。这种效率真的很低，仅仅考虑从子进程收到SYN消息开始到最后生成新的连接套接字这几个阶段，这个子进程一次又一次地被阻塞。当然，可以将监听套接字设置为非阻塞IO模式，只是即使是非阻塞模式，它也要不断地去检查状态。
再考虑worker/event处理模式，每个子进程中都使用了一个专门的监听线程和N个工作线程。监听线程专门负责监听并建立新的连接套接字描述符，放入apache的套接字队列中。这样监听者和工作者就分开了，在监听的过程中，工作者可以仍然可以自由地工作。如果只从监听这一个角度来说，worker/event模式比prefork模式性能高的不是一点半点。
当监听者发起accept()系统调用的时候，如果已完成连接队列中没有任何数据，那么监听者会被阻塞。当然，可将套接字设置为非阻塞模式，这时accept()在得不到数据时会返回EWOULDBLOCK或EAGAIN的错误。可以使用select()或poll()或epoll来等待已完成连接队列的可读事件。还可以将套接字设置为信号驱动IO模式，让已完成连接队列中新加入的数据通知监听者将数据复制到app buffer中并使用accept()进行处理。
常听到同步连接和异步连接的概念，它们到底是怎么区分的?同步连接的意思是，从监听者监听到某个客户端发送的SYN数据开始，它必须一直等待直到建立连接套接字、并和客户端数据交互结束，在和这个客户端的连接关闭之前，中间不会接收任何其他客户端的连接请求。细致一点解释，那就是同步连接时需要保证socket buffer和app buffer数据保持一致。通常以同步连接的方式处理时，监听者和工作者是同一个进程，例如httpd的prefork模型。而异步连接则可以在建立连接和数据交互的任何一个阶段接收、处理其他连接请求。通常，监听者和工作者不是同一个进程时使用异步连接的方式，例如httpd的event模型，尽管worker模型中监听者和工作者分开了，但是仍采用同步连接，监听者将连接请求接入并创建了连接套接字后，立即交给工作线程，工作线程处理的过程中一直只服务于该客户端直到连接断开，而event模式的异步也仅仅是在工作线程处理特殊的连接(如处于长连接状态的连接)时，可以将它交给监听线程保管而已，对于正常的连接，它仍等价于同步连接的方式，因此httpd的event所谓异步，其实是伪异步。通俗而不严谨地说，同步连接是一个进程/线程处理一个连接，异步连接是一个进程/线程处理多个连接。
2.5 send()和recv()函数
send()函数是将数据从app buffer复制到send buffer中(当然，也可能直接从内核的kernel buffer中复制)，recv()函数则是将recv buffer中的数据复制到app buffer中。当然，使用write()和read()函数替代它们并没有什么不可以，只是send()/recv()的针对性更强而已。
这两个函数都涉及到了socket buffer，但是在调用send()或recv()时，复制的源buffer中是否有数据、复制的目标buffer中是否已满而导致不可写是需要考虑的问题。不管哪一方，只要不满足条件，调用send()/recv()时进程/线程会被阻塞(假设套接字设置为阻塞式IO模型)。当然，可以将套接字设置为非阻塞IO模型，这时在buffer不满足条件时调用send()/recv()函数，调用函数的进程/线程将返回错误状态信息EWOULDBLOCK或EAGAIN。buffer中是否有数据、是否已满而导致不可写，其实可以使用select()/poll()/epoll去监控对应的文件描述符(对应socket buffer则监控该socket描述符)，当满足条件时，再去调用send()/recv()就可以正常操作了。还可以将套接字设置为信号驱动IO或异步IO模型，这样数据准备好、复制好之前就不用再做无用功去调用send()/recv()了。
2.6 close()、shutdown()函数
通用的close()函数可以关闭一个文件描述符，当然也包括面向连接的网络套接字描述符。当调用close()时，将会尝试发送send buffer中的所有数据。但是close()函数只是将这个套接字引用计数减1，就像rm一样，删除一个文件时只是移除一个硬链接数，只有这个套接字的所有引用计数都被删除，套接字描述符才会真的被关闭，才会开始后续的四次挥手中。对于父子进程共享套接字的并发服务程序，调用close()关闭子进程的套接字并不会真的关闭套接字，因为父进程的套接字还处于打开状态，如果父进程一直不调用close()函数，那么这个套接字将一直处于打开状态，见一直进入不了四次挥手过程。
而shutdown()函数专门用于关闭网络套接字的连接，和close()对引用计数减一不同的是，它直接掐断套接字的所有连接，从而引发四次挥手的过程。可以指定3种关闭方式：
1.关闭写。此时将无法向send buffer中再写数据，send buffer中已有的数据会一直发送直到完毕。
2.关闭读。此时将无法从recv buffer中再读数据，recv buffer中已有的数据只能被丢弃。
3.关闭读和写。此时无法读、无法写，send buffer中已有的数据会发送直到完毕，但recv buffer中已有的数据将被丢弃。
无论是shutdown()还是close()，每次调用它们，在真正进入四次挥手的过程中，它们都会发送一个FIN。
正常情况下，一个addr+port只能被一个套接字绑定，换句话说，addr+port不能被重用，不同套接字只能绑定到不同的addr+port上。举个例子，如果想要开启两个sshd实例，先后启动的sshd实例配置文件中，必须不能配置同样的addr+port。同理，配置web虚拟主机时，除非是基于域名，否则两个虚拟主机必须不能配置同一个addr+port，而基于域名的虚拟主机能绑定同一个addr+port的原因是http的请求报文中包含主机名信息，实际上在这类连接请求到达的时候，仍是通过同一个套接字进行监听的，只不过监听到之后，httpd的工作进程/线程可以将这个连接分配到对应的主机上。
对于监听进程/线程来说，每次重用的套接字被称为监听桶(listener bucket)，即每个监听套接字都是一个监听桶。
以httpd的worker或event模型为例，假设目前有3个子进程，每个子进程中都有一个监听线程和N个工作线程。
以上是关于Socket和TCP连接过程解析的主要内容，如果未能解决你的问题，请参考以下文章
Linux 网卡驱动学习（应用层tcp 层ip 层设备层和驱动层作用解析）
深入理解TCP协议及其源代码——send和recv背后数据的收发过程