networking performance of android

1. *
网络协议及其性能

2. 应用层：http0.9、http1.0、http1.1、http2.0 、spdy
网络层：路由、NAT、ip分片
数据链路层：移动网络性能、电量分析
物理层：3g、4g、wifi网络特点
传输层：tcp协议性能优化
app层：volley、okhttp、推送

3. TCP/ip历史
1947-1991，冷战，美苏争霸。
1970，unix诞生。1972，unix用C语言重写。
1970末－1980初，unix大规模商业应用。
1973，美国国防部ARPAnet项目开发TCP协议。
1977，一个叫Jon Postel的大神批评TCP协议：由于违背层级
原理，我们设计的互联网协议已经一团糟。特别是我们试图使
用TCP协议做下面二件事情：1、用作主机层级的端到端协议。

4. TCP/ip历史
2、用作网络包和路由协议。这二项服务应该通过层级和模块
化的方式完成。我建议建立一个新的互联网网络协议，在这个
协议中TCP层只用作主机层级的端到端服务。
1978，第三个迭代的TCP协议把TCP和IP分离开来，并且延
续至今。
1980，第四个迭代的TCP/IP协议开发完成，成为现代网络第
一个正式标准（IPV4）。
总结：TCP/IP协议的流行有其历史原因，它自身开放、高可
靠、高扩展的特点也是重要原因。

5. TCP/三次握手

6. TCP/流量控制
预防发送端过多的向接收端发送数据的机制。为实现流量控制，
TCP 的两端都要通告自己的接收窗口（rwnd）。如果一端跟
不上数据传输，就会向发送端通告一个较小的窗口，因此接收
的一端更可能成为性能瓶颈。

7. TCP/slow start

8. Slow start和拥塞避免算法

9. TCP/队首阻塞

10. 带宽延时积
▪ 假设rwnd和cwnd最小值16kb，往返时间RTT为100ms：
不管发送端和接受端实际带宽多大，这个TCP连接的数据传输
速率不会超过1.31Mbit/s。

11. 带宽延时积
▪ 假设往返时间RTT不变100ms，发送端、接收端带宽为
10Mbit/s，若充分利用10Mbit/s的带宽，则：
窗口至少需要122.1KB才能充分利用10Mbit/s带宽！
所以窗口大小有时候是TCP性能的限制因素。

12. Nagle算法
如果当前要发送的数据小于一个完整的TCP包数据段MSS，
发送将被延迟，数据将被缓存，直到：
▪ 有更多的数据需要发送，待发送数据凑齐一个完整的TCP包
数据段大小
▪ 或者前一个数据包被客户端确认了（收到客户端发来的ACK
包）

13. Delayed ACK
如果当前只需要发送一个确认包，那么客户端就hold on，直
到：
▪ 有后续的包需要发送，例如一个或多个数据包/ACK包（客户
端可能连续收到好几个数据包需要确认）。
▪ 或者等待超过预设的timeout时间。（参见IETF RFC
1122 4.2.3.2 When to Send an ACK Segment，这个预设时
间应该 < 500ms）

14. Nagle算法和Delayed ACK导致的高延时
如果发送方用Nagle算法，接收方用Delayed ACK：假设client
向server请求2048Bit的数据，MSS=1460。则server发送一个
MSS TCP包，2048-1460=588<MSS，因此server hold on，
等待客户端的确认包。
Client收到了1460Bit数据，因为Delayed ACK机制的存在，单
个确认包不会被立即发送，因此客户端也开始等待。
这样server和client就相互等待，直到client的Delay ACK等待
超时，发出ACK，server收到ACK后把剩下的数据发送给
client。这2KB数据花了上百毫秒的时间传输，但大部分时间
在等待。

15. 课件制作人：谢希仁
当网络出现拥塞时
■ 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络
出现拥塞（其根据就是没有按时收到确认），就要把慢开始门
限 ssthresh 设置为出现拥塞时的发送方窗口值的一半（但不能
小于2）。
■ 然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法。
■ 这样做的目的就是要迅速减少主机发送到网络中的分组数，使
得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

16. 22
16
慢开始和拥塞避免算法的实现举例
当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中
的窗口单位不使用字节而使用报文段。
慢开始门限的初始值设置为 16 个报文段，
即 ssthresh = 16。
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
传输轮次

17. 发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端
窗口 rwnd 中的最小值。我们假定接收端窗口足够大，
因此现在发送窗口的数值等于拥塞窗口的数值。
22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
传输轮次

