前语

成为一名优秀的Android开发，需求一份齐备的知识系统，在这里，让咱们一起生长为自己所想的那样~。

思维导图纲要

一、为什么要进行网络优化？

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

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

而网络优化最核心的处理方法便是 「消除和削减不用要的网络推迟，把传输的字节数降到最少」。

二、网络功能评估

1、无线网络通讯进程

手机 => 无线网络 =&@ [ F f ! J s kgt; 基站 => 运营商核心网 => 互联网 => 服务器

2、重要方针

1）、延时

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

• 1）、「传达推迟：音讯从发送端到接纳端需求4 ? J的时刻，是信号传达间隔和速度的函{ Q G { ^ g 1数。光速是全部能量、物质和信息运动所能抵达的最高速度，这个定论给网络分组的传达速度设定了上限」。
• 2）、「传输推迟：把音讯中的全部比特转移到链路中需求的时刻，是音讯长度和链路速率4 V i F % ; d L的函数」。
• 3）、「处理推迟：处理分组首部、查看位过错及承认分组方针所需的时刻」。# V !
• 4）、「排队推迟：到来的分组排队等候处理+ h ` d F P的时刻」。

一路上经过的路由器越多，每个分组的处理n 1 }和传输推迟就越多。并且，网络流量[ } ! d Z 7 c s X越拥挤，分组在入站缓冲区中被推迟的或许性就越大。

最终，推迟中相当大的一部分往往花在了最终几公里，经过 traceroute 命令，咱们就能U u /够知道上网服务商的拓扑结M W C构和速度。

2）M T / ; 3 g } p {、带宽

「逻辑或物理通通讯途径的最大吞吐量」。

网络核i 4 心的带{ } z L e t Z宽

光纤

便是一根“光导管”，比人的头发稍粗一点，专门用来从一端向另一端传送光信号9 3 i W W。

金a c 3 Y P属线

用于传送电信号，但信号损失、电磁R 0 4 s &搅扰较大，一起保护成本也较高。

这两种线路咱们的数据分组很或许都会经过，但一般长间隔的分组传输都是经过光纤完结的。

经过 「波分复用（WDM，Wavelength-Division Multiplexing）技能，光纤能够一起传输许多不同波长（信道）的光」，因而具有明显的带宽优势。

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

网络边缘的带宽

用户可用带宽取决于客户端与方针服务器间最低容量– i ^ ] = 3衔接，咱们能够在 akamai 查3 E } n x # (看世界各地的平均带宽。可是，「高带宽并不能确保端到p / v e端的传输速度」。

❝

推迟、带宽与什么要素有关？

❞

「信号强度、基站间隔、网络制式、拥塞状况」 等等许多要素相关。

3、了~ W t c h | , z q解不同网M r G x络制式的带宽与推迟参阅值

❝

什么是弱网络？

❞

即 「高延时、低带宽」 的网络，它具有 「丢包率、误码率高」 的特点。

「网络优化需求结合 App 的实践状况来综合考虑，看咱们的 App 是重延时的运用仍是重带宽的运用」。

惋惜的是，人类不太或许跳出物理定律的 “掌心”。假如需求针对推迟采纳优化办法，就有必要从 「规划和优化协议及运用」 着手，并且时刻紧记光速的约束。

三、TCP 优化

因特网有两个核心协议:IP 和 TCP。

• IP：即 Internet Protocol(因特网协议)，担^ G e # w i Q T任联网主机之间的路由挑选和寻址;
• TCP：即 TransmissionV z G c l ^ Control Protocol(传输操控协议)，担任在不牢靠的传输信道之上供给牢靠的笼v ) S 4 v统层。

而 TCP/IP 也常被称为
“因特网协议套件”(Internet Protocol4 # E Suite)。在实际傍边，因为 TCP 提 供了许多有用的功能，简直全部 HTTP 流量都是经过 TCP 传送的。

❝

咱们都知道有 IPv4 和 IPv6，那 IPv1~3 和 IPv5 呢?

❞

IPv4 中的 4 表明 TCP/IP 协议的第 4 个版别，发布于 1981 年 9 月。「m 9 o W j V VIPv4 中的 v4 仅仅表明晰它与 TCP 前 3 个版别的继承关系，之前并没有单独的 IPv1、IPv2 或 IPv3 协议。而 v5 现已: , 7 i C K R被分配给了另一个试验性协议 Internet Stream Protocol(ST)」。但 ST 一向没有什么进展，这也是咱们为什么很少听说它的原因。结果 TCP/IP3 + O 的下 一版别就成了 IPv6。

1、三次握手

• 1）、出于安全考虑，序列号由两头随机生成。
• 2）、客户端能够在发送 A* G o ? 9 X o Y 3CK 分组之后当即发送数据，而服务器有必要等接纳{ d ; a $ 0到 ACK 分组之后才干发送数据; ( u 3。
• 3）、三次握手带来的推迟使得每创立一个新 TCP 衔接都要付出很大价值a N U d $。而这也决定了进步 TCP 运用功能的要害，在于想办法重用衔接。

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

TFO 致力于削减新建 TCP 衔接带来的功能损失。但却只) * U H P能在某些状况下有用。比方，「伴随 SYN 分组一起发送的数据净荷有最大尺寸约束、只能发送某些类型的 HTTPV ) V | q P 请 求，以及因为依靠加密 cookie，只能运用于重复的衔接」。

2、拥塞防备及操控

ARPANET(Advanced Research Projects Agency Network，高级研究计划局 网络) 是现代互联网的前身，是世界上第一个实践运转的分组交流网络。这个项目于 1959 年正式发动，「1983 年 TCP/Ik L . SP 作为主要通讯协议替代了本来 的 NCP(Network C_ P I D ; a Sontrol Program)协议」。

1）、流量操控

为完结流量操控，TCP 衔接的每一方都要通告自己的接纳窗口(rwnd)，其间包, L 4 6 ; s c括能够保存数据的缓冲区空间巨细信息。这个进程贯穿于每个 TCP 衔接的整个生命周期: 「每个 ACK 分组都6 ; N t会带着相应的最新 rwnd 值，以便两头动态调整数据流速，使l x z j J = : ` l之习惯发送端和接纳端的容量及处理才干」。

窗口缩放(RFC 1323)

开端的 TCP 规范分配给通告窗口巨细的字段是 16 位的，RFC 1323 供给了“TCP 窗口缩放”(TCP Window Scaling)选项，能够 「把接u Z M U } h 9纳窗口巨细由 65535 字节进步到 1G 字节」!缩放 TCP 窗口是在三次握手期间完结的，其间有一个值表明在将来的 ACK 中左移 16 位窗口字段的位数。

23 Y Q @ ,）、慢发动

拥塞窗口巨细(cwnN r `d)，即发送端对从客4 I H [ l w L y户端接纳承认(ACK)之前能! $ o W 6 o r &够发送数据量的约束。

新 TCP 衔接传输的最大数据量取 rwnd 和 cwnd 中的最小值，而服务器实践上能够 向客户端发送 4 个 TCP 段，然后就有必要停下来等候承认。

为削减# m g { u 0增加到拥塞窗口的时刻，d 4 F % a @ ! A .能够削减客户端与服务器之间的往复时刻。比方，~ o * b C 把服务器布置到地理上挨近客户端的地方。要么，就把初始拥塞窗口巨{ . /细添加到 ^ , RFC 9828 规矩的 10 段。

因为慢发动约束了可用的吞吐量，而这关于小文件传输十分晦气。

SSR(Slow-Start Restart，慢发动重启)

在衔接闲暇一定时c m j I x + v w刻后重置衔接的拥塞窗口。道理很简略， 在衔接闲暇的一起，网络状况也l Y G 9 z x u或许发作了改变，为了防止拥塞，理应将拥塞窗K L e W y口重置回“安全的”默认值。

可是，「SSR 关于那些会呈现突发闲暇的长周期 TCP 衔接(比% f 8 p { O `方 HTTP 的 keep-alive 衔接* . ? ) M)有很大的影响。因而，咱们主张在服务器上禁用 SSR」。l % ?

能够看到，服务器和客户端之间的 5 Mbit/su e m 带宽并E Z | h %不影响 TCP 衔接的发动阶 段。此时，推迟和拥塞窗口巨细才是约束要素。

3）、拥塞防备

慢发动以保存的窗口初始化衔接，随后的 每次往复都会成倍进步传输的数据量，直到超越接纳端的流量操控窗口，即系统 装备的拥塞阈值(ssthresh)窗口，或许有分组丢掉停止，此时拥塞防备算法介入。

「拥塞防备算法把丢包作为网络P s h f u H ^ z Q拥塞的标0 o $ b I y志」，即途径中某个衔接或路由器现已拥堵了， 以至于有必要采纳删包办法。因而，有必要调整窗口巨细，以防止形成更多1 ` k的d M ] z L 0包丢掉， 然后确保网络畅通。

重置拥塞窗口后，拥塞防备机制依照自己的算法来增大窗口以尽量防止丢包。某个 时刻，或许又会有包丢掉，所以这个进程再从头开端。假如你看到过 TCl $ U . m | P 衔] B * G接的吞 吐量盯梢曲线，发现该曲线呈S 8 ) 6 r锯齿状，那现4 3 1 w 5 / V在就该明白为什么了。这是拥塞操控和 防备算法在调整拥塞窗q 4 5 } n n K口，进而消除网络中的丢包问题。

TCP PRR(+ Y N q W q ) /Proportional Rate Reduction，份额降速)

开端，TCP 运用 AIMD(Multiplicative Decrease and Additive Increase，倍减加增) 算法，即发作丢包时，「先将& c . C S = ] 1拥塞窗口折半，然后每次往复再缓慢地给窗口添加一 个固定的值」。

后来，呈现了 PRR(Proportional Rate Reduction，份额降速)，它是` Q ( 1 W 0 / RFC 6937 规矩的一个新算法，其方针便是 「改进丢包后的康复速度。运用它因丢包形成的平均衔接推迟削减了 3%~10%。此外，PRR 现在也是 Linux 3.2+ 内核默认的拥塞防备算法」。

3、n P F yBDP(Bandwidth! i * 4 C @ [ l-delay product，带宽推迟积)

接纳窗U g . . 9 – } ) ~口（rwnd）会随每次 ACK 一起发送，而 拥塞窗口（cwnd）则由发送端依据拥塞操控和防备算法动态调整。

不管发送端发送的数据仍是接纳端接纳的数据超越了未承认的最大数据量，都有必要停 下来等候另一方 ACK 承认某些分组才干继续。

而 BDP(Bandwidth-delay produ% , p Q X % s K #ct，带宽推迟积) 便是 「恣意? 4 2 O时刻处于在途未承认状况的最大数据量」。

BDP = 数据链路v h $ a ^ T的容量 * 其端到端推迟

「在高速衔接的客户端与服务器之间，假如实践传输速r + H w P H 4 ?度只要可用带宽的几分之一，那窗口巨细很或许便是 元凶巨恶。要么因为某一饱和端通告的接h n x z C ^ u r m纳窗口很小，要么因为网络拥堵和丢包导致拥塞窗口重置，更或许因为流量增加过快导致对衔接吞吐量施加了约束」。

4、TCP 队首(HOL，HeaX / q v Q v Nd of Line)堵塞s b t o _ . g

TCP 在不牢靠的信道上完结了牢靠的网络传输。根本的分组过错检测与纠正、按 序交给、丢包重发，以及确保网络最高功率的流量操控、拥塞操控和防备机制，让 TCP 成为大多数网络运用中最常见的传输协议。

可是，其间的按序交` i 3 9 d G . X给和牢靠交给有时候并不用要，反而会导致额定的推迟，对功能形成负面影响。例如：每个 TCP 分组都会带着一个仅有的序列号被宣布，而 全部分组有必要按次序传送到接纳端。假如半途有一个分组没能抵达接纳 端，那么后续分组E { , G有必要保存在接纳端的 TCP2 Y O * 缓冲k y d X ;区，等候丢掉的分组重发并抵达接 收端。这全部都发作在 TCP 层，运用程序对 TCP 重发和缓冲区中排队的分组一无所 知，有必要等候分组悉数抵达才干拜访数据U T K G R。在此之前，运用程序只能在经过套接字 读数据时感觉到推迟交给。这种效应称为 TCP 的队首(HOL，Head of Line)堵塞。

「队首堵s H ~ – B } )塞使得分组抵达时刻会存在f 3 a + &无法预知的推迟改变，而这个时刻改变一般被称为颤动」。

因而，关于无需按序交给数据或能够处理分组丢掉的运用程序，以及对推迟或 7 J s } c 2颤动要求很高+ n Q的运用程序，最好挑选 UDP 等协议。

丢包的反e o {作用力

丢包是让 TCP 抵达最佳功能的要害。被删除的包恰恰是一种反馈机制， 能够让接纳端和发送端各自调整速度，以防止网络拥堵，一起坚持推迟最短。

对与实时性比较强的音x u d [ 4 p E x视频运用来说，就算@ ( 有个包丢了g ^ 2 A ` 0 i p，音频编解码器只要在音频中刺进一个小小的间歇，就能够继续 处理后来的包。只要间歇够小，用户就留意不到，而等候丢掉的包则或许导致音 频输出发作无法预料的暂停。相对来说，后者的用户体会更糟糕。

5、TCP 优化 Tips

1）、TCP 中的要害细节

• 1）、「TCPr T E v U Q w 三次握手添加了整整一次往复时刻」;
• 2）、「TCP 慢发动将被运用到每个新衔接」;
• 3）、「TCP 流量及拥塞操l – O [ 1控会影响全部衔接的吞吐量」;
• 4）、「TCP 的吞吐量由当时拥塞窗口巨细操控」。

大多数状况下，「TCP 的瓶颈都是推迟，而非带宽」。

2）、服务端装备优2 z {化

1）、增大TCP的初始拥塞窗= } p o _ ;口

加大开端拥塞窗口能l c Y . 5 ? ~ b够让 TCP 在第一次往复就传输较多数据，而随后的速度提 升也会很明显。关于突发` K & D U @性的时刻短衔接，这也是特别要害的一个优化。

2）、慢发动重启

在衔接闲暇时禁用慢发动能够改进瞬时发送数据的长 TCP 衔接的功能。

3）、窗口缩放(R7 3 #FC 1323)

启用窗口缩放能够增大最大接纳窗口巨细，能够让高推迟的衔接w r d s | ( E抵达更好吞 吐量。

4）、TCP快速翻开

在某些条件下，答应在第一个 SYN 分组中发送运用程序8 % M 7 U K h数据。TFO(TCP Fast Open，TCP 快速翻开)是一种新的优化选项，i m L R留意，TFO 需求客户端和服务器u V N 3 2 ~一起支撑。

3）、客户端优化

• 1）、「少发或许不发网络状况（恳求合并）：消除不用要的数据传输本身 , 3 8 | V A便是很大的优化。比方，削减下载不用要的资源，或许经过压缩算法把要发送的= z i U ) K比特数降到最低」。
• 2）、「运用v l m : z } 7 CDN，让通讯间隔更短：经过在不同的区域布置服3 i r . C x务器，把数据放到挨近客户端的地方，能够削减网% 8 M R络往复的推迟，然后明显进步 TCP 功能」。
• 3）、「重用 TCP 衔接：把慢发动和其他拥塞操控机制的影响降到最低」。

四、UDP 优化

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

1、数据包和分组的差异

数据报(datagram)和分组(packet)是两个常常被人混用的词，实践上它们仍是 有差异的。「分组能够用来指代任何格式化的数据块，而数据报则一般只用来描绘那 些经过不牢靠的服务传输的分组，既不确保送达，也不发送失利告诉」。_ @ ^ !

IETF 和 WG W ; I 1 : U3C 工作组一起拟定了一套新 API—— WebRTC(Wm r % E x _ 5eb Real-Time Communication，Web 实时通讯)。「WebRTC 着眼于在浏览器中经过 UDP 完结原生的语音和视频实时通讯，以及其他方法的 P2 m N S c2P(Peer-to-Peer，端到端)通讯」。

2、无协议服务

众所周知，IP 层的主要任H 3 P q务便是依照地址从源主机向方针主机发送数据报。而 「数据报」 则暗示着:「IP 层不确保音讯牢靠的交给，也不发送失利告诉，实践上是把底层网络的不牢靠性直接露出给了上c l | ; (一层」。假如某个路由节点因为网络拥塞、负载过高或其他原因而删除了 IP 分组，那么在必要的状况下，IP 的上一层协议要担任检测、康复和重& A # K % )发数据。

UDP 数据报中的源端口和校验和字段0 ; – k 8 E都是可选的。IP 分组的首部也有校验和，运用程序能够忽略 UDP 校验和。因而，「UDP 仅仅是在 I/ e _ a / + x E BP 层之 o * { i . j N上经过嵌入运用程序的源端口和方针端口，供给了一个“运用程序多路复用”机制」。

UDP 的无服/ c T 6 H务

• 1）、「不确保音讯交给：不承认，不重传，无超时」。
• 2）、「不确保交给次序：不设置包序号，不重排，不会发作队首堵塞」。
• 3）、「不盯梢衔接状况：不用树立衔接或重启状况机」。
• 4{ K n）、「不需求拥塞操控：不内置客户端或网络反馈机制」。

3、UDP 与网络地址转化器(NAT，Netwok q Z m e ` 8rk Address Translator)

1）、衔接状况超时

关于较长时刻的 UDP 通讯，有一个事实上的最佳做法，即引进一个双向 keep-aliveI r q ) e $ 2 } 分组，「周期性地重置传输途径上全部 NAT 设备中转化记载的计时器」。

