编程语言
首页 > 编程语言> > C#之 TCP连接的建立与释放(三次握手 四次挥手)

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