TCP连接的建立与释放(三次握手 四次挥手)

SYN：同步（1：开启  0：关闭），表示客户机想与服务器同步

ACK：确认（1:表示有效  0：无效）

FIN：结束

PSH：有 DATA数据传输

RST：连接重置

 

seq：序号（随机生成的）

ack：确认号

 

三次握手

三次握手描述是不太准确的，建立Tcp链接只握了 一次手，所谓3次 是发送了3次报文。

客户机A、服务器B TCP默认关闭。

客户机想要与 服务器同步，客户机主动打开TCP。

服务器也要打开TCP，打开之后一直处于监听状态，等待客户机发送第一次握手的报文。

 

第一次握手：SYN（同步）

客户机：客户机第一次向服务器发送报文 ，会把SYN开启（设置为1），还需发送seq，作为后续判断依据。

 

第二次握手：SYN+ACK（同步 确认 ）

服务器：此时收到客户机的报文，会把TCP的报文中把SYN、ACK开启，SYN+ACK(同步 确认 )，服务器也生成自己的序号，还需加上ack（确认号 = 对方的序号+1）

这样客户机收到之后 - 1 就知道是不是自己发送的TCP报文了。

 

第三次握手：ACK（确认）

客户机：进行确认，再次发送第二次报文，否则服务器不知道自己发出去的 ” 确认同步 “ 是否被接收，客户机把ACK开启，seq序号（对方确认号+1），ack确认号（对方序号+1）。最终链接建立完成。

 

Q1：服务器为什么不记住自己的序号 或者生成序号？

如果每一次都SYN过来的时候，服务器都生成自己的序列号，造成服务器需要挂起非常多资源，如果黑客多次发送一次SYN 不进行下一步，导致服务器原地崩溃，就是典型的DDoS攻击。

所以服务器不保存自己的序列号。根据对方的序号+1 当做确认号。

 Q2：第一次握手+第二次握手 好像TCP链接就可以建立了，为什么客户机还要再次发送第二次报文？

我们TCP链接 第一次握手 有可能网络中的某种原因 造成阻塞滞留、停留在网络中，造成超时，客户机会再次发送一遍同样的，这次Tcp建立连接了，并且我们已经用完释放了。现在网络通畅了，刚刚那条阻塞滞留的 有可能 又发送到服务器 服务器并收到发送报文给客户机，若按照上述说的2次就可建立连接，那此刻TCP链接已经建立好了，但是我们在第二次超时重发的时候已经用完释放了，所以此刻就不需要再建立了。因此我们需要第三次报文握手再次确认。

 

四次挥手：

双端都可主动发起关闭请求

自己得序号：用对方的确认号+1

自己得确认号：用对方的序号+1

假如客户端发起：

第一次挥手：FIN + ACK（结束+确认）

客户机：发送报文，头部信息 FIN = 1, 还需序号seq 和 确认号ack

 

第二次挥手：ACK（确认）

服务器：向客户机发送 ACK（确认）报文，还需 确认号 ack( 对方的序号+ 1 )，序号（对方的确认号）一同发送过去

 

中间可能数据 需要服务器 发送给客户机 。。 发送完成之后 进行第三次挥手，服务器告诉客户端 我也要关闭了

 

第三次挥手：FIN + ACK（结束+确认）

服务器： 再次发送报文给客户机，FIN + ACK  来进行最后的确认。此时没有一来一回，所以 确认号 、序号 和上次相同即可。

 

第四次挥手：ACK（确认）

客户机：得到服务器最终的 【结束确认】（FIN + ACK ）之后 ，会发送ACK 给服务器 来进行确认，还需 序号（对方的确认号+1） 和 确认号（对方的序号 + 1） 一同发过去。

 

Q1：第一和第二次挥手 就足以断开链接了，为啥需要4次呢？

因为存在可能未发送完的数据

Q2：为什么客户机最后要等待一段时间呢？

客户机发送的最后一条确认报文，服务器可能会没有收到，服务器就会以为 自己第三次挥手 没有发送出去，服务器会再次发送 第三次报文，这就是客户机要等待一段时间的原因。