网站怎样制作图文排版,51星变网页游戏官网,互联网营销工具,官方网站建设的必要三次握手 与 四次挥手 1. 三次握手2. 四次挥手三次握手和四次挥手的区别 在正常情况下#xff0c;TCP 要经过三次握手建立连接#xff0c;四次挥手断开连接 1. 三次握手 服务端状态转化#xff1a;
[CLOSED - LISTEN] 服务器端调用 listen 后进入 LISTEN 状态#xff… 三次握手 与 四次挥手 1. 三次握手2. 四次挥手三次握手和四次挥手的区别 在正常情况下TCP 要经过三次握手建立连接四次挥手断开连接 1. 三次握手 服务端状态转化
[CLOSED - LISTEN] 服务器端调用 listen 后进入 LISTEN 状态等待客户端连接[LISTEN - SYN_RCVD] 一旦监听到连接请求同步报文段 SYN就将该连接放入内核等待队列中并向客户端发送 SYN ACK 确认报文。[SYN_RCVD - ESTABLISHED] 服务端一旦收到客户端的确认报文 ACK就进入 ESTABLISHED 状态可以进行读写数据了。
客户端状态转化
[CLOSED - SYN_SENT] 客户端调用 connect发送同步报文段 SYN[SYN_SENT - ESTABLISHED] connect 调用成功收到服务器的 SYN ACK 报文段则进入 ESTABLISHED 状态开始读写数据
三次握手有啥用 ? 和可靠性有什么关系 ?
三次握手相当于 “投石问路”, 检查一下当前这个网络的情况是否满足可靠传输的条件。 如果网络本身效果比较差强行进行 TCP 传输也会涉及到大量的数据丢包更具体的说三次握手是在检测通信双方的发送能力和接收能力是否都正常。让通信双方能协商一些必要的信息TCP 通信过程中需要客户端和服务器之间有一些共同的信息在三次握手过程中相互之间可以交互一些必要的内容。
举个栗子 以打电话为例 这个过程就是在检验通信双方的发送能力和接收能力 假如说小明麦克风坏了喂了几次没回应就会重传重试几次还没回应就放弃。
为啥是三次握手两次行不行 四次行不行
四次行但是没必要分开传输不如合在一起效率高。两次 不行两次意味着缺少最后一次由上面的两张图就可以知道两次的话此时客户端知道双方的发送和接收能力都是正常的但是服务器这边是残缺的不知道自己的发送能力和客户端的接收能力是否 OK此时服务器对于当下能否满足可靠传输心里没底这第三次交互就是为了给服务器吃一个定心丸。
2. 四次挥手 服务端状态转化
[ESTABLISHED - CLOSE_WAIT] 当客户端主动关闭连接调用 close服务器会收到结束报文段 FIN 服务器返回确认报文段 ACK 并进入 CLOSE_WAIT[CLOSE_WAIT - LAST_ACK] 进入 CLOSE_WAIT 后说明服务器准备关闭连接需要处理完之前的数据当服务器真正调用 close (用户代码中执行了 socket.close) 关闭连接时会向客户端发送 FIN此时服务器进入 LAST_ACK 状态等待最后一个 ACK 到来这个 ACK 是客户端确认收到了 FIN [LAST_ACK - CLOSED] 服务器收到了对 FIN 的 ACK彻底关闭连接。
客户端状态转化
[ESTABLISHED - FIN_WAIT_1] 客户端主动调用 close 时向服务器发送结束报文段同时进入 FIN_WAIT_1[FIN_WAIT_1 - FIN_WAIT_2] 客户端收到服务器对结束报文段的确认 ACK则进入 FIN_WAIT_2开始等待服务器的结束报文段[FIN_WAIT_2 - TIME_WAIT] 客户端收到服务器发来的结束报文段 FIN进入 TIME_WAIT并发出 LAST_ACK[TIME_WAIT - CLOSED] 客户端要等待一个 2MSLMax Segment Life报文最大生存时间的时间才会进入 CLOSED 状态。
为什么还要 TIME_WAIT 为的是给最后一次 ACK 提供重传机会表面上 A 发送完 ACK 后就没有 A 的事了按理说 A 可以销毁连接了但是怕最后一个 ACK 丢包若最后一个 ACK 丢了那么 B 一定会因为没收到 ACK 重传 FIN如果 A 已经销毁连接了那么就无人能够处理这个 FIN 了,因此 A 不应该释放的太早要等待一段时间确保 B 不会重传 FIN 后再真正的销毁连接。
为什么是TIME_WAIT的时间是2MSL
MSL 是 TCP 报文的最大生存时间因此 TIME_WAIT 持续存在 2MSL 的话 就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失 否则立刻客户端立即重新创建连接时可能会收到来自上一个进程的迟到的数据FIN但是这种数据很可能是错误的 同时也是在理论上保证最后一个报文可靠到达 假设最后一个ACK丢失那么服务器会再重发一个FIN。这时虽然客户端的进程不在了但是 TCP 连接还在仍然可以重发 LAST_ACK CLOSE_WAIT 一般而言对于服务器上出现大量的 CLOSE_WAIT 状态原因就是服务器没有正确的关闭 socket没有执行到 socket.close 导致四次挥手没有正确完成。这是一个 BUG。只需要加上对应的 close 即可解决问题。
三次握手和四次挥手的区别 三次握手一定是客户端发起的主动发起请求的一方叫做客户端 四次握手可能是客户端发起的也有可能是服务器主动发起的 三次握手中间有两次合并和 四次握手中间两次合并不了不能合并的原因在于 B 被动接收 FIN 的那一方发送 ACK 和 FIN 的时机不同 1 四次挥手中B 发送给 A 的 ACK 是由操作系统内核负责的除了应用层TCP/IP … 本身就是属于操作系统层面那么意味着当内核收到 FIN 后会立即返回 ACK 我们是感知不到的 2 B 发送给 A 的 FIN是由用户代码负责的B 中代码调用了 socket.close() 方法时才触发 FIN 发送所以要等到用户代码执行到 socket.close() 方法才触发但是什么时候发送 取决于用户代码若 1 2 操作之间的时间差较大就不能合并了若时间差较小由于 延时应带和捎带应答 机制可能会合并。 而三次握手中 B 发送的 ACK 和 SYN 都是由内核负责的是同一时机所以能够合并。
好啦 以上就是对 TCP 三次握手 与 四次挥手的讲解希望能帮到你 评论区欢迎指正 !
