TCP断开时的状态与Linux nf

题目有点大了，但是难免有一些愤怒！
我们的网关产品目前处在系统测试阶段，不太顺利，是太不顺利！各方面都在懈怠，包括我！我除了懈怠，还在找机会逆袭！顺便蔑视一下测试者，希望产生一种想象，即他发现的问题其实不是问题，而是因为他的无知所导致！就在昨天，机会来了，我便气扬了！
很多人觉得我是下三层网络的专家，对于TCP之类的无权问津，但是我对TCP除了辱骂还是辱骂！因为它太复杂了，作为一个低层的设施，如果太复杂，应用层的复杂空间便小了！编程的人，特别是socket编程的人，总是将IP以及网卡作为一个黑盒子，而着重看待TCP，他们对UDP是不屑一顾的，也不会关注什么非合作UDP流量。这是搞通讯网络和人和编程的人的本质区别，毕竟分工不同。但是我也是从研究TCP开始的，起初我并无法触及路由器之类的东西，更不晓得什么流量工程，可是到了后来当我懂了IP以后，我发现IP是多么的美妙，可以让人瞬间高潮！而TCP，就是一团乱麻，在产品系统测试的时候，一个TCP的疑难杂症可以让一个研发人员折腾一下午甚至好几天，而这几天时间，测试人员爽了，没什么事，可以聊天，看新闻，这是多么悲哀，让人没法释怀！真TMD想给测试人员上椅刑！旋转升降座椅一定会爆炸，菊花残，满地伤，花落人断肠！
只可惜，昨天的事在我愤怒状态时，彻底灭了这种格局！事情是这样的。
客户端A：128.129.1.2
网关外网口(连接客户端)：128.129.1.1
网关内网口(连接服务器)：192.168.220.223
服务器：192.168.30.75
网关上做NAT的redirect转换，将访问服务器的流量重定向到本地的apache服务器，apache服务器行使正向代理功能(正向代理是一个重要概念，请深入理解)。规则如下：
iptables -t nat -A PREROUTING -d 192.168.30.75 -j REDIRECT --to-ports 80
多么简单的规则，然而多么痛的领悟。

测试人员，严格说是黑盒测试人员(非白盒)，测试功能就算了，不影响业务就可以了，偏偏要搞什么抓包，关键是抓包还误会我们！问题如下：
连接的建立以及数据的传输，均经过了代理，但是连接的拆除却没有被NAT，直接forward出去了，导致192.168.30.75服务器直接接收到了源IP地址为128.129.1.2的数据包。这是怎么回事？！
       实际上，这是毫无影响的，只要应用程序能够坚持足够长的时间！
       我发现，这是服务器30.75主动断开的连接，也就是它主动发送了FIN，此后客户端发送了ACK，然而客户端迟迟没有发送自己方面的FIN，过了两分钟才发送了FIN/ACK，此时连接只是单方面断开了。此时，在客户端没有发送FIN之前，它处在CLOSE_WAIT状态。由于目前的产品是基于前一个产品构建的，在前一个产品中，我由于一些特殊的原因将conntrack的和TCP相关的timeout都减到了足够小，比如我将TCP的conntrack的establish的timeout减少到了120秒(默认是5天)，因此断开连接时的各状态timeout更小，因此在两分钟内，conntrack早就删除了！
       此时客户端的FIN来了，由于conntrack已经删除，网关会为其建立一个新的conntrack吗？这要看有没有设置loose，我当然设置了，也就是不再以syn为建立新conntrack的依据，按理说，Linux网关会创建一个新的conntrack，然而它携带了fin标志！这就意味着Linux不会创建新的conntrack！因此数据包就直接forward了。但是这不会造成什么影响！因为携带fin的数据包拥有自己的控制通道timeout期限。到期后会自动转换，这是和establish状态的截然不同！这是为什么呢？
       这样从TCP/IP的设计说起。有一种设计方案叫做带内控制，也就是控制通道和数据通道共享一条网络路径，TCP协议就是这种设计的典型，另一种就是IP，比如ICMP就是IP的控制协议，然而你不能说IP不是一种完全的带内控制，它虽然和TCP有所区别，那只是因为它的无状态所致！
       TCP的控制通道用标志来区分，携带SYN，FIN的数据段都是控制段，Linux的conntrack对TCP的行为就是以这种控制标志为依据的，如果来了一个establish的数据包-没有syn，没有fin，没有查找到conntrack，在设置loose标志的情况下，Linux为创建一个新的conntrack项，然后对于控制信号，比如fin段，就不同了，Linux不会创建。然而这并不影响终端的结果，虽然由于Linux没有NAT成功导致了数据不会正确到达服务器，可是由于已经fin了，终端会自动用timeout处理。
       但是一定要注意方向，这可能会稍微带来一些问题。如果主动发出的FIN被拦截，会有大问题吗？不会的，因为主动发出FIN的一端不管它会不会被拦截，都会更改状态，而被动关闭的那一端虽然收不到FIN，也会行使超时重传限制权利，虽然可能慢一点。
       持续饥饿！保持饥饿！

