C#之 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：为什么客户机最后要等待一段时间呢？
客户机发送的最后一条确认报文，服务器可能会没有收到，服务器就会以为 自己第三次挥手 没有发送出去，服务器会再次发送 第三次报文，这就是客户机要等待一段时间的原因。
标签：C#,客户机,确认,TCP,ACK,四次,序号,服务器,报文 来源： https://www.cnblogs.com/zhaolaosan/p/16222238.html