三次握手在理解TCP连接之前请先理解TCP消息的几个标志符号()大概一次就可以了！ ) :
需要重点介绍上图中的几个字段。
(1)序列号： seq序列号，用于标识要从TCP源端发送到目标端的字节流，其占用32位，发起方发送数据时对此进行标记
(简单说就是客户端和服务器端各自发起时用来计数的！)
)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 :接收方应该尽快将此消息传递到APP应用层。
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请求被屏蔽。
链接：握手三次
4挥手明白了上面的三次握手。 4挥手就很简单了。
请复习上面的徽标位置：
FIN :释放连接。
ACK :验证序列号是否有效。
(1)序列号： seq序列号，用于标识要从TCP源端发送到目标端的字节流，其占用32位，发起方发送数据时对此进行标记
(简单说就是客户端和服务器端各自发起时用来计数的！
ong>）（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个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
如果各位网友们还不懂
开玩笑，再不懂的话就在下面留言吧，看到了给你回复。