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

TCP三次握手和四次挥手

时间:2018-11-06 00:59:14      阅读:256      评论:0      收藏:0      [点我收藏+]

标签:可靠   参考   ima   prot   挥手   定时   超时重传   recv   还需要   

TCP报文格式

 TCP报文格式图:

技术分享图片 

  上图中有几个字段需要重点介绍下:

  (1)序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。

  (2)确认序号:Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1。

  (3)标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:

  (A)URG:紧急指针(urgent pointer)有效。

  (B)ACK:确认序号有效。

  (C)PSH:接收方应该尽快将这个报文交给应用层。

  (D)RST:重置连接。

  (E)SYN:发起一个新连接。

  (F)FIN:释放一个连接。

 需要注意的是:

  (A)不要将确认序号Ack与标志位中的ACK搞混了。

  (B)确认方Ack=发起方Req+1,两端配对。 

TCP三次握手

TCP(Transmission Control Protocol) 传输控制协议

TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接

位码即tcp标志位,有6种标示:

1)SYN(synchronous建立联机)

2)ACK(acknowledgement 确认)

3)PSH(push传送)

4)FIN(finish结束)

5)RST(reset重置)

6)URG(urgent紧急)

 

Sequence number(顺序号码)

Acknowledge number(确认号码) 

establish  建立,创建

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


技术分享图片
 

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

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

  (3)第三次握手:Client收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给Server,Server检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以开始传输数据了。

技术分享图片

  SYN攻击:

  在三次握手过程中,Server发送SYN-ACK之后,收到Client的ACK之前的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

容易理解的小故事

网络帝国的崛起

随着时间的流逝,计算机帝国的子民耐不住寂寞,他们好想去外面的世界看看,去其他的计算机家中串串门,他们经常抱怨,为什么那些官员可以互相聊天,而我们只能自己对自己说话.

这些抱怨传到了计算机国王的耳中,国王也很头痛啊,他也想让子民相互沟通,畅聊无阻,可是不同计算机运行着不同的操作系统,他们在表达同一种信息的时候采用的方式千差万别,很难统一啊,官员们也是费了好大劲才把那么几个操作系统的通信搞定,更何谈万千子民了.

这一次,国王召开会议与大臣一起讨论这个问题,最终一致认为成立网络专研小组,专门研究此问题

TCP/IP 家族的诞生

成立专家组之后,专家立即开始讨论如何使不同计算机建立通信,通过大量的考察不同的操作系统,专家们历经千辛万苦最终制定了统一标准——TCP/IP 协议族(注意:TCP/IP不是一个协议,而是一系列协议的总和),这个家族里包含了许多协议,比如常见的TCP协议,UDP协议

一次奇异的聊天

专家组把协议给国王看了看,国王非常高兴,马上派人把TCP/IP协议族中的所有协议分发给万千子民并给每一位子民拉了一根网线,子民们收到也非常高兴,各自研究其协议了

上官天宇和司马剑就是其中两位(下称上官和司马),数天后,在得知上官的地址(对应IP和端口)后,司马决定用可靠传输的TCP和上官进行通信,因为他不想在第一次聊条中漏掉任何文字

可是这个TCP有几个比较讨厌的就是聊天之前要做很多准备工作,有两步(真实的有三步,这里是为了体现两次握手的缺陷)
第一步: 他要发送一条建立连接的消息告诉对方咱两要通信了
第二步: 对方收到这个消息后,要回复他一个确认消息
上面两步(两次握手)做完了,两人才能够通信

于是,司马通过遵守TCP协议给上官天宇发了个”你好”,过了一会儿,他见上官没给他发确认消息
于是他就按照TCP的超时重传机制[简单的说就是在一定的时间后,如果对方没有回应,就认为这个消息发送失败,要重新发送],然后司马就重新发了一个消息给上官了

过了一小会,上官发来了确认消息,里面写着:“我收到了”(这个时候两次握手已经完成,两个人可以进行聊天了)
然后上官也给司马发了一个“你好”,相互聊了几句,就关闭了连接(四次挥手在下篇说)

殊不知过了一会,司马又收到聊了上官的确认消息,司马心中很纳闷,我没给他再发消息啊?喜欢探究原因的他把这个事情上报给TCP/IP的酋长了

设计上的缺陷

酋长带着问题来到了宫廷,见了专家组,专家组也很纳闷,想了许久,一个资深的元老突然说道,我们的设计可能有问题,现在我们的TCP是两次连接后就可以进行通信了,现在有这么一种情况,当A发送一个消息给B,这个消息由于网络的原因,阻塞在某个节点了,如下图

 技术分享图片

然后阻塞的时间很长,超出了咱们设定超时重发时间,那么A就会认为这个消息丢失了,然后重新发送

