蚂蚁网-多维人生，三实而立！

TCP保活（TCP keepalive）

作者：易隐者 发布于：2012-10-15 11:30 Monday 分类：网络分析

TCP保活的缘起

       双方建立交互的连接，但是并不是一直存在数据交互，有些连接会在数据交互完毕后，主动释放连接，而有些不会，那么在长时间无数据交互的时间段内，交互双方都有可能出现掉电、死机、异常重启等各种意外，当这些意外发生之后，这些TCP连接并未来得及正常释放，那么，连接的另一方并不知道对端的情况，它会一直维护这个连接，长时间的积累会导致非常多的半打开连接，造成端系统资源的消耗和浪费，为了解决这个问题，在传输层可以利用TCP的保活报文来实现。

TCP保活的作用

1， 探测连接的对端是否存活
        在应用交互的过程中，可能存在以下几种情况：
（1）， 客户端或服务器端意外断电、死机、崩溃、重启
（2）， 中间网络已经中断，而客户端与服务器端并不知道
        利用保活探测功能，可以探知这种对端的意外情况，从而保证在意外发生时，可以释放半打开的TCP连接。

2， 防止中间设备因超时删除连接相关的连接表

       中间设备如防火墙等，会为经过它的数据报文建立相关的连接信息表，并为其设置一个超时时间的定时器，如果超出预定时间，某连接无任何报文交互的话，中间设备会将该连接信息从表中删除，在删除后，再有应用报文过来时，中间设备将丢弃该报文，从而导致应用出现异常，这个交互的过程大致如下图所示：

       这种情况在有防火墙的应用环境下非常常见，这会给某些长时间无数据交互但是又要长时间维持连接的应用（如数据库）带来很大的影响，为了解决这个问题，应用本身或TCP可以通过保活报文来维持中间设备中该连接的信息，（也可以在中间设备上开启长连接属性或调高连接表的释放时间来解决，但是，这个影响可能较大，有机会再针对这个做详细的描述，在此不多说）。

常见应用故障场景：

       某财务应用，在客户端需要填写大量的表单数据，在客户端与服务器端建立TCP连接后，客户端终端使用者将花费几分钟甚至几十分钟填写表单相关信息，终端使用者终于填好表单所需信息后，点击“提交”按钮，结果，这个时候由于中间设备早已经将这个TCP连接从连接表中删除了，其将直接丢弃这个报文或者给客户端发送RST报文，应用故障产生，这将导致客户端终端使用者所有的工作将需要重新来过，给使用者带来极大的不便和损失。

TCP保活报文格式：

1， TCP keepalive probe报文

       我们看到，TCP保活探测报文是将之前TCP报文的序列号减1，并设置1个字节，内容为“00”的应用层数据，如下图所示：

发送keepalive probe报文之前的TCP报文

 TCP keepalive probe报文

2， TCP keepalive ACK报文

        TCP保活探测确认报文就是对保活探测报文的确认， 其报文格式如下：

TCP keepalive ACK报文

TCP保活报文交互过程

        TCP保活的交互过程大致如下图所示：

TCP保活可能带来的问题

1， 中间设备因大量保活连接，导致其连接表满

       网关设备由于保活问题，导致其连接表满，无法新建连接（XX局网闸故障案例）或性能下降严重
2， 正常连接被释放

       当连接一端在发送保活探测报文时，中间网络正好由于各种异常（如链路中断、中间设备重启等）而无法将该保活探测报文正确转发至对端时，可能会导致探测的一方释放本来正常的连接，但是这种可能情况发生的概率较小，另外，一般也可以增加保活探测报文发生的次数来减小这种情况发生的概率和影响。

TCP保活的设置

        一般而言，保活探测主要在服务器端实现，如果应用层有相应的保活机制时，传输层的TCP保活就可以不用。

        在windows系统中，我们可以通过修改注册表等来达到开启、调整保活相关
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
KeepAliveInterval
项：Tcpip\Parameters
数值类型：REG_DWORD - 时间（以毫秒为单位）
有效范围：1 - 0xFFFFFFFF
默认值：1000（1 秒）
说明：此参数确定在收到响应之前，保活重传之间的时间间隔。一旦收到一个响应，将由 KeepAliveTime 值重新控制在下一次保活传输之前的延迟。如果经过 TcpMaxDataRetransmissions 指定的重新传输次数后仍无响应，将放弃连接。
KeepAliveTime
项：Tcpip\Parameters
数值类型：REG_DWORD - 时间（以毫秒为单位）
有效范围：1 - 0xFFFFFFFF
默认值：7,200,000（两个小时）
说明：此参数控制 TCP 试图通过发送保活数据包来验证空闲连接是否仍然保持的次数。如果远程系统仍然可以连接并且正在运行，它就会响应保活传输。默认情况下不发送保活数据包。应用程序可以在连接上启用此功能。

       关于Linux、HP UNIX、IBM AIX、SUN solaris等系统keepalive参数的设置和修改，请大家自行百度谷歌，在此我就不做简单搬砖的事情了。

