Linux场景下数据包是如何在协议层传输的

描述

所有互联网服务,均依赖于TCP/IP协议栈。懂得数据是如何在协议栈传输的,将会帮助你提升互联网程序的性能和解决TCP相关问题的能力。

我们讲述在Linux场景下数据包是如何在协议层传输的。

1、发送数据

应用层发送数据的过程大致如下:

数据包

我们把上述处理过程的区域大致分为:

  1. User区域
  2. Kernel 区域
  3. Device区域

在user和kernel区域的任务都是由本机cpu执行,这两个区域合并称为host区域,以区分device区域(网络接口卡上有单独的cpu)。device是接收和发送数据包的网络接口卡(Network Interface Card),一般也称为LAN card。

当应用程序调用write(fd, buf, len)来发送数据时,用户态区域会进入内核态区域,建立这个关系的纽带是socket fd和系统调用write。

在内核态的socket有两个buffer:

  1. send socket buffer,用于发送数据
  2. receive socket buffer,用于接收数据

当write系统调用被执行,用户态的数据(buf,长度)会被拷贝到内核区域的内存,并被放入到send socket buffer的末尾(见下图,发送是按照顺序发送的),然后TCP就会被调用。

数据包

TCP中的数据结构是TCB(TCP Control Block)。TCB包含了执行TCP会话所需要的信息,包括TCP连接状态,接收窗口,拥塞窗口,序号,重传timer 等。

TCP会创建TCP数据分段,而TCP数据分段包括TCP header和payload,如下图:

数据包

Payload是待发送的socket buffer中的数据,而TCP header是为了TCP可靠发送数据而加的辅助信息。

这些数据分段会进入到IP层,IP层会加上IP头部信息到数据分段,如下图:

数据包

IP在执行路由之前会去检查Netfilter LOCAL_OUT钩子,看是否需要执行iptables相关配置。之后执行IP路由。IP路由主要功能是寻找下一跳(例如网关或路由器)的IP地址,而路由的目的是到达目的地IP地址所在的机器。

IP执行路由之后,检查Netfilter POST_ROUTING钩子,如果有iptables在这方面的配置,就会去执行相关操作。委托给数据链路层之前,IP层还会执行ARP(网络地址转换),通过下一跳IP地址来查找目的MAC地址,并把Ethernet头部添加到IP数据包,如下图。

数据包

IP层同时还给用户提供了raw socket接口,即发送数据包的接口。raw socket发送的数据包与正常流程的数据包不一样,在执行Netfilter的时候,会跳过这些钩子。

IP层做完工作以后,会把数据包(上图中的数据包,一般称frame)委托给数据链路层。

由于ARP已经把目的MAC地址写入到数据包头部,这样就减轻了驱动driver的工作。进入数据链路层后,内核会去检测是否有抓包工具在监听抓包(例如tcpdump),如果有,内核会拷贝数据包信息到抓包工具的内存地址空间。

之后,根据一定的协议规则,驱动driver会要求NIC传递这个数据包。当NIC收到这个请求后,NIC复制数据包到自己的内存里,并且发送给网络。当NIC发送完一个数据包,会产生一个中断, 主机 cpu去执行中断处理程序,完成后续工作。

2、接收数据

应用程序接收数据的过程大致如下:

数据包

首先NIC把数据包写入自己的内存,并校验数据包是不是有效的,如果是有效的,把数据包写入主机的内存空间,然后NIC给主机操作系统发送一个中断信号,这时就进入到kernel区域。

在数据链路层,内核首先会做数据包检测,然后Driver驱动把数据包进行改装,以便后续TCP/IP能够理解这个数据包。改装完以后,根据Ethernet头部信息中的Ethertype分发给上层,假设为IPv4,去除Ethernet头部,并发送给IP层。值得注意的是,委托给IP层之前,如果有抓包工具在监听抓包,那么内核就会拷贝数据包信息到抓包工具的内存地址空间。