2）、r a b ? N 4NAT 穿透

NAT 导W F ; z c _ ^ | }致了几个问题，如下所示：

• 1）、内部客户端不知道外网h { d i + K r IP 地址，只知道内网 IP 地址。
• 2）、任何抵达 NAT 设备外网 IP 的分组还有必要有一个方针端口，并且 NAT 转化表中也要有一个条目能够将其转e p { 1 s k化为内部主机的 IP 地址和端口号。假如没有这个条目(一般是从外网传数据进来)，那抵达的分) 5 Y [ i f (组就会被删除。

为处理 UDP 与 NAT 的这种不调配，人们发明晰许多穿透技能(TURN、STUN、 ICE)，用于在 UDP 主机之间树立端到端的衔接。

3）、STUN(Session Traversal Utilities for NAT)协议/ 0 4 F C x c(RFC 5389)

优b Q 9势

• 1）、运用程序能w { x够获得外网 IP 和端口，并利用这些信息与对端通讯;
• 2）、发送到 STUN 服务器的出站绑定恳求将[ ` 2 9在通讯要经过的 NAT 中树立路由条目，
  使得抵达该 IP 和端口的入站分组能够找到内网中的运用程序;
• 3）、Sf ! 8TUN 协议定义了一个简略 keep-alive 勘探机K L 0 6 Z 9 C制，能够确保 NAT 路由条目不超时。

缺陷

STUN 并不能习惯全部类型的 NAT 和网络装备。不仅如此，某些状况下 UDP 还会被防火墙或其他网络设备彻底屏蔽。

为处理这个问题，在5 G { 0 * STUN 失利的状况下，咱们还能够@ w v l 6 1 T运用 TURN(Traversal Using Relays around NAT)协议(RFC 57S 7 Z [ J P ) 866)^ , | d E Q & k作为后备。TURN 能够在最坏的状况下跳过 UDP 而切换到 TCP。

4）、TURN(Traversal Using Relays around NAT)协议(RFC 5766)

工作流程

• 1）、两头都要向同一台 TURN 服务器发送分配恳求来树立衔接，然后再进行权限洽谈。
• 2）、洽谈完毕，两头都把数据发送到 TURN 服务器，再由 TURN 服务器转发，然后
  完结通讯。

缺陷; ( n j 6 r

为满意传输数据! : y / p x u Q的需求，中继设备的容量有必要足够大。

谷歌的 libjingle 是一个用 C++ 开发的用于构建端到端运用程序的开源库，其文档也为? ] b咱们考量实际中的 STUN 与 TURN 功能供给了有价值的参阅:

• 92% 的时刻能够直接衔接(STUN);
• 8% 的时刻要运用中继器(TURN)。

5）、ICE(Interactive Connectivity Establishment)协议(RFC 5245)

ICE 规矩了一套方法，致力于在通讯各端之间树立一条最有用的通道:能直连就直连，必H _ E 7要时 STUN 洽谈，再不行运用 TURN。如下图所示：

假如要构建依据 UDP 的 P2P 运用程序，咱们应! = 2 n该挑选现有的平台 API，或许完结了 ICE、STUN 和 TURN 的第三方库。

4、UDP 优化 Tips

「UDP 的特色在于它所省掉的那些: 4 n r V 4 7功能:衔接状况、握手、重发、重组、重排、拥塞操控、拥塞防备、g e l ~ l流量操控，乃至可选的} 7 . d过错检测，通通没有」。

在 RFC 5405 中，对规划单播 UDP 运用程序给出了许多规划主张，如下所示：

• 1）、「有必要忍受各种因特网途径条件」;
• 2）、「应该操控传输速度」;
• 3）、「应该对全部流量进行拥塞操控」;
• 4）、「应该运用与 TCP 附近的带宽」;
• 5）、「应该预备依据丢包的重发计数器」;
• 6）、「应该不发送大于途径 MTU 的数据– ~ q ; a B | 3 I报」;
• 7）、「应该处理数据报丢掉、重复和重排G . d /」;
• 8）、Q E C f + h q *「应该足够稳定以支撑 2 分钟以上的交给推迟」;
• 9）、「应该支撑 IPv4 UDP 校验和，有必要支撑 IPv6 校验和」;
• 10）、「能够在需求时运用w q S 7 n keep-alive(最小间隔 15 秒)」。

而w O G WebRTC 协议则是上述的规划模范。

五、TLS（Transport Layer Security，传输层安全）

SSL 协议在直接位于 T% O r Y {CP 上一层的运用层被完^ 0 k G j结。

IETF 后来在规范化 SSL 协议时，将其改名为 Transport Layer Security (TLS，传输层安全)。许多人会混用 TLS 和 SSL，但严厉来讲它们并不相
同，因为它们指代的协议版别不同。

鉴于 SSL 协议是网景公司专有的，IETF 成立了一个小组担任* 8 d E O Q 7 k规范化该协 议，后来就有了 RFC 2246，即 TLS 1.0，也便是 SS% M F / a Q r VL 3.0 的升级版。

• 「TLS 1.5 l ; j ^ { w ` {0 在 1999 年 1 月发布」P 4 q [ a。
• 「2006 年 4 月发布了 TLS 1.1」。
• 「2008 年 8 月发布了 TLS 1.2」。

TLS 也能够完结g i h Y Q j在 UDP 之上，DTLSd E } I 5 R(Datagram Transport Layer Sd y recurity，数据报传输层安全)（RFC 6347）就旨在以 TLS 协议为根底，一起统筹数据报交给方法并供给类似的安全确保。

1、加密、身份验证与完好性

TLS 协议的方针是为在它之上运转的运用供O q 2 2 9给三个根本服务：

• 1）、「加密：混杂数据的机制」。
• 2）、「身份验证：验证身份标识有用性的机制」。
• 3）、「数据完好性：检测音讯是否被篡改或假造的机制」。

1）、加密

在握手机制中规划最巧妙的地方，便是其运用] , & 7 y d的公钥暗码系统 (也称“非对称密钥加密”)，这套系统能够z E 2 h让通讯两边不用事先“知道”即可商定共
享的安全密钥，并且洽谈进程仍] D P 3 Y f ^ c G是经过非加密通道完结的。

2）、身份验证

握手进程中，TLS 协议还答应通讯两头相互验明正身。这个验证首要需求树立“认证组织信赖链”(Chain of Trust and Certificate Authorities)。

3）、数据完好性

音讯分帧机制，运用 MAC (MeT G D { ; ^ Y 5ssage Authentication Code，音讯认证码)签署每一条音讯。MAC 算法是一个单向o T { A ! ,加密的散列函数(本质上是一个校验和)，「密钥由衔接两边洽谈承认。只q I – ) * | 4 G要发送 TLS 记载，就会生成一个 MAC 值并附加到该音讯中」。接纳端经过D C 3核算和验证这个
MAC 值来判别音讯的完好性和牢靠性。

2、TLS 握手

• 0 ms:TLS 在牢靠的传输层(TCP)之上运转，这意味着首要有必要完结 TCP 的“三 次握手”，即一次完好的往复。
• 56 ms:TCP 衔接树立之后，客户端再以纯文本方法发送一些规格阐明，比方s y * x它所运 行的 TLS 协议的版别、它所支撑的加密套件列表，以及它支撑或期望运用的另外一 些y p I g – TLS 选项。
• 84 ms:然后，服务器获得 TLS 协议版别以备将来通讯运用，从客户端供给的加密 套件列表中挑选一个，再附上自己的证书，将呼应发j X w a d H 2送回客户端。作为可选项，服 务器也能够发送一个恳求，w ( @ D v N & b要求客户端供给证书以及其他 TLS 扩展参数。
• 112 ms:假定两头经过洽谈承认了一起的版别和加密套件，客户端也高高兴兴地 把自己的证书供给给了服务器。然后，客户端会生成一个新的对称密钥，用服务 器的公q F i O u Z钥来加密，加密后发送给服务器，告诉服务器能够开端加密通讯E C X G # g了。到 目前停止，除了用服务器公钥加密的新对( a l : O r j ~称密钥之外，全部数据都以明文方法 发送。
• 140 ms:最终，服务器解密出客户端发来的对称密钥，经过验证音讯的 MAC 检 测音讯完好性，再回来给客户端一个加密的“Finished”音讯。
• 168 ms:客户端用它之前生成的对称密钥解密这条音讯，验证 MAA k Z x –C，假如全部 顺利，则树7 D K G立信道并开端发送运用数据。

1）、运用层协议洽谈(ALPNq a @ Y，Application Layer Protocol Negotiation)

NPN(Next Protocol Nex S x Tgotiation，下一代协议洽谈)是谷歌在 SPDY 协议中开发的一个 TLS 扩展] ( N M t p，「目的是经过在 TLS 握手期间洽谈运用协议来进步功率」。

ALPN 是 IETF 在 NPN 根底上修订并批准的版别。在 NPN 中，服务器广播自己 支撑的协议，客户端挑选3 ] 7 a T o u和承认协议。而 「在 ALPN 中，交流次序颠倒过来了，客 户端先声明自己支撑的协议，服务器挑选并承认协议。而这样修改的目的是为了让 AL– V ~ [ V O 9 dPN 与其他协议洽谈& K v ,规范坚持一起」。

ALPN 作为 TLS 扩展，让咱们能在 TLS 握手的一起洽谈运用协议，然后w U 7 a U F j F 省掉了 HTTP 的 Upgrade 机制所需的额定往复时刻。k T & } v J u V l

只要 TLS 握手完结、树立了加密信道并就运用协议达成一起，客户端A – N T C K ^与服务器就可 以当即通讯。

2）、SNP M m , I } M { %I (Server Name IL C h A – ( B @ cndication，服务器称+ C F 8号指示^ 4 L M ; W O)

假如服务器想在一个 IP 地址为多个站点供给服务，而每个站点都具有自己R 2 B T M [ W * s的 TLS 证书，那怎样办?

为了处理这个问题，SNI 扩展被引进 TLS 协议，该扩展 「答应客户端在握手之初就指明要衔接的主机名」。! b 0 W h

3、TLS 会话康复

即在多个衔q . g s I R接间同享洽谈后u , k `的安全密钥。

1）、会C 9 _ ] Y X 7 q话标识符 (Session Identifier，RFC 5246)

最早的“会话标识符”机制是在 SSL 2.0 中引进的， 支撑服务器创立 32 字节的会话标识符，它是在完好的 TLS 洽谈期间作为其“Se8 g s S v ! !rverHello”音讯的一部分[ 8 T l i #发送。

在内部，服务器会为每个客户端保存一个会话 ID 和洽谈后= A 0 Q 8 / Z N v的会话参数。相应地，客 户端也能够保存会话 ID 信息，并将该 ID 包括在后续会话的“ClientHello”音讯中， 然后告诉服务器自己还记取上次握手洽谈后的加密套件和密钥，这些都能够重用。

假定客户端和服务器都能够在自己的缓存中找到同享的会话 ID 参数，那么就能够进 行简略握手。不然z K ? }，就要重新发动一次全新的^ # $ ? G H W {会话洽谈，生成新的会话 ID。简略的 TLS 握手如下图所示：

优势

• 1）、「节约一次往复」。
• 2）、「省掉用于洽谈同享加密密钥的公钥加密核算」。

缺陷

关于那些每天都要“接待”几万乃至几百万独立衔接的服务器来说，因为每个翻开的 TLS 衔接都要占用内存，因而需求一套会话 ID 缓存@ [ = 4 5 a 1 5和清5 T ; k ]除战略。

为了处理上述服务器端布置 TLS 会话缓( c $ v { 3 T存的问题，“会话V T g记载单” 机制呈现了。

2）4 9 8、会话记载单(Session Ticket， RFC 5077)

该机制不用服务器保存每个客户端的会话状况。只Q : ~ )要客户端表明其支撑会话记载单，则「服务器能够在完好 TLS 握手的最终一次交流中添加一条“新会话记载单”(New Session Tic{ p G 7 E r # vket)记载，包括只要服务器知道的安全密钥加密过的全部会话数5 Z R y 1 V G据」。

然后，客户端将这个会话记载单保存起来，e n p | U f ) k在后续会话的 ClientHello 音讯中，能够将其包括在 SessionTicket 扩展中。这样，全部会话数据只保存在客户端，而因为 数据被加密过，且密钥只要服务器知道，因而L | $ – H仍然是安全的。

会话标识符和会话记载单机制，即“会话缓存”或“无状况康复”机制。其长处「主要是消除了服务器端的缓存担负，经过要求客户端在与服务器树立新衔接时供给会话记载单简化了O d n ; e |布置(除非记载单过期)」。

4、信赖S B H T f链与证书颁布组织

「身份验证即用自己的私钥签名，然后对方用自己的公[ ^ m a k w ) I钥验证收到的音讯签名」。但信赖是交流的i g y D – Q ] (要害。

关于浏览器来说，它信赖谁呢?

「至少有三个答案」：

• 1）、「手工指定证书：全部浏览器和操作系统都供给了一种手工导入信赖X / {证书的机制」。
• 2）、「CA(Certificate Authority，证书颁布组织)：被证书接受者(具有者)和依靠证 书的一方一起信赖的第三方」。
• 3）、「浏览器和操作系统：其间都会内置一个知名证书颁布组织的名单。因而，你也会信赖操作系统及浏览器供给商供给和保护的可信赖组织」。

最常见的计划，便是浏览器指定可信赖的证书颁布组织(根 CA)。而 「证书颁布组S @ V J d织签+ Z 7 J *署数字证书的流程」 如下图所示：

全部浏览器都答应用户检视自己安全衔接的信赖链，「常见的拜访入口便是地址栏头儿上的锁图标」，点击即可查看。如下图所示：

「整个链条的“信赖依据”是根证书颁布组织，而每个浏览器都会内置E p ? [ d l E 9 $一个可信赖的证书颁布组织(根组织)的名单」。

5、证书吊销

通讯的任何一端都能够依据嵌入的指令和签名V p @ b M查看链条中每个证书的状况。

1）、CRL(Certificate Revocation ListJ ( H b q b G r K，证书吊销名单) (RFC 528)

• 「每个证书颁布组织保护并定期发布已吊销证书的序列号名单」。
• 「任何想验证证书的人都能够下载吊销名单，查看相应证书是否榜上有名。 假如有，阐明证书现e m &已被吊销了」。

缺陷

• 1）、「CRL 名单会跟着要吊销的证书增多而变& q L U a m长，每个客户端都有必要获得包括全部序列 号的完好名单」。
• 2）、「没有办法当即更新刚刚被吊销的证书序列号，比方客户端先缓存. ` s [了 Cg y ^ _ : pRL，s = [之后某 证书被吊销，那到缓存过期之前，该证书将一向被视为有用」。

2）、OCSP(Online Certificate Status Protocol，在线证书状况协议)（RFC 256s a ) , l C A0）

• 「一种实时查看证P = y [ 3书状况的机制」。
• 「支撑验证端直接查询证书数据库中的序列号，然后验证证书链是否有用」。

缺陷

• 1）、「证书颁布组织有必M 6 e要处理实时查询」。
• 2）、「证书颁布组织有必要确保随时随地能够拜访」。
• 3）、「客户端在进一步洽谈之前堵塞# ^ c : – 6」 OCSP 恳求。
• 4）、「因为证书颁布组织知道客户端要拜访哪个站点，因而实时 OCSP 恳求或许会泄露
  客户端的隐私」。

实际中，「CRL 和 OCSP 机制是互补存在的，大多数证书既供给指令– T ) ^ # )也支撑查询」。

6、TLSQ 9 ` Z w 记载协议

TLS 记载协议担任 「辨认不同的音讯类型(握手、警告或数据，经) p = F Y # / &过“内容类型”字段)，以及每条音讯的安全和完好性验证」。TLS 记载结构如下图所示：

交给运用数据的典型流程如下：

• 1）、「记载协议接纳运用数据」。
• 2）、「接纳到+ 7 S的数据被切分为块^ z – Y s n c *:最大为每条记载 214 字节，即 16 KB」。
• 3）、「压缩运用数据(可选)」。
• 4）、「添加 MAC(Messa5 X – + – Fge Authentication Code)或 HMAC」。
• 5）、「运用商定的加密? c n ~套件加密数据」。

之后，加密数据就会被交给 TCP 层传输。「接纳端c l 5 A u i M _ t的流程」 相同，次序相反:「运用商定的加密套件解密数据、验证 MAC、提取N C k p | d并把数据转交W 7 ~ b s $给上层的运用」。

缺陷

• 1）、「TLS 记载最大为 16 KB」;
• 2）、「每条记载包括0 s . * { B 5 字节的首部、MAC(在 SSL 3.F Z g = d D0、TLS 1.0、TLS 1.1 中最多 20 字节，在 TLS 1.2 中最多 32 字节)，假如运用块加密则还有填充」;
• 3）、「有必要接纳到整条记载才干开端解密和验证」。

7、TLS 优化 Tips

1）、尽早完结握手

运用 CDN，在世界各地的服务器上O S T M I P p缓存或重复布置数据和服务，而不/ 2 ~需求让全部用户都经过跨海或跨大陆光缆衔接到一个中心原始服务器。

优势

• 1）、「经过运用本地署理服务器分流负载等手段下降推迟」。
• 2）、「本地署理服务器也能够与原始服务器树立一批长时刻的安全衔接，全权署理恳求与呼应」。
• 3）、「在 CDN 中，客户端衔接终止于附近 CDNs P # G k 0 节点，该节点将恳求转发到与对端服务器附近的 CDN 节点，之后恳求才会被路由到原始服务器。这能够让数据在优化的 CDN 骨干网中寻路，然后进一步削减客户端与服务器之间的推迟」。

2）、运用会话缓存与无状况康复

• 在大多数G : K Y服务器的默认L q Y t F Z x U y装备下它E v ! ; ) Y , 5是禁用的，咱们需求手动开启它。
• 在支撑的客户端中运用会话记载单，L ] w H 0 I – r ,而在不支撑的客* # C 4 ? p /户端中运用会话标识符。

3）、TLS 记载巨N { * r F u细

小记载会形成浪费，大记载1 – G会导x E 5 *致推迟。最优 TLS 记载巨细的参阅值如下所示：

• 「IPv4 帧需求 20 字节，IPv6 需5 m D & ( n T X H求 40 字节」;
• 「V / f 1 s WTCP 帧需求 20 字节」;
• 「TCP 选项需求 40 字节(时刻戳、SACK 等)」。

「默. ^ & ` 6 | { u认状况下，OpenSSL 等常用的库会给每个衔接分配 50 KB 空间，而谷歌的服务器把 OpenSSL 缓冲区的巨细削减到 了大约 5KB。因而，咱们需求在确保功能的前提下尽或许运用最小的内存」| P * } +。

4）、证书链的长度

❝

浏览器怎样知道到哪里去找证书呢?

❞

因为 「子证书中一般$ n s x k包括父证H B P W , W t书的 URL」。

咱们应该确保证书链的长度最小。「假如证书链长度超越了 TCP 的初始拥塞窗口，那咱们无意间就会让握手多了一次往Z f B $ x y复:证书长度超越拥塞窗口，然后导致服务器停下来等候 客户端的 ACK 音讯」。

对此，有 「两种处理方法」：

• 1V u X l & O u j）、「增大拥塞窗口」。
• 2）、「削减证书巨细」：

  • 「尽8 Z 9 _ ~ D 7 ~ ?量削减中心证书颁布组织的数量：理想状况下4 W @，发送的证书链d M _ y G M H f应该只包括两个 证书:站点证书和中心证书颁布组织的证书。第三个证书，也s + 5 { 6 H # ! :便是根证书颁布组织的证书，现已包括在浏览器内置的信赖名单中了，不用发送」。
  • 「理想的证书链应该在 2 KB 或 3 KB 左z X ~ X 9 R右」。

5）、OCSP 封套

服务器能够在证书链中包括(封套)证书颁布组织的 OCSP 呼应，让浏览器跳过在G c R 1 S y线查询。把查询 OCSP 操作转移到服务器能够让服务器缓存签名的 OCSP 呼应，然后节约许多客户端的恳求。

6）、HTTP 严厉传输安全(HSTS，Strict Transport Security)

「一种安全战略机制k J 0 3，让服务器经过简略的 HTTP 首部(如 Strict-Transport-Security: max-age== [ & ( Y _ ,31536000) 对适用的浏览器声明拜访规矩」。

max-age 以秒为单位指定 HSTS 规矩集的生存时8 l s刻(例如，max-age=31536000 等于
缓存 365 天)。

优势

「HS* s U $ 6 Z 2 ^ 1TS 经过把责任转移到客户端，让客户端自动把全部链接重写为1 k n w $ R H B HTTPS，消除了从 HTTP 到 HTTPS 的重定E n . = G向损失」。

咱们需求熟练掌握 openssl 命令行工具，经过它来查看整个握手和本地服务器配 置状况。其运用如下所示：

quchao@quchaodeM| n ~ $acBook-e m P ( _ WPro paxgo % openssl s_client -state -CAfile startssl.ca.cr j d Y 0 0 _  `t -connect igvita.com:443

4482293356:error:02FFF002:system library:func(4095):No such file or directory:/J z D d { , 6 GBuildRoot/Library/x a a ` ) ] Z 9Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/crypto/bio/bss_file.c:122:fopen('startssl.caZ L ( Q.crt', 'r')
4482293356:error:20FFF080:BIO routines:CRYPTO_interF M y $ F ] C Znal:no such file:T = c G M $ J /BuildRoot/Libraryv @ D N )/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/liq 0 s 5bressl-2.8/crypto/bio/] / c $ T r D h #bss_file.c:125:
4482293356:eY X # E v W J D 0rror:0BFF[ ~ x m g G P  FF002:x509 certificate routines:CRYPTO_internal:system lib:/BuildRoot/Library/Ca 8 rches/com.apple.xbs/Sources/l, O Nibressl/libressl-47.11.1/libressl-2.8/cryo ` o 7 6 !pto/x509/by_file.c:Q 9 )  A : c 7248:
CONNECTED(00000005)
SSL_conneV C q { S ] kct:before/connect initialization
SSL_connect:SS} 5 0 m #Lv3 write cli* r G ` X Z c !ent 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_conq z Dnect: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:SS7 ^ P s O YLv3 read finished A
---
Certificate chaik I 0 G &n
 0 s:/CN=igvita.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authorit_ = V G B / z y X3
 1 s:/C=US/O=Let's EncL Z f & A P /rype 6 c B pt/CN=Let's Encrypt AuthoriH = g Lty X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
--q ? ) W A x %-
Servers | Y 7 certificate
-----BEGIN CEs v ^ ]RTIFICATE-----
MIIFXTCCBEWgAwIBAgISBJN+3MX9OKjS5cX4b6ww h | m g ] {/vtAMA0GCSqGSIb3} ) l = C s oDQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncy! b ] 2 # K + MBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhy h + & _vcml0eSBYMzAeFw0yMDA0MjAxMzI1NDj u { & H cNaFw0y
MDA3MTkxMzI1NDNaMBUxEzARBgNV$ l S D wBAMTCmlndml0YS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEH C e + p 3 % m yKAoIBAQCx5ZoBTHLEUmRbkMVyBESzjCR1Ozh [ ? e &9aop5aQRAp
bviLS~ ; H 0 ] Yast _ U o 0 x t {QbKaXp1DkzaB10am9Nr3ROKtP6tQgB8suaYC94I4SatnJsB3EBe k M # F BGew5GUr
MKybvoQYp4HzJvC49o i u 3 J a 1uUZH 0  6 G (DWFOlWdw6P5ldVXjsX22ATobK5XY0Tr1Ci5j7goanXRF$ - 8 ~ } $
49sZ6yT5xVsKjprdg8/aoqtIDYXvJsZfJiDyG9 m { 3 S R =Vung3Qb8RbmjlPvvGS7AXX 2 . z p )ESSA8b
3g7lMdRBhsRPL7BXuVVnoU5CsPc4 E XTc7GPuJ5z0Qbfa34NILq4zPqvgH1pWRNJX7Fn
S7Hf5RVhlsuiCEr7BheVGWOjujuxFPOnPkoQ4EcfP6iGBITRAgMBAAGjggJwMIIC
bDAOBgNVHQ8BAf8EBAMCP e U  ~BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFJbxqiGG J # z w 6GEZ5EEEWj1p1RWhYRU/ESMB8G
A1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMwYTAu
BggrBgEFBQcwAYYiaHR0cDovL29jc3Auo V Y VaW50LXgzLW } u q * X H mxldHNlbmNyeXB0Lm9yZzAv
BggrBgEFBQcwAoYjaHR0cDov7 & l V s r ( |L2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9yZy8w
JQYDVR0RBB4wHIIKaWd2aXRhLmNvbYIOd3d3Lmlndml0YS5jb20wTAYDVR0gB; B I + 7 5 QEUw
Qz2 F _AIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDov
L2Nwcy5sZXRzZW5jcnlwdC5- F i / FvcmcwggEFBgorBgEEAdZ5AgQCBIH2BIHzAV k 7 A m , aPEAdwBv
U3asMfAxGdiZAKRRFf93FRwR2QLBACkGjbIImjfZE! ( bwAAAXGX+wdyAAAEAwBIMEYC
IQC55PavTz4OWvcbMpDNQIcR/SYEDvdSkqrYjxDRGx4vawIhAOCcGF3L{ @ :  y 9 AKximqSmf
ch6R1X L F N G CEuZo/WTDzPioxM7X3I % /w3kvFAAHYAB7dcG+V9aP/xsMYdIxXHu? % - 7 d a | F BuZXfFeUt2ru
vGE6GmnTohwAAAFxl/sHcgAABAMARzBFAiBUlTes9VFQ56gbUgRq/7fFUVi6r4Eo
sWHADNNsQ7BSIgIhAPyfR9jDpnHQi3cqjRV2lBp0rrLAcEKf+b4cpDUvw41NMA0G
CSqGSIb3DQEBCwUAA4IBAQBGvck8LK6h8zMxA6bNpxW5Md6K/cUA/HlS0GUiOlnh
9I{ } 0 * V s I `WZfg3t9f O O F6Co9d8i90tqjm2gGRVW v - RDk7ywiGUClFky6EPICTka0VQRwgLI6aIvh9OF
82 Y s B ; Wsyf0QijfXUIkFRZNxGRkAsFqPsbAbDc6+hUMOWQY1 N M M T + B b/uw2yITLBK 9 U d 6 20eS+HyRAZWszoJ
IS4b/Y/gHvnkF/d+y792Y61pf9qtuuTgV/Wdb/KtxJtHKOPVnq = } [2eMF7omwyQfqF5o
CijVj/znJBaq9f/8BerL76qRTgeJeM8z0H18ZRpplL l [ #MyS0T/k1QRTIq6c8lpOt887
PPj D x M m ] a U2IVI8v3WlgNtlZ8Xz l u { i 2 _ypmZdBjQtncaB1S2MmKgqas5Dx
-----END CERTIFICATE-----
subject=/CNo W g * Y U #=igvita.com
issuer=/C=Y # L b } = TUS/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certifice U ? fate CA names sent
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handsha- 1 i m l c Gke has read 3093 bytes and written 354 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-A E R s = I 4 QSHA384
Server public key is? d X n F  r 2048 bit
Secure Renegotiation IS supported
Compt d M = /  Dression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Se$ 0 Z 3 Us| P L | J K : @ Fsion-ID: CF508DEBB4768BBB308095B730EB0FBC7F21C53095AE8DF2E0905D085F98F158
    Session-ID-ctx:
    Master-Key: BEF07A818F91C840EF60A? D { 7 t e a4DB5AEE89A11$ 0 4 M [ $ F Y #07EB594BC4718D7B4E2FC6904289AE7E7DB2CF6497812A82CCFDz D m ? : P ^ b ^2T  l3F33B915B6
    Start Time: 1590415033
    Timeout   : 72+ I 8 J00 (sec)
    Verify r] d D M k Return code: 0 (ok)
---
SSL3 alert read:warning:close notify
ci Z K ! ! 6losed
SSL3 alert write:warning:cloE 6 w & fse notify

其间需求了$ ; # V p t ` y解 「四处要害信息」G H 8 Y e g m O：

• SSL_connect：「SSLv3– m ! [ read server done A：客户端完结对接纳到的证书链的验证」。
• Certificate chain：「接纳到的证书链(2 个证书)」。
• SSL handshake has read 3093 bytes and written 35* K r C y t o4 bytes：「接纳到证书链的巨细」。
• Session-ID：「对有状况 TLS 康复发送的会话标识符」。

六、无线网络功能

1、无线网络的类型

• 「个人局域网(PAN)」
• **局域网(LAN) **
• **城域网(@ G DMAN) **
• 「广域网(WAN)」

2、无线网络的功能根底

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

C= BW  log2(1+S/N)

• C 是信道容量，单位是 bit/s;
• BW 是可用带宽，单位是 Hz;
• S/ X _ 6 $ [ 是信号，N 是噪声，单位是 W。

「它涵盖了影响大多数无线网络功能的全部根本要素」。

2）、带宽

为完结通讯，「发送端与接纳端有必要事先就通讯运用的频率规模达成5 | I共识」，在这个频率规B @ 8 – s模内两边8 8 % : E Z ~ * 8才干够顺利地交流信息p / 9 $ U。

影响功能的最主要要素便是频率规模的巨细(带宽)。由信道t S 8 Z + Y { O U容量的公式可知，信道的总体比特率与分配的带宽呈正比。

3z e m J L k）、信号强度

信噪比(SNR，Signal Noise Ratio)，「它衡量的是预期信号强度与背景噪声及搅扰之间的比值」。背景m Q p : N f h噪声越大，带着信息的信号就有必F q 1 z `要越强。

「假如想在存在搅扰的状况下抵达预期的数据传输速度，要么增大 发射功率，也便是进步信号强度，要么缩短收发0 $ d 5 0 B f 6 u两头的间隔——或许左右开弓」。

途径损耗（通路衰减）

「信n _ j U v I w号强度随间隔下降」。

远近效应

接纳端捕获较强的信号，因而不或许检测到较弱的信号，实践上f x O w x y P ?是“挤出”了较弱的信号。例如你旁边一个或多个大声说话的人会阻挡较弱的信号，然后发作远近效应。

小区呼吸效应

小区掩盖规模或信号K r # g l W =传输间隔依据噪声巨细和搅扰等级扩展和收缩。例如你周围交谈的人越多，搅扰就越严重，能5 0 z I让你辨认有用信号的规模也越小，这便是呼j 8 ( 8 _ A Z吸效应。

4）、( [ F ?调制

「数字信号(1 和 0)需求转化成模拟X t ^ X w ` O + C信号(无线电波)」。调制指的就 是这个数模转化进程，而不同调制算法的转化功率是不一样的。

可是，「高阶调制的价值是针对噪声和搅扰的牢靠性下降」。因而，需求在它们与转化功率直接做一个权衡。

3、影响无线网络功能的要素

• 「收发端的间隔」;
• 「当时方位的背景p – 7 n } A K噪声巨细」;
• 「来自同一网络(小区)其他用户的搅扰巨细」;
• 「来自相邻网络(小区)其他用户的搅扰巨细」2 O & C;
• 「两头发射p S功率巨细」;
• 「处理才干及调制算法」。

七、Wi-F v ` W ] w Ai

Wi-Fi 能够用来指称任何依据 IEEE 802.11 规范的产品。它工作于免答应的 2.4 GHz ISM 频段。

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

在 1d i Y w &971 年夏威夷大学对外发布了第一个关于无线网络G 6 : j f的协t R m议— ALOHAnet 协议。

以太网协议很大程度上学习了 ALOHAnet 协议，以太网一般被称作局域网(LAN)规范，而 802.11 无线规范主要是作为既有以太网规范(X S Q J A802.3)的扩展来规划的。因而& Q ~ 2 ; Q c c它也相应地被称作无线局域网(k 5 ] z C l *WLAN，Wireless LAN )规范。

1）、以太网—抵触检测(CSMA/CD，ColJ ] G : C 7 C zlision Detection)机制

假如检测到抵触，则两边都当即停止发送数据并小睡一段随机的时刻(后续时刻以指数级增加)，然后确保发作抵触 的发送端y g y不会同步，且不会一起重新开端发送数据。

2）、Wi-Fi-抵触防止(CSMA/CA， Collision Avoidance)机制

因为收发无线电的硬件所限，它不能在发送数据期间检测到抵触。因而，每个发送方都会在自己认为信道闲暇时发送数据，以防止抵触。

2、Wi-Fi 优化 Tips

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

2）、习惯可变带宽

比方自习惯g * A a k ? G比特流，来b @ . J主动习惯带宽改变。自习惯比特率并不合适全部资源，但对视频和音频这样的长时刻流服务是十分合适的。

在客户端下载视频流期间，客户端或服务器能够监控每个视频块的下载速度，必要时C 9 y U f依据B W l n 2带宽的改变调t B % ! G * % , h整要下载的下s H F一个视频块的比特率。事实上，实际中的视频服务* q S，「开端一般是低比特率的视频块，以便视频播映能更快开端。然后，再依据可用带宽的动态改变调整后续视频块的比特率」。

❝

深化探索 Android 网络优化（二、网络优化根底篇）下

❞

参阅链接：

• 1、「《Web 功能权威指南》1 – 13章（本文核心）」
• 2、极客时刻之《Android开发高手课》 网络优化根底
• 3、极客时刻之《透视 HTTP 协议》优6 w ~ M x化根底部分
• 4、HTTP/2 头部压缩技能介绍
• 5、HTTP 2.0 Header table
• 6、从 IPv4 到 IPv6，阿里踩过哪些坑？
• 7、腾讯云如何快速从IPv4向IPv6演进？
• 8、千兆级LTE与5G的那些事儿
• 9、讲清楚5G，这或许是最接地气的一篇= | ;了
• 10、IEEr $ c + T w WE_802.11ac
• 11、MIMO
• 12、Link Tm j H A # 6urbo 便是 5G前夜的“网络加速r ^ 9 d { {器”
• 13、MultiPath TCP – Linux Kernel implementation
• 14w 5 L、Multipath TCP: an overS d R m ! | h 1 qview
• 15、聊聊Linux 五种I0 | A z nO模型
• 16、Unix 网络 IO 模型及 Linux 的 IO 多路复用模型
• 17、Android epoll.c

Contanct Me

● 微信：

❝

欢迎关注我的微信：bc! ( 7 & 4 4 K V 4ce53e k c _60

❞

● 微信群：

❝

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

❞

● QQ群：

❝

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

❞

About me

• Email: chao.Z { = ~qu521@gmail.com
  

• Blog: jsonchao.github.io/
  

• 掘金: juejin.im/user/5a3ba9…
  

很感谢您阅览这篇文章，期望您能将它共享给您的朋友或技能群，; ^ a H Y . p *这对我意义严重。

期望咱们能成为朋友，在 Github、掘金上一起共享知识。