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

计算机网络--TCP三次握手和四次挥手

时间:2018-09-09 18:09:46      阅读:174      评论:0      收藏:0      [点我收藏+]

标签:一个   png   item   为什么   面向   16px   通信协议   本地   image   

TCP(传输控制协议)

  TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。通过三次握手建立连接,通讯完成时要拆除连接,由于TCP是面向连接的所以只能用于端到端的通讯。TCP提供的是一种可靠的数据流服务,采用“带重传的肯定确认”技术来实现传输的可靠性。

  TCP报文首部格式:

技术分享图片

 

 

 

 

 

 

 

 

 

 

一、建立连接(三次握手)

  TCP连接建立过程:首先Client端发送连接请求报文,Server段接受连接后回复ACK报文,并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文,并分配资源,这样TCP连接就建立了。  

  置位概念:根据TCP的包头字段,存在3个重要的标识ACK、SYN、FIN

  • ACK:"acknowledge"确认标志"。
  • SYN:"synchronize"请求同步标志,位数置1,表示建立TCP连接。
  • FIN:"Finally"结束标志,位数置1,表示断开TCP连接。
  • seq:"sequance"序列号。
  • ack:"acknowledge"确认号。

技术分享图片

三次握手过程说明:
1、由客户端发送建立TCP连接的请求报文,其中报文中包含seq序列号,是由发送端随机生成的,并且将报文中的SYN字段置为1,表示需要建立TCP连接。(SYN=1,seq=x,x为随机生成数值)
2、由服务端回复客户端发送的TCP连接请求报文,其中包含seq序列号,是由回复端随机生成的,并且将SYN置为1,而且会产生ACK字段,ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP建立请求已得到验证。(SYN=1,ACK=x+1,seq=y,y为随机生成数值)这里的ack加1可以理解为是确认和谁建立连接。
3、客户端收到服务端发送的TCP建立验证请求后,会使自己的序列号加1表示,并且再次回复ACK验证请求,在服务端发过来的seq上加1进行回复。(SYN=1,ACK=y+1,seq=x+1)

  为什么要三次挥手?

  在只有两次“握手”的情形下,假设Client想跟Server建立连接,但是却因为中途连接请求的数据报丢失了,故Client端不得不重新发送一遍;这个时候Server端仅收到一个连接请求,因此可以正常的建立连接。但是,有时候Client端重新发送请求不是因为数据报丢失了,而是有可能数据传输过程因为网络并发量很大在某结点被阻塞了,这种情形下Server端将先后收到2次请求,并持续等待两个Client请求向他发送数据...问题就在这里,Cient端实际上只有一次请求,而Server端却有2个响应,极端的情况可能由于Client端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待,因而造成极大的资源浪费!所以,“三次握手”很有必要!

二、断开连接(四次挥手)

  TCP连接断开过程:假设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说"我Client端没有数据要发给你了",但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以你先发送ACK,"告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。当Server端确定数据已发送完成,则向Client端发送FIN报文,"告诉Client端,好了,我这边数据发完了,准备好关闭连接了"。Client端收到FIN报文后,"就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!

技术分享图片

四次挥手过程说明:
1、客户端发送断开TCP连接请求的报文,其中报文中包含seq序列号,是由发送端随机生成的,并且还将报文中的FIN字段置为1,表示需要断开TCP连接。(FIN=1,seq=x,x由客户端随机生成)

