TCP网络编程的代码网上很多,这里就不再赘述,简单用一个图展示一下tcp网络编程的流程:
1、深入connect、listen、accept系统调用,进一步理解TCP的三次握手
这三个函数都是系统调用,我们可以分为请求连接方和被动连接两部分,我们知道请求连接方并非都是client,为了方便,本文用client代表主动连接方,server代表被动连接方。
-
connect()是client的请求连接函数;处理client端的三次握手
-
listen()是server用来监听client端有没有连接请求,本质上它是监测半连接队列和全连接队列中有没有信息,这两个队列中存放的是需要和server端进行连接的客户端信息,下文对这两个队列有解释。下图listen函数的解析中可以看到,第二个参数backlog表示等待连接队列的最大长度。
-
accept()是server端为了独立管理每一个client连接,为其请求分配fd的函数,此函数调用时其实三次握手已经完成了。它从全连接队列中取出第一个节点,并为其分配fd。详情见下图
1、三次握手发生在那个函数?
- 三次握手具体流程:
- client端调用connect系统调用,发起连接请求,并阻塞等待返回结果;
- server端协议栈收到client端发来的syn请求报文后,将该client的tcb信息放入半连接队列,并回复client端syn+ack;
- client端的connect系统调用回复server端ack;
- server端收到client端发来的确认ack后,从半连接队列中找到此client对应的tcb,修改其连接状态,并放入全连接队列中,此时协议栈层面的三次握手完成。
因此对于client而言,三次握手发生在connect函数中;对于server而言,三次握手是由协议栈实现,不发生在任一网络编程函数中。
2、listen(fd, backlog)中,第二个参数backlog是什么意思?
经过对协议栈的分析,它首先创建一个半连接队列,存储发送了syn请求报文的client的信息,然后创建了一个全连接队列,存储回复了ack报文的client的信息(这个信息是从半连接队列中迁移来的),此时协议栈层面的三次握手已经完成;
对于server来说,所有的client连接都会进行业务交互,但是这两个队列中的client连接都还未交由server的用户态管理,因此它们还都属于待连接状态,所以等待连接队列=半连接队列+全连接队列
根据上述listen的函数解析和协议栈原理分析得知,backlog是等待连接队列的最大长度,即=半连接队列+全连接队列的最大长度和
3、accept函数的作用是什么?accept是如何分配fd的?
- 由上述函数解析和三次握手分析得,accept的作用为:
- 从全连接队列中取出第一个节点信息(tcb);
- 根据tcb信息为其重新分配一个sockfd。
- accept如何分配的fd:根据取出的tcb中的ip、port等信息,创建一个新的sockfd接收这个连接,交由server管理(多路io复用epoll)。
4、什么是半连接队列与全连接队列?
半连接队列:由协议栈创建并管理,存放只发送来了syn请求报文的client的tcb信息
全连接队列:由协议栈创建并管理,存放已经回复了ack确认报文的client的tcb信息。
2、深入TCP的四次挥手原理,进一步理解time_wait/close_wait状态
我们要明确一点,close()关闭的只是sockfd(文件句柄,五元组),那tcp连接怎么断开呢?从accept函数我们可以知道,server为每一个连接tcb都分配了一个与之对应的sockfd,当server关闭了这个sockfd之后,与之对应的tcb也被删除,若server没有调用close()关闭sockfd,则这个连接就一直存在,除非等到系统超时或出现网络异常。
RFC 793 - Transmission Control Protocol
1、什么是四次挥手?为什么这样做?
- 四次挥手过程:主动断开放用client表示,被动断开方用server表示
- client调用close()函数,向server发送fin请求报文,client进入fin_wait_1状态;
- server的协议栈收到fin后立即回应client一个ack报文,server进入close_wait状态;
- server应用层得知recv() == 0时,及时调用close() 函数向client发送fin报文,server进入last_ack状态;
- client收到fin报文后,立即回应server一个ack报文,client进入time_wait状态。
- 四次挥手的原因:
- server连接关闭的控制权在应用层,即调用close()后关闭,立即回复ack是协议栈的操作,所以两者不能做到同步。
2、什么是close_wait状态?产生大量close_wait的原因是什么?如何解决?
- close_wait是server端的状态,表示等待来自本地用户的连接终止请求,从server的协议栈回复ack后到用户层调用close()关闭连接之前这段时间称为close_wait状态。
- 大量close_wait原因:收到client的断开请求报文(判断recv()== 0)后,没有调用或没有及时调用close()关闭连接。
- 解决:收到client的断开请求报文(判断recv()== 0)后立即调用close(),在这之间不要出现多余的业务处理,如果无法避免就将业务抛给其他线程进行处理。
3、什么是time_wait状态?产生大量time_wait的原因是什么?如何解决?
- time_wait是client端的状态,表示等待足够的时间,以确保远程tcp接收到对其连接终止请求的确认。client给server回复ack报文后,就进入到time_wait状态。
- 大量time_wait的原因:一般只有服务器或中间服务层才会出现大量对外链接,因此服务端主动发起大量短链接关闭,导致服务端存在大量的time_wait状态(比如HTTP)。
-
HTTP默认的Connection值为close,那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。
-
虽然HTTP默认Connection值为close,但是,现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以,也有人说,现在没有必要通过调整参数来使TIME_WAIT降低了。
-
- 解决:
- 1、规避大量短链接的使用,
- 2、修改/etc/sysctl.conf文件,让服务器能够快速回收和重用那些time_wait的资源。
4、close_wait/time_wait的时长各自是多少?有什么作用?
- 时长:
-
close_wait:如果没有调用close()至少存在两个小时,直到系统崩溃。如果没有及时调用close(),那就得看具体的业务处理时长。
-
time_wait:2MSL,RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。
-
将TCP TIME-WAIT超时时间修改为小于60秒与TCP/IP协议quiet time概念相违背,可能导致您的系统将旧数据当做新数据接收,或者复制的新数据当做旧数据拒绝。因此请在网络专家建议下调整。
-
你可以通过运行
netstat -ant | grep TIME_WAIT | wc -l
命令判断服务器中是否存在大量短连接,然后再确定要不要修改。 -
修改 TIME-WAIT时间的方法有两种:
-
echo 5 > /proc/sys/net/ipv4/tcp_tw_timeout
-
sysctl -w "net.ipv4.tcp_tw_timeout=5"
-
-
- 作用:
-
close_wait:等待来自本地用户的连接终止请求。
-
time_wait:等待足够的时间,以确保远程tcp接收到对其连接终止请求的确认。
-
5、出现大量close_wait/time_wait的危害是什么?
close_wait:1、如果因为没有调用close()导致存在大量close_wait,那将会消耗系统资源,导致系统崩溃;2、如果因为没有及时调用close(),则危害和time_wait一样。
time_wait:占用的端口不能及时释放被使用,要等到2MSL时间后才能使用,则没有足够的sockfd分配,将大大降低并发量。
所以它们有一个共同的危害就是“占着茅坑不拉屎”,资源得不到充分利用。文章来源:https://www.toymoban.com/news/detail-697335.html
本文说提到的client和server不是表面上的客户端与服务器,client是主动请求方;server是被动响应方。文章来源地址https://www.toymoban.com/news/detail-697335.html
到了这里,关于深入协议栈了解TCP的三次握手、四次挥手、CLOSE-WAIT、TIME-WAIT。的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!