计算机网络-tcp连接常见异常

计算机网络-tcp连接常见异常

1. 目标端口未在监听：(操作系统参与）
   解决：TCP的服务端实际上就是从网卡的寄存器中读取数据，然后进行解析。对于TCP自然会解析出目的端口这个关键信息，然后根据这个信息查看有没有这样的套接字。这个套接字是什么呢？在用户层面是一个文件句柄，但在内核中实际是一个数据结构，里面记录了很多信息。这个数据结构存储在一个哈希表中，通过函数__inet_lookup_skb（net/inet_hashtables.h）可以实现对该数据结构的查找。对于上述情况，自然无法找到该套接字，因此TCP服务端会进行错误处理，处理的方式就是给客户端发送一个RST（通过函数tcp_v4_send_reset进行发送），告诉客户端发生错误。可以通过抓包来分析理解。
   常见返回：[Errno 111] Connection refused（连接拒绝）
2. 目标主机不存在：(自己的超时计时器）
   这也是一种比较常见的情况，当某台服务器主机宕机了，而客户端并不知道，仍然尝试去与其建立连接。这个时候由于宕机，操作系统帮不上忙，服务器处于一种完全没有响应的状态。那么此时客户端的TCP会怎么办呢？最多重传默认为6次，每一次时间间隔都不一样，而后仍未收到响应就会返回ETIMEDOUT错误。这是TCP建立连接自己的一个保护机制，但是我们要等待75s才能知道这个连接无法建立，对于我们所有服务来说都太长了。更好的做法是在代码中给connect设置一个超时时间。
3. Server进程被阻塞：
   由于某些情况，服务器端进程无法响应任何请求，比如所在主机的硬盘满了，导致进程处于完全阻塞，通常我们测试时会用gdb模拟这种情况。上面提到过，建立连接的过程对应用程序是不可见的，那么，这时连接可以正常建立。当然，客户端进程也可以通过这个连接给服务器端发送请求，服务器端TCP会应答ACK表示已经收到这个分节（这里的收到指的是数据已经在内核的缓冲区里准备好，由于进程被阻塞，无法将数据从内核的缓冲区复制到应用程序的缓冲区），但永远不会返回结果。
4. Server进程暂时关闭：
   这是线上最常见的操作，当一个模块上线时，OP同学总是会先把旧的进程杀死，然后再启动新的进程。那么在这个过程中TCP连接发生了什么呢。在进程正常退出时会自动调用close函数来关闭它所打开的文件描述符，这相当于服务器端来主动关闭连接——会发送一个FIN分节给客户端TCP；客户端要做的就是配合对端关闭连接，TCP会自动响应一个ACK，然后再由客户端应用程序调用close函数，也就是我们上面所描述的关闭连接的4次挥手过程。接下来，客户端还需要定时去重连，以便当服务器端进程重新启动好时客户端能够继续与之通信。
5. 通信的过程中服务器端宕机：
   客户端向服务器端发送分节，由于服务器端宕机，不会有任何响应，客户端持续重传，然而服务器始终不能应答，重传数次之后，大约4~10分钟才停止，之后返回一个ETIMEDOUT错误。