18. 慢开始和拥塞避免算法的实现举例
在执行慢开始算法时，拥塞窗口 cwnd 的初始值为 1，
发送第一个报文段 M0。
22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
传输轮次

19. 慢开始和拥塞避免算法的实现举例
发送端每收到一个确认 ，就把 cwnd 加 1。于是发送
端可以接着发送 M1 和 M2 两个报文段。
22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
传输轮次

20. 慢开始和拥塞避免算法的实现举例
接收端共发回两个确认。发送端每收到一个对新报文
段的确认，就把发送端的 cwnd 加 1。现在 cwnd 从 2
增大到 4，并可接着发送后面的 4 个报文段。
22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
传输轮次

21. 慢开始和拥塞避免算法的实现举例
发送端每收到一个对新报文段的确认，就把发送端的
拥塞窗口加 1，因此拥塞窗口 cwnd 随着传输轮次按
指数规律增长。
22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
传输轮次

22. 慢开始和拥塞避免算法的实现举例
当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时
（即当 cwnd = 16 时），就改为执行拥塞避免算法，
拥塞窗口按线性规律增长。
22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
传输轮次

23. 22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
慢开始和拥塞避免算法的实现举例
假定拥塞窗口的数值增长到 24 时，网络出现超时，
表明网络拥塞了。
传输轮次

24. 22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
慢开始和拥塞避免算法的实现举例
更新后的 ssthresh 值变为 12（即发送窗口数值 24 的
一半），拥塞窗口再重新设置为 1，并执行慢开始算
法。
传输轮次

25. 22
16
“乘法减小”
2 4 6 8 10 12 14 16 18 200
0
4
8
12
20
24
拥塞窗口 cwnd
新的 ssthresh 值
网络拥塞
指数规律增长
ssthresh 的初始值
慢开始
慢开始 慢开始
拥塞避免
“加法增大”
拥塞避免
“加法增大”
慢开始和拥塞避免算法的实现举例
当 cwnd = 12 时改为执行拥塞避免算法，拥塞窗口
按按线性规律增长，每经过一个往返时延就增加一
个 MSS 的大小。
传输轮次

26. http网络库
做一个网络库，需要考虑哪些点？
并发（异步请求）、内存池（heap churn）、连接池（减少
tcp三次握手）、数据解析、缓存（http协议）、异常处理等。

27. 两个流行的网络库，Volley、OkHttp
Volley：封装httpurlconnection（httpclient）。
▪ http异步请求
▪ 实现http缓存机制（lastModify、eTag）
▪ http请求优先级（PriorityBlockingQueue）
▪ http请求批量取消
▪ 其他优化（byte[]池、google持续更新volley以及bugfix）

28. Volley
遵守开闭原则，对扩展开放对修改关闭。

29. OkHttp
Okhttp，对http传输性能优化做的比较好：
▪ 连接池(使用多个TCP连接)
▪ 缓存
▪ http2.0/spdy3.1
▪ SocketFactory，自定义socket。

30. http协议／http0.9
http0.9（1991年起）的功能：
▪ 客户端／服务器、请求／响应协议；
▪ ASCII协议，运行于TCP/IP之上；
▪ 设计用来传输HTML文档；
▪ 服务器与客户端之间的连接在每次请求之后关闭。

31. http协议／http1.0
http1.0（1991-1995）的关键变化：
▪ 请求可以多行首部字段构成；
▪ 响应对象前面添加了一个响应状态行；
▪ 响应对象也有自己的由换行符分隔的首部字段；
▪ 响应对象不局限于超文本
▪ 服务器与客户端之间的连接在每次请求之后都会关闭。

32. http协议／http1.0
HTTP的“HTT”（Hypertext Transfer，超文本传输）在http1.0
出现后不久就用词不当了。HTTP迅速发展为超媒体传输协议，
但最初的名字则沿用至今。
除了媒体类型协商，http1.0还定义了其他功能：内容编码、字
符集支持、多部分类型、认证、缓存、代理行为、日期格式等。
但HTTP1.0对每个请求都打开一个新TCP连接严重影响性能：
1、TCP三次握手；2、慢启动。

35. http协议／http1.1互联网标准
HTTP1.1标准理清了之前版本很多歧义的地方，而且还加入了
很多重要的性能优化：
持久连接、请求管道（3倍性能提升）；
分块编码传输、传输编码；
字节范围请求(断点续传)；
增强的缓存机制（chache-control:Max-age）；

38. http协议／http2.0改进传输性能
HTTP2.0的主要目标是改进传输性能，实现低延迟、高吞吐量。

