码迷,mamicode.com
首页 > 其他好文 > 详细

TCP三次握手、四次握手

时间:2018-04-25 22:13:24      阅读:201      评论:0      收藏:0      [点我收藏+]

标签:rfc   timer   tab   模块   ima   错误   失效   技术分享   地址   

 前言

  TCP用于应用程序之间的通信。当应用程序希望通过TCP与另一个应用程序通信时,它会发送一个通信请求。这个请求必须被送到一个确切的地址。在双方“握手”之后,TCP将在两个应用程序之间建立一个全双工的通信 。这个全双工的的通信将占用两个计算机之间的通信线路,直到它被一方或双方关闭为止 。

由于TCP提供的是一种面向连接的、可靠的字节流服务。

  所以本文讲解连接建立时的“三次握手”、连接释放时的“四次握手”。

一、TCP的运输连接管理

1、TCP的连接建立(三次握手)

技术分享图片

  上图画出了TCP的建立连接过程。假定主机A运行的是TCP客户程序,而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED(关闭)状态。图中在主机下面的方框分别是TCP进程所处的状态。请注意,A主动打开连接,而B被动打开连接。

  B的TCP服务器进程先创建传输控制块TCB(存储了每一个连接中的一些重要信息,如:TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前的发送和接收序号,等等),准备接受客户进程的连接请求。然后服务器进程就处于LISTEN(收听)状态,等待客户的连接请求。如有,即作出响应。

  A的TCP客户进程也是首先创建传输控制模块TCB,然后向B发出连接请求报文段,这时首部中的同步位SYN=1,同时选择一个初始序号seq=x。TCP规定,SYN报文段(即SYN=1的报文段)不能携带数据,但要消耗掉一个序号。这时,TCP客户进程进入SYN-SENT(同步已发送)状态。

  B收到连接请求报文段后,如同意建立连接,则向A发送确认。在确认报文段中应把SYN位和ACK位都置1,确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。请注意,这个报文段也不能写到数据,但同样要消耗掉一个序号。这时TCP服务器进程进入SYN-RCVD(同步收到)状态。

  TCP客户进程收到B的确认后,还要向B给出确认。确认报文段的ACK置1,确认号ack=y+1,而自己的序号seq=x+1,TCP的标准规定,ACK报文段可以携带数据。但如果不携带数据则不消耗序号,在这种情况下,下一个数据报文段的序号仍是seq=x+1。这时,TCP连接已经建立,A进入ESTABLISHED状态。

  当B收到A的确认后,也进入ESTABLISHED状态。

  上面给出的连接建立过程叫做三次握手。

  为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B,因而产生错误。

  所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求,但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接。A共发送了两个连接请求报文段,其中第一个丢失,第二个到达了B。没有“已失效的连接请求报文段”。

  现假定出现一种异常情况,即A发出的第一个连接请求报文段并没有丢失,而是在某些网络结点长时间滞留了,以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B受到此失效的连接请求报文段后,就误认为A又发出一次新的连接请求。于是就向A发出确认报文段,同意建立连接。假定不采用三次握手,那么只要B发出确认,新的连接就建立了。

  由于现在A并没有发出建立连接的请求,以你次不会理睬B的确认,也不会向B的确认发出确认。B由于收不到确认,就知道A并没有要求建立连接。

2、TCP的连接释放(四次握手)

  技术分享图片

  数据传输结束后,通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态。A的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置1,其序号seq=u,它等于前面已传送过得数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1(终止等待1)状态,等待B的确认。请注意。TCP规定,FIN报文段即使不携带数据,它也消耗掉一个序号。

  B收到连接释放报文段后即发出确认,确认号是ack=u+1,而这个报文段自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号加1.然后B就进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程,因而从A到B这个方向的连接就释放了,这时的TCP连接处于半关闭状态,即A已经没有数据要发送了,但B若发送数据,A仍要接收。也就是说,从B到A这个方向的连接并未关闭,这个状态可能会持续一些时间。

  A收到来自B的确认后,就进入GIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段。

  若B已经没有要向A发送的数据,其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1.现假定B的序号为w(在瓣关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过得确认号ack=u+1.这时B就进入LAST-ACK(最后确认)状态,等待A的确认。

  A在收到B的连接释放报文段后,必须对此发出确认。在确认报文段中把ACK置1,确认号ack=w+1.而自己的序号是seq=u+1。然后进入到TIME-WAIT(时间等待)状态。请注意,现在TCP连接还没有释放掉。必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后(原因为了使B按照正常步骤进入CLOSED、也为了出现已失效的连接请求报文段),A才进入到CLOSED状态。时间MSL叫做最长报文段寿命,RFC793建议设为2分钟。一次。从A进入到TIME-WAIT状态后,要经过4分钟才能进入到CLOSED状态,才能建立下一个新的连接。当A撤销相应的传输控制块TCB后,就结束了这次的TCP连接。

  B只要收到了A发出的确认,就进入CLOSED状态。同样,B在撤销相应的传输控制块TCB后,就结束了这次的TCP连接,我们注意到,B结束TCP连接的时间要比A早一些。

  本文参考谢希仁编著的《计算机网络》

TCP三次握手、四次握手

标签:rfc   timer   tab   模块   ima   错误   失效   技术分享   地址   

原文地址:https://www.cnblogs.com/sxkgeek/p/8947266.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!