深入探索 Android 网络优化（二、网络优化基础篇）下

▲ 点击上方第二个“JsonChao”关注公众号

这是JsonChao的第 75 期分享

思维大图大纲

八、移动网络

用 2G 看 txt，用 3G 看 jpg，用 4G 看 avi。

1、G字号移动网络简介

代	峰值数据速率	说明
1G	无数据	模拟系统
2G	Kbit/s	第一代数字系统，作为对模拟系统的替代或与之并存
3G	Mbit/s	专用数字网络，与模拟系统并行部署
4G	Gbit/s	数字及分组网络

1）、1G

最早的商业 1G 网络于 1979 年部署于日本。这种网络属于模拟系统，没有数据传输能力。

2）、2G

1991 年，芬兰基于新兴的 GSM(Global System for Mobile communications， 全球移动通信系统) 标准建设了第一个 2G 网络，最早在无线电网络中引入了数字 信令。

直到 1990 年代中期，GPRS(General Packet Radio Service，通用无线分组业务) 被 引入 GSM 标准，无线互联网才真正走向实用。而 GPRS 与早期 2G 语音技术的 结合通常被称为 2.5G。

3）、3G

1998 年，GSM 和 IS-95 组织又成立了两个全球性的合作伙伴项目便于指定 3G 标准：

• 3GPP(3rd Generation Partnership Project，第三代合作伙伴项目)：负责制定 UMTS(Universal Mobile Telecommunication System，通用移动通信系统)，其后来也负责维护 GSM 标 准和制定新的 LTE 标准。
• 3GPP2(3rd Generation Partnership Project 2)：负责基于 CDMA2000，也就是高通制定的 IS-95 标准的后续技术制定 3G 规范。

3GPP 和 3GPP2 共同管理每种技术的演进。在 Android 手机上，输入:##4636#*#*，可以看到移动连接的类型、电池诊断等信息。

4）、满足 IMT-Advanced 的 4G

所谓 4G，背后是一组具体要求(IMT-Advanced)， 这组要求是 ITU 在 2008 年就制定和公布了的。任何达到这些要求的技术，都可以看作是 4G 技术。例如：

• 以 IP 分组交换网络为基础。
• 与之前的无线标准(3G 和 2G)兼容。
• 移动客户端的速率达到 100 Mbit/s，静止时的速率达到 Gbit/s 以上。

5）、长期演进(LTE)

随着对高速率和低延迟的需求越来越强烈，3GPP 计划重新设计核心及无线网络，于是 LTE(Long Term Evolution，长期演进)标准应运而生。而它与前面介绍的 IMT-Advanced 要求很类似。

2、无线电资源控制器(RRC)

2G、3G 和 4G 网络都有 RRC，它具有如下特点：

• 1）、负责调度协调移动设备与无线电基站之间所有的通信连接。
• 2）、直接直接影响延迟、吞吐量和设备电池的使用时间。
• 3）、2G 和 3G 网络中的 RRC 处于核心运营网络， 而在 4G 中，为提升性能、减少协调时间，RRC 被转移到了无线信号塔 (eNodeB)。

简而言之，RRC 就是无线电网络的大脑。想要通过无线信道发送数据?你必须先向 RRC 申请无线电资源。想要接收互联网上的数据? RRC 会通知你什么时候监听接收到来的分组。

3、移动网络中的分组流

1）、初始化请求

核心流程

• 1）、首先，由于手机处于空闲 RRC 状态，因此无线电模块必须与附近的信号塔同步，然后发送一个请求，以便建立无线通信环境，此次协商需要手机与信号塔之间的几次往返，可能需要花 100ms。如果是前几代网络，那 RRC 由服务网关负责管理，这个协商过程要长得多，可达几秒钟。
• 2）、建立了无线通信环境后，设备就会从信号塔得到相应资源，从而能够以特定的速度和功率传输数据。
• 3）、分组通过核心网络从 SGW 传输到 PGW。
• 4）、最后向外传到公共互联网。

其中各个步骤的延迟特点如下所示：

