TCP性能分析技术及其应用20121231

Page*TCP性能技术　　　　及其应用HUAWEITECHNOLOGIESCO.,LTD.Www.huawei.com2012.12.10陈爱军WTL解决部最新版本请访问：http://3ms.huawei.com/hi/blog/408_14244.htmlPage*目录4TCP原理3Socket原理12TCP抓包和分析工具6应用案例背景：为什么要学习TCP性能分析技术？5TCP问题定位思路和Page*2010.08.17：初稿完成。2011.09.02：关于窗口设置略大于BDP增加说明。2011.10.24：修正了超时重传后的慢启动门限错误问题。2012.06.15：增加TCP稳态速率和TCP环回时长分析，增加win7下TCP接收窗口　　　　　　自动调整算法的相关说明。2012.10.25：补充说明windows回复TCPACK的具体行为。2012.12.10：补充快速重传和超时重传时拥塞窗口随时间的变化图；补充总体定位思路和方法。2012.12.31：TCP问题定位思路部分增加socket分析。修订Page*【问题现象】拉脱维亚DORev.A系统，在DOS窗口中进行FTP上传吞吐量正常，但在IE窗口进行FTP上传时吞吐量低于DOS窗口下FTP吞吐量。拉脱维亚IE窗口FTP上传吞吐量低问题背景TCP原理Socket原理应用案例工具【初步定位】现场和总部的开发人员经过近一个月的定位，也没搞清楚根本原因，只好答复客户：“DOS窗口下进行FTP上传没问题，说明我们系统没问题，IE窗口下进行FTP上传有问题，是操作系统的问题，请找微软解决”，客户对此答复非常不满，扬言“必须尽快解决，否则投诉到公司高层”。1.6Mbps,速率正常400kbps,速率低！Page*拉脱维亚IE窗口FTP上传吞吐量低问题背景TCP原理Socket原理应用案例工具Page*【最终解决】该问题通过对抓包数据的深入分析，最终搞清楚了问题是由于使用IE进行FTP上传时的TCP发送缓冲区大小默认设置太小（8KB）引起，修改为64KB后问题解决。拉脱维亚IE窗口FTP上传吞吐量低问题这个问题提醒我们：对操作系统的TCP/IP实现不了解会影响问题定位速度，而且处理不好的话还会大大影响客户满意度。发送缓冲区大小只有8KB，受限接收窗口没有受限背景TCP原理Socket原理应用案例工具Page*【问题现象】荷兰项目一期测试时，使用常见的测试软件对我们的系统进行吞吐量测试没问题，但使用第三方的测试设备进行测试时上传和下载的吞吐量都非常低。局方人员一再强调Z公司使用该测试设备测试没问题。荷兰第三方测试FTP上传下载吞吐量低问题【初步定位】现场和总部的开发人员只好排查我们自己的设备问题，花了一周时间无结果。【最终解决】最终通过对抓包数据从TCP角度进行深入分析，以充分的理由说服了局方：是第三方测试软件的问题引起的上传下载吞吐量低。争取到了宝贵的重测机会，为项目的最终成功打下了很好的基础。背景TCP原理Socket原理应用案例工具Page*荷兰第三方测试FTP上传下载吞吐量低问题这个问题提醒我们：通过对TCP行为的深入分析可以找出应用软件的问题；反之，如果对TCP原理的理解太粗浅，当出现应用软件的问题时会束手无策。客户端应用软件1s取1次数据，造成下载吞吐量低！客户端应用软件0.5s发32KB数据，造成上传吞吐量低！为什么Z公司测试没问题呢？最终局方确认：Z用的测试软件版本和我们不同。背景TCP原理Socket原理应用案例工具Page*【问题现象】南非WiMAX吞吐量测试时发现FTP下载速率波动大。BS分片重组设计缺陷导致下载吞吐量波动大【初步定位】抓包发现TCP错包，包中内容出错位置恰好和R6口分片位置吻合，怀疑是IP分片重组出了问题。背景TCP原理Socket原理应用案例工具Page*BS分片重组设计缺陷导致下载吞吐量波动大通过对终端、BS、R6口、Server的抓包数据进行深入分析，最终发现送往BS的IP包是正常的，但BS在进行IP分片重组时出了问题：将同一ID的前一个IP包的第1个分片与后一个IP包的第2个分片重组在一起。背景TCP原理Socket原理应用案例工具Page*BS分片重组设计缺陷导致下载吞吐量波动大这个问题提醒我们：吞吐量测试仅仅利用DUMeter来观察速率是远远不够的，必须关注TCP/IP的行为，否则原本通过吞吐量测试就可以发现的问题很容易被遗漏到网上。什么情况会触发上述IP分片重组出错呢？丢包！可是从抓包数据来看并没有丢包呀？正确答案是：曾经丢包！R6口1个IP分片的丢失会引发后续的同一ID的所有IP分片重组全部出错！【最终解决】BS修改IP分片重组算法，增加IP分片重组定时器，在一定时间内如果相应的另外1个IP分片没有到达就丢弃该IP分片，保证1个IP分片的丢失只影响这1个IP分片的重组，不影响同一ID的后续IP分片重组。背景TCP原理Socket原理应用案例工具Page*目录4TCP原理3Socket原理12TCP抓包和分析工具6应用案例背景：为什么要学习TCP性能分析技术？5TCP问题定位思路和方法Page*常用抓包工具背景TCP原理Socket原理应用案例工具Windows：Ethereal/Wireshark实质上是同一个软件,安装和使用操作都非常简单，是我们最常用的抓包软件。最初叫Ethereal，2006年起叫Wireshark。当时Ethereal的主要开发者决定离开原来供职的公司，并继续开发这个软件。但由于Ethereal这个名称的使用权已经被原来那个公司注册，Wireshark这个新名字也就应运而生了。Linux：tcpdumptcpdump-ieth2-s0-x-wfile.pcapport1812注：请自行替换eth2为实际的网卡编号Solaris：snoopsnoop-deth2-ofile.pcapport1812注：请自行替换eth2为实际的网卡编号Page*TCP序号分析TCP序号分析：statistics-TCPstreamgraph-Time-SequenceGraph1）进行TCP序号分析时，光标要停在数据上，不要停在TCPACK上！2）TCP序号的概念，绝对序号和相对序号设置方法。3）图片的放大/缩小、平移：注意藏在后面的小窗口！4）数据关联：主窗口不见了怎么办？（老版本Ethereal存在该问题）5）TCP序号－时间图的具体含义参见：利用Ethereal进行TCP性能分析背景TCP原理Socket原理应用案例工具Page*TCP吞吐量分析TCP吞吐量分析：statistics-IOgraphs可以分析总吞吐量和各TCP连接（最多4个连接）的吞吐量。注：我们做的一个二次开发版本可以分析最多9个连接的吞吐量。背景TCP原理Socket原理应用案例工具Page*TCPRTT分析TCPRTT分析：statistics-TCPstreamgraph-RoundTripTimeGraph对TCP发端数据进行分析，得到RTT（包发出和收到TCPACK的时间差）。背景TCP原理Socket原理应用案例工具Page*目录4TCP原理3Socket原理12TCP抓包和分析工具6应用案例背景：为什么要学习TCP性能分析技术？5TCP问题定位思路和方法Page*TCP连接建立背景TCP原理Socket原理应用案例工具TCP连接建立过程客户端在通过TCP发送或接收数据之前，必须先建立TCP连接。TCP连接建立过程是通过三次握手实现的：[SYN]和[SYN,ACK]中会携带本端的MSS、接收窗口大小及窗口扩大因子，对端收到后，向本端发送数据时：TCP净荷大小会受到MSS的限制，TCP序号会受到接收窗口大小×窗口扩大因子的限制。注：对于FTP，数据连接有可能由服务器发起（主动模式），也可能由客户端发起（被动模式），具体参见：FTP主动模式和被动模式Page*TCP数据传输过程1、客户端和服务器的操作系统要为每个TCP连接分配对应的接收缓冲区和发送缓冲区。2、TCP负责将数据从发送端的TCP发送缓冲区发往接收端的TCP接收缓冲区。3、发送端的操作系统负责将上层应用的数据写入TCP发送缓冲区，接收端的操作系统负责将TCP接收缓冲区的数据送往上层应用。TCP数据传输背景TCP原理Socket原理应用案例工具Page*发端和收端的基本行为发端根据TCPACK发送数据，收端收到数据回复ACK。TCP基本行为背景TCP原理Socket原理应用案例工具收端：收2个报文回1个ACK发端：收到ACK后触发发包，最开始的每收到1个ACK发送3个报文，运行一段时间之后，TCP会进入一种稳定状态：接收端收2个报文回1个ACK，发送端收1个ACK发送2个报文。具体参见：深入解读TCP慢启动阶段的发包速率如果把TCP发端和收端之间的通道看作一个管道，TCP稳态情况下，流入这个管道的数据量和流出的数据量是相同的，换句话说管道中容纳的数据量是恒定的。Page*TCP稳态TCP序号－时间图，前面是慢启动阶段，之后进入稳态。后面在分析速率时，除非特别说明，否则指的都是稳态下的速率。TCP稳态速率背景TCP原理Socket原理应用案例工具Page*TCP稳态速率TCP稳态下的速率，取决于TCP窗口大小和BDP的关系。TCP窗口BDP当TCP窗口>BDP时，TCP稳态速率会不会进一步增大而超过瓶颈带宽呢？当然不会，速率还是会稳定在瓶颈带宽。那会带来什么影响呢？RTT的增大！RTT=TCP窗口/带宽TCP稳态速率背景TCP原理Socket原理应用案例工具Page*TCP窗口BDPTCP最初慢启动阶段的发包速率大于瓶颈带宽，发出的数据会在带宽瓶颈之前的缓冲区中产生堆积，越积越多。RTT>RTT0TCP环回时长背景TCP原理Socket原理应用案例工具Page*TCP窗口>BDP直至进入稳态，TCP发包速率等于瓶颈带宽，也就是说出缓冲区和入缓冲区的数据速率都等于瓶颈带宽，缓冲区中堆积的数据量不再增加。。缓冲区中堆积的数据产生了固定时延，导致时延增大。RTT=TCP窗口/带宽RTT=缓存时间+RTT0数据缓存时间=RTT-RTT0=TCP窗口/带宽-RTT0缓存数据量=带宽×缓存时间=TCP窗口-BDPTCP环回时长背景TCP原理Socket原理应用案例工具Page*TCP缓冲区大小的设置原则1、发送缓冲区和接收缓冲区的大小一般设置为相同的值。2、缓冲区的大小一般设置为略大于BDP。TCP缓冲区设置过大越大越好吗？缓冲区设置过大会导致RTT增加，带来两个弊端：1）丢包重传时速率恢复会变慢，因为重传包也会在缓冲区中排队发送。2）会导致RTT测量变得迟钝，无法跟上系统时延的变化，造成无谓的重传或重传不及时。具体参见后面RTT测量部分。TCP缓冲区设置背景TCP原理Socket原理应用案例工具Page*Windows下TCP缓冲区设置1、Windows操作系统中缓冲区的管理主要由AFD模块来完成。2、缓冲区大小的确定：如果应用程序指定了缓冲区的大小，则按应用程序指定的大小分配缓冲区，否则操作系统按如下优先级为TCP分配缓冲区：1）发送缓冲区DefaultSendWindow，如果无设置，默认为8192B（即4096B*2）注：有可能不同的操作系统版本默认值不同。2）接收缓冲区TCP缓冲区设置WindowsXPSP2：DefaultReceiveWindowTcpWindowSizeGlobalTcpWindowSizeWindowsXPSP1：TcpWindowSizeGlobalTcpWindowSizeDefaultReceiveWindow背景TCP原理Socket原理应用案例工具Page*Windows下TCP缓冲区设置如果注册表中没有上述设置，则操作系统按网络适配器上报的比特速率来确定接收缓冲区的大小：8KB（Bitrate＜1Mbps）17KB（1Mbps≤Bitrate＜100Mbps）64KB（Bitrate≥100Mbps）例如：10Mbps以太网，接收缓冲区大小为：1460*12=17520B100Mbps以太网，接收缓冲区大小为：1460*44=64240BWindows7：默认开启TCP窗口自动调整算法，从实测情况来看，大部分情况下TCP窗口过大，例如：3MB如果关闭TCP窗口自动调整算法，则TCP窗口固定为64KB，无非通过注册表进行修改。关闭方法：请用最新版本的TcpOptimizer，将Tcpwindows选项中选择“Disable”。TCP缓冲区设置背景TCP原理Socket原理应用案例工具Page*Windows下TCP缓冲区设置3、缓冲区大小的修改：可以通过注册表进行修改，也可以由应用程序通过socket接口进行修改。1）注册表TcpWindowSize和GlobalTcpWindowSize一般在注册表中如下位置进行修改：DefaultReceiveWindow和DefaultSendWindow一般在注册表中如下位置进行修改：TCP缓冲区设置HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\ParametersHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters背景TCP原理Socket原理应用案例工具Page*Windows下TCP缓冲区设置2）socket接口通过setsockopt()函数携带如下选项即可修改缓冲区的大小：　　SO_RCVBUF：指定接收缓冲区大小　　SO_SNDBUF：指定发送缓冲区大小TCP缓冲区设置背景TCP原理Socket原理应用案例工具Page*TCP数据发送和接收TCP收发包流程图这两张图清晰地描述了：发端如何发包，收端如何回ACK的过程。计算发包数量N启动发包N=0?N=N-1发出1个包N启动该包的重传定时器开始慢启动启动一轮发包重传定时器超时中断重传数据包cwnd=1ssthresh=65535cwnd=1ssthresh=65535处理完毕发包完毕Y超时重传慢启动是重复ACK？是第3个重复ACK？YYNNcwnd=cwnd+1NY收到ACK拥塞避免cwnd=cwnd+1/cwnd重传丢失的包cwnd>ssthresh？慢启动处理完毕启动新一轮发包ssthresh=cwnd/2cwnd=ssthresh+3启动新一轮发包快速重传快速恢复Ycwnd=cwnd+1前1个是否为重复ACK？Ncwnd=ssthresh+1Y是第1、2个重复ACK？Ncwnd保持不变TCP接收流程图TCP发送流程图背景TCP原理Socket原理应用案例工具Page*TCP数据发送和接收TCP发包数量以往大家熟知的TCP发包字节数：不超过接收窗口和拥塞窗口的大小。严格来讲是不够准确的，准确的计算公式及其示意图如下所示：发包字节数=MIN｛发送缓冲区中数据字节数，接收窗口，拥塞窗口｝－已发送未确认数据字节数背景TCP原理Socket原理应用案例工具Page*TCP窗口1、接收窗口1）泛指接收缓冲区的大小。2）接收缓冲区能够接收的数据字节数（接收缓冲区空出的字节数），实质上就是接收缓冲区的大小减去未送往应用层数据部分。又称为通告窗口。2、发送窗口1）泛指发送缓冲区的大小。2）可发送的数据就处于发送窗口中，发送窗口大小指的就是可发送的数据量。3、拥塞窗口发送端站在避免拥塞的角度，根据收到的ACK数量计算的应发送的数据字节数。TCP收到每个ACK都会对拥塞窗口进行更新，具体如何更新与收到ACK时所处的阶段（慢启动、拥塞避免、快速重传、快速恢复、超时重传）有关。具体会在“TCP发送端行为”中讲解。TCP数据发送和接收背景TCP原理Socket原理应用案例工具Page*TCP接收端行为TCP接收端行为1、基本行为收包，回ACK，告诉发端某序号之前的包已正常接收，当前缓冲区还空多大空间。适当时候将数据从接收缓冲区送往上层应用。2、具体行为1）收2个包，回1个TCPACK：2）如果第2个包在200ms内没有收到，定时器超时会触发接收端发TCPACK，该情况下所回的ACK称为Delayed-ACK，200ms定时器称为Delayed-ACKtimer背景TCP原理Socket原理应用案例工具Page*TCP接收端行为TCP接收端行为3）如果发现丢包，对于后续收到的每一个包回1个重复ACK。4）重传的包收到后，会和之前收到的所有包一起回ACK。5）接收端所回的ACK默认情况下是选择性ACK（SACK），ACK中携带了接收端已经接收到的包序号信息，发送端重传时只重传没有接收到的部分即可。6）满足下面任何一个条件时数据被送往应用层缓冲区：　应用程序已经通过调用recv()做好数据接收的准备　TCP头部中PSH被置1。　TCP接收缓冲区溢出。　数据在TCP接收缓冲区中存放的时间超过了0.5s。　如果注册表中IgnorePushBitOnReceives被置1，则TCP收到1个包就会立即将其送往上层应用。从实际抓包数据来看，windows操作系统的实现是：收到1个包会立即将其送往上层应用。发生乱序或丢包情况下，数据会被暂存在接收缓冲区中，直至收到乱序或重传的数据后才会送往上层应用。7）实际回ACK的行为比上面讲的要复杂，参见：深入解析Windows操作系统TCPACK回复机制背景TCP原理Socket原理应用案例工具Page*TCP接收端行为TCP相关参数的修改1、回ACK的频率收到几个包回1个ACK可以修改，修改方法：：XPSP1：TcpDelAckTicks，取值范围0~6，默认为2，修改为0则每个包都回ACK。XPSP2：TcpAckFrequency，取值范围0~255，默认为2，修改为1则每个包都回ACK。2、延迟ACK定时器Delayed-ACKtimer可以修改，默认是200ms。　XPSP1：TcpDelAckTicks：取值范围0~6，默认为2，修改0则收到包立即回ACK。XPSP2：TcpDelAckTicks：取值范围2~6，默认为2，修改为0或1还是200ms。3、忽略PSHIgnorePushBitOnReceives可以修改，默认是0。IgnorePushBitOnReceives：取值范围0或1，默认为0，改为1则每收到1个包就立即送往应用层。背景TCP原理Socket原理应用案例工具Page*TCP发送端行为TCP发送端1、基本行为接收TCPACK，将确认的数据从发送缓冲区中清除，并发出适当数量的数据包。发包数量取决于：　发包数量=MIN｛发送缓冲区中数据字节数，接收窗口，拥塞窗口｝－已发送未确认数据字节数2、具体行为1）不停进行RTT测量，确定RTO(超时重传定时器)。2）连接建立后先进入慢启动，拥塞窗口按指数增长。3）拥塞窗口达到慢启动门限后进入拥塞避免，拥塞窗口线性增长。4）收到第2个重复ACK，会启动快速重传，进入快速恢复。5）RTO定时器超时如果还未收到ACK，则启动超时重传，之后进入慢启动。背景TCP原理Socket原理应用案例工具Page*TCP发送端行为TCP发送端3、发包流程图计算发包数量N启动发包N=0?N=N-1发出1个包N启动该包的重传定时器开始进入慢启动启动一轮发包重传定时器超时中断重传数据包cwnd=1ssthresh=65535cwnd=1处理完毕发包完毕Y超时重传进入慢启动是重复ACK？是第3个重复ACK？YYNNcwnd=cwnd+1NY收到ACK拥塞避免cwnd=cwnd+1/cwnd重传丢失的包cwnd>ssthresh？慢启动处理完毕启动新一轮发包ssthresh=cwnd/2cwnd=ssthresh+3启动新一轮发包快速重传快速恢复进入拥塞避免Ycwnd=cwnd+1前1个是否为重复ACK？Ncwnd=ssthresh+1Y是第1、2个重复ACK？Ncwnd保持不变背景TCP原理Socket原理应用案例工具Page*TCP发送端行为TCP发送端1）RTT测量基本原理：在1个RTT时间内只会启动1次测量。在用于RTT测量的包的ACK包回来之前发送的其它包都不会启动RTT测量。RTO：RTOnew=β[αRTOold+(1-α)RTT]α：是滤波因子，例如：α取80%表示历史RTT占80%，新测得的RTT占20%。Β：一般取值为2，也就是RTO一般取测得的RTT的2倍。背景TCP原理Socket原理应用案例工具Page*TCP发送端行为TCP发送端2）慢启动定义：TCP建立之初，慢启动门限初始化为65535字节，cwnd=1(MSS)，之后每收到1个ACK，cwnd=cwnd+1，直至cwnd≤ssthresh，慢启动结束。之所以叫慢启动，是相对于没有拥塞控制只有流控的情况下发送端一次发下不超过接收窗口大小的数据来讲的。慢启动过程：拥塞窗口更新：每收到一个ACK拥塞窗口加1（MSS）：cwnd=cwnd+1假定接收端收到1个包，回1个ACK，ssthresh=16cwnd=1，第一个RTT期间，发出1个包，回来1个ACK，cwnd=2，第二个RTT期间，发出2个包，回来2个ACK，cwnd=4，第三个RTT期间，发出4个包，回来4个ACK，cwnd=8，第四个RTT期间，发出8个包，回来8个ACK，cwnd=16，达到慢启动门限，慢启动阶段结束。背景TCP原理Socket原理应用案例工具TCP发送端行为TCP发送端慢启动特征：拥塞窗口大小随时间指数上升。　　　　　　　　　　慢启动和拥塞避免情况下拥塞窗口大小随时间的变化规律注：为方便起见，在描述拥塞窗口时使用的单位都是1个MSS（最大段尺寸），实际中使用的拥塞窗口单位都是字节。Windows的实现：深入解读TCP慢启动阶段的发包速率背景TCP原理Socket原理应用案例工具Page*TCP发送端行为TCP发送端3）拥塞避免定义：cwnd超过慢启动门限即进入拥塞避免阶段。拥塞避免过程：拥塞窗口更新：cwnd=cwnd+1/cwnd，假定cwnd=16，cwnd=16，第一个RTT期间，发出16个包，回来16个ACK，cwnd=17，第二个RTT期间，发出17个包，回来17个ACK，cwnd=18，第三个RTT期间，发出18个包，回来18个ACK，cwnd=19，第四个RTT期间，发出19个包，回来19个ACK，cwnd=20，……拥塞避免特征：拥塞窗口大小随时间线性上升。背景TCP原理Socket原理应用案例工具Page*TCP发送端行为TCP发送端4）快速重传定义：收到3个重复ACK即启动快速重传，进入快速重传阶段。快速重传过程：重传数据包，不需要等到重传定时器超时。快速重传特征：收到3个重复ACK后立即重传数据包。注：启动快速重传的重复ACK数量可以在注册表中修改。TcpMaxDupAcks：取值范围1~3，默认为2。背景TCP原理Socket原理应用案例工具Page*TCP发送端行为TCP发送端5）快速恢复定义：快速重传结束后，不进入慢启动阶段，而是进入拥塞避免阶段，这就是快速恢复。快速恢复过程：慢启动门限更新：更新为当前cwnd的一半：ssthresh=cwnd/2拥塞窗口更新：cwnd=ssthresh+3（MSS）背景TCP原理Socket原理应用案例工具cwndSlowStartssthreshCongestionAvoidancePacketLossDetectedRTTFastRecoveryCongestionAvoidanceFastRetransmitPage*TCP发送端行为TCP发送端6）超时重传定义：在超时定时器超时之前，没有收到ACK，也没有收到重复ACK，则进入超时重传阶段。超时重传过程：重传定时器超时后，重发数据包。拥塞窗口更新：cwnd=1之后进入慢启动阶段。背景TCP原理Socket原理应用案例工具RTTPage*目录4TCP原理3Socket原理12TCP抓包和分析工具6应用案例背景：为什么要学习TCP性能分析技术？5TCP问题定位思路和方法Page*Socket原理背景TCP原理Socket原理应用案例工具Socket原理E2E流程图客户端:10.70.9.63服务器:10.70.9.64socket(af_inet,tcp,0)socket:508socket(af_inet,tcp,0)socket:264bind(264,0.0.0.0:60000)0listen(264,5)0accept(264)10.70.9.63:1205socket:536connect(508,10.70.9.64:60000)10035send(536,APP发送BUF指针和长度)Recv(508,APP接收BUF指针和长度)APP接收BUF收到数据的字节数发送到TCP发送BUF的数据字节数closesocket(508)0closesocket(536)0closesocket(264)0启动监听创建连接发送数据发送数据接收数据send(508,APP发送BUF指针和长度)发送到TCP发送BUF的数据字节数Recv(536,APP接收BUF指针和长度)APP接收BUF收到数据的字节数接收数据断开连接停止监听客户端程序操作系统操作系统服务器程序TCP连接释放流程TCP连接建立流程TCP数据传输过程TCP数据传输过程断开连接准备接收准备接收Page*Socket原理Socket原理应用程序调用send()和recv()函数发送和接收数据，不过只是写入TCP发送缓冲区和从TCP接收缓冲区读出数据。Socket发送和接收流程图：接收端程序发送端程序接收端OS发送端OSsend（APP发送BUF指针和长度）APP发送BUF数据写入TCP发送BUF返回（写入TCP发送BUF字节数）recv（APP接收BUF指针和长度）TCP接收BUF数据写入APP接收BUF返回（写入APP接收BUF字节数）-PSH被置1-TCP接收BUF满-数据存放超过0.5s如果1次写不完则分多次写入，直至全部写完为止背景TCP原理Socket原理应用案例工具Page*目录4TCP原理3Socket原理12TCP抓包和分析工具6应用案例背景：为什么要学习TCP性能分析技术？5TCP问题定位思路和方法Page*TCP问题定位思路总体定位思路1、使用iperf从发端向收端冲UDP包，如果吞吐量可以达到理论值，说明问题与TCP有关，否则说明问题与TCP无关，建议使用UDP冲包进一步进行问题定位。2、确认问题与TCP有关后，如果TCP速率稳定，说明没有丢包；否则说明有丢包。3、如果有丢包，需要多点同时抓包，逐段排查丢包位置。4、如果无丢包，有可能是TCP窗口问题，也可能是TCPACK出了问题，数量减少或被延迟发送。还有一个可能是：应用程序向TCP发送缓冲区中写入数据不及时，或者从TCP接收缓冲区中读取数据不及时，导致吞吐量低。5、同时建立多个TCP连接，如果速率达到理论值，在发送端抓包，分析TCP接收/发送窗口、TCPACK的数量和时延，看看是接收端的接收窗口出了问题，还是发送端的发送窗口出了问题，抑或是TCPACK数量减少或者被延迟发送（例如空口带宽请求或调度出了了问题，或者TCPACK被打包发送）造成TCP吞吐量达不到理论值，或者是应用程序向TCP发送缓冲区中写入数据不及时，或者从TCP接收缓冲区中读取数据不及时，导致吞吐量低。6、TCP上下行同传时，由于TCPACK和数据一起排队发送，会导致上行或下行的吞吐量达不到单独传送时的吞吐量，这是TCP机制造成的。相关原理参见：TCP上传下载并发速率理论分析背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路TCP速率分析使用IOGraph分析各TCP连接的吞吐量。背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路TCP接收窗口分析使用WindowsScalingGraph分析TCP接收窗口。背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路TCP发送窗口分析使用FlightSize分析TCP发送窗口。背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路TCP丢包分析：丢包位置分析使用TimeSequenceGraph分析丢包情况。背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路TCP丢包分析：突发流量造成的丢包使用TimeSequenceGraph进行突发流量造成的丢包分析。背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路TCP丢包分析：切换丢包使用TimeSequenceGraph进行切换丢包分析。背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路TCPACK分析使用TimeSequenceGraph分析TCPACK情况。TCPACK每隔360ms上来一堆，RTT高达360ms。背景TCP原理Socket原理应用案例工具Page*TCP问题定位思路Socket分析使用TimeSequenceGraph分析应用软件行为。TCP接收端应用软件从TCP缓冲区中读取数据不及时，导致TCP接收缓冲区中的数据越来越多直至满，TCP接收窗口越来越小，直至为零，TCP停止发包。背景TCP原理Socket原理应用案例工具Page*目录4TCP原理3Socket原理12TCP抓包和分析工具6应用案例背景：为什么要学习TCP性能分析技术？5TCP问题定位思路和方法Page*列出了通过TCP/IP行为分析定位的一些典型问题，展现了TCP/IP行为分析技术不断研究和深入应用的过程，具有很高的参考价值。典型案例介绍序号案例名称1数据业务性能测试：成功定位1xSCH传不动问题2数据业务性能测试：定位了网卡不禁用导致的吞吐量大幅波动问题3外部项目性能测试：解决白俄罗斯EVDO下载吞吐量低问题4外部项目性能测试：解决拉脱维亚IE窗口FTP上传吞吐量低问题5外部项目性能测试：定位荷兰上传下载吞吐量低问题6外部项目性能测试：解决荷兰HTTP下载吞吐量低于FTP问题7外部项目性能测试：解决南非FTP下载吞吐量低问题8外部项目性能测试：定位南非FTP上传初始阶段速率过高问题9外部项目性能测试：解决澳大利亚TCP下载吞吐量低于UDP问题背景TCP原理Socket原理应用案例工具Page*典型案例介绍[案例1]数据业务性能测试：成功定位1xSCH传不动问题USB抓包工具应用的典型案例。Commview抓包结合USBmonitor抓包，使用Ethereal进行分析，发现了BSC的FMR板在RLP重传包处理方面的一个BUG，是USB抓包工具USBmonitor的第一次成功应用。[案例2]数据业务性能测试：定位了网卡不禁用导致的吞吐量大幅波动问题超时重传类问题的典型案例。Ethereal抓包发现：网卡不禁用情况下计算机会向拨号网络发出一些以该网卡IP为源地址的“非法包”，PDSN收到之后触发了PPP重协商，重协商期间PDSN不再转发该拨号网络的数据，导致吞吐量大幅波动。长期困扰大家的问题得以解决。该案例中用到了Commview抓包和PPP日志。后续此类问题可以使用Ethereal/Wireshark的最新版本来定位，新的版本能够抓到PPP协商过程。背景TCP原理Socket原理应用案例工具Page*典型案例介绍[案例3]外部项目：解决白俄罗斯EVDO下载吞吐量低问题接收窗口类问题的典型案例。所有能想到的因素都让现场人员排查过了，包括：修改注册表将TCP接收窗口设置为64KB，修改完要重启计算机，现场人员说都做了。但从“起多个TCP连接吞吐量正常”的现象来分析，非常象TCP接收窗口受限引起。于是让现场人员抓包分析，果然不出所料，TCP接收窗口只有16KB。怀疑现场人员修改注册表有误，请现场人员使用Tcpoptimizer修改后吞吐量正常，问题解决。[案例4]外部项目：解决拉脱维亚IE窗口FTP上传吞吐量低问题发送窗口类问题的典型案例。在客户端IE窗口中进行FTP时的TCP发送窗口默认设置过小，修改为64KB后问题解决。[案例5]外部项目：定位荷兰上传下载吞吐量低问题应用软件类问题的典型案例。最终定位为是第三方测试软件问题引起。具体参见背景部分的介绍。背景TCP原理Socket原理应用案例工具Page*典型案例介绍[案例6]外部项目：解决荷兰HTTP下载吞吐量低于FTP问题发送窗口类问题的典型案例。现场调测时使用了WindowsXP操作系统，启动了IIS服务，进行HTTP下载，下载的吞吐量低于FTP下载的吞吐量。抓包分析是服务器侧发送缓冲区大小受限，只有8KB。试图通过修改注册表来解决这个问题，试遍了网上能够查到的所有方法都无效，只好咨询微软，最终回复：WinXP下无法修改。改用windows2003server问题解决。[案例7]外部项目：解决南非FTP下载吞吐量低问题快速重传类问题的典型案例。终端侧计算机、基站、R6口、服务器同时抓包进行深入分析，最终定位是BS分片重组算法设计缺陷引发的TCP错包、丢弃，触发快速重传，吞吐量下降。增加分片重组定时器后问题解决。[案例8]外部项目：定位南非FTP上传初始阶段速率过高问题慢启动速率问题的典型案例。局方要求给出令人信服的解释。抓包后，结合TCP慢启动原理对拥塞窗口进行分析，最终得出结论：慢启动阶段的发包速率是空口带宽的1.5倍，数据在终端内被缓存，空口带宽是恒定的。背景TCP原理Socket原理应用案例工具Page*典型案例介绍[案例9]外部项目：解决澳大利亚TCP下载吞吐量低于UDP问题终端处理能力受限导致出现速率瓶颈类问题的典型案例。由于TCP下载时上下行速率是相互影响的，只好使用UDP发包（前向发UDP包的同时在反向发UDP包）来模拟TCP下载，使用WaveJudge抓包，以定位速率瓶颈是否出在终端处，此方法对定位终端处理能力受限类问题非常有效。背景TCP原理Socket原理应用案例工具Page*《TCP性能分析技术及其应用》《TCP/IP详解（第一卷）》《Socket网络编程原理》更多资料请访问：http://3ms.huawei.com/hi/blog/408_14244.html附件：参考资料Page*ThankYouwww.huawei.com