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. 跨机器判断
在跨机器访问过程中，存在着如下潜在干涉(坑)：
这些问题将在TCPCopy和其它章节会有所介绍，这里不再详细描述。 6. 常用工具工作层次分析
上图展示了部分流行性工具的工作层次，比如tcpcopy默认工作在4层，调用IP层提供的raw socket接口来抓包和发包;netstat或者ss工具可以去获取TCP/IP各种统计值;LVS工作在4层，利用Netfilter来强行改变路由;tcpdump工作在数据链路层;HTTP应用工作在应用层。 懂得了这些工作原理，可以更加深刻的理解问题，并解决各种TCP相关问题。
（编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
