最通俗易懂的三次握手、四次挥手理解

三次握手

在了解TCP连接之前先来了解一下TCP报文的几个标志符号（大致过一遍就可以！）：

上图中有几个字段需要重点介绍下：
（1）序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（简单说就是客户端和服务器端各自发起时用来计数的！）

（2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
（这个就是接收方收到信号后确认用的，它的序号和发起序号有关的！接收到信号之后，先把ACK置1，才能产生小写的ack。不要将确认序号ack与标志位中的ACK搞混了。）

（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，
具体含义如下：

ACK：确认序号有效。
FIN：释放一个连接。
SYN：发起一个新连接。

PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
URG：紧急指针（urgent pointer）有效。

具体过程看下面这张图：
含义一个个说：
SYN：发起新链接，看图，一般就刚开始一端出现一个，后面只要不产生新的连接就不会再有了。
seq:他等于x是因为它的起始序列是随机的。但是再往后的客户方的起始序列都在它的基础上+1。服务器端的起始序列同理。
注意他俩的起始序列是两个不同的数值概念。
ACK：收到就标志为1，然后就把小写的ack确认序号根据发起方的序列号确定下来。

不论发送接收都要考虑这次行动的序列号seq。
如果是新发起的记得标志位SYN。
有应答的时候记得把ACK和ack都写上。
记住上面三点，基本没啥问题了。

从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题。

为什么客户端和服务端的初始序列号 ISN 是不相同的？

因为网络中的报文会延迟、会复制重发、也有可能丢失，这样会造成的不同连接之间产生互相影响，所以为了避免互相影响，客户端和服务端的初始序列号是随机且不同的。

为什么是三次握手不是两次？
解：
因为客户端和服务端，这两端都需要确定对方的收发能力都是可以的！

客户端 --------------------------- 服务端
客发----------------------------客发、服接 （第一次）
客接、服发、服接------------- 服发 （第二次）
客接 （第三次）

仔细看我上面的简易列表，分别代表每一次握手客户端和服务端对双方收发能力的了解程度。
第一次客户端发送，那么客户端就知道了客户端的发送是好的，服务端收到发送，就知道了客户端的发送是好的，自己的接收是好的；然后第二次服务端返回信息，服务端就知道自己发送是好的，客户端收到信息就知道自己的接收是好的，服务端的发送是好的，同时自己上次发的信息返回来了，说明也知道了服务端的接收是好的。
重点来了！服务端还不知道客户端的接收怎么样啊！怎么办？客户端再发一次！

所以就诞生了著名的三次握手！

主要原因：

三次握手才可以阻止历史重复连接的初始化（主要原因）
三次握手才可以同步双方的初始序列号
三次握手才可以避免资源浪费

1.当客户端发起SYN链接时，过去因为网路阻塞发起的旧的链接可能先于新的链接到达服务器端，服务器端会根据旧的链接返回一个旧的ack应答。通过第三次握手，客户端发现该应答不是最新，就会发出RST报文给服务器，表示中止链接。如果没有第三次握手，便无法与客户端最新请求生成链接。
2.根据上图，客户端发起链接会有一个序列号，服务器会根据该序列号生成ack应答；同时服务器也产生一个序列号，要求客户端也需要根据服务器的序列号产生相应的ack应答。这样两边的初始序列号就可以同步。否则会造成序列混乱。
3.由于网络阻塞，客户端前期发起了多次SYN请求都被阻塞，

参考链接：三次握手

四次挥手

看懂了上面的三次握手，四次挥手就很简单了。
复习一下上面的标志位：

FIN：释放一个连接。
ACK：确认序号有效。

（1）序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（简单说就是客户端和服务器端各自发起时用来计数的！）

（2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
（这个就是接收方收到信号后确认用的，它的序号和发起序号有关的！接收到信号之后，先把ACK置1，才能产生小写的ack。不要将确认序号ack与标志位中的ACK搞混了。）

然后接着看图，看看能不能自己理解：

有没有发现，这张图的服务器端连着两次返回返回了信号，为啥？

因为服务器端正在运行，你突然过来说要关停，需要人家把手头的后续工作做完。第一次应答是说它知道要关了，第二次应答是手头的事情做完了，真正的关掉了！当然服务器也可以发起关停，反过来同理！

这也是为什么连接的时候三次就可以，而关闭的时候需要四次，因为关闭的时候要确保各自都把手头最后的工作处理结束！

粘贴别人的过程来强调一下序列号的问题：

比如客户端初始化的序列号ISA=100，服务端初始化的序列号ISA=300。TCP连接成功后客户端总共发送了1000个字节的数据，服务端在客户端发FIN报文前总共回复了2000个字节的数据。

第一次挥手：当客户端的数据都传输完成后，客户端向服务端发出连接释放报文(当然数据没发完时也可以发送连接释放报文并停止发送数据)，释放连接报文包含FIN标志位(FIN=1)、序列号seq=1101(100+1+1000，序列号等于初始化序列号+发送的字节数+1，其中的1是建立连接时占的一个序列号)。
（需要注意的是客户端发出FIN报文段后只是不能发数据了，但是还可以正常收数据；另外FIN报文段即使不携带数据也要占据一个序列号。）

第二次挥手：服务端收到客户端发的FIN报文后给客户端回复确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=1102、序列号seq=2300(300+2000)（这里没有+1）。此时服务端处于关闭等待状态，而不是立马给客户端发FIN报文，这个状态还要持续一段时间，因为服务端可能还有数据没发完。（忙完手头的活）

第三次挥手：服务端将最后数据**(比如50个字节)**发送完毕后就向客户端发出连接释放报文，报文包含FIN和ACK标志位(FIN=1,ACK=1)、确认号和第二次挥手一样ack=1102、序列号seq=2350(2300+50)。

第四次挥手：客户端收到服务端发的FIN报文后，向服务端发出确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=2351、序列号seq=1102。

四次挥手时因为中间传输了数据，所以序列号出现了变化，而在三次握手时没有考虑数据，所以没有加数据的值。

客户端和服务器端那一个最先关闭连接？

注意看图，客户端发出确认报文后不是立马释放TCP连接，而是要经过2MSL(最长报文段寿命的2倍时长)后才释放TCP连接。而服务端一旦收到客户端发出的确认报文就会立马释放TCP连接，所以服务端结束TCP连接的时间要比客户端早一些。

为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

如果各位网友们还不懂

开玩笑，再不懂的话就在下面留言吧，看到了给你回复。