深刻探索 Android 网络优化（2、网络优化基础篇）上

时间  2020-05-31
标签 深刻 探索 android 网络 优化 基础 栏目 Android 繁體版
原文   原文链接

前言

成为一名优秀的Android开发，须要一份完备的知识体系，在这里，让咱们一块儿成长为本身所想的那样~。

思惟导图大纲

1、为何要进行网络优化？

「等待网络是咱们 App 最大的性能瓶颈，再怎么优化绘制、内存、卡顿或其它方面，也抵不上网络优化」！网络通讯速度越快，则：html

  • 1）、 「用户黏性越高」。
  • 2）、 「用户忠诚度更高」。
  • 3）、 「转化率越高」。

而网络优化最核心的处理方式就是 「消除和减小没必要要的网络延迟，把传输的字节数降到最少」。android

2、网络性能评估

一、无线网络通讯过程

手机 => 无线网络 => 基站 => 运营商核心网 => 互联网 => 服务器
复制代码

二、重要指标

1）、延时

「数据从信息源发送到目的地所需的时间」。客户端到服务端的总延迟时间以下所示：git

  • 1）、 「传播延迟：消息从发送端到接收端须要的时间，是信号传播距离和速度的函数。光速是全部能量、物质和信息运动所能达到的最高速度，这个结论给网络分组的传播速度设定了上限」。
  • 2）、 「传输延迟：把消息中的全部比特转移到链路中须要的时间，是消息长度和链路速率的函数」。
  • 3）、 「处理延迟：处理分组首部、检查位错误及肯定分组目标所需的时间」。
  • 4）、 「排队延迟：到来的分组排队等待处理的时间」。

一路上通过的路由器越多，每一个分组的处理和传输延迟就越多。而且，网络流量越拥挤，分组在入站缓冲区中被延迟的可能性就越大。github

最后，延迟中至关大的一部分每每花在了最后几千米，经过 traceroute 命令，咱们就能够知道上网服务商的拓扑结构和速度。web

2）、带宽

「逻辑或物理统统信路径的最大吞吐量」。算法

网络核心的带宽

光纤

就是一根“光导管”，比人的头发稍粗一点，专门用来从一端向另外一端传送光信号。数据库

金属线

用于传送电信号，但信号损失、电磁干扰较大，同时维护成本也较高。json

这两种线路咱们的数据分组极可能都会通过，但通常长距离的分组传输都是经过光纤完成的。浏览器

经过 「波分复用（WDM，Wavelength-Division Multiplexing）技术，光纤能够同时传输不少不一样波长（信道）的光」，于是具备明显的带宽优点。缓存

「一条光纤链接的总带宽，等于每一个信道的数据传输速率乘以可复用的信道数。而每条光缆会封装几条光纤（常见的是4条），折算出来的带宽容量能达到每秒几百太比特」。

网络边缘的带宽

用户可用带宽取决于客户端与目标服务器间最低容量链接，咱们能够在 akamai 查看世界各地的平均带宽。可是，「高带宽并不能保证端到端的传输速度」。

❝

延迟、带宽与什么因素有关？

❞

「信号强度、基站距离、网络制式、拥塞状况」 等等不少因素相关。

三、了解不一样网络制式的带宽与延迟参考值

网络制式 带宽（下行/上行） 延迟
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 是重延时的应用仍是重带宽的应用」。

遗憾的是，人类不太可能跳出物理定律的 “掌心”。若是须要针对延迟采起优化措施，就必须从 「设计和优化协议及应用」 着手，而且时刻牢记光速的限制。

3、TCP 优化

因特网有两个核心协议: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 个版本的承继关系，以前并无单独的 IPv一、IPv2 或 IPv3 协议。而 v5 已经被分配给了另外一个试验性协议 Internet Stream Protocol(ST)」。但 ST 一直没有什么进展，这也是咱们为何不多据说它的缘由。结果 TCP/IP 的下 一版本就成了 IPv6。

一、三次握手

  • 1）、出于安全考虑，序列号由两端随机生成。
  • 2）、客户端能够在发送 ACK 分组以后当即发送数据，而服务器必须等接收到 ACK 分组以后才能发送数据。
  • 3）、三次握手带来的延迟使得每建立一个新 TCP 链接都要付出很大代价。而这也决定了提升 TCP 应用性能的关键，在于想办法重用链接。

TFO（TCP Fast Open，TCP 快速打 开)