阅读全文>>

标签: 防火墙 保活 keepalive 连接表 TCP保活 TCP keepalive

评论(7) 引用(0) 浏览(76096)

网页打开慢但HTTP下载快故障分析案例

作者：易隐者 发布于：2012-10-10 16:06 Wednesday 分类：网络分析

【说在之前】：

1，用到了疑难杂症网络分析过程中最基本、最核心的两个分析方法：对比分析法和关联分析法；

2，该案例涉及到的知识点主要有SYN重传、连接数限制等，大家可参考本博客中相关知识点的文章。

【我的案例】：

故障环境

       某单位大体的网络结构如下图所示： 

内部办公人员通过交换机到流控设备，再通过防火墙做NAT访问互联网。

故障现象

1，在地矿局进行互联网时，打开网页的速度非常的慢，有的网页要刷新几次才可以正常显示；
2，但是使用下载工具或是基于HTTP的下载速度却很快。

故障分析

1 确认故障原因

        我们找一台主机，访问互联网的某网站，发现的确比较慢，我们抓取故障时的交互数据包，如下图所示： 

       通过上图，我们可以发现，客户端在与服务器建立TCP连接时，其SYN请求报文被客户端重传了一次，这个重传导致了2.88秒的延时。TCP重传一般是中间设备丢包导致的，那么到底是在什么地方丢包的呢？我们首先需要界定一下可能丢包的故障关键点。

2 选择故障关键点

       该故障环境相对简单，在办公用户访问互联网时，数据包只通过了交换机、流控设备和防火墙，而交换机主要负责转发数据，不会对数据包进行深度的检测和过滤等操作，所以在该环境下主要的关键故障点是流控设备和防火墙，如下图所示：

 

3分析流控设备是否丢包

       关键故障点确定之后，我们首先在流控设备的前后同时抓包做对比分析，以确定是否是流控设备丢包，如下图所示： 

       通过我们还原故障现象时，在流控设备前后抓取数据包的对比分析，结论显示，流控设备前后数据包交互的过程是一样的（这个对比分析通过五元组关联同一会话之后，对比查看数据交互过程的差异即可，由于流控设备前后的数据交互过程完全一样，在此不做具体详细的分析说明），这说明，在打开页面较慢时，流控设备并未丢弃任何交互的数据报文。

4 分析防火墙是否丢包

       同样，我们再在防火墙的进出口同时抓包，通过比较防火墙前后数据包的交互情况来确定造成故障的原因，部署图如下所示： 

1， 在访问某网站出现缓慢现象时，在防火墙前后同时抓取数据包，并保存，为下面的对比分析提供原始的数据报文。
2，我们先分析防火墙内网口抓取的数据，在科来网络分析系统的“TCP会话”视图，我们发现了一个web连接持续的时间为6秒，并且其在三次握手过程中，存在重传现象，如下图所示： 

这个TCP会话的源端口是1124，目的地址为58.30.236.11，目的端口是80
3，我们通过关联分析法，在进行网页访问时，我们在防火墙前后同时进行抓包，下图就是在防火墙出口处抓取到的数据包： 

       我们知道防火墙在网络运行中起到防护作用，会将未经授权的报文过滤，但是防火墙一般不会阻止正常的数据包，我们在比较上面两张图发现，在防火墙后捕获到的数据包第一次发送同步请求没有成功，然后又重传了一次同步数据包，才成功建立了连接；而在防火墙前面抓取到的数据包却没有看到重传的数据包（黑框标记的部分），这很清晰的说明，第一个SYN报文被防火墙丢弃了。

4 分析结论

       通过上面的分析，我们可以得出如下结论：

       由于防火墙在转发数据包时，随机丢弃了客户端发送的SYN报文而造成的。可能是防火墙配置不当（连接数限制）或防火墙BUG（在处理TCP新建连接时不稳定）导致的。

总结

       经过分析知道是由于防火墙不规律丢弃SYN报文导致的网页打开慢现象，但是为什么HTTP下载的速度却很快？这是因为防火墙仅随机丢弃SYN报文，而HTTP下载在刚开始建立TCP连接时，防火墙有可能会丢弃其SYN报文，但是下载行为决定其会不断发起SYN报文进行连接建立的尝试，而一旦连接建立成功，则防火墙不会丢包，给用户的感觉就是速度也非常快。

