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

TCP Fast Open（TFO）

作者：易隐者 发布于：2013-1-10 15:22 Thursday 分类：网络分析

【说在之前】：

我在之前的博客文章《非标准TCP三次握手建立连接过程一例》一文中提到了非标准的TCP三次握手行为，今天在微博上看到有人转发有关TCP Fast Open（TFO）的文章，大致看了一下，了解到所谓的TCP Fast Open（TFO）就是利用三次握手的SYN报文来传输应用数据，也就是说，允许SYN报文中包含应用数据。这样做的好处是在客户端与服务器的交互过程中减少一个RTT来提高交互的效率，如此来看，TCP Fast Open（TFO）就是一个最为典型的非标准TCP行为，但是这种非标准的TCP行为由于其特性优势使其将成为国际标准，其具体的交互过程和原理大家可参考下面的文章和相关链接。

【原文链接】：

http://blog.sina.com.cn/s/blog_583f42f101011veh.html

【原文全文】：

    Google近日正式公布了TFO的paper，地址：http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN/us/pubs/archive/37517.pdf

    Google研究发现TCP三次握手是页面延迟时间的重要组成部分，所以他们提出了TFO：在TCP握手期间交换数据，这样可以减少一次RTT。根据测试数据，TFO可以减少15%的HTTP传输延迟，全页面的下载时间平均节省10%，最高可达40%。

    目前互联网上页面平均大小为300KB，单个object平均大小及中值大小分别为7.3KB及2.4KB。所以在这种情况下，多一次RTT无疑会造成很大延迟。

    在HTTP/1.1中，我们有了keep-alive。但实际应用并不理想，根据Google对一个大型CDN网络的统计，平均每次建连只处理了2.4个请求。

    为了证实TCP三次握手是目前页面访问的重要性能瓶颈之一，Google工程师分析了Google的web服务器日志及Chrome浏览器统计数据。

    2011年6月，对Google web服务器进行连续7天数十亿次针对80端口的请求分析，包括搜索、Gmail、图片等多个服务。其中第一次建连被称为cold requests，复用连接的请求称为warm requests。

    图中描述了在cold requests及all requests中TCP握手时间在整个延迟时间中的占比。在cold requests中，TCP握手时间占延迟时间的8%-28%；即使统计所有的请求，TCP握手时间也占到了延迟时间的5%-7%。

    对Chrome浏览器的统计持续了28天，当然仅限于愿意发送统计数据的用户。经过分析，即使打开了keep-alive，仍有33%的请求建立了新连接。主要原因可能为：为了加快下载速度，新版的浏览器对单个域名都会并行打开6-10个连接；而网页设计时也会把元素分配到多个域名上；NAT也可能关闭keep-alive；而手机端为了节省电源，也会尽快关闭空闲连接。

    图中对比了三条线，一条为all requests；一条为cold request；而cold req no hsk代表去除了TCP握手时间的cold requests延迟数据。Y轴把所有采样数据按数值分布到各个百分比区间。

对比证明：cold requests基本比all requests慢50%，而TCP握手时间在cold requests延迟时间中往往占比了25%。

    下面这幅图清楚的说明了TFO的设计：

1、用户向服务器发送SYN包并请求TFO cookie；

2、服务器根据用户的IP加密生成cookie，随SYN-ACK发给用户；

3、用户缓存住TFO cookie。

    再次访问时：

1、用户向服务器发送SYN包并携带TCP cookie，同时请求实体数据；

2、服务器校验cookie。如果合法，向用户发送SYN+ACK，在用户回复ACK之前，便可以向用户传输数据；如果cookie校验失败，则丢弃此TFO请求，视为一次普通SYN，完成正常的三次握手。

    因为用户使用DHCP，IP地址会改变；同时也为了防止攻击，服务器端会定期变换cookie。

建立了TFO连接而又没有完成TCP建连的请求在服务器端被称为pending TFO connection，当pending的连接超过上限值，服务器会关闭TFO，后续的请求会按正常的三次握手处理。