2、服务端会回复客户端发送的TCP断开请求报文,其包含seq序列号,是由回复端随机生成的,而且会产生ACK字段,ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP断开请求已经得到验证。(FIN=1,ACK=x+1,seq=y,y由服务端随机生成)
3、服务端在回复完客户端的TCP断开请求后,不会马上进行TCP连接的断开,服务端会先确保断开前,所有传输到A的数据是否已经传输完毕,一旦确认传输数据完毕,就会将回复报文的FIN字段置1,并且产生随机seq序列号。(FIN=1,ACK=x+1,seq=z,z由服务端随机生成)
4、客户端收到服务端的TCP断开请求后,会回复服务端的断开请求,包含随机生成的seq字段和ACK字段,ACK字段会在服务端的TCP断开请求的seq基础上加1,从而完成服务端请求的验证回复。(FIN=1,ACK=z+1,seq=h,h为客户端随机生成)
至此TCP断开的4次挥手过程完毕

  为什么要四次挥手?

  试想一下,假如现在你是客户端你想断开跟Server的所有连接该怎么做?第一步,你自己先停止向Server端发送数据,并等待Server的回复。但事情还没有完,虽然你自身不往Server发送数据了,但是因为你们之前已经建立好平等的连接了,所以此时他也有主动权向你发送数据;故Server端还得终止主动向你发送数据,并等待你的确认。其实,说白了就是保证双方的一个合约的完整执行!

三、TCP连接中的11种状态

      技术分享图片

1、一开始,建立连接之前服务器和客户端的状态都为CLOSED;
2、服务器创建socket后开始监听,变为LISTEN状态;
3、客户端请求建立连接,向服务器发送SYN报文,客户端的状态变味SYN_SENT;
4、服务器收到客户端的报文后向客户端发送ACK和SYN报文,此时服务器的状态变为SYN_RCVD;
5、然后,客户端收到ACK、SYN,就向服务器发送ACK,客户端状态变为ESTABLISHED;
6、服务器端收到客户端的ACK后变为ESTABLISHED。此时3次握手完成,连接建立!

      技术分享图片

由于TCP连接是全双工的,断开连接会比建立连接麻烦一点点。
1、客户端先向服务器发送FIN报文,请求断开连接,其状态变为FIN_WAIT1;
2、服务器收到FIN后向客户端发送ACK,服务器的状态围边CLOSE_WAIT;
3、客户端收到ACK后就进入FIN_WAIT2状态,此时连接已经断开了一半了。如果服务器还有数据要发送给客户端,就会继续发送;
4、直到发完数据,就会发送FIN报文,此时服务器进入LAST_ACK状态;
5、客户端收到服务器的FIN后,马上发送ACK给服务器,此时客户端进入TIME_WAIT状态;
6、再过了2MSL长的时间后进入CLOSED状态。服务器收到客户端的ACK就进入CLOSED状态。
至此,还有一个状态没有出来:CLOSING状态。
CLOSING状态表示:
客户端发送了FIN,但是没有收到服务器的ACK,却收到了服务器的FIN,这种情况发生在服务器发送的ACK丢包的时候,因为网络传输有时会有意外。

  • LISTEN:等待从任何远端TCP 和端口的连接请求。
  • SYN_SENT:发送完一个连接请求后等待一个匹配的连接请求。
  • SYN_RECEIVED:发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。
  • ESTABLISHED:表示一个打开的连接,接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。
  • FIN_WAIT_1:等待远端TCP 的连接终止请求,或者等待之前发送的连接终止请求的确认。
  • FIN_WAIT_2:等待远端TCP 的连接终止请求。
  • CLOSE_WAIT等待本地用户的连接终止请求
  • CLOSING等待远端TCP 的连接终止请求确认。
  • LAST_ACK:等待先前发送给远端TCP 的连接终止请求的确认(包括它字节的连接终止请求的确认)
  • TIME_WAIT:等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。
  • TIME_WAIT 两个存在的理由1.可靠的实现tcp全双工连接的终止;2.允许老的重复分节在网络中消逝。
  • CLOSED:不在连接状态(这是为了方便描述假想的状态,实际不存在)。

参考博客:http://blog.51cto.com/jinlong/2065461

计算机网络--TCP三次握手和四次挥手

标签:一个   png   item   为什么   面向   16px   通信协议   本地   image   

原文地址:https://www.cnblogs.com/tag6254/p/9614196.html

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