• 1）、控制面延迟：由 RRC 协商和状态切换导致的固定的、一次性的延迟时间，从空闲到活动少于 100 ms，从休眠到活动少于 50 ms。
• 2）、用户面延迟：即用户数据从无线电模块传输到信号塔的时间，应用的每个数据分组从设备到无线电信号塔之间都要花的固定的时间，少于 5 ms。
• 3）、核心网络延迟：分组从无线电信号塔传输到分组网关的时间，因运营商而不同，一般为 30~ 100 ms。
• 4）、互联网路由延迟：从运营商分组网关到公共互联网上的目标地址所花的时间，可变。

2）、入站数据流

核心流程

• 1）、PGW 把入站分组路由到 SGW，SGW 进一步查询 MME。
• 2）、如果设备处于空闲状态，MME 会向当前跟踪区内的所有信号塔发送一条寻呼消息。
• 3）、收到消息的信号塔接着通过共享的无线信道广播一条通知，告知设备应该重建无线通信环境，以便接收数据。
• 4）、设备周期性地唤醒以监听寻呼消息，如果在寻呼列表中发现了自己，它就会向无线电信号塔发送一条协商请求，请求重建无线通信环境。
• 5）、无线通信环境重建之后，负责协商的信号塔向 MME 回发一条消息，表示它 正在为用户服务。
• 6）、然后，MME 向服务网关返回一个应答，服务网关于是就会把数据路由到该信号塔。
• 7）、最后，该信号塔再把数据转发给目标设备。

设备一旦处于连接状态，无线信号塔与服务网关之间就会建立一条直连信道，从而 让后续到达的数据能跳过第2 ~ 5步(不用再经过寻呼)，直接被转发到信号塔。因此，第一个分组的延迟是较长的。

4、LTE-A（千兆级 LTE ）

理论上速度可以达到光纤级别的 1Gbps（125MB/s），日常实际使用时平均速度 100Mbps 以上。

核心技术

1）、载波聚合

将多个载波聚合成更高的带宽，理论上LTE-A系统中可以实现2-5个LTE成员载波（ComponentCarrier，CC）的聚合。

当三个射频信道变成一个更宽的信道，三个20MHz就相当于60MHz，那么数据吞吐量便提升了3倍。

2）、高阶调制

利用有限带宽资源提供高数据速率一种的手段。

提高收发器的复杂程度可以让一个信号搬运更多的比特。例如将 64-QAM （64个样点，样点数目越多传输效率越高）提升到 256-QAM（256个样点），一个信号可以从承载6个比特提升到8个比特，带宽效率提升了33%。

3）、更高阶的 MIMO（Multiple-Input Multiple-Output）

在发射端和接收端分别使用多个发射天线和接收天线。这使信号通过发射端与接收端的多个天线传送和接收，大大增大信道容量。

5、5G

通信技术的极限，并不是技术工艺方面的限制，而是建立在严谨数学基础上的推论，在可以遇见的未来是基本不可能突破的。而 1G ~ 5G 都逃脱不了下面这个公式：

光速 = 波长 × 频率

1）、现代通信技术的现状

有线通信

实验室中的单条光纤最大速度 26 Tbps。

无线通信（瓶颈）

4 G LTE 理论速率仅有 150 Mpbs。

5G 实际上如何工作？

通信技术并不神秘，5G 作为通信技术皇冠上最耀眼的宝石，也不是什么遥不可及的创新革命技术，它更多是对现有通信技术的演进。而其实质就是 向新的毫米波和其他高频频段的转变。第五代移动通信技术，5G速率是4G的100倍，实际使用至少是10倍。

2）、优势

• 1）、高性能
• 2）、低延迟
• 3）、高容量

3）、核心技术

1、毫米波

目前主流的 4G LTE 波长都是集中在分米波与厘米波这两个区间，而 5 G 的波长是位于 毫米波 的区间。

2、微基站

由于电磁波频率越高，衰减越大的特点，如果使用高频，那么传输距离与覆盖能力都会减弱。因此覆盖同一个区域，需要的 5G 数量将大大超过 4G。为了降低基站成本，微基站应运而生。

基站分为宏基站和微基站，宏基站在郊外、山上经常可以看到，微基站通常在城区和室内，它可以小到只有巴掌大：）