IP层通过计算checksum来校验IP头部的checksum是否有效,如果有效,接着检查PRE_ROUTING钩子(比如查看是否有iptables的相应配置需要执行),然后执行IP路由,IP路由会判断这个数据包是本地处理还是转发当前数据包到其它主机。如果是转发数据包,执行FORWARD和POST_ROUTING钩子,并转发给数据链路层;如果是本地处理,IP还会检查LOCAL_IN钩子,执行完以后,根据IP头部信息的proto值,假设为TCP,去除IP头部,并把数据包传递给上层TCP。值得注意的是,委托给TCP层之前,如果有raw socket在监听抓包,那么内核会拷贝数据包信息到raw socket的内存地址空间(默认tcpcopy利用raw socket来监听IP层的数据包)。

TCP层会根据TCP checksum来检测数据包是否有效(如果采用了checksum offload,NIC会去做相关计算),然后就给这个数据包查找相应的TCB(TCP control block),查找的方法是通过如下组合信息来查找:

如果没有查到,一般会发送reset数据包;如果查到了,进入TCP数据包处理环节。

如果是接收到新数据,TCP就会把它放入到socket接收缓冲区,然后根据TCP状态,必要时发送ack确认数据包。Socket接收缓冲区的大小就是TCP接收窗口大小。在某种程度上,如果接收窗口很大,TCP吞吐量就会很大。目前较新的内核都能动态调整窗口的大小,无需用户去修改系统参数。

用户应用程序根据读事件去执行读操作,用户态空间进入到内核空间。内核把socket buffer里面的内容复制到用户指定的内存区域,然后把socket buffer读取过的内容释放,TCP增加接收窗口大小,如果有必要,会传递一个更新窗口的数据包给对端TCP。例如下图,TCP发送了一个ack数据包,用于通知对端TCP,本方TCP接收窗口更新了。

数据包

读取操作完成后,返回应用程序,应用程序就可以进行对数据进行处理了。

3、抓包工具工作原理

知道了数据如何发送和接收以后,我们分析一下tcpdump抓包原理。

在数据链路层和IP层交界的地方(属于数据链路层,如下图),是数据包被tcpdump捕获的场所。

数据包

执行到这个交界处时,内核会去查看tcpdump是否在监听,一旦有监听,就把数据包内容放入到tcpdump设置的缓冲区。理论上只要tcpdump及时去提取数据,在线上压力不大的情况下,抓包不会丢包。

tcpdump所抓到的数据包,仅仅是代表数据包经过了链路层和网络层之间的交界处。从网卡进来的数据包未来的命运,可能是继续一路往前走到TCP,也有可能在IP层被干掉,还有可能被路由转发出去;从本机发送出去的数据包,一旦被tcpdump捕获到,说明已经到了数据链路层,没有被IP层过滤掉,因为如果数据包被IP层过滤掉,这些数据包就不会到达tcpdump捕获点,也不会出现在抓包文件里。

下面我们通过一些实验来验证上述结论。

实验之前,我们先介绍一下iptables工具。iptables是被广泛使用的防火墙工具,它主要跟内核netfilter数据包过滤框架进行交互。

3.1 实验 LOCAL_IN过滤

我们在服务器上面配置如下的iptables命令:

iptables -I INPUT -p tcp --dport 3306 -s 172.17.0.2 -j QUEUE

上述iptables命令设置了'-I INPUT'参数,意味着在netfilter LOCAL_IN钩子处执行上述iptables规则,即通往服务器端TCP之前,如果匹配到上述iptables规则,则会被放入目标QUEUE(默认情况下是直接丢弃数据包),不再继续前行。

具体命令执行见下图:

数据包

设置上述iptables后,当172.17.0.2访问172.17.0.3 3306服务时,IP数据包(如下图绿色箭头)会在服务器端IP层被丢弃掉,而红色箭头所指方向是tcpdump抓包的地方。

数据包

我们开启tcpdump抓包:

tcpdump -i any tcp and port 3306 and host 172.17.0.2 -n -v

在172.17.0.2上利用MySQL客户端命令访问172.17.0.3上面的3306服务,如下图:

结果经过长时间等待,最终显示连接不上。

服务器端抓包结果如下:

数据包

我们看到第一次握手数据包反复重传。

利用netstat命令,查看有没有相应的TCP状态,结果发现没有,如下图:

数据包

正常情况下,没有TCP状态,说明数据包没有进入服务器端TCP,第一次握手数据包在服务器端IP层被干掉了。

