![两个流行的网络库，Volley、OkHttp
Volley：封装httpurlconnection（httpclient）。
? http异步请求
? 实现http缓存机制（lastModify、eTag）
? http请求优先级（PriorityBlockingQueue）
? http请求批量取消
? 其他优化（byte[]池、google持续更新volley以及bugfix）](https://image.slidesharecdn.com/random-160401113718/85/networking-performance-27-320.jpg)
More Related Content
What's hot (9)
Similar to networking performance (20)
networking performance
- 1. * 网络协议及其性能
- 5. 罢颁笔/叁次握手
- 9. 罢颁笔/队首阻塞
- 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 的大小。 传输轮次
- 27. 两个流行的网络库，Volley、OkHttp Volley：封装httpurlconnection（httpclient）。 ? http异步请求 ? 实现http缓存机制（lastModify、eTag） ? http请求优先级（PriorityBlockingQueue） ? http请求批量取消 ? 其他优化（byte[]池、google持续更新volley以及bugfix）
- 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）的关键变化： ? 请求可以多行首部字段构成； ? 响应对象前面添加了一个响应状态行； ? 响应对象也有自己的由换行符分隔的首部字段； ? 响应对象不局限于超文本 ? 服务器与客户端之间的连接在每次请求之后都会关闭。
- 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. 厂笔顿驰／二进制分帧层
- 43. 移动网络／一些统计数据
- 46. LTE RRC状态机
- 47. LTE RRC状态机不同状态消耗的电量 ? RRC空闲：设备处于低功率状态<15mW,只监听网络控制信 号。 ? RRC连接：设备处于高功率状态1000-3500mW，传输活着 等待数据。运营商分配了专用的无线电资源。 WIFI网络中，设备自己设定传输功率，通常是30-200mw。移 动网络发射功率由网络（基站）决定，空闲状态最低15mw。
- 49. 3驳、4驳、飞颈蹿颈性能
- 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 定时经过两倍报文段寿命后 关闭
- 62. MSS
- 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 的发送窗口内的序号都已用完， 但还没有再收到确认，必须停止发送。
- 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/