当A和B通信完成后,这个之前被A认为”失效的消息“到达了B,而对于B而言,以为这是一个新的请求连接消息,就向A发了一次确认(这就可以解释司马有收到了一次的确认消息了),而对于A而言,他认为他没有给B再次的发消息(因为上次的通话已经结束了),所以A不会理睬这条确认,但是B则会一直在傻傻的等待着A的消息

这就导致了B的时间被白白浪费(对于服务器而言,就是CPU等资源的一种浪费),这样是万万不可的,这就是为什么不能两次握手的原因

最终的修订

专家组的人一致赞同这个观点,然后几个人还做了几个实验,结论是确实是这个原因导致的,最后专家组坐在一块讨论如何修改这个TCP协议,元老发话了,其实修改也很简单,再加一次通信(握手)就行了,如下图

技术分享图片

就是说A最后还要给B发一个确认,还是上次的那个例子,如果A不给B发第三次确认消息,那么B就认为A并没给他发消息,B也就不会在那里傻傻的等待了。最后酋长带着答案和修改草稿回到了部落。

 

TCP四次挥手

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

技术分享图片

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

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

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

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

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

技术分享图片
 

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

技术分享图片

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

容易理解的小故事

酋长从宫中回来不久,国王就颁布了新的TCP协议法案,这次修正版的TCP协议运行的很好,举国上下一片喜悦

从小白到菜鸟的转变

经过上次的聊天后,司马和上官成为了好朋友,今天,司马又给上官发消息了,但是这次,两人建立连接后,同时给对方发送了一个报文“在吗?”,导致过了一会,司马和上官都收到对方的“在吗?”如下图:

 技术分享图片

在聊天完后,好学的司马又去请教酋长去了,酋长说,TCP是允许你们同时给对方发消息的,这种特性有一个专业名字叫做“全双工”,“哦,原来是这样”,“司马恍然大悟。原来TCP里面的门道挺多”,下来得好好学习学习,司马心中暗自说道

一次断开连接的历程

司马又找好哥们上官聊天了,与往常一样,建立连接,聊完天后,断开连接。这次司马特别有心,用了一个小本子记录下这次TCP断开连接的过程。

① 刚开始,司马发了一个“连接释放报文段”表示自己不再发送聊天消息了
② 然后上官接到这个“连接释放报文段”后给司马发出一个“确认报文段”,表示自己收到了

这时候,司马到上官方向的连接断了,即:司马没有消息给上官发了,但是上官到司马这个方向的连接还没有断,所以上官还可以给司马发送消息,他可能还有些话没说完。如下图:

 技术分享图片


1>上官这时候如果没有啥消息给司马发了,那他也会发送一个“连接释放报文段”给司马,表明他想断开连接(上官到司马方向的连接)
2>上官这时候如果还有消息想给司马发,那就按照往常一样把消息从他这边发给司马(因为从上官到司马这个方向的连接还没有断),等到发送完成后,然后再发送”连接释放报文段”

④ 司马收到这个报文后,也会给上官发送一个”确认报文段“以表明自己自己收到这个报文

⑤ 但是这个时候司马还不能撒手不管,他还需等待一段时间才可以进入到“CLOSED”(关闭)状态,表明自己的这次连接已经关闭了。可以接受下次连接了。

⑥ 当上官收司马的确认后,自己也进入“CLOSED”状态

完整的TCP四次挥手如下图:

 技术分享图片

司马心中的疑惑

司马下来看了看小本子,心中产生了一个疑惑,为什么我最后一次给上官发送确认,我还需要等一段时间,我不想等这么长时间,多麻烦。

他找酋长去诉苦去了,酋长说:“你等待这么长时间是有非常有必要的,你想啊,咱们TCP是不是规定了发出去的“请求报文(可能是请求连接,也有可能是请求关闭)”需要得到对方的确认,如果超过一定时间得不到确认会进行超时重传

如果说你给上官发送的那个确认如果在中途丢失了,上官迟迟等不到你的确认,他肯定会执行超时重传给你重新发一个请求关闭连接的报文的,如果你不等待这么长时间而直接进入关闭状态,是不是就接收不到这个重传的报文了?那上官是不是就收不到你的确认,进而上官就不能正常关闭了?如下图:

 技术分享图片

所以说,你在等的这段时间,其实是要确保你的确认让对方收到,如果对方超时重传一个连接释放报文段,这个时候你还没有关闭,那你就可以重新发一个确认给他呀”

“哦,原来是这样呀”,司马心中的怨气立马就消失了。

从此计算机帝国走向了互联网的时代

 

思考:

  (1)三次握手是什么或者流程?四次握手呢?

自己往上翻~

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

解释1、由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。 

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

 

注:参考来自以下,感谢

地址1:https://blog.csdn.net/Mark2When/article/details/54956559

地址2:https://blog.csdn.net/qq_30137611/article/details/77941313

TCP三次握手和四次挥手

标签:可靠   参考   ima   prot   挥手   定时   超时重传   recv   还需要   

原文地址:https://www.cnblogs.com/it-taosir/p/9912397.html

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