做网站开发,旅行网站开发需求说明书,企业所得税怎么征收标准,wordpress获取图片原图TCP 三次握手/四次挥手
参数用途SYN用于启动和建立连接时#xff0c;同步设备之间的序列号。0到2^32 - 1的随机数。ACK向另一端确认已经收到 SYN#xff0c;数值为收到 SYN 增一。SYN-ACK确认之前收到了 SYN#xff0c;数值为自定义值。FIN终止连接。RST重置连接。
三次握…TCP 三次握手/四次挥手
参数用途SYN用于启动和建立连接时同步设备之间的序列号。0到2^32 - 1的随机数。ACK向另一端确认已经收到 SYN数值为收到 SYN 增一。SYN-ACK确认之前收到了 SYN数值为自定义值。FIN终止连接。RST重置连接。
三次握手 三次握手流程为
第一次握手client 请求建立连接发送 SYN 包到主机 B并进入 SYN_SEND 状态等待 server 回应第二次握手server 向 client 发送 SYNACK 包表示也想和 client 建立连接并确认 client 的报文并进入 SYN_RECV 状态第三次握手client 收到 server 发送的 SYNACK 包向 server 发送 ACK 包
为什么需要三次握手
有很多种说法这里列出以下两种说法自我感觉第一种说法比较浅显易懂
因为经过了三次握手主机 A 和主机 B 才可以保证自己的发送能力和接收能力都是正常的那么理论上双方收发能力正常证明网络可靠可以进行通信。在谢希仁版《计算机网络》中是这样说的如果 client 发送的第一个 SYN 包并没有丢失只是在网络中滞留以致于延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文但 server 收到此失效报文后就误认为是 client 再次发出的一个新的连接于是向 client 发出 SYNACK 包如果不采用三次握手只要 server 发出 SYNACK 包就建立连接会导致 client 没有发出建立连接的请求因此不会理会 server 的 SYNACK 包但是 server 却以为新的连接建立好了并一直等待 client 发送数据导致资源被浪费
四次挥手 四次挥手流程为
第一次挥手客户端想要终止连接时向服务端发送 FIN客户端进入 FIN_WAIT_1 状态表示客户端没有数据要发送给服务端了但是如果服务端还有数据没有发送完服务端可以继续发送数据第二次挥手服务端收到客户端终止请求后回复 ACK 确认 FIN表示已经收到客户端的中断请求但是服务端还有数据需要发此时客户端进入 FIN_WAIT_2 状态继续等待服务端的 FIN中断连接 报文第三次挥手TCP 的连接是相互独立的当服务端已经发送完数据了向客户端发送 FIN1 报文告诉客户端数据已经发送完毕准备好关闭连接了服务端此时进入 LAST_ACK 状态 如果服务端一直没有收到客户端返回的 ACK 报文那么就会触发超时重传服务端会重传 FIN 报文 第四次挥手客户端收到服务端的 FIN 后知道可以关闭连接了因此向服务端发送 ACK 报文并进入 TIME_WAIT 状态如果客户端不向服务端发送 ACK 那么服务端并不请求客户端是否收到了服务端关闭连接的请求假如服务端发送给客户端的 FIN 报文丢失那么客户端就一直以为服务端没有请求关闭连接导致连接无法关闭 如果客户端在 2msl 内再次收到了来自服务端的 FIN 报文说明服务器端没有收到客户端的 ACK 报文客户端重新向服务端发送 ACK 报文计时器重置如果客户端再 2msl 内没有收到服务端的 FIN 报文说明服务端正常接收了 ACK 确认报文客户端可以进入 CLOSED 状态
为什么客户端的 TIME_WAIT 时间是 2msl 呢
首先 msl 是报文的最大生存时间如果超过 msl那么报文就会被丢弃
那么客户端等待 2msl 是因为客户端的 ACK 到达服务端最多花费 1msl而服务端重发 FIN 报文也最多花费 1msl因此如果客户端的 ACK 报文丢失最多 2msl 的时间就可以收到服务端重发的 FIN 报文
为什么要第四次挥手呢 其实很容易我们想一下如果没有通过第四次挥手对 server 发给 client 的 FIN 报文进行确认如果这个报文丢失的话客户端就不知道需要关闭连接了服务端也不知道报文丢失也不重发导致客户端一直认为连接处于打开状态
