TCP/IP协议栈之数据包怎样穿越各层协议

或许过了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相干题目。

（编辑：湖南网）

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