详解TCP三次握手和四次挥手

TCP,即传输控制协议(Transmission Control Protocol),是一种面向连接的、可靠的、基于字节流的运输层协议是专门为了在不可靠的互联网络上提供一个可靠的端到端字节流而设计的。每一次TCP连接都需要三个阶段:连接建立、数据传送和连接释放。“三次握手”就发生在连接建立阶段。

一、TCP报文

TCP报文格式图:
详解TCP三次握手和四次挥手_第1张图片
上图中有几个字段需要重点介绍下:
 序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。
 确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。
 确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
 同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。
 终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接。
 PS:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。
标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:
  • URG:紧急指针(urgent pointer)有效。
  • ACK:确认序号有效。
  • PSH:接收方应该尽快将这个报文交给应用层。
  • RST:重置连接。
  • SYN:发起一个新连接。
  • FIN:释放一个连接。
需要注意的是:
(A)不要将确认序号ack与标志位中的ACK搞混了。
(B)确认方ack=发起方seq+1,两端配对。 

参考链接: 

https://blog.csdn.net/chenlycly/article/details/51657413

https://blog.csdn.net/guyuealian/article/details/52535294

二、三次握手建立TCP连接

发送端首先发送一个带SYN标志的数据包给对方,接收端收到后回传一个带有SYN/ACK标志的数据包以示传达确认消息。最后,发送端再回传一个带ACK标志的数据包,代表“握手”结束。
 (1)第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。
 (2)第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=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之间可以开始传输数据了。
详解TCP三次握手和四次挥手_第2张图片

为什么需要第三次握手?

还要再发送一次确认是为了,防止已失效的连接请求报文段突然又传到了Server,因而产生错误。
  已失效的报文段:正常情况下:Client发出连接请求,但因为丢失了,故而不能收到Server的确认。于是Client重新发出请求,然后收到确认,建立连接,数据传输完毕后,释放连接,Client发了2个,一个丢掉,一个到达,没有“已失效的报文段”
  但是,某种情况下,Client的第一个在某个节点滞留了,延误到达,本来这是一个早已失效的报文段,但是在Client发送第二个,并且得到Server的回应,建立了连接以后,这个报文段竟然到达了,于是Server就认为,Client又发送了一个新的请求,于是发送确认报文段,同意建立连接,假若没有三次的握手,那么这个连接就建立起来了(有一个请求和一个回应),此时,Client收到Server的确认,但Client知道自己并没有发送建立连接的请求,因为不会理睬Server的这个确认,于是呢,Client也不会发送任何数据,而Server呢却以为新的连接建立了起来,一直等待Client发送数据给自己,此时Server的资源就被白白浪费了。但是采用三次握手的话,Client就不发送确认,那么Server由于收不到确认,也就知道并没有要求建立连接。
  简而言之:第三次握手,Client发送一次确认是为了防止:如果客户端迟迟没有收到服务器返回的确认报文,这时他会放弃连接,重新启动一条连接请求;但问题是:服务器不知客户端没收到,所以他会收到两个连接请求,白白浪费了一条连接开销。

类比三次握手

用打电话类比的话就是: 
小明拨打小红的电话 
小红按下通话键并说了声,喂 (一次握手) 
小明听到小红的回应,也说了声,喂 (二次握手) 
小红接收到小明的回应 (三次握手)

三、四次挥手断开TCP连接

由于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三次握手和四次挥手_第3张图片

为什么TCP释放连接需要四次?

TCP建立连接要进行三次握手,而断开连接要进行四次。这是由于TCP的半关闭造成的。因为TCP连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务,就发送一个FIN来向另一方通告将要终止这个方向的连接。

注意:

发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送),但是还可以接收数据。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据,比如:如主机A收到主机B的FIN断开TCP连接请求,只是表示主机B已经发送完数据,主机A收到FIN后作出应答,并终止这个方向的数据传输,此时处于半关闭状态。但是主机A仍然可以发送数据的,只有当主机A发送完数据并发送FIN给主机B时,主机B才停止这个方向的数据传输,并关闭TCP连接。

类比四次挥手:

还是用小明和小红打电话来类比, 
小明:我这没事儿了,你还有事儿吗? (1次挥手) 
小红:我也没事儿了,你确定没事儿了吗? (2次挥手) 
小红:我要挂电话了。 (3次挥手) 
小明:好吧,你挂吧。 (4次挥手)

参考链接:

https://blog.csdn.net/guyuealian/article/details/52535294

https://blog.csdn.net/sssnmnmjmf/article/details/68486261

https://blog.csdn.net/htyurencaotang/article/details/11569905

你可能感兴趣的:(网络基础)