标签：C# 客户机 确认 TCP ACK 四次 序号 服务器 报文
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。