阅读全文>>

标签: TCP 对比分析法 关联分析法 丢包 SYN 防火墙 重传 BUG NAT 连接数限制 SYN报文

评论(4) 引用(0) 浏览(11885)

多次RST以及不同场景下的RST报文的差异

作者：易隐者 发布于：2012-10-9 11:27 Tuesday 分类：网络分析

      在某个TCP交互过程中，我们发现在交互的后期，客户端多次向服务器端发送RST报文，如下图所示： 

        我们首先来看客户端发出的第一个RST报文的解码： 

       RST与ACK标志位都置一了，并且具有ACK number，非常明显，这个报文在释放TCP连接的同时，完成了对前面已接收报文的确认。

       我们再来看看客户端发出的后续RST报文的解码： 

       我们可以看到，这些后续的RST报文仅Reset位置一，ACK位未置一，在这种情况下，该报文的ACK确认号应该为0，但是我们留意到在这个报文中，其ACK确认号与序列号是一致的。

       这是为什么呢？

       因为ACK位未置一，ACK确认号也就失去了意义，因此，不论ACK确认号是什么值都不会对接收端产生影响，因此大部分的系统都会将ACK确认号设置为0，之所以在这个报文中出现ACK确认号非0而是与序列号一致的情况，个人认为应该是该主机端系统的处理机制与大部分系统不一样导致的。

       另外，我们也看到了wireshark的专家系统在此处给出了提示，由此可见wireshark在传输层的专家系统的强大之处。

       为什么前后RST报文会出现这种差异？

       原因为第一个RST报文是异常释放TCP连接的，在端系统发送RST报文之前，这个TCP连接尚在端系统的连接表中，因此其ACK位置一并且具有ACK确认号。而客户端后续收到DATA报文，因其连接表中已经没有相关信息与之对应，此时客户端发送的RST报文ACK位无需置一。

       也许有朋友会问：服务器端为什么在收到客户端的RST报文后，还继续给客户端发送报文呢？

       原因只有一个，那就是TCP成块数据流。服务器端一次性向客户端发送数个数据块，在客户端发出第一个RST报文之后，后续的报文已经在网络中传输了，并陆续达到客户端。

       其交互过程大致如下： 

阅读全文>>

标签: TCP wireshark RST ACK 连接表 TCP成块数据流 端系统 ACK确认号 连接

评论(0) 引用(0) 浏览(37048)

端系统对RST报文的过滤

作者：易隐者 发布于：2012-10-8 17:00 Monday 分类：网络分析

       前段时间在分析网上一个兄弟传给我的报文时，发现了几个有意思的现象，我觉得值得分析讨论，我们首先来看一个服务器与客户端交互的会话： 

       在这个交互的过程中，我们可以看到一个比较奇怪的现象，那就是客户端10.16.137.56在收到来自服务器的FIN报文之后，紧接着向服务器端发送RST报文，但是服务器给其回应了一个ICMP主机管理性禁止差错报文，并且不断尝试向服务器发送FIN报文。
       我们来看一下服务器给客户端回应的ICMP主机管理性禁止差错报文的解码： 

       Type 3，Code 10——主机管理性禁止差错，其封装的原始报文报头信息显示，该ICMP差错报文正是由客户端发往服务器端的RST报文引起的。下图为客户端发往服务器端的RST报文解码： 

       另外，我们注意到，服务器发送给客户端的ICMP差错报文的TTL值为48，而服务器端发送给客户端的FIN报文报头中的TTL值也是48，如下图所示： 

       这从侧面说明这个ICMP差错报文的确是服务器端系统发送的，而不是中间设备发出的。

       那么为什么服务器端系统会过滤掉客户端的RST报文呢？

       想想TCP会话劫持和TCP RST攻击，大家就能够体会，服务器管理员为什么这么做了。

       TCP会话劫持的实施者经常会扮演对端的身份分别向客户端或服务器端发送RST报文，以达到干扰客户端与服务器端正常交互的目的。有些服务器的管理员可能遇到过这种TCP会话劫持的攻击，因此在服务器端系统上利用相关工具设置了过滤RST报文的策略，当服务器收到RST报文时，直接忽略掉，因此服务器端系统的传输层并不会收到这个RST报文。

       其交互过程大致如下图所示：

过滤RST报文可能带来的影响

       服务器传输层无法收到客户端的RST 报文，只能在多次尝试重传FIN报文直至超时，然后主动向客户端发送RST报文。如此带来的影响就是执行过滤策略的端系统无法正常处理来自于TCP连接对端的异常释放行为（RST），这将导致端系统的TCP连接释放需要更长的时间，在有大量对端通过RST报文异常释放TCP连接的场景下，可能会对性能产生一定的影响。