TFO 致力于减小新建 TCP 链接带来的性能损失。但却只能在某些状况下有效。好比，「随同 SYN 分组一块儿发送的数据净荷有最大尺寸限制、只能发送某些类型的 HTTP 请 求，以及因为依赖加密 cookie，只能应用于重复的链接」。

二、拥塞预防及控制

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+ 内核默认的拥塞预防算法」。

三、BDP(Bandwidth-delay product，带宽延迟积)

接收窗口（rwnd）会随每次 ACK 一块儿发送，而 拥塞窗口（cwnd）则由发送端根据拥塞控制和预防算法动态调整。

不管发送端发送的数据仍是接收端接收的数据超过了未确认的最大数据量，都必须停 下来等待另外一方 ACK 确认某些分组才能继续。

而 BDP(Bandwidth-delay product，带宽延迟积) 就是 「任意时刻处于在途未确认状态的最大数据量」。

BDP = 数据链路的容量 * 其端到端延迟
复制代码

「在高速链接的客户端与服务器之间，若是实际传输速度只有可用带宽的几分之一，那窗口大小极可能就是 罪魁祸首。要么由于某一饱和端通告的接收窗口很小，要么由于网络拥堵和丢包致使拥塞窗口重置，更可能由于流量增加过快致使对链接吞吐量施加了限制」。

四、TCP 队首(HOL，Head of Line)阻塞

TCP 在不可靠的信道上实现了可靠的网络传输。基本的分组错误检测与纠正、按 序交付、丢包重发，以及保证网络最高效率的流量控制、拥塞控制和预防机制，让 TCP 成为大多数网络应用中最多见的传输协议。

可是，其中的按序交付和可靠交付有时候并没必要要，反而会致使额外的延迟，对性能形成负面影响。例如：每一个 TCP 分组都会带着一个惟一的序列号被发出，而 全部分组必须按顺序传送到接收端。若是中途有一个分组没能到达接收 端，那么后续分组必须保存在接收端的 TCP 缓冲区，等待丢失的分组重发并到达接 收端。这一切都发生在 TCP 层，应用程序对 TCP 重发和缓冲区中排队的分组一无所 知，必须等待分组所有到达才能访问数据。在此以前，应用程序只能在经过套接字 读数据时感受到延迟交付。这种效应称为 TCP 的队首(HOL，Head of Line)阻塞。

「队首阻塞使得分组到达时间会存在没法预知的延迟变化，而这个时间变化一般被称为抖动」。

所以，对于无需按序交付数据或可以处理分组丢失的应用程序，以及对延迟或抖动要求很高的应用程序，最好选择 UDP 等协议。

丢包的副作用力

丢包是让 TCP 达到最佳性能的关键。被删除的包偏偏是一种反馈机制， 可以让接收端和发送端各自调整速度，以免网络拥堵，同时保持延迟最短。

对与实时性比较强的音视频应用来讲，就算有个包丢了，音频编解码器只要在音频中插入一个小小的间歇，就能够继续 处理后来的包。只要间歇够小，用户就注意不到，而等待丢失的包则可能致使音 频输出产生没法预料的暂停。相对来讲，后者的用户体验更糟糕。

五、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 链接：把慢启动和其余拥塞控制机制的影响降到最低」。

4、UDP 优化

数据报，即一个完整、独立的数据实体，携带着从源节点到目的地节点的足够信息，对这些 节点间以前的数据交换和传输网络没有任何依赖。

一、数据包和分组的区别

数据报(datagram)和分组(packet)是两个常常被人混用的词，实际上它们仍是 有区别的。「分组能够用来指代任何格式化的数据块，而数据报则一般只用来描述那 些经过不可靠的服务传输的分组，既不保证送达，也不发送失败通知」。

IETF 和 W3C 工做组共同制定了一套新 API—— WebRTC(Web Real-Time Communication，Web 实时通讯)。「WebRTC 着眼于在浏览器中经过 UDP 实现原生的语音和视频实时通讯，以及其余形式的 P2P(Peer-to-Peer，端到端)通讯」。

二、无协议服务

众所周知，IP 层的主要任务就是按照地址从源主机向目标主机发送数据报。而 「数据报」 则暗示着:「IP 层不保证消息可靠的交付，也不发送失败通知，其实是把底层网络的不可靠性直接暴露给了上一层」。若是某个路由节点由于网络拥塞、负载太高或其余缘由而删除了 IP 分组，那么在必要的状况下，IP 的上一层协议要负责检测、恢复和重发数据。