TCP断开时的状态与Linux nf_conntrack相关推荐

TCP断开连接时的2MSL的time_wait状态
http://blog.csdn.net/xiaofei0859/article/details/24621487 2MSL TIME_WAIT状态存在的理由: TIME_WAIT状态的存在有两个理由 ...
linux服务器上tcp有大量time_wait状态的解决方法和原因解释
在检查服务器时,发现有很多连接超时情况出现,用netstat命令查看,tcp的time_wait状态较多,需要进行优化. 1. 看一下现在time_wait的数量 netstat -an | grep ...
TCP/IP详解第十二章(9) TCP断开连接
前言不管面试 Java .C/C++.Python 等开发岗位, TCP 的知识点可以说是的必问的了. 任 TCP 虐我千百遍,我仍待 TCP 如初恋. 遥想小林当年校招时常因 TCP 面试题被刷, ...
Linux nf_conntrack连接跟踪的实现
连接跟踪,顾名思义,就是识别一个连接上双方向的数据包,同时记录状态.下面看一下它的数据结构: struct nf_conn { /* Usage count in here is 1 ...
监控io性能，free命令，ps网络命令，查看网络状态，Linux下抓包
10.6 监控io性能磁盘的io是一个非常重要的指标,所以要更详细的查看磁盘状态,需要用到iostat命令,如果之前已经安装了sysstat包的话,在安装sysstat包时iostat命令就已经被安 ...
实时监测tcp链接状态_终于搞懂了 TCP 的 11 种状态，太不容易了…
后台回复"666",获取新资料本来想写运维过程中,nginx 服务器中 time_wait 的相关测试及解决方法的,然后发现TCP 的状态需要先铺垫一下,于是就整理了这篇文章. ...
tcp假连接_ESTABLISHED状态的连接收到 SYN 会回复什么？
通过阅读这篇文章,你会了解到这些知识 ESTABLISHED 状态的连接收到乱序包会回复什么 Challenge ACK 的概念 ACK 报文限速是什么鬼 SystemTap 工具在 linux 内核 ...
如何使用RST来解决TCP断开问题
女主宣言最近在团队分享中,关于长链接的服务中,提到了一个TIMEWAIT的解决方案,具体关于TIMEWAIT具体产生的原因,原理,对系统产生的影响,会在其他的文章中给出具体的说明和解释,这个简单介绍 ...
linux 进程状态 ri,LINUX下解决netstat查看TIME_WAIT状态过多问题(转)
# netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c 16 CLOSING 130 ESTABLISHED 298 FIN_WAIT1 13 FIN_WA ...

TCP断开时的状态与Linux nf_conntrack

TCP断开时的状态与Linux nf_conntrack相关推荐

最新文章

热门文章