TCP/IP协议栈之数据包如何穿越各层协议

在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状态。

（编辑：应用网_丽江站长网）

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