3、Massive MIMO（大量的多输入、多输出 => 多天线技术）

以前的手机有天线，其实现在的手机也有，只不过天线已经非常小了。因为 天线的长度与波长成正比，公式如下所示：

天线长度 = 波长/10 ~ 波长/4

如果使用了 5 G 的毫米波通信，天线也就可以变成毫米级了，因此，高阶版的多天线技术应运而生。

需要注意的是，无论是基站还是手机中的天线制作，天线之间的距离都应该保持在半个波长以上，以避免互相干扰。

4、全双工

手机与手机直接不仅可以直接进行通信，而且可以实现全双工。

5、波束成形

在基站布设天线阵列（一大群天线），通过对射频信号相位的控制，使得互相作用后的电磁波的波瓣变得非常狭窄，并指向它所提供服务的手机，并且还能够根据手机的移动而转变方向。

优势

将全向的信号覆盖转变为精准指向性服务，这样便可以在相同的空间中提供更多的通信链路。

而目前常用 WIFI 协议标准 5 G：802.11ac，它的特点如下所示：

• 理想速率 866.7Mbps
• 支持8个 MIMO 空间流

6、华为 Link Turbo 网络聚合加速技术

在理想环境下，手机开启 Link Turbo 功能后，**速度相比只连接 WiFi 和只连接 4G 的速度分别提高了 135% 和 71%**，因为它在基础网络协议和算法两方面做了大量的优化。

• 1）、它从业务类型、接入网络的类型、用户喜好三方面进行感知建模，在经过处理之后找到最佳匹配的网络协议。
• 2）、通过算法让两条通道（WIFI、4G）同时满载，需要大量的计算与调试，才能平衡数据包在快慢通道之间的运送比例，最终达到运送效率最佳，速度最快。

需要注意的是，硬件上 WIFI 与 蜂窝网络属于基带芯片的不同模块 => 类似双网卡。

MultiPath TCP（iOS 7 引入）

• 1）、可以让 TCP 连接使用多条路径来最大化资源利用率。
• 2）、需要解决 跨路径数据碎片化、SSL 解密效率低 的问题。
• 3）、MPTCP 会话同 TCP 一样的方式启动，不同的是在 TCP 的 SYN、SYN-ACK、最终的 ACK 数据包的选项中多添加了一个 MP_CAPABLE 选项。

而 Link Turbo 使用了自研 MultiPath UDP，Link Turbo 就是在使用 WIFI 的同时使用移动网络加速。

因此，尝试跟手机厂商、芯片厂商或运营商合作也是一大优化方向。

7、移动网络优化 Tips

1）、爆发传输数据并转为空闲

移动无线接口专门为爆发性传输做过优化，我们可以 尽可能多和快地下载数据，然后让无线模块转为空闲。这样，既可以获得最大的网络吞吐量，也能节约电量。

如果需要大型音频或视频文件，考虑提前下载整个文件，而不要以比特为单位地流式下载。

2）、把负载转移到 Wi-Fi 网络

Wi-Fi 连接下的大数据量传输更省电，而且在通信过程中也不需要 RRC，相对于 4G 网络，这将会节省 50~100 ms 的延迟。

九、HTTP

1、非官方的 HTTP 0.9

1991 年出现，它是只有一行的协议。其主要功能如下：

• 客户端 / 服务器、请求 / 响应协议;
• ASCII 协议，运行于 TCP/IP 链接之上;
• 设计用来传输超文本文档(HTML);
• 服务器与客户端之间的连接在每次请求之后都会关闭。

2、非互联网标准的 HTTP 1.0

1994 年，IETF(Internet Engineering Task Force，互联网工程任务组) 成立了 HTTP 工作组(HTTP-WG)，致力于改进 HTTP 协议。

1996 年，HTTP 工作组发布了 RFC 1945，解释说明了当时很多 HTTP 1.0 实现的“公共用法”。但 HTTP 1.0 并不是一个正式的规范或互联网标准。

由于响应对象本身可以是任何类型:HTML 文件、纯文本文件、图片，或其他内容类型。因此，HTTP 中的“HTT”(Hypertext Transfer，超文本传输)在协议出现后不久就已经用词不当了。在实践中，HTTP 迅 速发展为 超媒体传输协议，但最初的名字则沿用至今。

