深入探索 Android 网络优化（二、网络优化基础篇）上(1)

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⚠️close notify
closed
SSL3 alert write⚠️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)机制

资源分享

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2020年虽然路途坎坷，都在说Android要没落，但是，不要慌，做自己的计划，学自己的习，竞争无处不在，每个行业都是如此。相信自己，没有做不到的，只有想不到的。祝大家2021年万事大吉。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

j1o-1714662146521)]

[外链图片转存中…(img-oFMeGDNQ-1714662146521)]

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2020年虽然路途坎坷，都在说Android要没落，但是，不要慌，做自己的计划，学自己的习，竞争无处不在，每个行业都是如此。相信自己，没有做不到的，只有想不到的。祝大家2021年万事大吉。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！