所有互联网服务，均依赖于TCP/IP协议栈。懂得数据是如何在协议栈传输的，将会帮助你提升互联网程序的性能和解决TCP相关问题的能力。
我们讲述在Linux场景下数据包是如何在协议层传输的。
1. 发送数据
应用层发送数据的过程大致如下：
我们把上述处理过程的区域大致分为：
- User区域
- Kernel 区域
- Device区域
在user和kernel区域的任务都是由本机cpu执行，这两个区域合并称为host区域，以区分device区域(网络接口卡上有单独的cpu)。device是接收和发送数据包的网络接口卡(Network Interface Card)，一般也称为LAN card。
当应用程序调用write(fd, buf, len)来发送数据时，用户态区域会进入内核态区域，建立这个关系的纽带是socket fd和系统调用write。
在内核态的socket有两个buffer：
- send socket buffer，用于发送数据
- 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)，查找的方法是通过如下组合信息来查找：
- <source IP, source port, target IP, target port>
如果没有查到，一般会发送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数据包过滤框架进行交互。
(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层不会有任何变化。
(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层有状态。
进一步的分析可以尝试下面两个方向：
- 通过分析TCP状态来区分这两种情况
- 利用netstat -s给出的TCP/IP统计参数变化
通过上面实验，我们看出tcpdump抓包只是从一个点来观察世界，并不能看到全貌，这个时候就需要通过推理来辅助解决问题。
4. 潜在协议层的干扰
(1) 接收数据
下图展示了数据包从NIC到协议栈，再到应用程序的过程。
TCP offload由NIC完成，目的是减轻TCP的工作量，但存在潜在坑;在数据链路层，存在抓包接口，供tcpdump等抓包工具抓包，同时也存在着raw socket原始抓包方式接口;在网络层，存在raw socket抓包接口，IP Forward转发功能，还有一整套Netfilter框架(存在大量坑的地方);在TCP层则相对比较清静，干扰少;用户程序通过socket接口从TCP取出数据或者获取新建连接。
(2) 发送数据
下图展示了数据包从应用发送数据到NIC的过程。
用户程序通过socket接口来委托TCP发送数据或者建立连接;在网络层，存在raw socket发包接口，还有一整套Netfilter框架(存在大量坑的地方);在数据链路层，存在pcap发包接口，同时也存在着raw socket原始发包接口;TCP offload是NIC做的，目的为了提升减轻TCP的工作量(比如分段，checksum)，我们也遇到过由于TCP offload不当导致的丢包问题。
(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. 跨机器判断
在跨机器访问过程中，存在着如下潜在干涉(坑)：
- 本机器自身IP层安全过滤
- 链路层发送QUEUE丢包
- 链路层TCP offload潜在问题(这里把NIC归入数据链路层)
- 中途设备各种问题(设备包括路由器/交换机/防火墙/网关/负载均衡器等)
- 对端机器链路层接收QUEUE丢包
- 对端链路层TCP offload(NIC)潜在问题
- 对端IP层安全过滤
- 对端TCP异常状态干扰
这些问题将在TCPCopy和其它章节会有所介绍，这里不再详细描述。
6. 常用工具工作层次分析
上图展示了部分流行性工具的工作层次，比如tcpcopy默认工作在4层，调用IP层提供的raw socket接口来抓包和发包;netstat或者ss工具可以去获取TCP/IP各种统计值;LVS工作在4层，利用Netfilter来强行改变路由;tcpdump工作在数据链路层;HTTP应用工作在应用层。
懂得了这些工作原理，可以更加深刻的理解问题，并解决各种TCP相关问题。
