深入探索 Android 网络优化（二、网络优化基础篇，android编程基础教程
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