Download pptx - networking performance

Transcript
Page 1: networking performance

*

网络协议及其性能

Page 2: networking performance

应用层:http0.9、 http1.0、 http1.1、 http2.0 、 spdy

网络层:路由、 NAT、 ip分片

数据链路层:移动网络性能、电量分析物理层: 3g、 4g、 wifi网络特点

传输层: tcp协议性能优化

app层: volley、 okhttp、推送

Page 3: networking performance

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

Page 4: networking performance

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

Page 5: networking performance

TCP/三次握手

Page 6: networking performance

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

Page 7: networking performance

TCP/slow start

Page 8: networking performance

Slow start和拥塞避免算法

Page 9: networking performance

TCP/队首阻塞

Page 10: networking performance

带宽延时积▪假设 rwnd和 cwnd最小值 16kb,往返时间 RTT为

100ms:

不管发送端和接受端实际带宽多大,这个 TCP连接的数据传输速率不会超过 1.31Mbit/s。

Page 11: networking performance

带宽延时积▪假设往返时间 RTT不变 100ms,发送端、接收端带宽为

10Mbit/s,若充分利用 10Mbit/s的带宽,则:

窗口至少需要 122.1KB才能充分利用 10Mbit/s带宽!所以窗口大小有时候是 TCP性能的限制因素。

Page 12: networking performance

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

Page 13: networking performance

Delayed ACK如果当前只需要发送一个确认包,那么客户端就 hold on,直到:▪有后续的包需要发送,例如一个或多个数据包 /ACK包(客户端可能连续收到好几个数据包需要确认)。▪或者等待超过预设的 timeout时间。(参见 IETF RFC

1122 4.2.3.2  When to Send an ACK Segment,这个预设 时间应该 < 500ms)

Page 14: networking performance

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数据花了上百毫秒的时间传输,但大部分时间在等待。

Page 15: networking performance

课件制作人:谢希仁

当网络出现拥塞时■ 无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有按时收到确认),就要把慢开始门

限 ssthresh 设置为出现拥塞时的发送方窗口值的一半(但不能小于 2)。■ 然后把拥塞窗口 cwnd 重新设置为 1,执行慢开始算法。■ 这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压的分组处理完

毕。

Page 16: networking performance

22

16

慢开始和拥塞避免算法的实现举例

当 TCP 连接进行初始化时,将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。 慢开始门限的初始值设置为 16 个报文段,

即 ssthresh = 16。

“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

传输轮次

Page 17: networking performance

发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端 窗口 rwnd 中的最小值。我们假定接收端窗口足够大,因此现在发送窗口的数值等于拥塞窗口的数值。

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

传输轮次

Page 18: networking performance

慢开始和拥塞避免算法的实现举例

在执行慢开始算法时,拥塞窗口 cwnd 的初始值为1 ,发送第一个报文段 M0。

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

传输轮次

Page 19: networking performance

慢开始和拥塞避免算法的实现举例

发送端每收到一个确认,就把 cwnd 加 1。于是发 送端可以接着发送 M1 和 M2 两个报文段。

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

传输轮次

Page 20: networking performance

慢开始和拥塞避免算法的实现举例

接收端共发回两个确认。发送端每收到一个对新报文 段的确认,就把发送端的 cwnd 加 1 。现在 cwnd

从 2 增大到 4 ,并可接着发送后面的 4 个报文段。

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

传输轮次

Page 21: networking performance

慢开始和拥塞避免算法的实现举例

发送端每收到一个对新报文段的确认,就把发送端的 拥塞窗口加 1 ,因此拥塞窗口 cwnd 随着传输轮次

按指数规律增长。

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

传输轮次

Page 22: networking performance

慢开始和拥塞避免算法的实现举例

当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时 (即当 cwnd = 16 时),就改为执行拥塞避免算法,

拥塞窗口按线性规律增长。

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

传输轮次

Page 23: networking performance

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

慢开始和拥塞避免算法的实现举例

假定拥塞窗口的数值增长到 24 时,网络出现超时, 表明网络拥塞了。

传输轮次

Page 24: networking performance

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

慢开始和拥塞避免算法的实现举例

更新后的 ssthresh 值变为 12 (即发送窗口数值 24 的一半),拥塞窗口再重新设置为 1,并执行慢开始

算法。

传输轮次

Page 25: networking performance

22

16“ ”乘法减小

2 4 6 8 10 12 14 16 18 2000

4

8

12

20

24

拥塞窗口cwnd

新的 ssthresh 值

网络拥塞

指数规律增长

ssthresh 的初始值

慢开始

慢开始 慢开始

拥塞避免“ ”加法增大 拥塞避免

“ ”加法增大

慢开始和拥塞避免算法的实现举例

当 cwnd = 12 时改为执行拥塞避免算法,拥塞窗口按按线性规律增长,每经过一个往返时延就增加一 个 MSS 的大小。

传输轮次

Page 26: networking performance

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

Page 27: networking performance

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

bugfix)

Page 28: networking performance

Volley遵守开闭原则,对扩展开放对修改关闭。

Page 29: networking performance

OkHttpOkhttp,对 http传输性能优化做的比较好:▪连接池 (使用多个 TCP连接 )

▪缓存▪ http2.0/spdy3.1

▪ SocketFactory,自定义 socket。

Page 30: networking performance

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

Page 31: networking performance

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