39. HTTP2.0/SPDY
SPDY（读SPeeDY）是google开发的一个实验性协议，
HTTP2.0协议基于SPDY，其主要目的是解决HTTP1.1的性能
问题：
▪ Single request per connection（pipeline、multiple
connections per domain）；
▪ Uncompressed request and response headers ；
▪ Optional data compression.

40. SPDY／二进制分帧层

41. HTTP2.0/SPDY面临的问题
TCP的性能瓶颈：
TCP队首阻塞；
TCP窗口、拥塞控制。
TCP很可能就是下一个性能瓶颈，服务器端TCP配置对
HTTP2.0至关重要。

42. WIFI
特点：
共享传输信道，抗干扰性差，延迟和传输速率不稳定。
Wifi热点越多，终端设备越多，传输速率越低，网络延迟越高。

43. 移动网络／一些统计数据

45. 移动网络／RRC（移动网络的大脑）
RRC（无线电资源控制器）。RRC负责协调移动设备与基站
之间的通信连接。RRC直接影响延迟、吞吐量和设备电池使
用时间。

46. LTE RRC状态机

47. LTE RRC状态机不同状态消耗的电量
▪ RRC空闲：设备处于低功率状态<15mW,只监听网络控制信
号。
▪ RRC连接：设备处于高功率状态1000-3500mW，传输活着
等待数据。运营商分配了专用的无线电资源。
WIFI网络中，设备自己设定传输功率，通常是30-200mw。移
动网络发射功率由网络（基站）决定，空闲状态最低15mw。

48. 低效率周期性传输
每一次无线电传输，都会切换到高功耗状态。传输完成，必须
等待计时器超时才能切换回低功耗状态（可能经过几个中间状
态）。

49. 3g、4g、wifi性能

50. 推送/问题根源
推送问题根源是IPV4。IP地址不够，运营商使用NAT转换，但
65k端口也不够用，需要回收空闲链路的端口。设备通过发心
跳包，阻止运营商回收链路。

51. 推送/物理层
▪ G协议栈，RRC
▪ 基带芯片（BP），能唤醒休眠的CPU。

52. 推送/websocket
WebSocket protocol 是HTML5一种新的协议。它实现了客户
端与服务器全双工通信(full-duplex)。
目前来看，http协议经过20多年的发展，已经非常成熟，cdn、
代理服务器、缓存服务器、防火墙等网络设备都针对http协议
优化，甚至只能识别http网络包（识别不了的丢弃）。完全使
用websocket或其他协议代替http协议不是一个最优的选择。
非http协议一般需要tls加密才能正常的跑在各种网络上，以防
中间网络设备，修改、丢弃网络包。

54. 推送/pomelo服务器框架
http server

55. 推送/优化
▪ 使用长连接＋http的方式，长连接传输server命令、client状
态，http传输数据。
▪ 为了减轻server的压力，考虑使用udp长连接。
▪ 网络切换最好对应用逻辑层透明，不要再断线重连。
▪ 长连接动态心跳。

56. 固
定
部
分
可变
部分
0 4 8 16 19 24 31
版 本
标志
生 存 时 间 协 议
标 识
区 分 服 务 总 长 度
片 偏 移
填 充
首 部 检 验 和
源 地 址
目 的 地 址
可 选 字 段 （长 度 可 变）
位
首部长度
数 据 部 分
数 据 部 分首 部
IP 数据报
首
部
发送在前

57. 首
部
0 4 8 16 19 24 31
版 本
标志
生 存 时 间 协 议
标 识
总 长 度
片 偏 移
填 充
首 部 检 验 和
源 地 址
目 的 地 址
可 选 字 段 （长 度 可 变）
位
首部长度
数 据 部 分
固
定
部
分
可变
部分
标识(identification) 占 16 位，
它是一个计数器，用来产生数据报的标识。
区 分 服 务

58. 偏移 = 0/8 = 0
偏移 = 0/8
= 0
偏移 = 1400/8 = 175 偏移 = 2800/8 = 350
1400 2800 379927991399
3799
需分片的
数据报
数据报片 1
首部
数据部分共 3800 字节
首部 1 首部 2 首部 3
字节 0
数据报片 2 数据报片 3
1400 2800字节 0
IP 数据报分片

59. TCP
首部
20 字节的
固定首部
目 的 端 口
数据
偏移
检 验 和
选 项 （长 度 可 变）
源 端 口
序 号
紧 急 指 针
窗 口
确 认 号
保 留
F
I
N
32 位
S
Y
N
R
S
T
P
S
H
A
C
K
U
R
G
位 0 8 16 24 31
填 充
TCP 数据部分TCP 首部TCP 报文段
IP 数据部分IP 首部
发送在前
TCP 报文段的首部格式

