首页 > 编程知识 正文

tcp的四次挥手,tcp和udp的端口号

时间:2023-05-03 11:31:40 阅读:32765 作者:3967

文章目录TCP报文段头形式4挥手过程半封闭问题网络编程总结

TCP的制作过程和释放过程都是通过TCP/IP协议栈自动完成的。本文主要分析TCP释放的过程。

TCP段头格式注意: TCP虽然是面向字节流的, 但是TCP传送的数据单元却是报文段.

本篇主要介绍TCP首款: FIN

4挥手的过程

要断开连接,必须发送4次消息。 这是因为需要TCP连接是全双工的, 每一端都需要对读写部分分别进行关闭。 如果一端关闭读写或同时关闭两者,则该端会向对方发送FIN,通知我将关闭。 对方知道后挥后发送确认,关闭后再发送另一个确认给对方。 整个是http://ww.Sina.com

上面的照片是客户发送的FIN,当然服务端也可以发送FIN,但通常客户端会主动断开连接。

服务端调用close等函数自行关闭,向服务端发送包含FIN的消息,进入FIN-WAIT1阶段。 这个阶段,等待对方的ACK来。 服务端收到对方的FIN后,立即向对方返回确认,进入关闭等待阶段。 3358www.Sina.com/.服务器发送数据后,发送FIN字段。 然后进入LAST-ACK阶段,等待服务端的ACK到来,客户端收到对方的ACK时,接收到首先进行关闭的一方将执行主动关闭, 而另一方执行被动关闭对方的FIN后立即向对方发送ACK确认,然后

由于半闭环TCP是全双工通信,因此积极地在关闭的发送FIN之后关闭了写入侧,但读取侧没有关闭,所以能够继续接收数据。 这种状态被称为该阶段服务端还能够将没有发送完的数据发送给对端。 可以使用shutdown函数指定读写侧的关闭[1]。

问题进入FIN-WAIT2阶段, 该阶段客服端还能够继续接收数据, 但是不能在发送数据了

分析过程中,进入TIME_WAIT阶段. 等待2MSL后客户端彻底关闭.主动退出是因为没有发送数据,工作结束了,但对方也不一定会退出。 因为可能还会发送数据,所以被动侧可以从发送数据开始到FIN结束为止发送数据。 此过程只能主动发送(或丢弃)接收,不能进行其他操作。 如图:所示

当然,被动方也有可能没有发送数据。 如果ACK和FIN一起来,这就是“挥了3次手”,但实际上是挥了4次手。 图33、360

2. 半关闭

为什么是四次挥手

这是因为双方都同意关闭连接,握手的四条消息也可以协调发送,逻辑上可以直接返回到关闭状态; 但是,我们必须假设网络不可靠,所以不能保证你最后发送的ACK消息一定会传到对方那里。 因此,对方处于LAST_ACK状态的套接字可能会因超时而未收到ACK消息,并重新发送FIN消息。 此TIME_WAIT状态的作用是重新发送可能丢失的ACK消息。

TCP连接是全双工的, 有半关闭特性, 每一端都需要对读写部分分别进行关闭

为什么主动方最后要等待2MSL

这是因为双方都同意关闭连接,握手的四条消息也可以协调发送,逻辑上可以直接返回到关闭状态; 但是,我们必须假设网络不可靠,所以不能保证你最后发送的ACK消息一定会传到对方那里。 因此,对方处于LAST_ACK状态的套接字可能会因超时而未收到ACK消息,并重新发送FIN消息。 此TIME_WAIT状态的作用是重新发送可能丢失的ACK消息。

可靠的实现TCP全双工链接的终止

如果不存在等待时间状态,则IP地址和端口号相同,以便APP应用程序可以立即建立与刚关闭的连接相似的连接。 这个新连接被称为上一个连接的化身。 新化身可能会接收属于原始连接的APP应用程序数据的TCP消息。 这显然不会发生。 为了不那样,http://www.Sina.coona

正因为需要2MSL的等待时间,所以如果在为什么主动方最后要等待2MSL.例如: TCP套接字的通信实验中关闭了服务端,服务端暂时无法重新启动。

网络编程通常可以直接ctrl c或程序正常结束后闭合一端,摆动4次手释放。 可以调用close函数,也可以调用shutdown函数分别关闭读/写。

总结4次挥手的过程,为什么需要4次挥手,为什么自愿关闭的一方需要等待2MSL的时间?

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。