UDP 数据报中的源端口和校验和字段都是可选的。IP 分组的首部也有校验和，应用程序能够忽略 UDP 校验和。所以，「UDP 仅仅是在 IP 层之上经过嵌入应用程序的源端口和目标端口，提供了一个“应用程序多路复用”机制」。

UDP 的无服务

  • 1）、 「不保证消息交付：不确认，不重传，无超时」。
  • 2）、 「不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞」。
  • 3）、 「不跟踪链接状态：没必要创建链接或重启状态机」。
  • 4）、 「不须要拥塞控制：不内置客户端或网络反馈机制」。

三、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 的第三方库。

四、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 协议则是上述的设计典范。

5、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 协议为基础，同时兼顾数据报交付模式并提供相似的安全保障。

一、加密、身份验证与完整性

TLS 协议的目标是为在它之上运行的应用提供三个基本服务：

  • 1）、 「加密：混淆数据的机制」。
  • 2）、 「身份验证：验证身份标识有效性的机制」。
  • 3）、 「数据完整性：检测消息是否被篡改或伪造的机制」。

1）、加密

在握手机制中设计最巧妙的地方，就是其使用的公钥密码系统 (也称“非对称密钥加密”)，这套系统可让通讯双方没必要事先“认识”便可商定共 享的安全密钥，并且协商过程仍是经过非加密通道完成的。

2）、身份验证

握手过程当中，TLS 协议还容许通讯两端互相验明正身。这个验证首先须要创建“认证机构信任链”(Chain of Trust and Certificate Authorities)。

3）、数据完整性

消息分帧机制，使用 MAC (Message Authentication Code，消息认证码)签署每一条消息。MAC 算法是一个单向加密的散列函数(本质上是一个校验和)，「密钥由链接双方协商肯定。只要发送 TLS 记录，就会生成一个 MAC 值并附加到该消息中」。接收端经过计算和验证这个 MAC 值来判断消息的完整性和可靠性。

二、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 协议，该扩展 「容许客户端在握手之初就指明要链接的主机名」。

三、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 扩展中。这样，全部会话数据只保存在客户端，而因为 数据被加密过，且密钥只有服务器知道，所以仍然是安全的。

会话标识符和会话记录单机制，即“会话缓存”或“无状态恢复”机制。其优势「主要是消除了服务器端的缓存负担，经过要求客户端在与服务器创建新链接时提供会话记录单简化了部署(除非记录单过时)」。

四、信任链与证书颁发机构

「身份验证即用本身的私钥签名，而后对方用本身的公钥验证收到的消息签名」。但信任是交流的关键。

对于浏览器来讲，它信任谁呢?

「至少有三个答案」：

  • 1）、 「手工指定证书：全部浏览器和操做系统都提供了一种手工导入信任证书的机制」。
  • 2）、 「CA(Certificate Authority，证书颁发机构)：被证书接受者(拥有者)和依赖证 书的一方共同信任的第三方」。
  • 3）、 「浏览器和操做系统：其中都会内置一个知名证书颁发机构的名单。所以，你也会信任操做系统及浏览器提供商提供和维护的可信任机构」。

最多见的方案，就是浏览器指定可信任的证书颁发机构(根 CA)。而 「证书颁发机构签署数字证书的流程」 以下图所示：

全部浏览器都容许用户检视本身安全链接的信任链，「常见的访问入口就是地址栏头儿上的锁图标」，点击便可查看。以下图所示：

「整个链条的“信任依据”是根证书颁发机构，而每一个浏览器都会内置一个可信任的证书颁发机构(根机构)的名单」。

五、证书撤销

通讯的任何一端均可以根据嵌入的指令和签名检查链条中每一个证书的状态。

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 机制是互补存在的，大多数证书既提供指令也支持查询」。

六、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）、 「必须接收到整条记录才能开始解密和验证」。

七、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 恢复发送的会话标识符」。

6、无线网络性能

一、无线网络的类型

  • 「我的局域网(PAN)」
  • **局域网(LAN) **
  • **城域网(MAN) **
  • 「广域网(WAN)」

二、无线网络的性能基础

1）、信道容量（最大信息速率）

C= BW × log2(1+S/N) 复制代码
  • C 是信道容量，单位是 bit/s;
  • BW 是可用带宽，单位是 Hz;
  • S 是信号，N 是噪声，单位是 W。