60. TCP
的
有
限
状
态
机
CLOS
ED
ESTABLISHE
D
LISTE
N
CLOSE_WA
IT
FIN_WAIT
_1
SYN_RCV
D
FIN_WAIT
_2
CLOSI
NG
TIME_WA
IT
SYN_SE
NT
LAST_AC
K
主动打开
被动打开
被动关闭
主动关闭
起点
被动打开
主动打开
发送 SYN
同时打开
收到 SYN，发送 SYN, ACK
收到 ACK
数据传送
阶段
关闭
发送 FIN
关闭
发送 FIN
关闭
发送 FIN
收到 RST
收到 SYN
发送 SYN, ACK
关闭
或超时
收到 ACK
收到 SYN, ACK
发送 ACK
收到 ACK收到 ACK
收到 FIN
发送 ACK
收到 FIN, ACK
发送 ACK
收到 FIN
发送 ACK
同时关闭
收到 FIN
发送 ACK
发送 SYN
定时经过两倍报文段寿命后
关闭

61. MSS
MSS选项占4byte。MSS是每一个TCP报文段中数据字段的最
大长度。
TCP在三次握手中，每一方都会通告其期望收到的MSS
（MSS只出现在SYN数据包中）如果一方不接受另一方的
MSS值则定位默认值536byte。
与MSS相似的在IP层也有一个类似的概念---MTU（Maximum
Transfer Unit）。
MTU=MSS+TCP Header+IP Header。

62. MSS

63. TCP窗口
滑动窗口：rwnd
拥塞窗口：cwnd

64. 课件制作人：谢希仁
5.6 TCP 可靠传输的实现
5.6.1 以字节为单位的滑动窗口
前移
不允许发送已发送并
收到确认
A 的发送窗口 = 20
允许发送的序号
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
4
8
4
9
5
0
5
1
5
2
5
3
5
4
5
5
5
6
B 期望
收到的序号
前沿后沿
前移 收缩
根据 B 给出的窗口值
A 构造出自己的发送窗口
TCP 标准强烈不赞成
发送窗口前沿向后收缩

65. 不允许发送已发送并
收到确认
A 的发送窗口位置不变
允许发送但尚未发送
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
4
8
4
9
5
0
5
1
5
2
5
3
5
4
5
5
已发送但未收到确认
5
6
P1 P2 P3
不允许接收已发送确认
并交付主机
B 的接收窗口
允许接收
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
4
8
4
9
5
0
5
1
5
2
5
3
5
4
5
5
5
6
未按序收到
可用窗口
A 发送了 11 个字节的数据
P3 – P1 = A 的发送窗口（又称为通知窗口）
P2 – P1 = 已发送但尚未收到确认的字节数
P3 – P2 = 允许发送但尚未发送的字节数（又称为可用窗口）

66. 允许发送但尚未发送
A 的发送窗口向前滑动
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
4
8
4
9
5
0
5
1
5
2
5
3
5
4
5
5
已发送并收到确认 不允许
发送已发送
但未收到确认
5
6
P1 P2 P3
允许接收
B 的接收窗口向前滑动
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
4
8
4
9
5
0
5
1
5
2
5
3
5
4
5
5
已发送确认
并交付主机
不允许
接收
5
6
未按序收到
A 收到新的确认号，发送窗口向前滑动
先存下，等待缺少的
数据的到达

67. 不允许
发送
已发送并收到确认
A 的发送窗口已满，有效窗口为零
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
4
8
4
9
5
0
5
1
5
2
5
3
5
4
5
5
已发送但未收到确认
5
6
P1 P2
P3
A 的发送窗口内的序号都已用完，
但还没有再收到确认，必须停止发送。

68. 课件制作人：谢希仁
发送缓存
最后被确认
的字节
发送应用程
序
发送缓存
最后发送
的字节
发送窗口
已发送
TCP
序号增大

69. 课件制作人：谢希仁
接收缓存
接收应用程
序
已收到
接收窗口
TCP
接收缓存
下一个读取
的字节
序号增大下一个期望收到的
字节（确认号）

70. NAT

71. 引用
▪ web性能权威指南
▪ https://www.chromium.org/spdy
▪ http://www.cnblogs.com/polymorphism/archive/2012/12/10/High_Latency_for_Small_Size_Entities
_in_Table_Service.html
▪ https://github.com/NetEase/pomelo/wiki/Pomelo-framework-overview
▪ http://www.multipath-tcp.org/