利用netstat -s命令,在服务器端TCP/IP统计参数里找线索:

数据包

上图服务器端IP层接收到20079个数据包,下图接收到20086个数据包,MySQL客户端登入过程累计增加了7个数据包,正好符合抓包文件显示的7个第一次握手数据包。

数据包

在服务器端TCP层,对比上面两张图,数据没有任何变化,说明了服务器端TCP没有收到任何数据包。

实验说明了在服务器端IP层进来的方向干掉数据包,服务器端TCP层不会有任何变化。

3.2 实验 LOCAL_OUT过滤

我们这次实验的目的是查看IP层netfilter LOCAL_OUT情况下的抓包情况。

如下图:

数据包

我们设置如下iptables命令:

iptables -I OUTPUT -p tcp --sport 3306 -d 172.17.0.2 -j QUEUE

具体操作如下图:

数据包

上述iptables命令设置了OUTPUT参数,意味着在netfilter LOCAL_OUT钩子处会执行上述iptables规则,即IP数据包在IP路由之前,如果匹配上述iptables规则,则会被放入目标QUEUE(默认情况下直接丢弃数据包),不会继续往下走。

在172.17.0.2上利用MySQL客户端命令访问172.17.0.3上面的3306服务,如下图:

数据包

结果经过长时间等待,最终显示连接不上。

服务器端抓包结果如下:

我们看到第一次握手数据包反复重传,跟上一个抓包结果几乎一模一样

数据包

利用netstat命令,查看有没有相应的TCP状态,结果发现有SYN_RECV状态,如下图:

数据包

有TCP状态,说明数据包进入服务器端TCP,并进入SYN_RECV状态,服务器端TCP会发送第二次握手数据包,但抓包显示并没有第二次握手数据包,说明被iptables配置干掉了。

查看netstat -s结果:

数据包

上图显示了实验之前的值,下图显示了实验之后的值。

数据包

从TCP层面信息来看,发送了17个数据分段,说明服务器端TCP发送了第二次握手数据包,而且发送了很多次,但因为设置了iptables,这些数据包被拦截掉了,所以到不了数据链路层,也就没法被tcpdump捕获到。

从这两个实验来看,tcpdump抓的数据包是一样的,都是在努力重传第一次握手数据包,但iptables设置的位置不一样,一个在入口,在TCP层无状态,一个在出口,在TCP层有状态。

进一步的分析可以尝试下面两个方向:

  1. 通过分析TCP状态来区分这两种情况
  2. 利用netstat -s给出的TCP/IP统计参数变化

通过上面实验,我们看出tcpdump抓包只是从一个点来观察世界,并不能看到全貌,这个时候就需要通过推理来辅助解决问题。

4、潜在协议层的干扰

4.1 接收数据

下图展示了数据包从NIC到协议栈,再到应用程序的过程。

TCP offload由NIC完成,目的是减轻TCP的工作量,但存在潜在坑;在数据链路层,存在抓包接口,供tcpdump等抓包工具抓包,同时也存在着raw socket原始抓包方式接口;在网络层,存在raw socket抓包接口,IP Forward转发功能,还有一整套Netfilter框架(存在大量坑的地方);在TCP层则相对比较清静,干扰少;用户程序通过socket接口从TCP取出数据或者获取新建连接。

数据包

4.2 发送数据

下图展示了数据包从应用发送数据到NIC的过程。

用户程序通过socket接口来委托TCP发送数据或者建立连接;在网络层,存在raw socket发包接口,还有一整套Netfilter框架(存在大量坑的地方);在数据链路层,存在pcap发包接口,同时也存在着raw socket原始发包接口;TCP offload是NIC做的,目的为了提升减轻TCP的工作量(比如分段,checksum),我们也遇到过由于TCP offload不当导致的丢包问题。

数据包

4.3 案例

下面是一个从NIC接收数据包,并一路到应用,再发送响应出去的案例:

我们的应用程序是Nginx(Web服务器软件),其中Nginx配置监听端口为8080,且开启access log。

数据包

上图设置了nginx keepalive_timeout = 0,即保持客户端空闲连接(方便实验)。

启动nginx,通过netstat查看,nginx已经在监听8080端口的连接请求。

数据包

刚开始nginx没有任何访问,access log都为空,iptables也没有设置。

