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

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

TCP交互式应用

作者：易隐者 发布于：2012-8-30 21:29 Thursday 分类：网络分析

       TCP交互式应用由于其交互的特性，一般对时延的要求较高，因此一旦有应用数据时便立即向对端发送并要求对端能够及时处理，其交互的报文基本上都是小包（小于MSS），常见的TCP交互式应用主要有telnet、rlogin、互动游戏等，我们先来看一个TCP交互应用的报文分析：

点击查看原图

其具有以下三个明显特点:

1，客户端与服务器端的数据传输是交互式进行的；

2，应用字段长度均较小；

3，带有应用字段的TCP报文PUSH位均置一。

TCP交互式应用的场景（以游戏为例）：

       对于实时网络游戏这种交互应用，如果TCP接收方不立即将应用数据提交应用程序处理的话，很可能会导致游戏应用出现卡、客户端与服务器端不同步等故障，严重影响游戏应用的正常运行。你想啊，你在玩CS，扮演警察，突然一个悍匪跟你正面冲突，悍匪那边快速操作已经移动位置了，但是悍匪移位这个应用信息却被你的TCP放在接收缓存里，你机器显示器上看到的悍匪还在原来的位置，然后你自然向悍匪原来的位置开枪，结果呢，肯定没伤到悍匪，却被早就移位的悍匪爆头击毙，这时候你会爽吗？肯定骂死这个游戏应用了，呵呵。
        那么交互式应用如何保证应用字段能够被立即处理呢？答案就是将带有应用字段的TCP报文（不论应用字段大小）的PUSH位全部置一，虽是小包，但TCP一旦接收到便立即将其交付应用程序处理。

       我在08年做内部《TCPIP详解卷一》培训在讲到第19章《TCP的交互数据流》时，曾今专门捕获了WAR 3的局域网游戏的交互报文，用于讲解TCP交互式应用的特性，现在把这个报文一并放在此供各位参考。

WAR 3的局域网游戏的报文：

点击查看原图

        交互式应用并不是非常常见，因此经常被大家忽略，导致有时在遇到交互应用场景的分析时，将其当作HTTP等常见应用的特性来进行分析，可想而知，如此将走向错误的分析方向，望各位兄弟姐妹引以为鉴。

        这里提到了TCP报文的一个非常重要的标志位——PUSH，我下一篇文章将会针对PUSH位做一个详尽的讨论和分析，望大家关注。

阅读全文>>

标签: 同步 TCP 应用字段 故障 push 交互式应用 交互

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

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