注意：HTTP 1.0 对每个请求都打开一个新 TCP 连接严重影响性能。

3、互联网标准 HTTP 1.1

1997 年 1 月，定义正式 HTTP 1.1 标准的 RFC 2068 发布了。

HTTP 1.1 中引入了大量增强性能的重要特性：

• 1）、持久化连接以支持连接重用;
• 2）、分块传输编码以支持流式响应;
• 3）、请求管道以支持并行请求处理;
• 4）、字节服务以支持基于范围的资源请求;
• 5）、改进的更好的缓存机制。

HTTP 1.1 改变了 HTTP 协议的语义，默认使用持久连接。换句话说，除非明确告知(通过 Connection: close 首部)，否则服务器默认会保持连接打开。

不过，这个功能也反向移植到了 HTTP 1.0，可以通过 Connection: Keep- Alive 首部 来启用。实际上，如果你使用的是 HTTP 1.1，从技术上说不需要 Connection: Keep-Alive 首部，但很多客户端还是选择加上它。

1）、持久连接的优点

在启用持久连接的情况下，N 次请求节省的总延迟时间就是 (N-1) × RTT。

2）、HTTP 管道

持久 HTTP 可以让我们重用已有的连接来完成多次应用请求，但多次请求必须严格 满足先进先出(FIFO)的队列顺序:发送请求，等待响应完成，再发送客户端队列 中的下一个请求。HTTP 管道是一个很小但对上述工作流却非常重要的一次优化。管道可以让我们把 FIFO 队列从客户端(请求队列)迁移到服务器(响应队列)。如下图所示：

优势

• 消除了发送请求和响应的等待时间。这种并行处理请求的能力对提升应用性能的帮助非常之大。
• 网络延迟越高，请求越多，节省的时间就越多。而越是大型应用，网络优化的影响就越大。

HTTP 中的队首阻塞

例如第一个请求无限期挂起，或者要花很长时间才能处理完，怎么办呢?在 HTTP 1.1 中，所有后续的请求都将被阻塞，等待它完成。

3)、计算图片对内存的需求

所有编码的图片经浏览器解析后都会以 RGBA 位图的形式保存于内存当中。每个 RGBA 图片的像素需要占用 4 字节:红、绿、蓝通道各占 1 字节，Alpha(透明) 通道占 1 字节。

所以，一张图片占用的内存量 = 图片像素宽度 × 像素高度 × 4 字节。

4）、谨慎使用 base64 编码

base64 编码使用 64 个 ASCII 符号和空白符将任意字节流编码为 ASCII 字符串。编码过程中，base64 会导致被编码的流变成原来的 4/3，即增大 33% 的字节开销。

4、改进传输性能的 HTTP 2.0

HTTP 工作组已经在 2012 年宣布要开发 HTTP 2.0，HTTP 2.0 的主要目标是 改进传输性能，实现低延迟和高吞吐量。其具体是 通过支持请求与响应的多路复用来减少延迟，通过压缩 HTTP 首部字段将协议开销降至最低，同时增加对请求优先级和服务器端推送的支持。

1）、历史及其与 SPDY 的渊源

SPDY 是谷歌开发的一个实验性协议，于 2009 年年**中 发布，其主要目标是 通过解决 HTTP 1.1 中广为人知的一些性能限制，来减少网页的加载延迟**。

2012 年初，HTTP-WG(HTTP Working Group) 把 HTTP 2.0 提到了议事日程，并吸取 SPDY 的经验教训，在此基础上制定了官方 HTTP 2.0 标准。

2）、走向 HTTP 2.0

SPDY 是 HTTP 2.0 的催化剂，但 SPDY 并非 HTTP 2.0。SPDY 规范仅仅是作为制定 HTTP 2.0 标准的基础。

3）、二进制分帧层

HTTP 2.0 性能增强的核心，全在于新增的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。

可以看到，相较于 HTTP 1.1，编码方式变了。HTTP 1.x 以换行符作为纯文本的分隔符，而 HTTP 2.0 将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码。