而一个带有TFO的SYN请求如果在一段时间内没有收到回应，用户会重新发送一个标准的SYN请求，不带任何其他数据。

    在集群环境中，所有服务器会使用相同的key。

    目前TFO被植入了Linux 2.6.34内核。

    为了验证TFO的作用，Google分别测试了全页面的下载时间及开启TFO对服务器性能的影响。平均来看，页面一般会包含44个元素，分布在7个域名中。同时浏览器会支持并行下载。抽样的测试对象为：亚马逊、纽约时报、华尔街日报和维基百科。可以看到RTT时间越大，TFO的效果越明显。当RTT为200ms时，改善达到了11%-41%。这对移动互联网尤其意义重大。

     那么TFO对服务器性能是否有影响呢？可以直观看出，完全没有，甚至在某些连接数区间，性能还有改善。

    网页访问的一步步优化看起来都是ms级别的，但对于大型网站来说，无形中影响的可能就是PV、用户满意度及收入。

【相关链接】：

http://www.pagefault.info/?p=282

http://blog.solrex.org/articles/tcp-fast-open-by-google.html

http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-01

阅读全文>>

标签: TCP SYN 非标准TCP cookie RTT TCP Fast Open TFO

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

多层架构业务应用场景下的网络分析

作者：易隐者 发布于：2012-11-22 13:06 Thursday 分类：网络分析

       我们在日常工作中，最为常见的网络分析场景为针对简单的C/S或B/S架构的应用的分析，在简单环境中，C/S或B/S架构的应用主要是一层架构的，如下图所示： 

       在这个架构的应用中，业务的交互仅仅涉及到客户端与服务器，这样的业务交互过程和报文交互路径都非常简单清晰，分析这种架构业务应用的性能问题、故障问题并不存在很大的难度，因为不会涉及过多的中间环节，但是在规模较大、应用较为重要和复杂的环境中，最为常见的是多层架构的业务应用系统。

三层/多层架构应用

       那么什么是多层架构的应用呢？我从网上找了一段文字，应该能够将其说明清楚：“所谓三层架构，是在客户/服务之间加入了一个"中间层"，也叫组件层。它与客户层、服务器层共同构成了三层体系。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才有三层体系结构，三层是指逻辑上的三层。通过引入中间层，将复杂的商业逻辑从传统的双层结构(Client-Server)应用模型中分离出来，并提供了可伸缩、易于访问、易于管理的方法，可以将多种应用服务分别封装部署于应用服务器，同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性，使用户在管理上所花费的时间最小化，从而实现了便捷、高效、安全、稳定的企业级系统应用。”

       三层架构主要分为表示层、业务逻辑层、数据访问层三层，每层主要负责的工作如下：

表示层：主要负责从用户收集信息，将用户信息发送到业务服务层做处理，从业务服务层接收处理结果，将结果显示给用户等；
业务逻辑层：主要负责从表示层接收输入，与数据层交互执行已设计的业务，操作（业务逻辑，系统服务等），将处理结果发送到表示层等；
数据访问层：主要负责数据存储，数据获取，数据维护，数据完整性等；

       下图为一个经典三层架构的应用示意图： 

       在实际工作环境中，最为简单和常见的三层架构的应用为下图所示：

       在这个架构中，其实是将表示层和业务逻辑层整合在一起，通过应用服务器统一对外提供业务访问界面和业务逻辑处理。
       我们遇到的大型、复杂的应用基本上都是基于多层架构开发的，针对多层架构应用的分析将是以后网络分析工作中无法回避的问题。

分析多层架构应用的难处

       针对多层架构应用的分析，可不像我们平时分析简单一层架构的B/S、C/S应用那样简单，分析多层架构的业务应用主要具有以下几点难度：

1， 业务数据交互路径更为复杂
       一个客户端访问多层架构的业务应用时，其业务数据交互路径一般如下图所示： 

1， 客户端向Web服务器发送相关业务应用的操作
2， Web服务器将客户端的相关业务操作请求交由应用服务器处理
3， 应用服务器将业务操作涉及到的相关数据请求发往数据库服务器
4， 数据库服务器将相关数据操作结果反馈给应用服务器
5， 应用服务器根据数据库服务器反馈的数据结合业务逻辑，得出相关信息发往Web服务器
6， Web服务器将客户端相关业务操作的反馈数据显示给客户端

       纵观整个交互的过程，我们可以知道同样一个业务操作的交互，多层架构的应用跟简单的一层架构的应用相比，多出了数个中间环节，这导致业务交互路径变得复杂，我们需要在不同的环节分别抓包做关联分析。这些都会增加网络分析的工作量和难度。

