网络编程之TCP状态

网络编程之TCP状态


TCP状态

TCP三次握手

TCP四次挥手

SIGPIPE信号

往一个已经接收FIN的套接字写时允许的,接收到FIN仅仅代表对方不再发送数据。
在收到RST段之后,如果再调用write就会产生SIGPIPE信号,对于这个信号的处理的处理我们通常忽略即可。
signal(SIGPIPE, SIG_IGN);


TIME_WAIT状态

TIME_WAIT状态对大并发服务器的影响,应尽可能在服务器避免出现TIME_WAIT状态,如果服务器端主动断开连接,服务端就会进入TIME_WAIT状态,协议设计上,应该让客户端主动断开连接,这样就把TIME_WAIT状态分散到大量的客户端。如果客户端不活跃了,一些客户端不断开连接,这样子就会占用服务器端的连接资源。服务器端也有有个机制踢掉不活跃的连接。
TIME_WAIT状态存在原因如下:

  • 保证可靠地终止TCP连接
    处于TIME_WAIT状态的发送端会向目的端发送ACK,如果此时ACK丢失,目的端会超时重传FIN报文段,目的端收到重传的报文段最少需要2MSL,所以发送端会等待2MSL时间。
  • 保证迟到的TCP报文段有足够的时间识别被丢弃

EMFILE错误

  • 调高进程文件描述符数目
  • 死等
  • 退出程序
  • 关闭监听套接字。那什么时候重新打开呢?
  • 如果是epoll模型,可以改用edge trigger。问题是如果漏掉了一次accept(2),程序再也不会收到新连接。
  • 准备一个空闲的文件描述符。遇到这种情况,先关闭这个空闲文件,获得一个文件描述符名额;再accept拿到socket连接的文件描述符;随后立刻close,这样就优雅地断开了与客户端的连接;最后重新打开空闲文件,把“坑”填上,以备再次出现这种情况时使用。

RST报文段

产生复位报文段RST的情况:

  • 访问不存在的端口或者处于TIME_WAIT状态的端口
  • 异常终止连接
  • 处理半打开连接