流、消息和帧

在 HTTP 2.0 中，所有通信都在一个 TCP 连接上完成。而要理解 HTTP 2.0，就 必须理解流、消息和帧这几个基本概念，如下所示：

• 流：已建立的连接上的双向字节流。流是连接中的一个虚拟信道，可以承载双向的消息;每个流都有一个唯一的整数标识符(1、2...N)。
• 消息：与逻辑消息对应的完整的一系列数据帧。消息是指逻辑上的 HTTP 消息，比如请求、响应等，由一或多个帧组成。
• 帧：HTTP 2.0 通信的最小单位，每个帧包含帧首部、负荷等等，至少也会标识出当前帧所属的流。

多向请求与响应

在二进制分帧层的基础上，客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。

因此，HTTP 2.0 的二进制分帧机制解决了 HTTP 1.x 中存在的队首阻塞问题，也消 除了并行处理和发送请求及响应时对多个连接的依赖。

请求优先级

每个流都可以带有一个 31 比特的优先值:

• 0 表示最高优先级。
• 2 ^ 31 - 1表示最低优先级。

服务器可以根据流的优先级，控制资源分配(CPU、内存、带宽)，而在响应数据准备好之后，优先将最高优先级的帧发送给客户端。

每个来源一个连接

• 所有 HTTP 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接即可。
• 虽然 HTTP 2.0 消除了 HTTP 队首阻塞现象，但 TCP 层次上仍然存在队首阻塞。

4）、首部压缩

每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，网络开销随着请求数的增多而变大。因此，HTTP 2.0 实现了首部压缩。

实现原理

在支持 HTTP2 的客户端与服务端之间：

1）、维护一份相同的静态字典 Static Table

常见头部名称、特别常见头部名称及值的组合。

HTTP2 静态字典 的作用是什么？

• 1）、完全匹配的头部键值对，例如 :method:POST, 直接使用一个字符表示。
• 2）、匹配头部名称的键值对，例如 cookie: xxx，将名称使用一个字符表示。

2）、维护一份相同的动态字典 Dynamic Table

• 1）、用于动态添加内容。
• 2）、客户端与服务端可以相互通知对方，将发送的 key-value，例如 cookie：xxx 添加到自身的动态字典中。
• 3）、同一个连接上产生的请求和响应越多，动态字典积累得越全，头部压缩效果也就越好。
• 4）、注意，需要为每个 HTTP2 连接维护不同的动态字典。

3）、利用支持基于 静态哈夫曼码表 的哈夫曼编码 Huffman Coding

如果静态、动态字典中没有对应的 key:value，则使用哈夫曼编码减少体积。

5）、帧首部

帧是 HTTP 2.0 中通信的最小单位。所有帧都共享一个 8 字节的首部，如下图所示：

• 16 位的长度前缀：意味着一帧大约可以携带 64 KB 数据，不包括 8 字节首部。
• 8 位的类型字段：决定如何解释帧其余部分的内容。
• 8 位的标志字段：允许不同的帧类型定义特定于帧的消息标志。
• 1 位的保留字段：始终置为 0。
• 31 位的流标识符：唯一标识 HTTP 2.0 的流。

HTTP 2.0 规定了如下帧类型：

• 1）、DATA：用于传输 HTTP 消息体。
• 2）、HEADERS：用于传输关于流的额外的首部字段。
• 3）、PRIORITY：用于指定或重新指定引用资源的优先级。
• 4）、RST_STREAM：用于通知流的非正常终止。
• 5）、SETTINGS：用于通知两端通信方式的配置数据。
• 6）、PUSH_PROMISE：用于发出创建流和服务器引用资源的要约。
• 7）、PING：用于计算往返时间，执行“活性”检查。
• 8）、GOAWAY：用于通知对端停止在当前连接中创建流。
• 9）、WINDOW_UPDATE：用于针对个别流或个别连接实现流量控制。
• 10）、CONTINUATION：用于继续一系列首部块片段。

5、QUIC

• Google 2013 实现，2018 基于 QUIC 协议的 HTTP 被确认为 HTTP3。
• QUIC 简单理解为 HTTP/2.0 + TLS 1.3 + UDP。弱网环境下表现于 TCP。

