欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

应用层保活行为

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

        我之前专门针对TCP保活撰写了一篇较为详细的说明文章——《TCP保活（TCP keepalive）》，在传输层主要通过TCP的保活功能来实现连接的保持，当时我也提到应用层的保活功能，但是应用层的保活功能在实际工作中较为少见，因为如果TCP能够提供保活功能的话，应用层一般就可以利用TCP的保活功能来实现连接的保活，但是毕竟应用层跟传输层是有区别的，一方面并不是所有的应用层会话都需要实现保活功能，另一方面TCP是针对传输层的，一旦开启TCP保活功能，将对所有基于TCP的应用产生影响，这些影响可能会是负面的，如我博客里的案例：《由TCP保活引起的业务访问故障案例》，这也是运维管理者不愿意看到的，因此，有些应用自行设计自己的应用层保活行为。

       近期在用户的工作环境中，看到了如下图所示的应用层交互行为： 

点击查看原图

       大家可以清晰的看到，这个交互过程具有以下行为特征：
1， 客户端每间隔固定时间（30秒）发出同样的请求；
2， 每次交互的报文都是一致的（客户端的请求、服务器的响应、报文长度等）；

       个人认为这些行为特征足以证明该交互过程是应用层设置的应用连接保活探测行为。

阅读全文>>

标签: TCP 明文 故障 运维管理 保活 行为特征 TCP保活 应用保活

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

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) 浏览(81812)

TCP 的PUSH标志位

作者：易隐者 发布于：2012-8-31 15:32 Friday 分类：网络分析

       发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括接收方已经接收放在接收缓存的数据和刚刚收到的PUSH位置一的TCP报文中封装的应用数据。
还是看一个简单明了的图示吧：

点击查看原图

关于PUSH位的一些讨论和分析

       Long_323（龙的传人）兄弟曾跟我讨论：在无法解码应用层报文时，能否根据TCP  PUSH位来分析应用响应时间？

       我的回答是：不可以，我个人不会这么做，因为不够科学。

       所谓应用响应时间，是指客户端有发出请求，服务器端会针对该请求作出相应的响应，我们才可以分析计算其响应时间。如果我们无法解码应用层，那么我们就无法确定其到底是不是一个请求报文，如果不是请求报文（例如，我的《TCP交互交互式应用》一文中提到的互动游戏的报文、TCP keepalive保活的报文等）但是其TCP PUSH位是置一的，那么我们怎么能根据这一点就计算出应用的响应时间呢？

       也许有经常关注我的兄弟会问：你说不可以，那怎么在你写的文章《关于“client push”应用响应时间测量方法的讨论》中，建议说“从客户端带有PUSH标志位的数据包开始计算，至服务器端响应应用层数据停止计算”呢？如果真有这么问的兄弟，我会非常欣慰，因为能问出这个问题的人，说明他有认真仔细的研读过我的文章，那么他肯定会从中获得一些帮助和成长，我会为此而心生满足。言归正传，在我的《关于“client push”应用响应时间测量方法的讨论》一文里，全文的基础和基调都已经定在为“client push”的应用场景了，看标题你就会明白，不需要我多说了吧。

       言已至此，我想大家也会明白，我说的不可以并不是绝对不可以，而只是站在我个人的角度而说的，仅代表我的个人主观选择。

       在有些情况下，可以作为一个参考分析思路。那么到底在哪些情况下能这么做呢？我个人认为主要有以下几点：
1， 可以明确我们要分析的应用类型为请求-响应类的应用
2， 虽不能解码，但是我们在做分析时，需要将具体的请求操作和数据报文结合起来分析，以提高分析的科学性和准确性
3， 对分析的结果要求不是非常高、非常严谨的

       还有兄弟认为如果所有带有应用字段的TCP报文PUSH位都置一的话，会对服务器造成较为严重的性能影响。这个所谓的影响如果真的存在的话，我想应该是在服务器的内存、CPU等资源严重不足或应用程序本身处理存在严重性能问题时才会出现，是因为本来就有问题了，导致PUSH位都置一的报文加重了这种影响，而不是因为PUSH位置一的报文导致了服务器的性能问题的出现。

关于PUSH位的应用

        PUSH位就是用来通告接收方立即将收到的报文连同TCP接收缓存里的数据递交应用进程处理。一般会出现在发送方封装最后一个应用字段的TCP报文中，针对TCP交互式应用，则只要封装有应用字段的TCP报文，均会将PUSH位置一，当然，应用程序的开发者，可以根据需要，在某个应用功能模块或某个应用操作时，将所有封装应用字段的TCP报文PUSH位置一，以提高交互双方的处理效率，这在理论上应该也是可行的。

  

阅读全文>>

标签: TCP 应用字段 响应时间 应用响应时间 ART 保活 push 交互式应用 client push 接收缓存 keepalive

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

基于UDP的应用如何保证应用数据的可靠性

作者：易隐者 发布于：2012-8-28 22:58 Tuesday 分类：网络分析

       UDP的传输效率比TCP更高一些，其在网络中交互时具有更小的延时，因为其一，发送方只要把应用字段全部交给网络层处理就行了，接收方不需要确认发送方发送的数据，发送方也没有等待接收方确认报文这些过程；其二，TCP报头一般20个字节，UDP报头只有8字节，因此UDP跟TCP相比，在同长度的IP报文中能够承载更多的有效应用数据。

       很多应用设计者和开发者正是看中了UDP的这种特性，将他们的应用程序利用UDP来实现端对端的数据交互，但是UDP不可靠，它没有TCP的确认、重传、窗口、保活等机制，那么基于UDP的应用如何保证其应用数据在交互过程的可靠性呢？答案是由基于UDP的应用程序来完成。

    为此我花费了点时间找了一些基于UDP 的应用报文解码，我们一起逐一来看看吧。 

TFTP（应用层确认）：  

点击查看原图

某UDP应用（应用层保活）：

点击查看原图

RTP(应用层排序)： 

点击查看原图

DHCP：（应用层标识） 

点击查看原图

       上次有个网友问我QQ传大文件的时候，为什么没抓到分片包文？我的回答是：应用层做了分片。虽然我并不清楚QQ文件传输协议的具体工作机制，但是其实跟我上面分析讨论的一样，QQ利用UDP传输文件，抓包的时候也看到的确是UDP的连接，但是没看到分片报文，那么原因只能是QQ应用程序为了保障传输文件的可靠性，避免在网络层被分片，应用程序在将大的应用字段交付给UDP之前，针对大的应用字段做了分片处理，这个过程跟TCP的MSS协商后做分段处理有点类似。

       现实工作环境下常见的UDP应用主要有P2P下载、视频会议、在线视频、VOIP语音、在线游戏等，有兴趣的兄弟姐妹，可以找一些工作环境中的这些应用的报文，来验证或完善一下我上述所言，如果找到的话，记得给我留言，顺便把报文给我一份。

阅读全文>>

标签: UDP 基于UDP的应用 可靠性 DHCP RTP TFTP 保活

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

Powered by 易隐者 基于emlog 皖ICP备12002343号-1