Page 32: networking performance

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

Page 33: networking performance
Page 34: networking performance
Page 35: networking performance

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

Page 36: networking performance
Page 37: networking performance
Page 38: networking performance

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

Page 39: networking performance

HTTP2.0/SPDYSPDY(读 SPeeDY)是 google开发的一个实验性协议, HTTP2.0协议基于 SPDY,其主要目的是解决 HTTP1.1的性能问题:▪ Single request per connection( pipeline、multiple

connections per domain);▪ Uncompressed request and response headers ;▪ Optional data compression. 

Page 40: networking performance

SPDY/二进制分帧层

Page 41: networking performance

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

Page 42: networking performance

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

Page 43: networking performance

移动网络/一些统计数据

Page 44: networking performance
Page 45: networking performance

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

Page 46: networking performance

LTE RRC状态机

Page 47: networking performance

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

Page 48: networking performance

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

Page 49: networking performance

3g、 4g、 wifi性能

Page 50: networking performance

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

Page 51: networking performance

推送 /物理层▪ G协议栈, RRC

▪ 基带芯片( BP),能唤醒休眠的 CPU。

Page 52: networking performance

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

Page 53: networking performance
Page 54: networking performance

推送 /pomelo服务器框架

http server

Page 55: networking performance

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

Page 56: networking performance

固定部分可变部分

0 4 8 16 19 24 31

版 本标志

生存时间 协 议 标 识

区分服务 总 长 度 片 偏 移

填 充

首 部 检 验 和 源 地 址

目 的 地 址 可 选 字 段 (长 度 可 变)

位首部长度

数 据 部 分 数 据 部 分 首 部

IP 数据报

首部

发送在前

Page 57: networking performance

首部

0 4 8 16 19 24 31

版 本标志

生存时间 协 议 标 识

总 长 度 片 偏 移

填 充

首 部 检 验 和 源 地 址

目 的 地 址 可 选 字 段 (长 度 可 变)

位首部长度

数 据 部 分

固定部分

可变部分

标识 (identification) 占 16 位, 它是一个计数器,用来产生数据报的标识。

区分服务

Page 58: networking performance

偏移 = 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 数据报分片

Page 59: networking performance

TCP首部20 字节的固定首部

目 的 端 口

数据偏移 检 验 和

选 项 (长 度 可 变)

源 端 口 序 号

紧 急 指 针 窗 口

确 认 号 保 留 F

IN

32 位

SYN

RST

PSH

ACK

URG

位 0 8 16 24 31

填 充

TCP 数据部分TCP 首部TCP 报文段

IP 数据部分IP 首部发送在前

TCP 报文段的首部格式

Page 60: networking performance

TCP的有限状态 机

CLOSED

ESTABLISHED

LISTEN

CLOSE_WAIT

FIN_WAIT_1

SYN_RCVD

FIN_WAIT_2

CLOSING

TIME_WAIT

SYN_SENT

LAST_ACK

主动打开

被动打开

被动关闭

主动关闭

起点被动打开 主动打开

发送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

定时经过两倍报文段寿命后

关闭

Page 61: networking performance

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

Page 62: networking performance

MSS

Page 63: networking performance

TCP窗口滑动窗口: rwnd

拥塞窗口: cwnd

Page 64: networking performance

课件制作人:谢希仁

5.6 TCP 可靠传输的实现5.6.1 以字节为单位的滑动窗口

前移

不允许发送已发送并收到确认

A 的发送窗口 = 20

允许发送的序号26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

B 期望收到的序号

前沿后沿 前移 收缩

根据 B 给出的窗口值A 构造出自己的发送窗口

TCP 标准强烈不赞成 发送窗口前沿向后收缩

Page 65: networking performance

不允许发送已发送并收到确认

A 的发送窗口位置不变

允许发送但尚未发送26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

已发送但未收到确认56

P1 P2 P3

不允许接收已发送确认并交付主机

B 的接收窗口允许接收

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

未按序收到

可用窗口A 发送了 11 个字节的数

P3 – P1 = A 的发送窗口(又称为通知窗口)P2 – P1 = 已发送但尚未收到确认的字节数P3 – P2 = 允许发送但尚未发送的字节数(又称为可用窗口)

Page 66: networking performance

允许发送但尚未发送

A 的发送窗口向前滑动26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55已发送并收到确认 不允许发送已发送但未收到确认

56

P1 P2 P3

允许接收

B 的接收窗口向前滑动26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55已发送确认并交付主机 不允许接收

56

未按序收到

A 收到新的确认号,发送窗口向前滑动

先存下,等待缺少的数据的到达

Page 67: networking performance

不允许发送已发送并收到确认A 的发送窗口已满,有效窗口为零2

627

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

已发送但未收到确认56

P1 P2P3

A 的发送窗口内的序号都已用完, 但还没有再收到确认,必须停止发送。

Page 68: networking performance

课件制作人:谢希仁

发送缓存

最后被确认的字节

发送应用程序发送缓存

最后发送的字节

发送窗口已发送

TCP

序号增大

Page 69: networking performance

课件制作人:谢希仁

接收缓存接收应用程序

已收到接收窗口

TCP 接收缓存下一个读取的字节

序号增大下一个期望收到的字节(确认号)

Page 70: networking performance

NAT

Page 71: networking performance

引用▪ 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/

Page 72: networking performance

Recommended