《linuxtcp优化案例详解.ppt》由会员分享，可在线阅读，更多相关《linuxtcp优化案例详解.ppt（20页珍藏版）》请在三一文库上搜索。
1、Linux TCP/IP 优化案例详解,搜索平台部 杨辉 2010/12/09,跨机房传输文件为什么这么慢？ 短连接传输速率还能提高吗？ 我们后台服务时间才几十毫秒，为什么我们的用户感知时间却是秒级的？ TCP/IP - 窗口机制 TCP/IP 拥塞控制 TCP/IP 拥塞算法,Linux TCP/IP 优化案例详解,问题 北京上海间传输速率太慢，单socket 2MB/s左右。 可选方法 1）创建多个socket连接 2) 增大TCP缓冲(发送/接收）传输速率30MB/s 思考 为什么增大缓冲，就能提高传输速率？ 为什么BJ 机房内不增大缓冲，也能达到几十兆的速率? 发送/接收缓冲中，只调整
2、一个，行不行？,跨机房传输文件为什么这么慢？,原理分析 带宽公式 网络带宽=(win*MSS)/rtt win=min发送窗口，拥塞窗口 BJ-BJ RTT 1ms BJ-SH RTT 20-30ms,跨机房传输文件为什么这么慢？,问题 短连接下，BJ和SH间发送1MB的文件, 传输速率太慢，只有4MB/s。 解决方法 修改内核，增大TCP初始窗口（滑动窗口、拥塞窗口） 传输速率提高到12MB/s 思考 12MB/s是否已经是上限了，还有提高的余地吗?,短链接传输速率还能提高吗？,速度是否已经达到上限 TCP传输一个1MB的文件最少需要2.5个RTT TCP三次握手占用1.5个RTT, 数据传
3、输最少占1个RTT， 即20ms2.5=50ms 最大传输速率为1MB/50ms=20MB/s。,短链接传输速率还能提高吗？,问题 ,我们后台的服务时间几十毫秒，为什么我们的用户感知的时间却是秒级？ 瓶颈分析方向 用户感知服务时间 = 后台服务时间 + 公网（接入网）数据传输时间 + 浏览器展现时间 搜索结果命中cache的情况下，办公区访问更快 思考 与对比，差异应该主要在公网传输时间上？ 传输时间如何测量？传输时间占多大比重? 后台服务时间能够控制和优化，传输时间是否也能优化？,SOSO用户响应时间瓶颈在哪？,测试工具至关重要,传输时间测量工具TCPFLOW,RTT = t2-t1 后端服
4、务时间 = t4-t3 数据传输时间 = max(t5 - t4 + RTT/2, t6-t4 RTT/2) 服务响应时间= max(t5 - t3 + RTT/2, t6-t3 RTT/2),TCP协议传输时间测试方法,平均后台服务时间：接入网平均传输时间 = 1 ：10 瓶颈分析方向 平均请求的数据包的小 5 12左右 丢包情况 重复包率高 思考 平均传输数据量小，均属于短连接数据传输，短连接数据传输速率受那些因素影响？ 丢包后，平均传输时间均达到1-4s, 很大比例超过3s，是否和丢包的机制有关？,瓶颈主要在传输时间,频繁的慢启动 请求的应答数据少，频繁的进入慢启动过程 慢启动初始窗口2
5、，丢包后慢启动窗口为1 delay Ack机制 导致慢启动窗口增长缓慢 超时重传 RTO与RTT采样有关，初始RTO为3s 客户端不支持timestamp选项，导致RTT采样不太精确 delay Ack最大延迟200MS,导致RTT采样速度和频率都受影响,传输时间瓶颈分析,慢启动优化 增加慢启动初始发送窗口（2 - 48，proc参数) 增加丢包后发送窗口（1- 24, proc参数） 增加对窗口增加/减小速度进行控制的相关参数（proc) (对比分析了baidu,google的相关参数，同时参考了HSTCP和google论文中的解决方案） 超时重传优化 建立连接的过程中采样RTT,用于计算初
6、始RTO (3s - max(200, 2RTT) RTO计算 max(200,3RTT) - (100, 2RTT) 部分快速重传取代超时重传，快速重传条件 3 - 2 副作用 重复包率上升,内核协议栈优化技术点,优化传输时间效果 北京联通 369ms 优化后181ms 下降188ms 50.8% 深圳电信 490ms 203ms 287ms 58.5% 上海电信 449ms 217ms 232ms 51.7% 西安电信 417ms 205ms 212ms 50.6% 西安教育网 834ms 399ms 435ms 52.2% 优化后与百度对比 北京办公区在结果检索结果均命中cache的情况
7、下，明显快于百度。,SOSO优化效果,窗口机制 滑动窗口与控制窗口 拥塞控制 控制控制过程 拥塞控制窗口变化 拥塞算法 各种算法简介,TCP/IP,问题 假设网络中有两台主机A和B，主机A向B发送多个数据包，为了避免数据包丢失，需要考虑哪些因素 滑动窗口 主机B接收缓冲区（rmem）的大小 A向B发送数据包的速度比B应用程序处理的快 rmem溢出，数据包丢失 引入了滑动窗口协议 控制窗口 链路上节点负荷过大，导致缓冲队列溢出，数据包丢失拥塞 引入了拥塞控制窗口协议 MIN(滑动窗口，拥塞窗口)决定TCP传输速率,TCP/IP - 窗口机制,慢启动 拥塞窗口snd_cwnd初始化为2，然后在每个
8、RTT内增大，即每收到一个ACK包，snd_cwnd+=1。当snd_cwnd超过阈值snd_ssthresh时，进入拥塞避免阶段。tcp_slow_start,delay ack机制导致snd_cwnd增长更慢 拥塞避免 snd_cwnd已经超过阈值snd_ssthresh，为了避免拥塞，snd_cwnd缓慢增大。每收到一个ACK增大1/snd_cwnd。tcpbic_cong_avoid, delay ack机制导致snd_cwnd增长更慢 丢包 当发生数据包丢失时，TCP认为网络中存在拥塞，将减小拥塞窗口的大小，降低发送速率。timeout loss: snd_ssthresh= snd
9、_cwnd/2，snd_cwnd = 1；dup-ack loss : tcp_fastretransmit_alert, tcp_cwnd_down,TCP/IP 拥塞控制过程,窗口变化 影响拥塞窗口 tcp_cwnd_restart（rto时间未传数据），tcp_process_frto，tcp_enter_frto_loss，tcp_complete_cwr，tcp_undo_cwr，tcp_enter_cwr，tcp_cwnd_down，tcp_moderate_cwnd，tcp_cwnd_application_limited，tcp_create_openreq_child,TCP
10、/IP拥塞控制过程,Reno - TCP/IP默认拥塞算法 超时：ssthresh = cwnd/2，cwnd=1；快速重传：ssthresh = cwnd/2，cwnd= ssthresh+3（/pros/sys/net/ipv4/tcp_reordering）；快速重传(Reno)从丢失的数据包算起，全部重传。 SACK - 选择重传 用TCP扩展头部，接收端告诉发送端哪些数据包已经收到；发送端标志sk_buf，说明该数据包已经正确传输；重传丢失的数据包。 FACK 由sack确认的包之间的数据包，丢失 还是 其它? Sack之间的所有数据包，认为已丢失。 D-SACK 接收端收到了相同s
11、eq的数据包，怎么办? 收到两个相同seq的数据包，说明 没必要的重传；接收端在ACK TCP头部扩展域中加入 重复数据包的seq。发送端收到D-Sack，cwnd恢复重传前的设置。,TCP/IP拥塞算法简介,BIC 适合高时延、高带宽的网络，如BJ-SH,LINUX默认选项; 拥塞避免： cwndcwnd+inc；inc = 1/ca-cnt 丢包： ssthresholdssthreshold（1）。 VEGAS 适合rtt波动大的网络, 即丢包率高的网络， 事前预测拥塞：在丢包之前，通过rtt的变化提前预测拥塞。 WESTWOOD 适合高带宽网络，其scalability比BIC差。 丢包：ssthresh= max(2, bw_est*rtt_min/mss)，bw_est为估计发送速率，rtt_min为最小rtt。,TCP/IP拥塞算法简介,Thanks,