加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

从TCP协议到TCP通信的各种异常现象和分析

发布时间:2019-05-17 03:39:00 所属栏目:教程 来源:itworld123
导读:很多人总觉得学习TCP/IP协议没什么用,觉得日常编程开发只需要知道socket接口怎么用就可以了。如果大家定位过线上问题就会知道,实际上并非如此。如果应用在局域网内,且设备一切正常的情况下可能确实如此,但如果一旦出现诸如中间交换机不稳定、物理服务
副标题[/!--empirenews.page--]

很多人总觉得学习TCP/IP协议没什么用,觉得日常编程开发只需要知道socket接口怎么用就可以了。如果大家定位过线上问题就会知道,实际上并非如此。如果应用在局域网内,且设备一切正常的情况下可能确实如此,但如果一旦出现诸如中间交换机不稳定、物理服务器宕机或者其它异常情况时,此时引起的问题如果只停留在套接字接口的理解层面将无法解决。因此,深入理解TCP/IP协议,对我们分析异常问题有很大的帮助。

下图是网络通信中常见的架构,也就是CS架构。其中程序包括两部分,分别为客户端(Client)和服务端(Server)。当然,实际的环境还要复杂的多,在客户端和服务端之间可能有多种不同种类和数量的设备,这些设备都会增加网络通信的复杂性。自然,也会增加程序开发容错的复杂性。

从TCP协议到TCP通信的各种异常现象和分析

图1 基本架构

TCP的基本流程

在分析异常情况之前,我们先回忆一下TCP协议的基本逻辑。在客户端和服务端能够收发数据之前首先必需建立连接。连接的建立在协议层面也是通过收发数据包完成,只不过在用户层面就是客户端调用了一个connect函数。连接的过程俗称“三次握手”,具体流程如图2所示。

从TCP协议到TCP通信的各种异常现象和分析

图2 TCP的三次握手流程

TCP连接的断开也是比较复杂的,需要经过所谓的“四次挥手”的流程。其原因是因为TCP是双工通信,分别需要从客户端和服务端2侧断开连接。

从TCP协议到TCP通信的各种异常现象和分析

图3 TCP的四次挥手

另外一个比较重要的内容是TCP协议的状态转换,理解了这个内容,我们才能清楚出现各种异常情况下数据包的内容。

从TCP协议到TCP通信的各种异常现象和分析

图4 TCP状态转换图

本文只是简单回忆一下TCP的基本流程,详细的内容可以参考本号之前的文章《从TCP到Socket,彻底理解网络编程是怎么回事》

异常情况分析

了解了TCP的基本流程之后,我们再看一下各种异常情况。这些异常情况才是我们在后续解决问题的时候的关键。了解了这些异常情况及原理,后面解决问题才能游刃有余。

1. 试图与一个不存在的端口建立连接(主机正常)

这里的不存在的端口是指在服务器端没有程序监听在该端口。我们的客户端就调用connect,试图与其建立连接。这时会发生什么呢?

这种情况下我们在客户端通常会收到如下异常内容:

  1. [Errno 111] Connection refused(连接拒绝) 

具体含义可以查一下Linux的相关手册,或者用搜索引擎搜索一下。试想一下,服务端本来就没有程序监听在这个接口,因此在服务端是无法完成连接的建立过程的。我们参考‘三次握手’的流程可以知道当客户端的SYNC包到达服务端时,TCP协议没有找到监听的套接字,就会向客户端发送一个错误的报文,告诉客户端产生了错误。而该错误报文就是一个包含RST的报文。这种异常情况也很容易模拟,我们只需要写一个小程序,连接服务器上没有监听的端口即可。如下是通过wireshark捕获的数据包,可以看到红色部分的RST报文。

从TCP协议到TCP通信的各种异常现象和分析

图5 数据包截图

继续深入理解一下,在操作系统层面,TCP的服务端实际上就是从网卡的寄存器中读取数据,然后进行解析。对于TCP自然会解析出目的端口这个关键信息,然后根据这个信息查看有没有这样的套接字。这个套接字是什么呢?在用户层面是一个文件句柄,但在内核中实际是一个数据结构,里面记录了很多信息。这个数据结构存储在一个哈希表中,通过函数__inet_lookup_skb(net/inet_hashtables.h)可以实现对该数据结构的查找。对于上述情况,自然无法找到该套接字,因此TCP服务端会进行错误处理,处理的方式就是给客户端发送一个RST(通过函数tcp_v4_send_reset进行发送)。

2. 试图与一个某端口建立连接但该主机已经宕机(主机宕机)

这也是一种比较常见的情况,当某台服务器主机宕机了,而客户端并不知道,仍然尝试去与其建立连接。这种场景也是分为2种情况的,一种是刚刚宕机,另外一种是宕机了很长时间。为什么要分这2种情况?

这主要根ARP协议有关系,ARP会在本地缓存失效,TCP客户端就无法想目的服务端发送数据包了。

  1. (192.168.1.100) 位于 08:00:27:1a:7a:0a [ether] 在 eth0 

了解了上述情况,我们分析一下刚刚宕机的情况,此时客户端是可以向服务端发送数据包的。但是由于服务器宕机,因此不会给客户端发送任何回复。

从TCP协议到TCP通信的各种异常现象和分析

图6 数据包截图

由于客户端并不知道服务端宕机,因此会重复发送SYNC数据包,如图6所示,可以看到客户端每隔几秒会向服务端发送一个SYNC数据包。这里面具体的时间是跟TCP协议相关的,具体时间不同的操作系统实现可能稍有不同。

3. 建立连接时,服务器应用被阻塞(或者僵死)

还有一种情况是在客户端建立连接的过程中服务端应用处于僵死状态,这种情况在实际中也会经常出现(我们假设仅仅应用程序僵死,而内核没有僵死)。此时会出现什么状态?TCP的三次是否可以完成?客户端是否可以收发数据?

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读