国外个人网站,给公司做个网站多少钱,微信公众号的激活方法,苏州网站建设sz sogou文章目录 一、四次挥手各状态FIN_WAIT_1CLOSE_WAITFIN_WAIT_2LAST_ACKTIME_WAITCLOSE 二、双方同时调用close()#xff0c;FIN_WAIT_1状态后进入CLOSING状态CLOSING状态 三、TIME_WAIT状态详解(1) TIME_WAIT状态下的2MSL是什么MSL #xff08;报文最大生存时间#xff09;为… 文章目录 一、四次挥手各状态FIN_WAIT_1CLOSE_WAITFIN_WAIT_2LAST_ACKTIME_WAITCLOSE 二、双方同时调用close()FIN_WAIT_1状态后进入CLOSING状态CLOSING状态 三、TIME_WAIT状态详解(1) TIME_WAIT状态下的2MSL是什么MSL 报文最大生存时间为什么TIME__WAIT状态必须停留两倍MSL时间 (2) TIME_WAIT存在的意义(3) 为什么会出现大量的TIME_WAIT状态(4) TIME_WAIT状态的影响解决方法 四、HTTP中一般服务端是请求断开方 由于TCP连接是全双工的因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭而另一方执行被动关闭。 一、四次挥手各状态
FIN_WAIT_1
当主动关闭方在ESTABLISHED状态时发送一个FIN用来关闭数据传送此时即进入到FIN_WAIT_1状态。
CLOSE_WAIT
处于ESTABILSHED状态的服务器收到FIN包将发回一个ACK确认序号为收到的序号加1。 CLOSE_WAIT 这种状态表示在等待关闭。当对方发送FIN报文给自己系统会回应一个ACK报文给对方此时则进入到CLOSE_WAIT状态。如果还有数据发送给对方则可以在数据发送结束后再发送FIN报文来结束连接所以这个状态是被断开方再等待自己数据发送结束后断开连接
FIN_WAIT_2
处于FIN_WAIT_1状态时当接收到对方回应的ACK报文后则进入到FIN_WAIT_2状态
LAST_ACK
被动关闭一方在发送FIN报文后最后等待对方的ACK报文期间处于LAST_ACK状态
TIME_WAIT
time_wait 是「主动关闭 TCP 连接」一方的状态可能是「客服端」的也可能是「服务器端」的 当TCP的一端发起主动关闭收到 FIN 请求即第3次握 手完成后发送了第四次握手的ACK包后最后的 ACK 是由「主动关闭连接」的一端发出的就进入了TIME_WAIT状态。
CLOSE
当被动方收到ACK报文后也即可以进入到CLOSED可用状态了。
二、双方同时调用close()FIN_WAIT_1状态后进入CLOSING状态 CLOSING状态
CLOSING 当发送FIN报文后进入fin_wait_1状态过后并没有收到对方的ACK报文反而也收到了对方的FIN报文。就是双方几乎在同时close一个SOCKET然后就出现了双方同时发送FIN报文的情况表示双方都正在关闭SOCKET连接。 closing状态收到ack报文以后即直接进入time_wait状态
三、TIME_WAIT状态详解
(1) TIME_WAIT状态下的2MSL是什么
MSL 报文最大生存时间
任何报文在网络上存在的最长时间超过这个时间报文将被丢弃。IP 报文 RFC 793中规定MSL为2分钟实际应用中常用的是30秒1分钟和2分钟等。
为什么TIME__WAIT状态必须停留两倍MSL时间
等待2MSL时间主要目的是怕最后一个 ACK包对方没收到那么对方在超时后将重发第三次握手的FIN包主动关闭端接到重发的FIN包后可以再发一个ACK应答包。
当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。
(2) TIME_WAIT存在的意义
可靠的实现 TCP 全双工连接的终止 四次挥手关闭 TCP 连接过程中最后的 ACK 是由「主动关闭连接」的一端发出的如果这个 ACK 丢失则对方会重发 FIN 请求因此在「主动关闭连接」的一段需要维护一个 time_wait 状态处理对方重发的 FIN 请求
假设发起主动关闭方发送的ACK 4次交互的最后一个包在网络中丢失那么由于TCP的重传机制被动关闭方需要重发FIN第三次挥手在该FIN到达主动发起方之前client必须维护这条连接的状态尽管它已调用过close具体而言就是这条TCP连接对应的源IP源端口资源不能被立即释放或重新分配。直到对端重发的FIN达到client也重发ACK后该TCP连接才能恢复初始的CLOSED状态。如果主动方不进入TIME_WAIT以维护其连接状态则当被动方重发的FIN达到时主动方的TCP传输层会以RST包响应对方这会被对方认为有错误发生而事实上这是正常的关闭连接过程并非异常。
处理延迟到达的报文 由于路由器可能抖动TCP 报文会延迟到达为了避免「延迟到达的 TCP 报文」被误认为是「新 TCP 连接」的数据则需要在允许新创建 TCP 连接之前保持一个不可用的状态等待所有延迟报文的消失一般设置为 2 倍的 MSL报文的最大生存时间解决「延迟达到的 TCP 报文」问题。
TCP是流式的所有包到达的顺序是不一致的依靠序列号由TCP协议栈做顺序的拼接假设如果一个新连接建立后旧连接的seq1000包到达对端可能会顶替掉新连接的seq1000造成错误
(3) 为什么会出现大量的TIME_WAIT状态
大量的短连接存在 TCP 四次挥手关闭连接机制中为了保证 ACK 重发和丢弃延迟数据设置 time_wait 为 2 倍的 MSL报文最大存活时间
(4) TIME_WAIT状态的影响
time_wait 状态下TCP 连接占用的端口无法被再次使用 要等到2MSL时间结束才可继续使用而TCP 端口数量上限是 6.5w6553516 bit 大量 time_wait 状态存在会导致新建 TCP 连接会出错address already in use : connect 异常
解决方法
服务器端允许 time_wait 状态的 socket 被重用
缩减 time_wait 时间设置为 1 MSL即2 mins
四、HTTP中一般服务端是请求断开方
在HTTP1.1协议中有个 Connection 头Connection有两个值close和keep-alive这个头就相当于客户端告诉服务端服务端你执行完成请求之后是关闭连接还是保持连接保持连接就意味着在保持连接期间只能由客户端主动断开连接。还有一个keep-alive的头设置的值就代表了服务端保持连接保持多久。
HTTP默认的Connection值为close那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。
虽然HTTP默认Connection值为close但是现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以也有人说现在没有必要通过调整参数来使TIME_WAIT降低了。
