TCP连接的三次握手和四次挥手

面试中常常问到的三次握手和四次挥手,整理于互联网。

TCP连接

特点:

  • 面向连接
  • 全双工
  • 保证可靠
  • 拥塞控制

建立连接:三次握手

三次握手(three times handshake;three-way handshake)所谓的“三次握手”即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步,根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系,并建立虚连接。

图示:

 

步骤:

第一次握手:

建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认; SYN:同步序列编号(Synchronize Sequence Numbers)

第二次握手:

服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),

即SYN+ACK包,表示接收到这个消息,此时服务器进入SYN_RECV状态;

第三次握手:
客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,
客户端和服务器进入ESTABLISHED状态,完成三次握手.
SYN:同步序列编号(Synchronize Sequence Numbers)。是TCP/IP建立连接时使用的握手信号。
ACK:ACK (Acknowledgement)即是确认字符,在数据通信中,接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。
ESTABLISHED:TCP连接成功

关闭连接四次挥手

图示:

步骤:

第一步,

当主机A的应用程序通知TCP数据已经发送完毕时,TCP向主机B发送一个带有FIN附加标记的报文段(FIN表示英文finish)。

第二步,

主机B收到这个FIN报文段之后,并不立即用FIN报文段回复主机A,而是先向主机A发送一个确认序号ACK,

同时通知自己相应的应用程序:对方要求关闭连接(先发送ACK的目的是为了防止在这段时间内,对方重传FIN报文段)。

第三步,

主机B的应用程序告诉TCP:我要彻底的关闭连接,TCP向主机A送一个FIN报文段。

第四步,

主机A收到这个FIN报文段后,向主机B发送一个ACK表示连接彻底释放。

值得注意的是:关闭请求也可以由服务端发出,或者两者同时发出

问题

  • 为什么建立连接是三次握手,而关闭连接却是四次挥手呢?

这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。

  • 为什么不是2次握手:防止失效的连接请求报文段突然又传送到主机B 

①A首先发送一个连接请求,但是该请求在网络节点上滞留了,没有收到确认。于是A重传了一次请求,并且收到了B的确认,于是连接建立,数据传输完成后,释放连接,假定A发出的第一个请求报文段并没有丢失,而是在某些网络节点上滞留,本来是一个失效的请求,但B收到后误认为是A再次发出一个新请求,于是向A发送确认,同意建立连接。

②假定采用两次握手,那么只要B发出确认,则新的连接就建立了。由于A并没有发出请求,因此不理会B的确认,也不会向B发送数据,但B却以为新的连接已经建立,并一直等待A的数据,B的许多资源就这样白白浪费了。

③假定采用三次握手,则B发出确认,但A因为并没有发请求,所以不理会B的确认,B没有收到A的确认,则连接建立失败,B知道连接建立失败。会回收资源。

④极端的情况可能由于Client用户端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待,因而造成极大的资源浪费!所以,“三次握手”很有必要。

 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值