「它涵盖了影响大多数无线网络性能的全部基本因素」。

2）、带宽

为实现通讯，「发送端与接收端必须事先就通讯使用的频率范围达成共识」，在这个频率范围内双方才能够顺畅地交换信息。

影响性能的最主要因素就是频率范围的大小(带宽)。由信道容量的公式可知，信道的整体比特率与分配的带宽呈正比。

3）、信号强度

信噪比(SNR，Signal Noise Ratio)，「它衡量的是预期信号强度与背景噪声及干扰之间的比值」。背景噪声越大，携带信息的信号就必须越强。

「若是想在存在干扰的状况下达到预期的数据传输速度，要么增大 发射功率，也就是提升信号强度，要么缩短收发两端的距离——或者左右开弓」。

路径损耗（通路衰减）

「信号强度随距离下降」。

远近效应

接收端捕获较强的信号，于是不可能检测到较弱的信号，其实是“挤出”了较弱的信号。例如你旁边一个或多个大声讲话的人会阻挡较弱的信号，从而产生远近效应。

小区呼吸效应

小区覆盖范围或信号传输距离基于噪声大小和干扰级别扩展和收缩。例如你周围交谈的人越多，干扰就越严重，能让你识别有用信号的范围也越小，这就是呼吸效应。

4）、调制

「数字信号(1 和 0)须要转换成模拟信号(无线电波)」。调制指的就 是这个数模转换过程，而不一样调制算法的转换效率是不同的。

可是，「高阶调制的代价是针对噪声和干扰的可靠性下降」。所以，须要在它们与转换效率直接作一个权衡。

三、影响无线网络性能的因素

  • 「收发端的距离」;
  • 「当前位置的背景噪声大小」;
  • 「来自同一网络(小区)其余用户的干扰大小」;
  • 「来自相邻网络(小区)其余用户的干扰大小」;
  • 「两端发射功率大小」;
  • 「处理能力及调制算法」。

7、Wi-Fi

Wi-Fi 能够用来指称任何基于 IEEE 802.11 标准的产品。它工做于免许可的 2.4 GHz ISM 频段。

一、从以太网到无线局域网

在 1971 年夏威夷大学对外公布了第一个关于无线网络的协议— ALOHAnet 协议。

以太网协议很大程度上借鉴了 ALOHAnet 协议，以太网一般被称做局域网(LAN)标准，而 802.11 无线标准主要是做为既有以太网标准(802.3)的扩展来设计的。所以它也相应地被称做无线局域网(WLAN，Wireless LAN )标准。

1）、以太网—冲突检测(CSMA/CD，Collision Detection)机制

若是检测到冲突，则双方都当即中止发送数据并小睡一段随机的时间(后续时间以指数级增加)，从而保证发生冲突 的发送端不会同步，且不会同时从新开始发送数据。

2）、Wi-Fi-冲突避免(CSMA/CA， Collision Avoidance)机制

因为收发无线电的硬件所限，它不能在发送数据期间检测到冲突。所以，每一个发送方都会在本身认为信道空闲时发送数据，以免冲突。

二、Wi-Fi 优化 Tips

1）、利用不计流量的带宽

2）、适应可变带宽

好比自适应比特流，来主动适应带宽变化。自适应比特率并不适合全部资源，但对视频和音频这样的长时间流服务是很是合适的。

在客户端下载视频流期间，客户端或服务器能够监控每一个视频块的下载速度，必要时根据带宽的变化调整要下载的下一个视频块的比特率。事实上，现实中的视频服务，「开始通常是低比特率的视频块，以便视频播放能更快开始。而后，再根据可用带宽的动态变化调整后续视频块的比特率」。

❝

深刻探索 Android 网络优化（2、网络优化基础篇）下

❞

参考连接：

Contanct Me

● 微信：

❝

欢迎关注个人微信：bcce5360

❞

● 微信群：

❝

微信群若是不能扫码加入，麻烦你们想进微信群的朋友们，加我微信拉你进群。

❞

● QQ群：

❝

2千人QQ群，「Awesome-Android学习交流群，QQ群号：959936182」， 欢迎你们加入~

❞

About me

很感谢您阅读这篇文章，但愿您能将它分享给您的朋友或技术群，这对我意义重大。

但愿咱们能成为朋友，在 Github、掘金上一块儿分享知识。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程