TCP的三次握手与四次挥手理解(官方与通俗)

 

TCP的三次握手

TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。

  (1)第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认。

  (2)第二次握手:服务器B收到SYN包,必须确认客户ASYNACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器B进入SYN_RECV状态。

  (3)第三次握手:客户端A收到服务器BSYNACK包,向服务器B发送确认包ACKACK=k+1),此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手。

   完成三次握手,客户端与服务器开始传送数据

 

TCP四次挥手关闭连接

由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。

这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
  TCP协议的连接是全双工连接,一个TCP连接存在双向的读写通道。 
  简单说来是先关读,后关写,一共需要四个阶段。以客户机发起关闭连接为例:
  1.服务器读通道关闭
  2.客户机写通道关闭
  3.客户机读通道关闭
  4.服务器写通道关闭
  关闭行为是在发起方数据发送完毕之后,给对方发出一个FINfinish)数据段。直到接收到对方发送的FIN,且对方收到了接收确认ACK之后,双方的数据通信完全结束,过程中每次接收都需要返回确认数据段ACK

 

TCP报文格式

        TCP/IP协议的详细信息参看《TCP/IP协议详解》三卷本。下面是TCP报文格式图:

http://blog.chinaunix.net/attachment/201304/7/22312037_1365321234nnNc.png
1 TCP报文格式

        上图中有几个字段需要重点介绍下:
        1)序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。
        2)确认序号:Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1
        3)标志位:共6个,即URGACKPSHRSTSYNFIN等,具体含义如下:
                AURG:紧急指针(urgent pointer)有效。
                BACK:确认序号有效。
                CPSH:接收方应该尽快将这个报文交给应用层。
                DRST:重置连接。
                ESYN:发起一个新连接。
                FFIN:释放一个连接。

        需要注意的是:
                A)不要将确认序号Ack与标志位中的ACK搞混了。
                B)确认方Ack=发起方Req+1,两端配对。 

 

 

 

 

 

 

 

 

 

 

 

 

 

三次握手


        所谓三次握手(Three-Way Handshake)即建立TCP连接,就是指建立一个TCP连接时,需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中,这一过程由客户端执行connect来触发,整个流程如下图所示:

http://blog.chinaunix.net/attachment/201304/8/22312037_1365405910EROI.png
2 TCP三次握手

 

1)第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给ServerClient进入SYN_SENT状态,等待Server确认。

2)第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYNACK都置为1ack=J+1,随机产生一个值seq=K,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。

3)第三次握手:Client收到确认后,检查ack是否为J+1ACK是否为1,如果正确则将标志位ACK置为1ack=K+1,并将该数据包发送给ServerServer检查ack是否为K+1ACK是否为1如果正确则连接建立成功,ClientServer进入ESTABLISHED状态,完成三次握手,随后ClientServer之间可以开始传输数据了。
        
        SYN
攻击:
                在三次握手过程中,Server发送SYN-ACK之后,收到ClientACK之前的TCP连接称为半连接(half-open connect),此时Server处于SYN_RCVD状态,当收到ACK后,Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server回复确认包,并等待Client的确认,由于源地址是不存在的,因此,Server需要不断重发直至超时,这些伪造的SYN包将产时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击,检测SYN攻击的方式非常简单,即当Server上有大量半连接状态且源IP地址是随机的,则可以断定遭到SYN攻击了,使用如下命令可以让之现行:
                #netstat -nap | grep SYN_RECV

 

 

四次挥手

三次握手耳熟能详,四次挥手估计就 ,所谓四次挥手(Four-Way Wavehand)即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发,整个流程如下图所示:

http://blog.chinaunix.net/attachment/201304/9/22312037_1365503104wDR0.png
3 TCP四次挥手

由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN来终止这一方向的连接,收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭,上图描述的即是如此。

(1)第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,

Client进入FIN_WAIT_1状态。

2)第二次挥手:Server收到FIN后,发送一个ACKClient,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。

3)第三次挥手:Server发送一个FIN,用来关闭ServerClient的数据传送,Server进入LAST_ACK状态。

(4)第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。
       

上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况,具体流程如下图:

http://blog.chinaunix.net/attachment/201304/10/22312037_13655617062cGr.png
4 同时挥手

        流程和状态在上图中已经很明了了,在此不再赘述,可以参考前面的四次挥手解析步骤。

 

 

 

 

通俗易懂解释TCP 三次握手

https://pic4.zhimg.com/80/v2-4295f6ab7be9507a8b387f75a61a9b20_hd.jpg

 

 

https://pic1.zhimg.com/80/v2-338707c5a7beb3ddd7755b82ea9a86c4_hd.jpg

https://pic3.zhimg.com/80/v2-64176963ea4f35b1dfd12079b913548e_hd.jpg

https://pic4.zhimg.com/80/v2-edc4088fef2da5cc8a7621a14c2439fe_hd.jpg

 

 

https://pic1.zhimg.com/80/v2-53230f10333f5824bd0a9c35843aced0_hd.jpg

https://pic2.zhimg.com/80/v2-b757a036a1f3da91514688fbf1e9bb1c_hd.jpg

 

 

https://pic4.zhimg.com/80/v2-5a6083ce16951a2ba7e5874d40681926_hd.jpg

