所有互联网服务，均依赖于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层的数据包）。

相关视频推荐

4个小时搞懂tcp/ip协议栈，从tcp/ip协议栈原理到实现一个网络协议栈

10道面试必问的经典网络八股文，让你在面试中逼格满满

7道面试题打通C/C++后端开发的技术脉络

免费学习地址：c/c++ linux服务器开发/后台架构师

需要C/C++ Linux服务器架构师学习资料加qun812855908（资料包括C/C++，Linux，golang技术，内核，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等）

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是不够的，还需要综合利用各种信息，并加以推理，最终得出问题出在哪一个环节，才能解决问题。如果不会利用这些知识，客户端就就会得出服务器端没有收到请求的错误判断。