2，数据加密问题：数据库加密
       基于数据安全的角度，现在很多涉及到数据库的交互，其在应用层将数据库应用字段加密，如下图所示： 

       在这种情况下，我们站在网络交互的角度捕获的报文只能够提供三层和四层的相关信息，数据库应用数据信息均无法正常查看，因此我们无法分析到底哪一个报文是某个客户端的业务操作引发的应用服务器对数据库服务器的访问行为，这给我们的分析工作带来了巨大的不便。
       如果真的遇到加密的情况，那么站在网络层面对其报文进行分析已经无能为力了，建议在数据库服务器上站在业务应用的角度，调用其数据库日志进行辅助分析。

3，存在连接复用问题：连接复用
       一般情况下，如果客户端与服务器建立业务交互连接，那么可能涉及到的web服务器、应用服务器、数据库服务器之间都分别新建连接用于相关数据的交互，如下图所示： 

       但是在这个情况下，一旦客户端的访问的数量非常巨大或者访问峰值时的连接非常巨大，将导致应用服务器与数据库服务器之间的连接数非常大，严重影响数据库服务器的性能，为了解决这种问题，应用服务器在与数据库服务器之间交互时，采用连接复用的方式以节省服务器的资源，提高交互的性能和效率，如下图所示： 

       在这种方式下，应用服务器与数据库服务器之间只需要建立很少的连接，并将这些连接长期保持（长连接），后续的所有应用服务器与数据库服务器之间的增、删、改、查询等操作均通过已有的数条连接进行应用交互。如此大大降低了应用服务器与数据库服务器之间的连接数。

       连接复用给网络分析带来的问题是，我们不得不在数条连接中查找某个客户端具体操作对应的数据库报文，而每个数据库的连接均包含大量的数据库语句，有些是相近甚至是相同的数据库语句，这些无疑会给网络分析工作带来巨大的工作量和难度，如果同时间访问的客户端数量很多的话，这样的分析工作无异于大海捞针，基本上变得不可行了。

       上述三大难点，给我们分析多层架构的应用带来了非常大的难度，虽然如此，但是好在并不是所有的多层架构应用都是连接复用的，也不是所有的数据库交互都是加密的，如果实际工作中真的遇到了多层架构的应用需要我们进行分析，我们往往没有什么太多的选择余地，我们能做的就是尽己所能、尽力而为了。

多层架构应用的分析

       针对多层架构的业务应用的分析，我们一般按照如下的思路开展网络分析工作：

1， 关键路径多点同时捕包
       要针对多层架构的业务应用进行分析，必须在业务数据交互路径中的每个关键点进行捕包，以便后续的关联分析和对比分析。这个在我的文章《疑难网络故障的分析方法和原理之对比分析法》中介绍得非常清楚，大家可以访问http://www.vants.org/?post=49参考。
       在多层架构的应用中，我们主要需要在客户端与Web服务器之间、Web服务器与应用服务器之间、应用服务器与数据库服务器之间同时进行业务交互报文的猜忌和捕获，如下图所示： 

2， 捕包机器时间同步
       一般而言，我们可以通过NTP服务器将多台捕包机器的时间同步，但如果在条件不允许的情况下，大家可参考我的文章《如何保证中间设备两端捕获的数据包的时间同步性？》中提供的简单有效的方法来实现不同关键点捕包时间的同步，如下图所示： 

       在各个关键路径上的捕包机器时间都同步了，那么在大部分的情况下，我们就可以根据连接或报文发生的时间段在海量业务交互报文中提取跟业务操作相关的报文进行关联分析，从而提高关联的分析的效率。

3， 关联分析
       一旦全部准备就绪，那么剩下的工作就是根据不同位置捕获到的业务交互报文，利用应用层字段，如cookie值、sessionID、用户名、帐号、Userid、业务号、单号、ProcessID等关键字实现客户端<->Web服务器、Web服务器<->应用服务器、应用服务器<->数据库服务器之间的关联。下面我选取了部分在实际工作中遇到的多层架构应用中可关联的关键字截图以供参考： 

参考资料：
1，海万学——《多层结构应用性能分析与故障诊断》
       海万学是国内为数不多的网络分析方面的专家，其个人博客为：www.packetstory.com，就是更新有点慢，大家可关注。
2，gqming——《多层结构应用各层之间数据传递的问题》链接为：http://bbs.csdn.net/topics/190123492

阅读全文>>

标签: 同步 日志 网络分析 对比分析法 应用字段 关联分析 C/S 多层架构 连接复用 cookie 时间同步 B/S 三层架构

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