https://pic3.zhimg.com/80/v2-c2986e38dcd83b98786c3f177364a159_hd.jpg

 

 

https://pic4.zhimg.com/80/v2-cc4470596e1c6b86b01211bda84ee81d_hd.jpg

三次握手:客户端和服务端都具备发送和接收消息的能力

  1. 乔哥:你说“喂喂喂,能听到我说话吗?”,是第一次握手,也就是说小萌你的发送消息的能力没有问题,
  2. 然后我回了你一句“小萌,我可以听到你说话,你能听到我说话吗?”这是第二次握手,我回了你一句,说明了我可以听到你说话(说明了我具有接受消息的能力),我对你说了你能听到我说话吗”也说明了我这里也有可以发送消息的能力。到第二次握手结束,说明了我具有发送消息和接受消息的能力,
  3. 小萌你具有发送消息的能力。然后你说“乔哥,我听到你说话了”,这是第三次握手,你听到我说话,也就是说明小萌你的接受消息的能力没有问题。

这样就可以进行通话了(建立了TCP连接)

 

 

https://pic4.zhimg.com/80/v2-ceac0099f5d06ae8d8e5877a302d9ced_hd.jpg

 

 

https://pic1.zhimg.com/80/v2-7d0c0bfd252490a88a0d5e83ce82064c_hd.jpg

 

https://pic1.zhimg.com/80/v2-4665d9ec3533e93406d8fa25aaff2f3b_hd.jpg

 

 

小萌:“喂,乔哥听得到吗?”

乔哥:“乔哥听得到呀,小萌你听得到乔哥吗?”

小萌:“小萌能听到乔哥,乔哥能听到小萌吗?”

https://pic1.zhimg.com/80/v2-8f8481aa1fe6ad408a7dfdd2cf3eeaa5_hd.jpg

 

 

https://pic2.zhimg.com/80/v2-38f64046319b61f62c783e87dbc2e637_hd.jpg

 

 

https://pic3.zhimg.com/80/v2-e84ba5c09f27d8f8fe67d2ed3edae69e_hd.jpg

 

https://pic4.zhimg.com/80/v2-2f199d685eb547e3cb34272605489682_hd.jpg

 

https://pic3.zhimg.com/80/v2-55b04f797cf7411a802f3c4b96205352_hd.jpg

 

小萌:

1.两次握手,这个我想是因为服务器收到了客户端的消息,服务器知道了客户端是可以发送消息的,但由于没有第三次握手,所以服务器不知道客户端是否具有接受消息的能力;

2.客户端从服务器接受到了消息,客户端知道了服务器接受到了我的消息才回复,说明服务器的接受消息能力和发送消息的能力没问题(服务器发送出了消息);

3.综上所述,客户端确保了服务器的接受发送没问题,但是服务器仅仅只知道客户端的发送消息没问题,这并不是可靠的,所以两次握手不可以。

 

https://pic1.zhimg.com/80/v2-94b50d1097583bb2797977e905d4aa1c_hd.jpg

 

https://pic3.zhimg.com/80/v2-6f4e15665b5a8310da374fb2db56b663_hd.jpg

 

乔戈里:这里举个例子,假设客户端和服务器进行TCP连接,然后第一次发送的TCP连接请求发生了阻塞。

 

https://pic2.zhimg.com/80/v2-d43d6cafadb19db8cd9562e2dfa54ac7_hd.jpg

 

于是由于客户端没有收到服务器的应答报文,客户端认为这个TCP连接请求丢失了,于是重新发送了TCP连接请求。这次没有阻塞,成功连接了,因为是讨论的两次握手,所以只进行两次连接就可以进行通信了。

 

https://pic2.zhimg.com/80/v2-beaa85eb1aaacc4b25021268307929fb_hd.jpg

 

通信结束,然后就断开了连接。

 

https://pic2.zhimg.com/80/v2-428891a83eb547d902c12e37652ea12c_hd.jpg

 

这时候最开始的阻塞的连接请求A客户端以为丢失了,但是没有丢失,只是阻塞了而已,阻塞一段时间网络又畅通了,于是TCP连接请求A成功到达了服务器,服务器又以为是客户端又要进行数据传输,于是服务器就又对这个连接请求进行应答,两次握手,于是又成功建立了TCP连接。

https://pic1.zhimg.com/80/v2-4edf650822ef74232a7994d64c83eff7_hd.jpg

 

但是由于客户端它以为这个连接请求已经丢失了,所以不会利用这个建立的连接请求进行数据通信,虽然服务器分配给了资源给客户端,但是客户端并不进行数据传输,这样就白白浪费了服务器的资源,试想一下如果网络很拥堵,那么等网络变畅通以后,服务器岂不是浪费了一堆资源,可能对于正常的连接请求都无法处理了!

https://pic2.zhimg.com/80/v2-dd2e66486c9064d1ddc4aefbc520e3cd_hd.jpg

 

 

https://pic1.zhimg.com/80/v2-472c44e57338e78dc896eef632a0cc5c_hd.jpg

服务器过了很长时间(规定好的时间和客户端)都没有收到回复,于是也不会为客户端分配资源,这次连接就放弃了。

 

 

 

 

 

 

发布了37 篇原创文章 · 获赞 124 · 访问量 14万+

猜你喜欢

转载自blog.csdn.net/zam183/article/details/103766881
今日推荐