欢迎关注: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) 浏览(39028)

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