深入探索 Android 网络优化（二、网络优化基础篇）上
▲ 点击上方第二个“JsonChao”关注公众号
一、为什么要进行网络优化？
等待网络是我们 App 最大的性能瓶颈，再怎么优化绘制、内存、卡顿或其它方面，也抵不上网络优化！网络通信速度越快，则：
1）、用户黏性越高。 2）、用户忠诚度更高。 3）、转化率越高。
而网络优化最核心的处理方式就是 消除和减少不必要的网络延迟，把传输的字节数降到最少。
二、网络性能评估
1、无线网络通信过程
手机 => 无线网络 => 基站 => 运营商核心网 => 互联网 => 服务器
2、重要指标
1）、延时
数据从信息源发送到目的地所需的时间。客户端到服务端的总延迟时间如下所示：
1）、传播延迟：消息从发送端到接收端需要的时间，是信号传播距离和速度的函数。光速是所有能量、物质和信息运动所能达到的最高速度，这个结论给网络分组的传播速度设定了上限。 2）、传输延迟：把消息中的所有比特转移到链路中需要的时间，是消息长度和链路速率的函数。 3）、处理延迟：处理分组首部、检查位错误及确定分组目标所需的时间。 4）、排队延迟：到来的分组排队等待处理的时间。
一路上经过的路由器越多，每个分组的处理和传输延迟就越多。并且，网络流量越拥挤，分组在入站缓冲区中被延迟的可能性就越大。
最后，延迟中相当大的一部分往往花在了最后几公里，通过 traceroute 命令，我们就可以知道上网服务商的拓扑结构和速度。
2）、带宽
逻辑或物理通通信路径的最大吞吐量。
网络核心的带宽
光纤
就是一根“光导管”，比人的头发稍粗一点，专门用来从一端向另一端传送光信号。
金属线
用于传送电信号，但信号损失、电磁干扰较大，同时维护成本也较高。
这两种线路我们的数据分组很可能都会经过，但一般长距离的分组传输都是通过光纤完成的。
通过 波分复用（WDM，Wavelength-Division Multiplexing）技术，光纤可以同时传输很多不同波长（信道）的光，因而具有明显的带宽优势。
一条光纤连接的总带宽，等于每个信道的数据传输速率乘以可复用的信道数。而每条光缆会封装几条光纤（常见的是4条），折算出来的带宽容量能达到每秒几百太比特。
网络边缘的带宽
用户可用带宽取决于客户端与目标服务器间最低容量连接，我们可以在 akamai （http://www.akamai.io）查看世界各地的平均带宽。但是，高带宽并不能保证端到端的传输速度。
延迟、带宽与什么因素有关？
信号强度、基站距离、网络制式、拥塞情况 等等很多因素相关。
3、了解不同网络制式的带宽与延迟参考值
| 网络制式 | 带宽（下行/上行） | 延迟 |
|---|---|---|
| 2.75 G | 384KB/48KB | 600~700ms |
| 3 G | 7MB/2MB | 150~400ms |
| 4 G | 128MB/56MB | 40~50ms |
| 5G | >100MB/>50MB | <10ms |
什么是弱网络？
即 高延时、低带宽 的网络，它具有 丢包率、误码率高 的特点。
网络优化需要结合 App 的实际情况来综合考虑，看我们的 App 是重延时的应用还是重带宽的应用。
遗憾的是，人类不太可能跳出物理定律的 “掌心”。如果需要针对延迟采取优化措施，就必须从 设计和优化协议及应用 着手，并且时刻牢记光速的限制。
三、TPC 优化
因特网有两个核心协议:IP 和 TCP。
IP：即 Internet Protocol(因特网协议)，负责联网主机之间的路由选择和寻址;TCP：即 Transmission Control Protocol(传输控制协议)，负责在不可靠的传输信道之上提供可靠的抽象层。
而 TCP/IP 也常被称为“因特网协议套件”(Internet Protocol Suite)。在现实当中，由于 TCP 提 供了很多有用的功能，几乎所有 HTTP 流量都是通过 TCP 传送的。
我们都知道有 IPv4 和 IPv6，那 IPv1~3 和 IPv5 呢?
IPv4 中的 4 表示 TCP/IP 协议的第 4 个版本，发布于 1981 年 9 月。IPv4 中的 v4 只是表明了它与 TCP 前 3 个版本的承继关系，之前并没有单独的 IPv1、IPv2 或 IPv3 协议。而 v5 已经被分配给了另一个试验性协议 Internet Stream Protocol(ST)。但 ST 一直没有什么进展，这也是我们为什么很少听说它的原因。结果 TCP/IP 的下 一版本就成了 IPv6。
1、三次握手
1）、出于安全考虑，序列号由两端随机生成。 2）、客户端可以在发送 ACK 分组之后立即发送数据，而服务器必须等接收到 ACK 分组之后才能发送数据。 3）、三次握手带来的延迟使得每创建一个新 TCP 连接都要付出很大代价。而这也决定了提高 TCP 应用性能的关键，在于想办法重用连接。
TFO（TCP Fast Open，TCP 快速打 开)
TFO 致力于减少新建 TCP 连接带来的性能损失。但却只能在某些情况下有效。比如，随同 SYN 分组一起发送的数据净荷有最大尺寸限制、只能发送某些类型的 HTTP 请 求，以及由于依赖加密 cookie，只能应用于重复的连接。
2、拥塞预防及控制
ARPANET(Advanced Research Projects Agency Network，高级研究计划局 网络) 是现代互联网的前身，是世界上第一个实际运行的分组交换网络。这个项目于 1959 年正式启动，1983 年 TCP/IP 作为主要通信协议取代了原来 的 NCP(Network Control Program)协议。
1）、流量控制
为实现流量控制，TCP 连接的每一方都要通告自己的接收窗口(rwnd)，其中包含能够保存数据的缓冲区空间大小信息。这个过程贯穿于每个 TCP 连接的整个生命周期: 每个 ACK 分组都会携带相应的最新 rwnd 值，以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力。
窗口缩放(RFC 1323)
最初的 TCP 规范分配给通告窗口大小的字段是 16 位的，RFC 1323 提供了“TCP 窗口缩放”(TCP Window Scaling)选项，可以 把接收窗口大小由 65535 字节提高到 1G 字节!缩放 TCP 窗口是在三次握手期间完成的，其中有一个值表示在将来的 ACK 中左移 16 位窗口字段的位数。
2）、慢启动
拥塞窗口大小(cwnd)，即发送端对从客户端接收确认(ACK)之前可以发送数据量的限制。
新 TCP 连接传输的最大数据量取 rwnd 和 cwnd 中的最小值，而服务器实际上可以 向客户端发送 4 个 TCP 段，然后就必须停下来等待确认。
为减少增长到拥塞窗口的时间，可以减少客户端与服务器之间的往返时间。比如， 把服务器部署到地理上靠近客户端的地方。要么，就把初始拥塞窗口大小增加到 RFC 9828 规定的 10 段。
因为慢启动限制了可用的吞吐量，而这对于小文件传输非常不利。
SSR(Slow-Start Restart，慢启动重启)
在连接空闲一定时间后重置连接的拥塞窗口。道理很简单， 在连接空闲的同时，网络状况也可能发生了变化，为了避免拥塞，理应将拥塞窗口重置回“安全的”默认值。
但是，SSR 对于那些会出现突发空闲的长周期 TCP 连接(比如 HTTP 的 keep-alive 连接)有很大的影响。因此，我们建议在服务器上禁用 SSR。
可以看到，服务器和客户端之间的 5 Mbit/s 带宽并不影响 TCP 连接的启动阶 段。此时，延迟和拥塞窗口大小才是限制因素。
3）、拥塞预防
慢启动以保守的窗口初始化连接，随后的 每次往返都会成倍提高传输的数据量，直到超过接收端的流量控制窗口，即系统 配置的拥塞阈值(ssthresh)窗口，或者有分组丢失为止，此时拥塞预防算法介入。
拥塞预防算法把丢包作为网络拥塞的标志，即路径中某个连接或路由器已经拥堵了， 以至于必须采取删包措施。因此，必须调整窗口大小，以避免造成更多的包丢失， 从而保证网络畅通。
重置拥塞窗口后，拥塞预防机制按照自己的算法来增大窗口以尽量避免丢包。某个 时刻，可能又会有包丢失，于是这个过程再从头开始。如果你看到过 TCP 连接的吞 吐量跟踪曲线，发现该曲线呈锯齿状，那现在就该明白为什么了。这是拥塞控制和 预防算法在调整拥塞窗口，进而消除网络中的丢包问题。
TCP PRR(Proportional Rate Reduction，比例降速)
最初，TCP 使用 AIMD(Multiplicative Decrease and Additive Increase，倍减加增) 算法，即发生丢包时，先将拥塞窗口减半，然后每次往返再缓慢地给窗口增加一 个固定的值。
后来，出现了 PRR(Proportional Rate Reduction，比例降速)，它是 RFC 6937 规定的一个新算法，其目标就是 改进丢包后的恢复速度。使用它因丢包造成的平均连接延迟减少了 3%~10%。此外，PRR 现在也是 Linux 3.2+ 内核默认的拥塞预防算法。
3、BDP(Bandwidth-delay product，带宽延迟积)
接收窗口（rwnd）会随每次 ACK 一起发送，而 拥塞窗口（cwnd）则由发送端根据拥塞控制和预防算法动态调整。
无论发送端发送的数据还是接收端接收的数据超过了未确认的最大数据量，都必须停 下来等待另一方 ACK 确认某些分组才能继续。
而 BDP(Bandwidth-delay product，带宽延迟积) 就是 任意时刻处于在途未确认状态的最大数据量。
BDP = 数据链路的容量 * 其端到端延迟
在高速连接的客户端与服务器之间，如果实际传输速度只有可用带宽的几分之一，那窗口大小很可能就是 罪魁祸首。要么因为某一饱和端通告的接收窗口很小，要么因为网络拥堵和丢包导致拥塞窗口重置，更可能因为流量增长过快导致对连接吞吐量施加了限制。
4、TCP 队首(HOL，Head of Line)阻塞
TCP 在不可靠的信道上实现了可靠的网络传输。基本的分组错误检测与纠正、按 序交付、丢包重发，以及保证网络最高效率的流量控制、拥塞控制和预防机制，让 TCP 成为大多数网络应用中最常见的传输协议。
但是，其中的按序交付和可靠交付有时候并不必要，反而会导致额外的延迟，对性能造成负面影响。例如：每个 TCP 分组都会带着一个唯一的序列号被发出，而 所有分组必须按顺序传送到接收端。如果中途有一个分组没能到达接收 端，那么后续分组必须保存在接收端的 TCP 缓冲区，等待丢失的分组重发并到达接 收端。这一切都发生在 TCP 层，应用程序对 TCP 重发和缓冲区中排队的分组一无所 知，必须等待分组全部到达才能访问数据。在此之前，应用程序只能在通过套接字 读数据时感觉到延迟交付。这种效应称为 TCP 的队首(HOL，Head of Line)阻塞。
队首阻塞使得分组到达时间会存在无法预知的延迟变化，而这个时间变化通常被称为抖动。
因此，对于无需按序交付数据或能够处理分组丢失的应用程序，以及对延迟或抖动要求很高的应用程序，最好选择 UDP 等协议。
丢包的反作用力
丢包是让 TCP 达到最佳性能的关键。被删除的包恰恰是一种反馈机制， 能够让接收端和发送端各自调整速度，以避免网络拥堵，同时保持延迟最短。
对于实时性比较强的音视频应用来说，就算有个包丢了，音频编解码器只要在音频中插入一个小小的间歇，就可以继续 处理后来的包。只要间歇够小，用户就注意不到，而等待丢失的包则可能导致音 频输出产生无法预料的暂停。相对来说，后者的用户体验更糟糕。
5、TCP 优化 Tips
1）、TCP 中的关键细节
1）、TCP 三次握手增加了整整一次往返时间; 2）、TCP 慢启动将被应用到每个新连接; 3）、TCP 流量及拥塞控制会影响所有连接的吞吐量; 4）、TCP 的吞吐量由当前拥塞窗口大小控制。
大多数情况下，TCP 的瓶颈都是延迟，而非带宽。
2）、服务端配置优化
1）、增大TCP的初始拥塞窗口
加大起始拥塞窗口可以让 TCP 在第一次往返就传输较多数据，而随后的速度提 升也会很明显。对于突发性的短暂连接，这也是特别关键的一个优化。
2）、慢启动重启
在连接空闲时禁用慢启动可以改善瞬时发送数据的长 TCP 连接的性能。
3）、窗口缩放(RFC 1323)
启用窗口缩放可以增大最大接收窗口大小，可以让高延迟的连接达到更好吞 吐量。
4）、TCP快速打开
在某些条件下，允许在第一个 SYN 分组中发送应用程序数据。TFO(TCP Fast Open，TCP 快速打开)是一种新的优化选项，注意，TFO 需要客户端和服务器共同支持。
3）、客户端优化
1）、少发或者不发网络情况（请求合并）：消除不必要的数据传输本身就是很大的优化。比如，减少下载不必要的资源，或者通过压缩算法把要发送的比特数降到最低。 2）、使用 CDN，让通信距离更短：通过在不同的地区部署服务器，把数据放到接近客户端的地方，可以减少网络往返的延迟，从而显著提升 TCP 性能。 3）、重用 TCP 连接：把慢启动和其他拥塞控制机制的影响降到最低。
四、UDP 优化
数据报，即一个完整、独立的数据实体，携带着从源节点到目的地节点的足够信息，对这些 节点间之前的数据交换和传输网络没有任何依赖。
1、数据包和分组的区别
数据报(datagram)和分组(packet)是两个经常被人混用的词，实际上它们还是 有区别的。分组可以用来指代任何格式化的数据块，而数据报则通常只用来描述那 些通过不可靠的服务传输的分组，既不保证送达，也不发送失败通知。
IETF 和 W3C 工作组共同制定了一套新 API—— WebRTC(Web Real-Time Communication，Web 实时通信)。WebRTC 着眼于在浏览器中通过 UDP 实现原生的语音和视频实时通信，以及其他形式的 P2P(Peer-to-Peer，端到端)通信。
2、无协议服务
众所周知，IP 层的主要任务就是按照地址从源主机向目标主机发送数据报。而 数据报 则暗示着:IP 层不保证消息可靠的交付，也不发送失败通知，实际上是把底层网络的不可靠性直接暴露给了上一层。如果某个路由节点因为网络拥塞、负载过高或其他原因而删除了 IP 分组，那么在必要的情况下，IP 的上一层协议要负责检测、恢复和重发数据。
UDP 数据报中的源端口和校验和字段都是可选的。IP 分组的首部也有校验和，应用程序可以忽略 UDP 校验和。因此，UDP 仅仅是在 IP 层之上通过嵌入应用程序的源端口和目标端口，提供了一个“应用程序多路复用”机制。
UDP 的无服务
1）、不保证消息交付：不确认，不重传，无超时。 2）、不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞。 3）、不跟踪连接状态：不必建立连接或重启状态机。 4）、不需要拥塞控制：不内置客户端或网络反馈机制。
3、UDP 与网络地址转换器(NAT，Network Address Translator)
1）、连接状态超时
对于较长时间的 UDP 通信，有一个事实上的最佳做法，即引入一个双向 keep-alive 分组，周期性地重置传输路径上所有 NAT 设备中转换记录的计时器。
2）、NAT 穿透
NAT 导致了几个问题，如下所示：
1）、内部客户端不知道外网 IP 地址，只知道内网 IP 地址。 2）、任何到达 NAT 设备外网 IP 的分组还必须有一个目标端口，而且 NAT 转换表中也要有一个条目可以将其转换为内部主机的 IP 地址和端口号。如果没有这个条目(通常是从外网传数据进来)，那到达的分组就会被删除。
为解决 UDP 与 NAT 的这种不搭配，人们发明了很多穿透技术(TURN、STUN、 ICE)，用于在 UDP 主机之间建立端到端的连接。
3）、STUN(Session Traversal Utilities for NAT)协议(RFC 5389)
优势
1）、应用程序可以获得外网 IP 和端口，并利用这些信息与对端通信; 2）、发送到 STUN 服务器的出站绑定请求将在通信要经过的 NAT 中建立路由条目， 使得到达该 IP 和端口的入站分组可以找到内网中的应用程序; 3）、STUN 协议定义了一个简单 keep-alive 探测机制，可以保证 NAT 路由条目不超时。
缺点
STUN 并不能适应所有类型的 NAT 和网络配置。不仅如此，某些情况下 UDP 还会被防火墙或其他网络设备完全屏蔽。
为解决这个问题，在 STUN 失败的情况下，我们还可以使用 TURN(Traversal Using Relays around NAT)协议(RFC 5766)作为后备。TURN 可以在最坏的情况下跳过 UDP 而切换到 TCP。
4）、TURN(Traversal Using Relays around NAT)协议(RFC 5766)
工作流程
1）、两端都要向同一台 TURN 服务器发送分配请求来建立连接，然后再进行权限协商。 2）、协商完毕，两端都把数据发送到 TURN 服务器，再由 TURN 服务器转发，从而 实现通信。
缺点
为满足传输数据的需要，中继设备的容量必须足够大。
谷歌的 libjingle 是一个用 C++ 开发的用于构建端到端应用程序的开源库，其文档也为我们考量现实中的 STUN 与 TURN 性能提供了有价值的参考:
92% 的时间可以直接连接(STUN); 8% 的时间要使用中继器(TURN)。
5）、ICE(Interactive Connectivity Establishment)协议(RFC 5245)
ICE 规定了一套方法，致力于在通信各端之间建立一条最有效的通道:能直连就直连，必要时 STUN 协商，再不行使用 TURN。如下图所示：
如果要构建基于 UDP 的 P2P 应用程序，我们应该选择现有的平台 API，或者实现了 ICE、STUN 和 TURN 的第三方库。
4、UDP 优化 Tips
UDP 的特色在于它所省略的那些功能:连接状态、握手、重发、重组、重排、拥塞控制、拥塞预防、流量控制，甚至可选的错误检测，统统没有。
在 RFC 5405 中，对设计单播 UDP 应用程序给出了很多设计建议，如下所示：
1）、必须容忍各种因特网路径条件; 2）、应该控制传输速度; 3）、应该对所有流量进行拥塞控制; 4）、应该使用与 TCP 相近的带宽; 5）、应该准备基于丢包的重发计数器; 6）、应该不发送大于路径 MTU 的数据报; 7）、应该处理数据报丢失、重复和重排; 8）、应该足够稳定以支持 2 分钟以上的交付延迟; 9）、应该支持 IPv4 UDP 校验和，必须支持 IPv6 校验和; 10）、**可以在需要时使用 keep-alive(最小间隔 15 秒)**。
而 WebRTC 协议则是上述的设计典范。
五、TLS（Transport Layer Security，传输层安全）
SSL 协议在直接位于 TCP 上一层的应用层被实现。
IETF 后来在标准化 SSL 协议时，将其改名为 Transport Layer Security (TLS，传输层安全)。很多人会混用 TLS 和 SSL，但严格来讲它们并不相 同，因为它们指代的协议版本不同。
鉴于 SSL 协议是网景公司专有的，IETF 成立了一个小组负责标准化该协 议，后来就有了 RFC 2246，即 TLS 1.0，也就是 SSL 3.0 的升级版。
TLS 1.0 在 1999 年 1 月发布。 2006 年 4 月发布了 TLS 1.1。 2008 年 8 月发布了 TLS 1.2。
TLS 也可以实现在 UDP 之上，DTLS(Datagram Transport Layer Security，数据报传输层安全)（RFC 6347）就旨在以 TLS 协议为基础，同时兼顾数据报交付模式并提供类似的安全保障。
1、加密、身份验证与完整性
TLS 协议的目标是为在它之上运行的应用提供三个基本服务：
1）、加密：混淆数据的机制。 2）、身份验证：验证身份标识有效性的机制。 3）、数据完整性：检测消息是否被篡改或伪造的机制。
1）、加密
在握手机制中设计最巧妙的地方，就是其使用的公钥密码系统 (也称“非对称密钥加密”)，这套系统可以让通信双方不必事先“认识”即可商定共 享的安全密钥，而且协商过程还是通过非加密通道完成的。
2）、身份验证
握手过程中，TLS 协议还允许通信两端互相验明正身。这个验证首先需要建立“认证机构信任链”(Chain of Trust and Certificate Authorities)。
3）、数据完整性
消息分帧机制，使用 MAC (Message Authentication Code，消息认证码)签署每一条消息。MAC 算法是一个单向加密的散列函数(本质上是一个校验和)，密钥由连接双方协商确定。只要发送 TLS 记录，就会生成一个 MAC 值并附加到该消息中。接收端通过计算和验证这个 MAC 值来判断消息的完整性和可靠性。
2、TLS 握手
0 ms:TLS 在可靠的传输层(TCP)之上运行，这意味着首先必须完成 TCP 的“三 次握手”，即一次完整的往返。 56 ms:TCP 连接建立之后，客户端再以纯文本形式发送一些规格说明，比如它所运 行的 TLS 协议的版本、它所支持的加密套件列表，以及它支持或希望使用的另外一 些 TLS 选项。 84 ms:然后，服务器取得 TLS 协议版本以备将来通信使用，从客户端提供的加密 套件列表中选择一个，再附上自己的证书，将响应发送回客户端。作为可选项，服 务器也可以发送一个请求，要求客户端提供证书以及其他 TLS 扩展参数。 112 ms:假设两端经过协商确定了共同的版本和加密套件，客户端也高高兴兴地 把自己的证书提供给了服务器。然后，客户端会生成一个新的对称密钥，用服务 器的公钥来加密，加密后发送给服务器，告诉服务器可以开始加密通信了。到 目前为止，除了用服务器公钥加密的新对称密钥之外，所有数据都以明文形式 发送。 140 ms:最后，服务器解密出客户端发来的对称密钥，通过验证消息的 MAC 检 测消息完整性，再返回给客户端一个加密的“Finished”消息。 168 ms:客户端用它之前生成的对称密钥解密这条消息，验证 MAC，如果一切 顺利，则建立信道并开始发送应用数据。
1）、应用层协议协商(ALPN，Application Layer Protocol Negotiation)
NPN(Next Protocol Negotiation，下一代协议协商)是谷歌在 SPDY 协议中开发的一个 TLS 扩展，目的是通过在 TLS 握手期间协商应用协议来提高效率。
ALPN 是 IETF 在 NPN 基础上修订并批准的版本。在 NPN 中，服务器广播自己 支持的协议，客户端选择和确认协议。而 在 ALPN 中，交换次序颠倒过来了，客 户端先声明自己支持的协议，服务器选择并确认协议。而这样修改的目的是为了让 ALPN 与其他协议协商标准保持一致。
ALPN 作为 TLS 扩展，让我们能在 TLS 握手的同时协商应用协议，从而省掉了 HTTP 的 Upgrade 机制所需的额外往返时间。
只要 TLS 握手完成、建立了加密信道并就应用协议达成一致，客户端与服务器就可 以立即通信。
2）、SNI (Server Name Indication，服务器名称指示)
如果服务器想在一个 IP 地址为多个站点提供服务，而每个站点都拥有自己的 TLS 证书，那怎么办?
为了解决这个问题，SNI 扩展被引入 TLS 协议，该扩展 允许客户端在握手之初就指明要连接的主机名。
3、TLS 会话恢复
即在多个连接间共享协商后的安全密钥。
1）、会话标识符 (Session Identifier，RFC 5246)
最早的“会话标识符”机制是在 SSL 2.0 中引入的， 支持服务器创建 32 字节的会话标识符，它是在完整的 TLS 协商期间作为其“ServerHello”消息的一部分发送。
在内部，服务器会为每个客户端保存一个会话 ID 和协商后的会话参数。相应地，客 户端也可以保存会话 ID 信息，并将该 ID 包含在后续会话的“ClientHello”消息中， 从而告诉服务器自己还记着上次握手协商后的加密套件和密钥，这些都可以重用。
假设客户端和服务器都可以在自己的缓存中找到共享的会话 ID 参数，那么就可以进 行简短握手。否则，就要重新启动一次全新的会话协商，生成新的会话 ID。简短的 TLS 握手如下图所示：
优势
1）、节省一次往返。 2）、省掉用于协商共享加密密钥的公钥加密计算。
缺点
对于那些每天都要“接待”几万甚至几百万独立连接的服务器来说，由于每个打开的 TLS 连接都要占用内存，因此需要一套会话 ID 缓存和清除策略。
为了解决上述服务器端部署 TLS 会话缓存的问题，“会话记录单” 机制出现了。
2）、会话记录单(Session Ticket， RFC 5077)
该机制不用服务器保存每个客户端的会话状态。只要客户端表明其支持会话记录单，则服务器可以在完整 TLS 握手的最后一次交换中添加一条“新会话记录单”(New Session Ticket)记录，包含只有服务器知道的安全密钥加密过的所有会话数据。
然后，客户端将这个会话记录单保存起来，在后续会话的 ClientHello 消息中，可以将其包含在 SessionTicket 扩展中。这样，所有会话数据只保存在客户端，而由于 数据被加密过，且密钥只有服务器知道，因此仍然是安全的。
会话标识符和会话记录单机制，即“会话缓存”或“无状态恢复”机制。其优点**主要是消除了服务器端的缓存负担，通过要求客户端在与服务器建立新连接时提供会话记录单简化了部署(除非记录单过期)**。
4、信任链与证书颁发机构
身份验证即用自己的私钥签名，然后对方用自己的公钥验证收到的消息签名。但信任是交流的关键。
对于浏览器来说，它信任谁呢?
至少有三个答案：
1）、手工指定证书：所有浏览器和操作系统都提供了一种手工导入信任证书的机制。 2）、CA(Certificate Authority，证书颁发机构)：被证书接受者(拥有者)和依赖证 书的一方共同信任的第三方。 3）、浏览器和操作系统：其中都会内置一个知名证书颁发机构的名单。因此，你也会信任操作系统及浏览器提供商提供和维护的可信任机构。
最常见的方案，就是浏览器指定可信任的证书颁发机构(根 CA)。而 证书颁发机构签署数字证书的流程 如下图所示：
所有浏览器都允许用户检视自己安全连接的信任链，常见的访问入口就是地址栏头儿上的锁图标，点击即可查看。如下图所示：
整个链条的“信任依据”是根证书颁发机构，而每个浏览器都会内置一个可信任的证书颁发机构(根机构)的名单。
5、证书撤销
通信的任何一端都可以根据嵌入的指令和签名检查链条中每个证书的状态。
1）、CRL(Certificate Revocation List，证书撤销名单) (RFC 528)
每个证书颁发机构维护并定期发布已撤销证书的序列号名单。 任何想验证证书的人都可以下载撤销名单，检查相应证书是否榜上有名。如果有，说明证书已经被撤销了。
缺点
1）、CRL 名单会随着要撤销的证书增多而变长，每个客户端都必须取得包含所有序列 号的完整名单。 2）、没有办法立即更新刚刚被撤销的证书序列号，比如客户端先缓存了 CRL，之后某 证书被撤销，那到缓存过期之前，该证书将一直被视为有效。
2）、OCSP(Online Certificate Status Protocol，在线证书状态协议)（RFC 2560）
一种实时检查证书状态的机制。 支持验证端直接查询证书数据库中的序列号，从而验证证书链是否有效。
缺点
1）、证书颁发机构必须处理实时查询。 2）、证书颁发机构必须确保随时随地可以访问。 3）、客户端在进一步协商之前阻塞 OCSP 请求。 4）、由于证书颁发机构知道客户端要访问哪个站点，因此实时 OCSP 请求可能会泄露 客户端的隐私。
现实中，CRL 和 OCSP 机制是互补存在的，大多数证书既提供指令也支持查询。
6、TLS 记录协议
TLS 记录协议负责 识别不同的消息类型(握手、警告或数据，通过“内容类型”字段)，以及每条消息的安全和完整性验证。TLS 记录结构如下图所示：
交付应用数据的典型流程如下：
1）、记录协议接收应用数据。 2）、接收到的数据被切分为块:最大为每条记录 214 字节，即 16 KB。 3）、压缩应用数据(可选)。 4）、添加 MAC(Message Authentication Code)或 HMAC。 5）、使用商定的加密套件加密数据。
之后，加密数据就会被交给 TCP 层传输。接收端的流程 相同，顺序相反:使用商定的加密套件解密数据、验证 MAC、提取并把数据转交给上层的应用。
缺点
1）、TLS 记录最大为 16 KB; 2）、每条记录包含 5 字节的首部、MAC(在 SSL 3.0、TLS 1.0、TLS 1.1 中最多 20 字节，在 TLS 1.2 中最多 32 字节)，如果使用块加密则还有填充; 3）、必须接收到整条记录才能开始解密和验证。
7、TLS 优化 Tips
1）、尽早完成握手
使用 CDN，在世界各地的服务器上缓存或重复部署数据和服务，而不需要让所有用户都通过跨海或跨大陆光缆连接到一个中心原始服务器。
优势
1）、通过使用本地代理服务器分流负载等手段降低延迟。 2）、本地代理服务器也可以与原始服务器建立一批长期的安全连接，全权代理请求与响应。 3）、在 CDN 中，客户端连接终止于邻近 CDN 节点，该节点将请求转发到与对端服务器邻近的 CDN 节点，之后请求才会被路由到原始服务器。这可以让数据在优化的 CDN 骨干网中寻路，从而进一步减少客户端与服务器之间的延迟。
2）、使用会话缓存与无状态恢复
在大多数服务器的默认配置下它是禁用的，我们需要手动开启它。 在支持的客户端中使用会话记录单，而在不支持的客户端中使用会话标识符。
3）、TLS 记录大小
小记录会造成浪费，大记录会导致延迟。最优 TLS 记录大小的参考值如下所示：
IPv4 帧需要 20 字节，IPv6 需要 40 字节; TCP 帧需要 20 字节; TCP 选项需要 40 字节(时间戳、SACK 等)。
默认情况下，OpenSSL 等常用的库会给每个连接分配 50 KB 空间，而谷歌的服务器把 OpenSSL 缓冲区的大小减少到 了大约 5KB。因此，我们需要在保障功能的前提下尽可能使用最小的内存。
4）、证书链的长度
浏览器怎么知道到哪里去找证书呢?
因为 子证书中通常包含父证书的 URL。
我们应该确保证书链的长度最小。如果证书链长度超过了 TCP 的初始拥塞窗口，那我们无意间就会让握手多了一次往返:证书长度超过拥塞窗口，从而导致服务器停下来等待 客户端的 ACK 消息。
对此，有 两种解决方式：
1）、增大拥塞窗口。 2）、减少证书大小： 尽量减少中间证书颁发机构的数量：理想情况下，发送的证书链应该只包含两个 证书:站点证书和中间证书颁发机构的证书。第三个证书，也就是根证书颁发机构的证书，已经包含在浏览器内置的信任名单中了，不用发送。 理想的证书链应该在 2 KB 或 3 KB 左右。
5）、OCSP 封套
服务器可以在证书链中包含(封套)证书颁发机构的 OCSP 响应，让浏览器跳过在线查询。把查询 OCSP 操作转移到服务器可以让服务器缓存签名的 OCSP 响应，从而节省很多客户端的请求。
6）、HTTP 严格传输安全(HSTS，Strict Transport Security)
一种安全策略机制，让服务器通过简单的 HTTP 首部(如 Strict-Transport-Security: max-age=31536000) 对适用的浏览器声明访问规则。
max-age 以秒为单位指定 HSTS 规则集的生存时间(例如，max-age=31536000 等于 缓存 365 天)。
优势
HSTS 通过把责任转移到客户端，让客户端自动把所有链接重写为 HTTPS，消除了从 HTTP 到 HTTPS 的重定向损失。
我们需要熟练掌握 openssl 命令行工具，通过它来检查整个握手和本地服务器配 置情况。其使用如下所示：
quchao@quchaodeMacBook-Pro paxgo % openssl s_client -state -CAfile startssl.ca.crt -connect igvita.com:443
4482293356:error:02FFF002:system library:func(4095):No such file or directory:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/crypto/bio/bss_file.c:122:fopen('startssl.ca.crt', 'r')
4482293356:error:20FFF080:BIO routines:CRYPTO_internal:no such file:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/crypto/bio/bss_file.c:125:
4482293356:error:0BFFF002:x509 certificate routines:CRYPTO_internal:system lib:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/crypto/x509/by_file.c:248:
CONNECTED(00000005)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = igvita.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/CN=igvita.com
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFXTCCBEWgAwIBAgISBJN+3MX9OKjS5cX4b6ww/vtAMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA0MjAxMzI1NDNaFw0y
MDA3MTkxMzI1NDNaMBUxEzARBgNVBAMTCmlndml0YS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCx5ZoBTHLEUmRbkMVyBESzjCR1Oz9aop5aQRAp
bviLSasQbKaXp1DkzaB10am9Nr3ROKtP6tQgB8suaYC94I4SatnJsB3EBGew5GUr
MKybvoQYp4HzJvC49uUZDWFOlWdw6P5ldVXjsX22ATobK5XY0Tr1Ci5j7goanXRF
49sZ6yT5xVsKjprdg8/aoqtIDYXvJsZfJiDyGVung3Qb8RbmjlPvvGS7AXESSA8b
3g7lMdRBhsRPL7BXuVVnoU5CsPcTc7GPuJ5z0Qbfa34NILq4zPqvgH1pWRNJX7Fn
S7Hf5RVhlsuiCEr7BheVGWOjujuxFPOnPkoQ4EcfP6iGBITRAgMBAAGjggJwMIIC
bDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFJbxqiGGEZ5EEEWj1p1RWhYRU/ESMB8G
A1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMwYTAu
BggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9yZzAv
BggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9yZy8w
JQYDVR0RBB4wHIIKaWd2aXRhLmNvbYIOd3d3Lmlndml0YS5jb20wTAYDVR0gBEUw
QzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDov
L2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdwBv
U3asMfAxGdiZAKRRFf93FRwR2QLBACkGjbIImjfZEwAAAXGX+wdyAAAEAwBIMEYC
IQC55PavTz4OWvcbMpDNQIcR/SYEDvdSkqrYjxDRGx4vawIhAOCcGF3LKximqSmf
ch6R1EuZo/WTDzPioxM7X3w3kvFAAHYAB7dcG+V9aP/xsMYdIxXHuuZXfFeUt2ru
vGE6GmnTohwAAAFxl/sHcgAABAMARzBFAiBUlTes9VFQ56gbUgRq/7fFUVi6r4Eo
sWHADNNsQ7BSIgIhAPyfR9jDpnHQi3cqjRV2lBp0rrLAcEKf+b4cpDUvw41NMA0G
CSqGSIb3DQEBCwUAA4IBAQBGvck8LK6h8zMxA6bNpxW5Md6K/cUA/HlS0GUiOlnh
9IWZfg3t96Co9d8i90tqjm2gGRVDk7ywiGUClFky6EPICTka0VQRwgLI6aIvh9OF
8syf0QijfXUIkFRZNxGRkAsFqPsbAbDc6+hUMOWQY/uw2yITLB0eS+HyRAZWszoJ
IS4b/Y/gHvnkF/d+y792Y61pf9qtuuTgV/Wdb/KtxJtHKOPVn2eMF7omwyQfqF5o
CijVj/znJBaq9f/8BerL76qRTgeJeM8z0H18ZRpplMyS0T/k1QRTIq6c8lpOt887
PP2IVI8v3WlgNtlZ8XypmZdBjQtncaB1S2MmKgqas5Dx
-----END CERTIFICATE-----
subject=/CN=igvita.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 3093 bytes and written 354 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: CF508DEBB4768BBB308095B730EB0FBC7F21C53095AE8DF2E0905D085F98F158
Session-ID-ctx:
Master-Key: BEF07A818F91C840EF60A4DB5AEE89A1107EB594BC4718D7B4E2FC6904289AE7E7DB2CF6497812A82CCFD23F33B915B6
Start Time: 1590415033
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
SSL3 alert read:warning:close notify
closed
SSL3 alert write:warning:close notify
其中需要了解 四处关键信息：
SSL_connect：SSLv3 read server done A：客户端完成对接收到的证书链的验证。Certificate chain：接收到的证书链(2 个证书)。SSL handshake has read 3093 bytes and written 354 bytes：接收到证书链的大小。Session-ID：对有状态 TLS 恢复发送的会话标识符。
六、无线网络性能
1、无线网络的类型
个人局域网(PAN) 局域网(LAN) 城域网(MAN) 广域网(WAN)
2、无线网络的性能基础
1）、信道容量（最大信息速率）
C= BW × log2(1+S/N)
C 是信道容量，单位是 bit/s; BW 是可用带宽，单位是 Hz; S 是信号，N 是噪声，单位是 W。
它涵盖了影响大多数无线网络性能的所有基本因素。
2）、带宽
为实现通信，发送端与接收端必须事先就通信使用的频率范围达成共识，在这个频率范围内双方才可以顺畅地交换信息。
影响性能的最主要因素就是频率范围的大小(带宽)。由信道容量的公式可知，信道的总体比特率与分配的带宽呈正比。
3）、信号强度
信噪比(SNR，Signal Noise Ratio)，它衡量的是预期信号强度与背景噪声及干扰之间的比值。背景噪声越大，携带信息的信号就必须越强。
如果想在存在干扰的情况下达到预期的数据传输速度，要么增大 发射功率，也就是提高信号强度，要么缩短收发两端的距离——或者双管齐下。
路径损耗（通路衰减）
信号强度随距离降低。
远近效应
接收端捕获较强的信号，因而不可能检测到较弱的信号，实际上是“挤出”了较弱的信号。例如你旁边一个或多个大声讲话的人会阻挡较弱的信号，从而产生远近效应。
小区呼吸效应
小区覆盖范围或信号传输距离基于噪声大小和干扰级别扩展和收缩。例如你周围交谈的人越多，干扰就越严重，能让你识别有用信号的范围也越小，这就是呼吸效应。
4）、调制
数字信号(1 和 0)需要转换成模拟信号(无线电波)。调制指的就 是这个数模转换过程，而不同调制算法的转换效率是不一样的。
但是，高阶调制的代价是针对噪声和干扰的可靠性降低。因此，需要在它们与转换效率直接做一个权衡。
3、影响无线网络性能的因素
收发端的距离; 当前位置的背景噪声大小; 来自同一网络(小区)其他用户的干扰大小; 来自相邻网络(小区)其他用户的干扰大小; 两端发射功率大小; 处理能力及调制算法。
七、Wi-Fi
Wi-Fi 可以用来指称任何基于 IEEE 802.11 标准的产品。它工作于免许可的 2.4 GHz ISM 频段。
1、从以太网到无线局域网
在 1971 年夏威夷大学对外公布了第一个关于无线网络的协议— ALOHAnet 协议。
以太网协议很大程度上借鉴了 ALOHAnet 协议，以太网通常被称作局域网(LAN)标准，而 802.11 无线标准主要是作为既有以太网标准(802.3)的扩展来设计的。因此它也相应地被称作无线局域网(WLAN，Wireless LAN )标准。
1）、以太网—冲突检测(CSMA/CD，Collision Detection)机制
如果检测到冲突，则双方都立即停止发送数据并小睡一段随机的时间(后续时间以指数级增长)，从而保证发生冲突 的发送端不会同步，且不会同时重新开始发送数据。
2）、Wi-Fi-冲突避免(CSMA/CA， Collision Avoidance)机制
由于收发无线电的硬件所限，它不能在发送数据期间检测到冲突。因此，每个发送方都会在自己认为信道空闲时发送数据，以避免冲突。
2、Wi-Fi 优化 Tips
1）、利用不计流量的带宽
2）、适应可变带宽
比如自适应比特流，来主动适应带宽变化。自适应比特流并不适合所有资源，但对视频和音频这样的长时间流服务是非常合适的。
在客户端下载视频流期间，客户端或服务器可以监控每个视频块的下载速度，必要时根据带宽的变化调整要下载的下一个视频块的比特率。事实上，现实中的视频服务，开始一般是低比特率的视频块，以便视频播放能更快开始。然后，再根据可用带宽的动态变化调整后续视频块的比特率。
END
参考链接：
1、《Web 性能权威指南》1 - 13章（本文核心）
https://book.douban.com/subject/25856314/
2、《Android开发高手课》 网络优化基础
https://time.geekbang.org/column/intro/142?gk_ucode=6891EC39BDEA36
3、《透视 HTTP 协议》优化基础部分
https://time.geekbang.org/column/intro/100029001
4、HTTP/2 头部压缩技术介绍
https://imququ.com/post/header-compression-in-http2.html
5、HTTP 2.0 Header table
https://httpwg.org/specs/rfc7541.html#static.table.definition
6、从 IPv4 到 IPv6，阿里踩过哪些坑？
https://mp.weixin.qq.com/s/RXICO_3W2cxTYk0UV40GLQ
7、腾讯云如何快速从IPv4向IPv6演进？
https://mp.weixin.qq.com/s/ufV7mZWHPfLNE1-QxWmEfQ
8、千兆级LTE与5G的那些事儿
https://rf.eefocus.com/article/id-332405
9、讲清楚5G，这可能是最接地气的一篇了
https://mp.weixin.qq.com/s/bPNuEbwZZS9uS5bKmHskTw
10、IEEE_802.11ac
https://zh.wikipedia.org/wiki/IEEE_802.11ac
11、MIMO
https://zh.wikipedia.org/wiki/MIMO
12、Link Turbo 就是 5G前夜的“网络加速器”
https://www.pingwest.com/a/181911
13、MultiPath TCP - Linux Kernel implementation
http://www.multipath-tcp.org/
14、Multipath TCP: an overview
https://lwn.net/Articles/544399/
15、聊聊Linux 五种IO模型
https://www.jianshu.com/p/486b0965c296
16、Unix 网络 IO 模型及 Linux 的 IO 多路复用模型
http://matt33.com/2017/08/06/unix-io/
17、Android epoll.c
http://androidxref.com/9.0.0_r3/xref/external/libevent/epoll.c
深入探索 Android 网络优化（一、网络筑基篇）上
深入探索 Android 网络优化（一、网络筑基篇）下
欢迎关注我的微信：bcce5360，群人数已超200，无法扫码入群，加我微信拉你进群。
点击下方卡片关注JsonChao，为你构建一套
未来Android开发必备的知识体系
▲ 点击上方卡片关注 JsonChao，构建一套
未来 Android 开发必备的知识体系
欢迎把文章分享到朋友圈
很感谢您阅读这篇文章，希望您能将它分享给您的朋友或技术群，这对我意义重大。
你若喜欢，为JsonChao点个在看哦