数据包

在172.17.0.2机器,利用telnet访问172.17.0.3上面的8080端口服务,如下图:

数据包

这样telnet跟nginx建立连接,下图可以看出服务器端相应连接已经进入ESTABLISHED状态。

数据包

建立连接后,我们设置iptables命令,如下图,对返回172.17.0.2的nginx响应进行拦截并丢弃。

数据包

我们在客户端(172.17.0.2)上面继续执行telnet命令,键入'GET hello.html',然后回车执行。

数据包

从nginx日志来看,这个请求已经被处理了,虽然是非法请求,但请求已经确认到达nginx了。

数据包

大概过了2分钟,查看客户端抓包情况,累计捕获了16个数据包,客户端还显示连接处于ESTABLISHED状态。

数据包

我们查看服务器端情况,利用netstat已经查不到服务器端的相应连接了,说明连接在服务器端的TCP层已经不存在了。

数据包

我们分析抓包情况(服务器抓包和客户端抓包效果一样):

数据包

自从发送了请求数据包,客户端由于没有看到任何服务器端的数据包回来,一直在重传请求数据包。客户端以为服务器还没有收到请求,但其实请求已经被nginx处理完毕。

在服务器端查看netstat -st的统计情况。

数据包

上图是执行telnet请求之前的状况,下图是执行telnet请求之后的状况。

数据包

从上图我们可以看出connection aborted due to timeout增加了一个,说明在服务器端TCP看来,请求的响应数据包(同时带有关闭fin标志)由于发送不出去,连接被aborted,这个时候在服务器端看不到连接相应状态的存在。

在上层nginx看来,遇到了非法请求,回复了响应并关闭了连接。在TCP层看来,由于带有关闭fin的数据包到不了tcpdump抓包接口,服务器端的TCP状态会处于FIN_WAIT_1状态('遇到大量FIN_WAIT1,怎么破?'会有详细介绍),会维持一段时间并不断努力重传。由于重传一直得不到响应,TCP就把FIN_WAIT_1状态变为CLOSED状态,在服务器端查不到该连接了。

这里案例中,我们事先知道我们设置了iptables,但如果不知道呢,我们如何判断出问题出在哪一个环节呢?

仅仅靠tcpdump抓包,明显不够,因为通过抓包分析,我们只能得出服务器端没有接收到请求,我们还需要利用服务器端的信息,才能继续进一步判断。通过nginx日志,判断出请求已经被应用层处理了,说明请求数据包已经到达应用层,nginx已经处理请求,并作了响应处理,接着委托服务器端TCP去发送这些响应数据包,但显然服务器端TCP发送的响应都没有到达抓包接口,说明在IP层干掉了,于是可以根据这些信息去找数据包出去方向(outgoing)的netfilter相关配置,看看有没有这样针对这些响应进行过滤。

从上面案例,可以看出仅仅利用tcpdump是不够的,还需要综合利用各种信息,并加以推理,最终得出问题出在哪一个环节,才能解决问题。如果不会利用这些知识,客户端就就会得出服务器端没有收到请求的错误判断。

5、跨机器判断

数据包

在跨机器访问过程中,存在着如下潜在干涉(坑):

  1. 本机器自身IP层安全过滤
  2. 链路层发送QUEUE丢包
  3. 链路层TCP offload潜在问题(这里把NIC归入数据链路层)
  4. 中途设备各种问题(设备包括路由器/交换机/防火墙/网关/负载均衡器等)
  5. 对端机器链路层接收QUEUE丢包
  6. 对端链路层TCP offload(NIC)潜在问题
  7. 对端IP层安全过滤
  8. 对端TCP异常状态干扰

这些问题将在TCPCopy和其它章节会有所介绍,这里不再详细描述。

6、常用工具工作层次分析

数据包

上图展示了部分流行性工具的工作层次,比如tcpcopy默认工作在4层,调用IP层提供的raw socket接口来抓包和发包;netstat或者ss工具可以去**TCP/IP各种统计值;LVS工作在4层,利用Netfilter来强行改变路由;tcpdump工作在数据链路层;HTTP应用工作在应用层。

懂得了这些工作原理,可以更加深刻的理解问题,并解决各种TCP相关问题。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分