模板网站建设的公司,百度网盟如何选择网站,视频制作软件哪个好 前十名,包装设计需要学什么软件在我之前写的Wireshark抓包#xff1a;理解TCP三次握手和四次挥手过程中#xff0c;通过抓包分析了TCP传输的三次握手和四次挥手的过程。在这一节中#xff0c;将分析在Linux中的三次握手和四次挥手的状态和过程#xff0c;另外还有一个在我们编程过程中值得注意的SIGPIPE信…在我之前写的Wireshark抓包理解TCP三次握手和四次挥手过程中通过抓包分析了TCP传输的三次握手和四次挥手的过程。在这一节中将分析在Linux中的三次握手和四次挥手的状态和过程另外还有一个在我们编程过程中值得注意的SIGPIPE信号的处理。 文章目录 1 TCP连接的11种状态2 实验查看TCP状态变化3 read/recv返回0的作用4 SIGPIPE信号 1 TCP连接的11种状态
在TCP建立连接的过程中将经历一系列状态包括LISTEN(监听)、SYN-SENT(同步已发送)、SYN-RECEIVED(同步已接收)、ESTABLISHED(已建立)、FIN-WAIT-1(等待第一个关闭)、FIN-WAIT-2(等待第二个关闭)、CLOSE-WAIT(等待关闭)、CLOSING(关闭中)、LAST-ACK(最后的确认)、TIME-WAIT(等待时间)、以及虚构的状态CLOSED(关闭)。
CLOSED是虚构的因为它表示当没有传输控制块(TCB)时的状态(没有连接时的状态)
在TCP标准中
三次握手首先发送SYN标志的客户端被称为主动打开者而另一侧的服务器称为被动打开者四次挥手首先发送FIN标志的客户端或服务器被称为主动关闭者而另一端则被称为被动关闭者
如下图所示客户端通过发送SYN标志成为SYN_SENT状态的过程(主动打开)同时服务器成为LISTEN状态的过程(被动打开)。 现在来看一下我们熟悉的三次握手和四次挥手的握手流程 LISTEN(监听) 表示服务器在接收到来自客户端的SYN标志后可以创建新连接的状态。在Linux中通过bind()和listen()系统调用服务器进入LISTEN状态。 SYN_SENT(SYN已发送) 表示关闭状态的客户端发送SYN标志并转换的状态。在Linux中客户端可以通过connect()系统调用进入SYN_SENT状态。根据/proc/sys/net/ipv4/tcp_syn_retries值以最大RTO(重传超时)间隔发送SYN标志。 SYN_RECEIVED(SYN已接收) 表示处于LISTEN状态的服务器在接收到客户端的SYN标志后响应SYNACK标志并转换的状态。在Linux中通过accept()系统调用服务器进入SYN_RECEIVED状态。根据/proc/sys/net/ipv4/tcp_synack_retries值以最大RTO(重传超时)间隔发送SYN标志。 ESTABLISHED(已建立) 表示在3次握手后建立连接的状态服务器和客户端可以交换数据。在Linux中通过send()和recv()系统调用可以进行数据交换。可以通过在套接字中设置SO_KEEPALIVE选项来定期检查TCP连接的有效性。 FIN_WAIT_1(等待第一次关闭) 表示在已建立的状态中主动关闭者结束后转换的状态。主动关闭者在调用close()或其进程终止后由于套接字关闭主动关闭者发送FIN标志并进入FIN_WAIT_1状态。 FIN_WAIT_2(等待第二次关闭) 表示FIN_WAIT_1状态的主动关闭者接收到被动关闭者的ACK或者直到由Linux内核设置的FIN_WAIT_2的超时时间过去为止。 TIME_WAIT(等待时间) 表示FIN_WAIT_2状态的主动关闭者接收到被动关闭者的FIN标志后的状态。TIME_WAIT状态应持续2MSL(2 * 最大分段寿命)即直到网络上的所有相关数据包(分段)完全被清除为止以确保对后续新连接的影响最小化。 CLOSING(关闭中) 表示发生同时关闭FIN_WAIT_1状态的主动关闭者接收到FIN标志时的状态。 CLOSE_WAIT(等待关闭) 表示被动关闭者从主动关闭者接收到FIN标志并转换的状态。在Linux环境中CLOSE_WAIT状态没有超时只有在被动关闭者的套接字关闭时才会结束。 LAST_ACK(最后确认) 表示CLOSE_WAIT状态的被动关闭者发送FIN标志给主动关闭者后在收到相应的ACK之前保持的状态。
理论介绍完了还是得实际写代码看看Linux中这些状态的切换来看看实际执行过程中会遇到什么问题。
2 实验查看TCP状态变化
这里实验使用这篇利用fork实现服务端与多个客户端建立连接最后贴出来的代码
1、运行服务端程序 可以看到此时服务端处于LISTEN状态。
2、运行客户端程序 现在客户端和服务端都处于ESTABLISHED建立连接状态。
SYN_SENT和SYN_RCVD状态切换地过快这里没体现出来
3、关闭客户端程序 可以看到客户端进入了TIME_WAIT状态。在等待2MSL时间后客户端的网络状态将关闭(CLOSED)。
3 read/recv返回0的作用
注意在一端关闭后另一端需要关闭自己的程序否则主动关闭的那一端将无法进入TIME_WAIT状态而是保持在FIN_WAIT2状态。
那如何判断对端关闭了呢 当一端关闭后另一端的read或recv函数将无限非阻塞返回0。
现在修改一下服务端的读取代码
这里把break注释掉也就是在客户端关闭时服务端不退出fork出来的子进程。现在重复一下前面的实验过程运行服务端和客户端然后客户端断开连接。如下图所示客户端果然处于FIN_WAIT2状态。 所以无论是客户端还是服务端都需要实时的read或recv来判断对端是否断开进行资源的回收处理否则对端的状态将无法处于TIME_WAIT。
4 SIGPIPE信号
我们知道当一方关闭连接时它会发送一个FIN标志给对方。这是TCP的一种半关闭状态表示发送方(主动关闭的一方)不再发送数据但仍然可以接收数据。所以当服务端收到客户端发送的FIN后它可以继续向客户端发送数据但这些数据会被送入TCP的发送缓冲区并不会立即发送。
如果客户端收到服务端的FIN并关闭了连接而服务端仍然试图向客户端发送数据这时如果客户端已经关闭了接收端写入操作就会导致Linux内核发送一个SIGPIPE信号被发送给服务端进程。
SIGPIPE用于通知进程它试图向一个已经关闭的管道(或socket)写数据。
默认情况下如果进程忽略或者不捕获SIGPIPE信号进程会被终止。因此为了避免进程因为SIGPIPE信号而终止可以在程序中捕获SIGPIPE信号或者在写入之前使用一些手段来检查连接状态。
现在再来修改一下服务端程序 这里我们也把break注释掉这样理论上这个recv函数会无限非阻塞地返回0也就是服务端用于处理客户端的子进程会一直输出peer closed同时客户端还会处于FIN_WAIT2状态。就是前面read/recv返回0的作用中的实验结果。
但现在在服务端的recv返回0时表示服务端已经收到了FIN信号此时服务端使用send往客户端发送一个消息。现在会产生一个SIGPIPE信号将服务端用于处理客户端的子进程杀掉。如下图所示可以看到进程确实被杀掉了。 为了验证一下确实产生了SIGPIPE信号我们自己来注册这个信号。程序做出如下修改 结果如下 不注册的话内核默认会将程序杀掉注册了这个信号的话内核就不会杀掉进程就由我们自己处理了。在这里由于服务端的socket_read中没有break掉内核也没有杀掉这个子进程所以这里recv将无限非阻塞返回0加上在这个分支中一直调用send发送数据所以服务端在这里无限输出peer closed并无限收到SIGPIPE信号。 所以为了防止服务端程序在客户端被关闭后由于程序之间没有及时的同步导致服务端继续往客户端写数据最后异常地被SIGPIPE信号关闭我们可以忽略掉SIGPIPE信号以防止服务端被误关闭。
signal(SIGPIPE, SIG_IGN);
