Transcript Linux TCP/IP 优化案例详解 - idning

Linux TCP/IP 优化案例详解
搜索平台部
杨辉<nickyang>
2010/12/09
Linux TCP/IP 优化案例详解
跨机房传输文件为什么这么慢？
短连接传输速率还能提高吗？
我们后台服务时间才几十毫秒，为什么
我们的用户感知时间却是秒级的？
TCP/IP - 窗口机制
TCP/IP – 拥塞控制
TCP/IP – 拥塞算法
跨机房传输文件为什么这么慢？
问题
北京－上海间传输速率太慢，单socket 2MB/s左右。
可选方法
1）创建多个socket连接
2) 增大TCP缓冲(发送/接收）传输速率30MB/s
思考
为什么增大缓冲，就能提高传输速率？
为什么BJ 机房内不增大缓冲，也能达到几十兆的速
率?
发送/接收缓冲中，只调整一个，行不行？
跨机房传输文件为什么这么慢？
原理分析
带宽公式
网络带宽=(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,
数据传输最少占1个RTT，
即20ms×2.5=50ms
最大传输速率为1MB/50ms=20MB/s。
SOSO用户响应时间瓶颈在哪？
问题
www.soso.com,我们后台的服务时间几十毫秒，为什么
我们的用户感知的时间却是秒级？
瓶颈分析方向
用户感知服务时间 = 后台服务时间 + 公网（接入网）
数据传输时间 + 浏览器展现时间
搜索结果命中cache的情况下，办公区访问
www.baidu.com更快
思考
与www.baidu.com对比，差异应该主要在公网传输时
间上？ 传输时间如何测量？传输时间占多大比重? 后台服
务时间能够控制和优化，传输时间是否也能优化？
传输时间测量工具TCPFLOW
测试工具至关重要
后端
RBU/RBU_PROXY
tcpflow
Ngix:
www.soso.com
tcpflow线上采集点图示
Apache:
www.soso.com
Squid:
www.soso.com
TCP协议传输时间测试方法
t0
SYN
SYN ACK
ACK
t1
t2
GET-1
t3
GET ACK
DATA 1
t4
DATA2
Last DATA
Last
DATA
ACK
GET-2
t5
t6
t3
GET ACK
DATA 1
t4
DATA2
Last DATA
Last
DATA
ACK
t5
t6
RTT = t2-t1
后端服务时间 = t4-t3
数据传输时间 = max(t5 - t4 + RTT/2, t6-t4 – RTT/2)
服务响应时间= max(t5 - t3 + RTT/2, t6-t3 – RTT/2)
FIN/RST
ACK
瓶颈主要在传输时间
平均后台服务时间：接入网平均传输时间
= 1 ：10
瓶颈分析方向
平均请求的数据包的小 5 ~ 12左右
丢包情况 重复包率高
思考
平均传输数据量小，均属于短连接数据传输，短连接数
据传输速率受那些因素影响？
丢包后，平均传输时间均达到1-4s, 很大比例超过3s，
是否和丢包的机制有关？
传输时间瓶颈分析
频繁的慢启动
请求的应答数据少，频繁的进入慢启动过程
慢启动初始窗口2，丢包后慢启动窗口为1
delay Ack机制 导致慢启动窗口增长缓慢
超时重传
RTO与RTT采样有关，初始RTO为3s
客户端不支持timestamp选项，导致RTT采样不太精确
delay Ack最大延迟200MS,导致RTT采样速度和频率都
受影响
内核协议栈优化技术点
慢启动优化
增加慢启动初始发送窗口（2 - > 4~8，proc参数)
增加丢包后发送窗口（1-> 2~4, proc参数）
增加对窗口增加/减小速度进行控制的相关参数（proc)
(对比分析了baidu,google的相关参数，同时参考了
HSTCP和google论文中的解决方案）
超时重传优化
建立连接的过程中采样RTT,用于计算初始RTO (3s ->
max(200, 2RTT)
RTO计算 max(200,3RTT) -> (100, 2RTT)
部分快速重传取代超时重传，快速重传条件 3 -> 2
副作用
重复包率上升
SOSO优化效果
优化传输时间效果
北京联通 369ms
优化后181ms
深圳电信 490ms
203ms
上海电信 449ms
217ms
西安电信 417ms
205ms
西安教育网 834ms
399ms
下降188ms
287ms
232ms
212ms
435ms
50.8%
58.5%
51.7%
50.6%
52.2%
优化后与百度对比
北京办公区在结果检索结果均命中cache的情况下，明
显快于百度。
TCP/IP
窗口机制
滑动窗口与控制窗口
拥塞控制
控制控制过程
拥塞控制窗口变化
拥塞算法
各种算法简介
TCP/IP - 窗口机制
问题
假设网络中有两台主机A和B，主机A向B发送多个数据
包，为了避免数据包丢失，需要考虑哪些因素
滑动窗口
主机B接收缓冲区（rmem）的大小
A向B发送数据包的速度比B应用程序处理的快 －>
rmem溢出，数据包丢失 －>引入了滑动窗口协议
控制窗口
链路上节点负荷过大，导致缓冲队列溢出，数据包丢
失－拥塞 －>引入了拥塞控制窗口协议
MIN(滑动窗口，拥塞窗口)决定TCP传输速率
TCP/IP 拥塞控制过程
慢启动
拥塞窗口snd_cwnd初始化为2，然后在每个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_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/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
接收端收到了相同seq的数据包，怎么办?
收到两个相同seq的数据包，说明 没必要的重传；接收端在ACK TCP头部扩展域中加入
重复数据包的seq。－>发送端收到D-Sack，cwnd恢复重传前的设置。
TCP/IP拥塞算法简介
BIC
适合高时延、高带宽的网络，如BJ-SH,LINUX默认选项;
拥塞避免： cwnd＝cwnd+inc；inc = 1/ca->cnt
丢包： ssthreshold＝ssthreshold×（1－β）。
VEGAS
适合rtt波动大的网络, 即丢包率高的网络，
事前预测拥塞：在丢包之前，通过rtt的变化提前预测拥塞。
WESTWOOD
适合高带宽网络，其scalability比BIC差。
丢包：ssthresh= max(2, bw_est*rtt_min/mss)，bw_est为估计发送速率，
rtt_min为最小rtt。
Thanks