前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >TCP 三次握手

TCP 三次握手

原创
作者头像
软件UP
修改2021-05-25 14:28:58
7220
修改2021-05-25 14:28:58
举报

前言

TCP 协议在传世数据的时候,客户端(Client)和服务端(Server)会建立连接,然后把需要传输的文件进行分段,以及提供可靠的传输和流量控制!在数据传输完成后,当前的会话也要断开连接,避免资源浪费。所有 TCP 的三次握手就是建立连接的过程,而四次挥手是断开连接的过程!

TCP 基本认识

传输控制协议(英语:Transmission Control Protocol,缩写:TCP)是一种面向连接的、可靠的、基于字节流的传输层通信协议

TCP 头格式

  • 序列号:在建立连接时由计算机生成的随机数作为初始值,通过 SYN 包传给接收端主机,每发送一次,就累加一次该字节数大小。用来解决网络包乱序问题
  • 确认应答信号:指下一次 [期望] 收到的数据的序列号,发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决不丢包的问题
  • 控制位

ACK:该位为 1 时,确定应答字段变为有效,TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置位 1

RST:该位为 1 时,表示 TCP 连接时出现异常必须强制断开连接

SYN:该位为 1 时,表示希望建立连接,并在其序列号的字段进行序列号初始值的设定

FIN:该位为 1 时,表示今后不会再有数据发送,希望断开连接。当通信结束希望断开连接时,通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

三次握手

  • 第一次握手:建立连接时,客户端 A 发送 SYN 包 (SEQ_NUMBER=x) 到服务器 B,并进入 SYN_SEND 状态,等待服务器 B 确认。
  • 第二次握手:服务器 B 收到 SYN 包,必须确认客户 A 的 SYN(ACK_NUMBER=x+1),同时自己也发送一个 SYN 包 (SEQ_NUMBER=y),即 SYN+ACK 包,此时服务器 B 进入 SYN_RECV 状态。
  • 第三次握手:客户端 A 收到服务器 B 的 SYN+ACK 包,向服务器 B 发送确认包 ACK(ACK_NUMBER=y+1),此包发送完毕,客户端 A 和服务器 B 进入 ESTABLISHED 状态,完成三次握手。
  • 完成三次握手,客户端与服务器开始传送数据。

四次挥手

  • 第一次挥手:客户端打算关闭连接,此时会发送一个 TCP 首部 FIN 标志位设置为 1,其序列号为前面已经传送过来的数据的最后一个字节的序号加 1(seq=x)
  • 第二次挥手:客户端收到报文后,就向客户端发送 ACK 应答报文,ACK=1,ack=x+1,并且带上自己的序列号 seq=y,此时,服务端就进入了 CLOSE-WAIT(关闭等待)状态。
  • 客户端收到服务器的确认请求后,此时,客户端就进入 FIN-WAIT-2(终止等待 2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
  • 第三次挥手:服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=x+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为 seq=z,此时,服务器就进入了 LAST-ACK(最后确认)状态,等待客户端的确认。
  • 第四次挥手:客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=z+1,而自己的序列号是 seq=h,此时,客户端就进入了 TIME-WAIT(时间等待)状态。注意此时 TCP 连接还没有释放,必须经过最长报文段寿命的时间后,当客户端撤销相应的 TCB 后,才进入 CLOSED 状态。
  • 服务器只要收到了客户端发出的确认,立即进入 CLOSED 状态。同样,撤销 TCB 后,就结束了这次的 TCP 连接。可以看到,服务器结束 TCP 连接的时间要比客户端早一些。

为什么不能使用两次握手进行连接?

答:三次握手完成两个重要的功能,既要双方做好发送数据的准备工作,也要知道双方都知道彼此已准备好!如果改为两次握手会导致死锁的问题。假定客户端给服务端发送一个连接请求,服务端收到了这个分组,并发送了确认应答分组。按照两次握手的协定,服务端认为连接已经成功地建立了,可以开始发送数据分组。可是,服务端的应答信号在传输中被丢失的情况下,客户端还不知道服务端是否已准备好,不知道服务端将建立什么样的序列号,客户端甚至怀疑服务端是否收到自己的连接请求分组。在这种情况下,客户端认为连接还未建立成功,将忽略服务器发来的任何数据分组,只等待连接确认应答分组。而服务端在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

四次挥手中的第二、三次合并起来会发生什么?

答:因为服务器收到客户端断开连接的请求时,可能还有一些数据没有发完,这时先回复 ACK,表示接收到了断开连接的请求。等到数据发完之后再发 FIN,断开服务器到客户端的数据传送。

只有等到服务端所有的报文都发送完了,才能发送 FIN 报文,因此不能一起发送。故需要四次挥手。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
作者已关闭评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • TCP 基本认识
  • 三次握手
  • 四次挥手
  • 为什么不能使用两次握手进行连接?
  • 四次挥手中的第二、三次合并起来会发生什么?
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档