tcp的报文序号,三次握手和四次挥手 |
您所在的位置:网站首页 › 顺序号和确认号 › tcp的报文序号,三次握手和四次挥手 |
下面是TCP报文格式图: 发送包的序号可以保证传送数据包的顺序,确保了tcp的可靠性。响应包 内也包括一个序列号,表示接收方准备好接收这个序列号的包。在TCP传送一个数据包时,它会把这个数据包放入重发队列中,同时启动计时器,如果收到了关于这个 包的确认信息,便将此数据包从队列中删除,如果在计时器超时的时候仍然没有收到确认信息,则需要重新发送该数据包。另外,TCP通过数据分段中的序列号来 保证所有传输的数据可以按照正常的顺序进行重组,从而保障数据传输的完整。 包序号为什么是随机的? 防止黑客猜测序列号攻击防止连接失效后SOCKET被重用使得以前残留的包被错误的接受,而且序列号以后应该 3次握手过程详解所谓三次握手(Three-Way Handshake)即建立TCP连接,就是指建立一个TCP连接时,需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中,这一过程由客户端执行connect来触发,整个流程如下图所示: #netstat -nap | grep SYN_RECV 为什么不是两次握手 主要存在两种说法: 1 TCP 协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤;如果只是两次握手, 至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认。 2建立连接的过程中因网络等原因可能存在阻塞的问题,假设是两次握手建立连接,会有如下情况发生: 客户端发出连接请求1,但此时连接请求1被阻塞了 然后客户端需要重试,翻出连接请求2,并且正常发送和建立连接了,然后通信处理完毕后,针对请求2的连接已经正常关闭。 被阻塞的请求1阻塞结束,请求1被发送到服务端,服务端此时以为又有一个请求过来了,因此会处理,并返回数据,但此时客户端并不会响应,因此就会造成连接和资源资源的浪费。为什么三次握手就没有该问题呢? 因为2次握手的时候,只要server有返回,无论client是否接收,都是完成了二次握手,所以此时如果用的是二次握手,则说明连接已经建立成功;而对三次握手,需要client返回确认信息,才成功建立连接,而上面的场景client不会响应,所以连接并不会建立。 上面的说法都是正确的,因为他们其实是2次握手会导致的两种问题。 4次挥手过程详解三次握手耳熟能详,四次挥手估计就少有人知道了。所谓四次挥手(Four-Way Wavehand)即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发,整个流程如下图所示: 上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况,具体流程如下图: 关于三次握手与四次挥手通常都会有典型的面试题,在此提出供有需求的XDJM们参考: (1) 三次握手是什么流程?四次握手呢?答案前面分析就是。(2) 为什么建立连接是三次握手,而关闭连接却是四次挥手呢?这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。 借鉴与:http://www.52im.net/thread-258-1-1.html |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |