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层有状态。 进一步的分析可以尝试下面两个方向：
通过上面实验，我们看出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状态。
（编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