1）、优势

• 1）、解决了在连接复用中 HTTP2 + TCP 存在的队首阻塞问题，
• 2）、由于是基于 UDP，所以可以灵活控制拥塞协议。例如 Client 端可以直接使用 Google 的 BBR 算法。
• 3）、连接迁移：由于 UDP 通过类似connection id 的特性,使得客户端网络切换的时候不需要重连，用户使用 App 的体验会更加流畅。

2）、目前的缺点

• 1）、NAT 局域网路由、交换机、防火墙等会禁止 UDP 443 通行，因此 QUIC 创建连接成功率只有95%。
• 2）、运营商针对 UDP 通道不支持/支持不足。
• 3）、使用 UDP 不一定会比 TCP 更快，客户端可同时使用 TCP 和 QUIC 竞速，从而选择更优链路。

3）、使用场景

• 1）、实时性
• 2）、可丢弃
• 3）、请求互相依赖
• 4）、可同时使用 TCP & QUIC

6、浏览器性能优化 Tips

大多数浏览器都利用了如下四种优化技术：

• 1）、资源预取和排定优先次序：文档、CSS 和 JavaScript 解析器可以与网络协议层沟通，声明每种资源的优先 级:初始渲染必需的阻塞资源具有最高优先级，而低优先级的请求可能会被临时 保存在队列中。同样，客户端也可以对请求做优先级排序处理。
• 2）、DNS 预解析：对可能的域名进行提前解析，避免将来 HTTP 请求时的 DNS 延迟。预解析可以 通过学习导航历史、用户的鼠标悬停，或其他页面信号来触发。而在客户端中可以使用 HTTPDNS。
• 3）、TCP 预连接：DNS 解析之后，浏览器可以根据预测的 HTTP 请求，推测性地打开 TCP 连接。如果猜对的话，则可以节省一次完整的往返(TCP 握手)时间。
• 4）、页面预渲染：某些浏览器可以让我们提示下一个可能的目标，从而在隐藏的标签页中预先渲染 整个页面。这样，当用户真的触发导航时，就能立即切换过来。

十、网络 IO

网络 IO 的本质是 Socket 的读取，Socket 在 Linux 系统被抽象为流，而 IO 可以理解为对流的操作。

1、Socket recvfrom 读取数据过程

• 1）、等待 Socket 数据准备好，即网络数据已下载至内核的缓冲区中。
• 2）、将数据从内核的缓冲区中拷贝到应用进程的地址空间。

2、Unix 网络 IO 模型

共有五种类型，分别如下所示：

1）、同步

1、阻塞 I/O(blockig I/O)

特点

• 默认 I/O 行为，整个 Socket 的读取或发送都要阻塞应用进程。
• 1、2阶段均阻塞。

优点

及时返回数据。

缺点

对用户来说等待太耗性能。

2、非阻塞 I/O(non-blocking I/O)

特点

• 通过 O_NONBLOCK 将 Socket 设为非阻塞。
• 第1阶段
• 不阻塞，数据没有准备好会立即返回。
• 一直没有获取到数据的话会每隔一定时间轮询进行 recvform 系统调用。
• 第2阶段：阻塞。

优点

能够在等待数据准备的时间里干其它事。

缺点

任务可能在两次轮询间的任意时刻完成，这将会降低整体数据的吞吐量。

3、多路复用 I/O(multiplexing I/O)

特点

一般使用 select/poll/epoll 实现，它们的好处在于 单个进程可以同时处理多个网络连接的 IO。其在内部会不断地轮询所负责的所有 socket，当某个 socket 有数据到达了，就通知用户进程。通过把多个 I/O 的阻塞复用到同一个 select 的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。

• 第1阶段：阻塞在 select/poll/epoll 调用处。
• 第2阶段：阻塞。

优点

相比于多线程/多进程模型，系统开销更小。

4、信号驱动式 I/O(signal-driven I/O)

通过 SIGIO 信息处理，很少用到。

• 1阶段不阻塞：首先需要开启 socket 信号驱动 IO 功能，并通过系统调用 sigaction 执行一个信号处理函数（非阻塞，立即返回）。当数据准备好时，进程会受到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。
• 2阶段：阻塞。