阅读全文>>

标签: TCP RST icmp差错 会话劫持 TTL FIN type 3 code 10 端系统

评论(2) 引用(0) 浏览(13218)

某业务系统由于连接数限制导致间歇性访问慢故障分析案例

作者：易隐者 发布于：2012-9-26 18:05 Wednesday 分类：网络分析

【说在之前】：

1，该案例为端系统设置连接数限制导致的应用间歇性缓慢故障，在实际工作环境下，我们更容易遇到的是中间系统对连接数限制导致的一些范访问异常，令人头疼的是，并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文，这会给大家分析定位带来难度，大家在实际工作中需要留意；

2，该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”，关于ICMP主机管理性禁止差错报文，大家可参考本博客《ICMP通讯管理性过滤禁止差错报文（type 3，code 13）》一文，虽然“type 3，code 10”与“type3，code 13”有些差异，但是差别不大，可以借鉴；关于连接数相关知识点，大家可参考本博客《连接数相关知识》一文；

【我的案例】：

1 故障环境

网络拓扑：

说明：
1，内部办公机器都是192.168.1.0/24段的，内部办公主机通过防火墙做NAT，转换为X.X.X.138访问互联网；
2，内部办公服务器的地址为192.168.1.191，其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程：
       内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示： 

2 故障现象

       故障现象主要表现为：
1，部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况，如下图所示： 

打开主页时的长时间等待页面截图 

登录时长时间等待页面截图

2，这些故障现象间歇性出现，有时多刷新几次页面后，打开的速度会恢复正常。
3，外网用户访问业务系统一直正常，该故障已经持续数月。

3 故障分析

       通过故障现象，我们可以看出，这是比较典型的部分系统出现问题的案例，由于其不具备全体的故障特征，又是间歇性的发生，因此，此类故障按照常规的分析方法很难找到真正的故障原因，我们还是先在客户端抓取一下故障时交互的数据包，站在数据包的角度来分析一下可能的原因。
1，找一台出现故障的主机192.168.1.167，捕获其打开主页面缓慢时的数据包。
2，查看缓慢时的数据交互情况，如下图所示： 

       我们通过delta tima值可以看到，这个交互的过程存在较大的延时，并且我们发现，在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文，这些报文都是X.X.X.139发给故障主机192.168.1.167的。
3，我们双击其中一个ICMP主机通讯管理性禁止报文，查看其封装的被过滤的原报文相关信息，如下图所示：

       我们发现，被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。
4，我们再结合上下数据包交互的情况，我们可以发现，这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文，如下图所示： 

       这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时，被服务器管理性过滤禁止了。
5，那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢？难道服务器上设有针对源端口为4075的禁止访问策略吗？服务器显然没有做这种针对源端口过滤的必要，另外，我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外，还有其他源端口的SYN请求报文被服务器管理性禁止，如下图所示： 

       这里被服务器禁止的报文的源端口有4078、4083、4086等。
       另外，通过上图中的“delta time”值，我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间（SYN重传时间，大家可参考本博客《TCP重传》一文），从而导致了页面打开缓慢的现象出现。
6，这个现象具有明显的针对TCP的随机性的过滤特性，因此，我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制？而在传输层最为常见的就是TCP连接数限制了。
       一般而言，在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情，一个独立的IP只允许与服务器建立少量的TCP连接，这对于那些对外提供服务的服务器来说是一种较为常见的防护措施，在正常情况下，单个客户端与服务器的正常交互所需要的TCP连接数并不是很多，而限制的数值一般都会高于正常的需求，但是在有些情况（如经过NAT或代理后对业务的访问）下，这将导致问题的产生。
7， 上述推理非常合理，我们通过检查服务器的相关设置，验证了我们的分析和推论结果。
8， 分析结论：
       这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能，而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问，这直接导致在业务访问高峰时，出口NAT IP地址访问业务服务器的连接数超出限制，业务服务器对后续的TCP连接建立请求发出ICMP差错报文，等一些TCP连接释放后，才允许新建TCP连接，这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。

4 故障解决

       通过修改服务器Apach对单一IP地址的连接数的限制后，故障得到解决。

阅读全文>>

标签: 疑难故障 TCP icmp差错 SYN 连接数 NAT 地址转换 业务慢 连接数限制 ICMP主机管理性禁止差错报文 Type 3 Code 13 type 3 code 10

评论(2) 引用(0) 浏览(11337)