2）、异步

1、异步 I/O(asynchronous I/O)

Linux AIO库函数实现，但通常使用开源的异步 IO 库，例如 libevent、libev、libuv。1、2阶段非阻塞。

3、常见问题

1）、同步 IO 与异步 IO 的区别？

异步 IO 做 IO 操作时不会将 process 阻塞。

2）、非阻塞 IO 与异步 IO 的区别？

在非阻塞 IO 中，进程大部分时间都不会阻塞，但是需要进程主动去 check，并且当数据准备后，也还需要进程主动再次调用 recvfrom 将数据拷贝到用户内存。

而在异步 IO 中，用户进程将整个 IO 操作交给了内核完成，然后他人做完后发信号通知。在此期间，用户进程不需要去 check IO 操作的状态，也不需要主动地去拷贝数据。

3）、网络 IO 同时使用了软中断和硬中断？

首先，通过硬中断通知 CPU 有数据来了，处理过程非常轻量。然后，通过软中断处理函数去慢慢处理耗时操作。

4）、多路复用 I/O 一定比阻塞 I/O 好？

同一般的 多线程 + 阻塞 I/O 模式相比，多路复用 I/O 在网络连接非常多的时刻肯定性能更好，但当在同一时刻的网络连接很少时，频繁使用 select/poll 系统调用消耗的性能会得不偿失。

5）、epoll 一定比 select/poll 好？

同一时间连接数很少时 select 性能会比 epoll 更好。

6）、epoll 使用了 mmap 减少内核到用户空间的拷贝？

无论是在单纯的 Linux 内核上还是 Android 的 Linux 内核上均没有使用 mmap 去实现 epoll。

十一、IPv6

中国 0.4% 用户使用。预计从 IPv4 全部切换到 IPv6，需要 5-10 年的时间。相比 IPv4 连接耗时降低 10%~20%。

IPv6 过渡技术分类

1）、翻译技术

• 实现纯 IPv4 与 IPv6 网络互通，类似于 IPv4 NAT。
• 根据 IP 报文头的地址和协议进行翻译。
• 最常用的 NAT64 翻译技术使用地址池的方式将大量的 IPV6 地址转换为少量的 IPv4 地址，常用于 IPv6 网络发起连接到 IPV4 网络。

2）、双栈技术

目前大部分的网络设备和主机操作系统均已支持双栈协议—同时运行 IPv4 与 IPv6 两套协议。

链路协议支持双协议栈，例如在 以太网协议的以太帧中：

• 协议 ID 0x0800 表示网络层协议采用 IPv4。
• 协议 ID 0x86DD 表示网络层协议采用的是 IPv6。

应用支持双协议栈，DNS 优先选择 IPv6 协议栈作为网络层协议。

3）、隧道技术

• 通过 IPv4 骨干网络连接两端的 IPv6 孤岛：隧道技术通过网络边界设备将 IPv6 源封装到 IPv4 的报文中经过 IPv4 骨干网传递到另一边的网络边界设备还原 IPv6 报文。
• 通过 IPv6 骨干网络连接两端的 IPv4 孤岛：类比如上。

例如 GRE 隧道技术提供了点对点连接服务，需要手工指定隧道的端点地址。

十二、总结

在本文中，我们深入学习地了网络优化相关的必备基础知识，可以看到，每一处优化基础知识点都是在原先的网络基础知识点上再深入了一层，这不仅有助于我们更好地理解网络核心基础知识，而且也为我们后续深入探讨网络优化相关的课题提供了良好的基础储备。最后，再多提一句，在学习的过程中，一定要注意多使用隔期复习法，特别是针对于计算机基础学科类的知识。

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

欢迎关注我的微信：bcce5360，群人数已超200，无法扫码入群，加我微信拉你进群。

点击下方卡片关注JsonChao，为你构建一套

未来Android开发必备的知识体系

▲ 点击上方卡片关注 JsonChao，构建一套

未来 Android 开发必备的知识体系

欢迎把文章分享到朋友圈

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

你若喜欢，为JsonChao点个在看哦