Android高手筆記 - 網(wǎng)絡(luò)優(yōu)化

  • 很難找到一款完全不需要網(wǎng)絡(luò)的應(yīng)用，即使是單機(jī)應(yīng)用，也會(huì)存在數(shù)據(jù)上報(bào)、廣告等各種各樣的網(wǎng)絡(luò)請(qǐng)求

網(wǎng)絡(luò)基礎(chǔ)

Http & Https

定義：
  1. https:Hypertext Transfer Protocol over Secure Socket Layer 超文本傳輸協(xié)議的安全套接字層
  2. http:一種詳細(xì)規(guī)定了瀏覽器和萬(wàn)維網(wǎng)服務(wù)器之間互相通信的規(guī)則
區(qū)別：
  1. https協(xié)議需要到ca申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用。
  2. http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的SSL/TLS加密
    傳輸協(xié)議（在 HTTP 與 TCP 之間）。(SSL/TSL 的常見(jiàn)開(kāi)源實(shí)現(xiàn)是 OpenSSL)
  3. http和https使用的是完全不同的連接方式，默認(rèn)端口也不一樣，前者是80，后者是443。
  4. http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、
    身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。
  5. 寫(xiě)法上的區(qū)別是前綴的不同，客戶端處理的方式也不同；
SSL(Secure Sockets Layer)安全套接層
  • SSL 位于傳輸層與應(yīng)用層之間，它是一個(gè)子層，作用主要有兩點(diǎn)：
  1. 數(shù)據(jù)安全（保證數(shù)據(jù)不會(huì)被泄漏）與數(shù)據(jù)完整（保證數(shù)據(jù)不會(huì)被篡改）；
  2. 對(duì)數(shù)據(jù)進(jìn)行加密后傳輸；
https目的：
  • 提供對(duì)網(wǎng)站服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私和完整性；
HTTPS 解決的問(wèn)題：
  1. 信任主機(jī)問(wèn)題（從CA申請(qǐng)證書(shū)）；
  2. 防止通信過(guò)程中的數(shù)據(jù)的泄密和被篡改；
https實(shí)現(xiàn)原理：
  1. 客戶使用https的URL訪問(wèn)Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。
  2. Web服務(wù)器收到客戶端請(qǐng)求后，會(huì)將網(wǎng)站的證書(shū)信息（證書(shū)中包含公鑰）傳送一份給客戶端。
  3. 客戶端的瀏覽器與Web服務(wù)器開(kāi)始協(xié)商SSL連接的安全等級(jí)（交換協(xié)議版本號(hào)），也就是信息加密的等級(jí)。
  4. 客戶端的瀏覽器根據(jù)雙方同意的安全等級(jí)，建立臨時(shí)會(huì)話密鑰，然后利用網(wǎng)站的公鑰將會(huì)話密鑰加密，
    并傳送給網(wǎng)站。
  5. Web服務(wù)器利用自己的私鑰解密出會(huì)話密鑰。
  6. Web服務(wù)器利用會(huì)話密鑰加密與客戶端之間的通信。

https加密原理

  • 相比較對(duì)稱加密而言，非對(duì)稱加密安全性更高，但是加解密耗費(fèi)的時(shí)間更長(zhǎng)，速度慢。
CA證書(shū)：

其實(shí)就是數(shù)字證書(shū)，是由 CA 機(jī)構(gòu)頒發(fā)的，包括證書(shū)的頒發(fā)機(jī)構(gòu)、版本，
使用者，公鑰，有效時(shí)間，數(shù)字簽名 Hash 值和簽名 Hash 算法；

客戶端如何校驗(yàn)CA證書(shū)

CA 證書(shū)中的 Hash 值，其實(shí)是用證書(shū)的私鑰進(jìn)行加密后的值（證書(shū)的私鑰不在 CA 證書(shū)
中）。然后客戶端得到證書(shū)后，利用證書(shū)中的公鑰去解密該 Hash 值，得到 Hash-a ；然
后再利用證書(shū)內(nèi)的簽名 Hash 算法去生成一個(gè) Hash-b 。最后比較 Hash-a 和 Hash-b 這
兩個(gè)的值。如果相等，那么證明了該證書(shū)是對(duì)的，服務(wù)端是可以被信任的；如果不相等，那
么就說(shuō)明該證書(shū)是錯(cuò)誤的，可能被篡改了，瀏覽器會(huì)給出相關(guān)提示，無(wú)法建立起 HTTPS 連
接。除此之外，還會(huì)校驗(yàn) CA 證書(shū)的有效時(shí)間和域名匹配等。

HTTPS中的SSL握手建立過(guò)程
  1. 客戶端和服務(wù)端建立 SSL 握手，客戶端通過(guò) CA 證書(shū)來(lái)確認(rèn)服務(wù)端的身份；
  2. 互相傳遞三個(gè)隨機(jī)數(shù)，之后通過(guò)這隨機(jī)數(shù)來(lái)生成一個(gè)密鑰；
  3. 互相確認(rèn)密鑰，然后握手結(jié)束；
  4. 數(shù)據(jù)通訊開(kāi)始，都使用同一個(gè)對(duì)話密鑰來(lái)加解密；
    (簡(jiǎn)而言之，用非對(duì)稱加密算法生成對(duì)稱加密的秘鑰，用對(duì)稱加密算法加密通信內(nèi)容)

分層：

OSI七層模型(物數(shù)網(wǎng)傳會(huì)表應(yīng))
  • 應(yīng)用層: 為計(jì)算機(jī)用戶提供接口和服務(wù)。
  • 表示層: 數(shù)據(jù)處理：編解碼、加解密等等。
  • 會(huì)話層: 管理（建立、維護(hù)、重連）通信會(huì)話。
  • 傳輸層: 管理端到端的通信連接。
  • 網(wǎng)絡(luò)層: 數(shù)據(jù)路由：決定數(shù)據(jù)在網(wǎng)絡(luò)中的路徑。
  • 數(shù)據(jù)鏈路層: 管理相鄰節(jié)點(diǎn)之間的數(shù)據(jù)通信。
  • 物理層: 數(shù)據(jù)通信的光電物理特性。
TCP/IP 四層模型
  • 應(yīng)用層：包括OSI中的會(huì)表應(yīng)三層，HTTP，F(xiàn)TP，SMTP，POP3，NFS、DNS等協(xié)議都屬于應(yīng)用層；
  • 傳輸層，TCP/UDP協(xié)議屬于傳輸層
  • 網(wǎng)絡(luò)層：IP協(xié)議屬于網(wǎng)絡(luò)層
  • 網(wǎng)絡(luò)接口層：包括OSI中的物數(shù)兩層，
HTTP（應(yīng)用層）》》TSL/SSL（安全層）》》TCP（傳輸層）》》IP（網(wǎng)絡(luò)層）》》網(wǎng)絡(luò)接口（數(shù)據(jù)鏈路層）
DNS(Domain Name System) 域名系統(tǒng)服務(wù)
  • 通過(guò)把沒(méi)有規(guī)則的點(diǎn)分十進(jìn)制 IP 地址轉(zhuǎn)換為可以理解的一些域名(域名通過(guò) DNS 服務(wù)可以被轉(zhuǎn)換成 IP 地址。);
域名：
  • 可以分為頂級(jí)域、二級(jí)域、三級(jí)域...，例如：www.taobao.com => - 三級(jí)域.二級(jí)域.頂級(jí)域。
DHCP(Dynamic Host Configuratin Protocol) 動(dòng)態(tài)主機(jī)設(shè)置協(xié)議
  • 網(wǎng)絡(luò)管理員只需配置一段共享的 IP 地址，每一臺(tái)新接入的機(jī)器都可以通過(guò) DHCP 來(lái)這個(gè)共享的 IP 地址里面申請(qǐng) IP 地址，就可以自動(dòng)配置。等用完還回去其它機(jī)器也能使用；
  • DHCP 是一個(gè)局域網(wǎng)協(xié)議，是應(yīng)用 UDP 協(xié)議的應(yīng)用層協(xié)議；

為什么 TCP 要經(jīng)過(guò)三次握手，四次揮手

三次握手：
  1. 第一次握手：建立連接?？蛻舳税l(fā)送連接請(qǐng)求報(bào)文段，將 SYN 位置為 1，Sequence Number為 x；然后，客戶端進(jìn)入 SYN_SEND 狀態(tài)，等待服務(wù)器的確認(rèn)。
  2. 第二次握手：服務(wù)器收到 SYN 報(bào)文段。服務(wù)器收到客戶端的 SYN 報(bào)文段，需要對(duì)這個(gè) SYN 報(bào)文段進(jìn)行確認(rèn)，設(shè)置 Acknowledgment Number 為 x+1(Sequence Number+1)；同時(shí)，自己自己還要發(fā)送 SYN 請(qǐng)求信息，將 SYN 位置為 1，Sequence Number 為 y；服務(wù)器端將上述所有信息放到一個(gè)報(bào)文段（即 SYN+ACK 報(bào)文段）中，一并發(fā)送給客戶端，此時(shí)服務(wù)器進(jìn)入 SYN_RECV 狀態(tài)；
  3. 第三次握手：客戶端收到服務(wù)器的 SYN+ACK 報(bào)文段。然后將 Acknowledgment Number設(shè)置為 y+1，向服務(wù)器發(fā)送 ACK 報(bào)文段，這個(gè)報(bào)文段發(fā)送完畢以后，客戶端和服務(wù)器端都進(jìn)入 ESTABLISHED 狀態(tài)，完成 TCP 三次握手。
四次揮手
  1. 第一次分手：主機(jī) 1（可以使客戶端，也可以是服務(wù)器端），設(shè)置 Sequence Number 和Acknowledgment Number，向主機(jī) 2 發(fā)送一個(gè) FIN 報(bào)文段；此時(shí)，主機(jī) 1 進(jìn)入 FIN_WAIT_1狀態(tài)；這表示主機(jī) 1 沒(méi)有數(shù)據(jù)要發(fā)送給主機(jī) 2 了；
  2. 第二次分手：主機(jī) 2 收到了主機(jī) 1 發(fā)送的 FIN 報(bào)文段，向主機(jī) 1 回一個(gè) ACK 報(bào)文段，Acknowledgment Number 為 Sequence Number 加 1；主機(jī) 1 進(jìn)入 FIN_WAIT_2 狀態(tài)；主機(jī) 2 告訴主機(jī) 1，我“同意”你的關(guān)閉請(qǐng)求；
  3. 第三次分手：主機(jī) 2 向主機(jī) 1 發(fā)送 FIN 報(bào)文段，請(qǐng)求關(guān)閉連接，同時(shí)主機(jī) 2 進(jìn)入 LAST_ACK狀態(tài)；
  4. 第四次分手：主機(jī) 1 收到主機(jī) 2 發(fā)送的 FIN 報(bào)文段，向主機(jī) 2 發(fā)送 ACK 報(bào)文段，然后主機(jī)1 進(jìn)入 TIME_WAIT 狀態(tài)；主機(jī) 2 收到主機(jī) 1 的 ACK 報(bào)文段以后，就關(guān)閉連接；此時(shí)，主機(jī)1 等待 2MSL 后依然沒(méi)有收到回復(fù)，則證明 Server 端已正常關(guān)閉，那好，主機(jī) 1 也可以關(guān)閉連接了。（MSL是Maximum Segment Lifetime英文的縮寫(xiě)，中文可以譯為“報(bào)文最大生存時(shí)間”，他是任何報(bào)文在網(wǎng)絡(luò)上存在的最長(zhǎng)時(shí)間，超過(guò)這個(gè)時(shí)間報(bào)文將被丟棄）;
  • “三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤”。主要目的防止 server 端一直等待，浪費(fèi)資源。換句話說(shuō)，即是為了保證服務(wù)端能收接受到客戶端的信息并能做出正確的應(yīng)答而進(jìn)行前兩次(第一次和第二次)握手，為了保證客戶端能夠接收到服務(wù)端的信息并能做出正確的應(yīng)答而進(jìn)行后兩次(第二次和第三次)握手。
  • “四次揮手”原因是因?yàn)?tcp 是全雙工模式，接收到 FIN 時(shí)意味將沒(méi)有數(shù)據(jù)再發(fā)來(lái)，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)。
TCP 在三次握手的時(shí)候，IP 層和 MAC層在做什么？
  • TCP 每發(fā)送一個(gè)消息，都會(huì)帶著 IP 層和 MAC 層。因?yàn)?TCP 每發(fā)送一個(gè)消息，IP 層和 MAC 層的所有機(jī)制都要運(yùn)行一遍。

TCP 和 UDP 的區(qū)別？

  1. TCP面向連接,UDP是無(wú)連接(即發(fā)送數(shù)據(jù)之前不需要建立連接);
  2. 對(duì)系統(tǒng)資源的要求（TCP 較多，UDP 少）；
  3. UDP 程序結(jié)構(gòu)較簡(jiǎn)單，不會(huì)對(duì)數(shù)據(jù)報(bào)進(jìn)行任何的處理，即不合并，也不拆分?jǐn)?shù)據(jù)，直接將應(yīng)用層數(shù)據(jù)塞進(jìn)報(bào)文里面。
  4. UDP 通常用于多媒體信息分發(fā)，即視頻、語(yǔ)音、實(shí)時(shí)信息 等等。而 TCP 通常用于可靠信息的傳輸，應(yīng)用場(chǎng)景包括金融交易、可靠通信、MQ 等等 ；
  5. TCP提供可靠的服務(wù)。也就是說(shuō)，通過(guò)TCP連接傳送的數(shù)據(jù)，無(wú)差錯(cuò)，不丟失，不重復(fù)，且按序到達(dá);
    UDP沒(méi)有擁塞控制，盡最大努力交付，不管網(wǎng)絡(luò)是否擁塞，它都會(huì)把數(shù)據(jù)給交付出去，但不保證可靠交付
  6. UDP具有較好的實(shí)時(shí)性，工作效率比TCP高，適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。
  7. 每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信
  8. TCP是全雙工通信：兩個(gè)設(shè)備在連接時(shí)，它們都可以同時(shí)地發(fā)送數(shù)據(jù)與接收數(shù)據(jù)。
  9. TCP是面向字節(jié)流的協(xié)議（可能出現(xiàn)黏包問(wèn)題），UDP面向報(bào)文傳輸
  10. TCP 首部開(kāi)銷20字節(jié)；UDP 的首部開(kāi)銷小，只有 8 個(gè)字節(jié)。
TCP 協(xié)議的可靠傳輸
  • TCP 的可靠傳輸基于連續(xù) ARQ 協(xié)議。
  1. 滑動(dòng)窗口
  2. 累積確認(rèn)
  3. 選擇重傳
TCP 協(xié)議的流量控制
  • 流量控制指的是 讓發(fā)送方發(fā)送速率不要太快。TCP 使用了滑動(dòng)窗口來(lái)實(shí)現(xiàn)流量控制。
  1. 滑動(dòng)窗口: 接收方可以調(diào)整滑動(dòng)窗口的大小來(lái)控制發(fā)送方發(fā)送數(shù)據(jù)的效率。
  2. 堅(jiān)持定時(shí)器: 使用滑動(dòng)窗口進(jìn)行流量控制的時(shí)候設(shè)置：當(dāng)接收到窗口為0的消息，則啟動(dòng)堅(jiān)持定時(shí)器；堅(jiān)持定時(shí)器每隔一段時(shí)間發(fā)送一個(gè)窗口探測(cè)報(bào)文；
TCP 協(xié)議的擁塞控制
  • 不同于流量控制考慮的是點(diǎn)對(duì)點(diǎn)的通信量的控制，擁塞控制考慮的是整個(gè)網(wǎng)絡(luò)，是一個(gè)全局性的考慮。
  1. 慢啟動(dòng)算法：由小到大逐漸增加發(fā)送數(shù)據(jù)量；每收到一個(gè)報(bào)文確認(rèn)，就加一；超過(guò)慢啟動(dòng)閾值(ssthresh) 則不再增長(zhǎng)。
  2. 擁塞避免算法：維護(hù)一個(gè)擁塞窗口的變量；只要網(wǎng)絡(luò)不擁塞，就試探著將擁塞窗口調(diào)大。
  • TCP 的擁塞控制在前期使用了 慢啟動(dòng) 算法對(duì)窗口大小進(jìn)行指數(shù)增長(zhǎng)，直到超過(guò)慢啟動(dòng)閾值(ssthresh)則不再增長(zhǎng)，后續(xù)則啟動(dòng)擁塞避免算法對(duì)窗口進(jìn)行線性增長(zhǎng)。
TCP 協(xié)議的四個(gè)定時(shí)器
  1. 超時(shí)定時(shí)器;
  2. 堅(jiān)持定時(shí)器;
  3. 時(shí)間等待定時(shí)器;
  4. 保活定時(shí)器：
TCP可靠傳輸原理實(shí)現(xiàn)
  1. 確認(rèn)和重傳：接收方收到報(bào)文后就會(huì)進(jìn)行確認(rèn)，發(fā)送方一段時(shí)間沒(méi)有收到確認(rèn)就會(huì)重傳。
  2. 數(shù)據(jù)校驗(yàn)。
  3. 數(shù)據(jù)合理分片與排序: TCP 會(huì)對(duì)數(shù)據(jù)進(jìn)行分片，接收方會(huì)緩存為按序到達(dá)的數(shù)據(jù)，重新排序后再提交給應(yīng)用層。
  4. 流程控制：當(dāng)接收方來(lái)不及接收發(fā)送的數(shù)據(jù)時(shí)，則會(huì)提示發(fā)送方降低發(fā)送的速度，防止包丟失。
  5. 擁塞控制：當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時(shí)，減少數(shù)據(jù)的發(fā)送。
    (http://blog.chinaunix.net/uid-26275986-id-4109679.html)

IP 協(xié)議

  • 物理設(shè)備通過(guò)使用 IP 協(xié)議，屏蔽了物理網(wǎng)絡(luò)之間的差異；
作用
  1. IP 協(xié)議 使得復(fù)雜的實(shí)際網(wǎng)絡(luò)變?yōu)橐粋€(gè)虛擬互連的網(wǎng)絡(luò)；
  2. IP 協(xié)議 使得網(wǎng)絡(luò)層可以屏蔽底層細(xì)節(jié)而專注網(wǎng)絡(luò)層的數(shù)據(jù)轉(zhuǎn)發(fā)；
  3. IP 協(xié)議 解決了在虛擬網(wǎng)絡(luò)中數(shù)據(jù)報(bào)傳輸路徑的問(wèn)題；
IP 地址
  • 每一個(gè)唯一的網(wǎng)絡(luò)設(shè)備都有一個(gè)唯一的 IP 地址。不同于 MAC 地址是不可改變的，IP 地址會(huì)根據(jù)當(dāng)前設(shè)備所連接的網(wǎng)絡(luò)環(huán)境的變化而發(fā)生變化。
MAC 地址與 IP 地址的區(qū)別
  1. 數(shù)據(jù)幀每一跳的 MAC 地址都在變化，而IP 數(shù)據(jù)報(bào)每一跳的 IP 地址始終不變。
  2. IP 地址具有遠(yuǎn)程定位功能，而 MAC 地址更像是身份證號(hào)，它的唯一性是為了組網(wǎng)時(shí)可以不用擔(dān)心不同的網(wǎng)卡在一個(gè)網(wǎng)絡(luò)里會(huì)產(chǎn)生沖突，從硬件角度保證不同的網(wǎng)卡有不同的標(biāo)識(shí)。
  3. 相比于 IP 地址，MAC 地址的通信范圍比較小，局限在一個(gè)子網(wǎng)里。例如：從 192.168.0.1/24 訪問(wèn) 192.168.0.9/24 是可以用 MAC 地址的。
ARP(Address Resolution Protocol)地址解析協(xié)議
  • 將網(wǎng)絡(luò)層 IP 32位地址轉(zhuǎn)換為數(shù)據(jù)鏈路層 MAC 48位地址。
  • ARP 協(xié)議被直接封裝在了數(shù)據(jù)鏈路層中的數(shù)據(jù)幀里面的。
RARP(Reverse Address Resolutioni Protocol)逆地址解析協(xié)議
  • 將數(shù)據(jù)鏈路層 MAC 48位地址轉(zhuǎn)換為網(wǎng)絡(luò)層 IP 32位地址
  • 除了類型 8035 標(biāo)識(shí)為 RARP 協(xié)議，其它內(nèi)容與 ARP 協(xié)議類似。
網(wǎng)絡(luò)地址轉(zhuǎn)換 NAT(Network Address Translationn) 技術(shù)
  • 不改變 IP 地址的網(wǎng)關(guān)，我們稱為轉(zhuǎn)發(fā)網(wǎng)關(guān)；改變 IP 地址的網(wǎng)關(guān)，我們稱為 NAT 網(wǎng)關(guān)。
  • 使用 NAT ，它用于多個(gè)主機(jī)通過(guò)一個(gè)公有 IP 訪問(wèn)互聯(lián)網(wǎng)的私有網(wǎng)絡(luò)，并減緩了 IP 地址的消耗，但是增加了網(wǎng)絡(luò)通信的復(fù)雜度。
  • 為什么要使用 NAT？
    1. IPv4 最多只有40+億個(gè) IP 地址。
    2. 早期 IP 地址的不合理規(guī)劃導(dǎo)致 IP 號(hào)浪費(fèi)。
內(nèi)網(wǎng)地址
  • 內(nèi)部機(jī)構(gòu)使用, 避免與外網(wǎng)地址重復(fù)。
三類內(nèi)網(wǎng)地址:
  1. A 類：10.0.0.0~10.255.255.255（支持千萬(wàn)數(shù)量級(jí)設(shè)備）。
  2. B 類：172.16.0.0~172.31.255.255（支持百萬(wàn)數(shù)據(jù)級(jí)設(shè)備）。
  3. C 類：192.168.0.0~192.168.255.255（支持萬(wàn)數(shù)量級(jí)設(shè)備）。
ICMP(Internet Control Message Protocol)協(xié)議
  • ICMP 協(xié)議主要是用于 輔助 IP 協(xié)議發(fā)送與接收數(shù)據(jù)的，它可以報(bào)告錯(cuò)誤信息或異常情況。
應(yīng)用：使用 Ping 命令對(duì)網(wǎng)絡(luò)故障進(jìn)行排查
  1. ping 回環(huán)地址 127.0.0.1，不通，說(shuō)明計(jì)算機(jī)使用的協(xié)議棧有問(wèn)題，需要重裝系統(tǒng)或協(xié)議棧。
  2. Ping 網(wǎng)關(guān)地址（路由地址），內(nèi)網(wǎng) ping 192.168.0.1/ 192.168.1.1，通，說(shuō)明本機(jī)到路由器的地址是通的。不通，則說(shuō)明 WIFI、網(wǎng)線是有問(wèn)題的。
  3. Ping 遠(yuǎn)端地址 ping www.wanandroid.com，不通，則說(shuō)明家中到 ISP 的網(wǎng)絡(luò)之間是有故障的。這個(gè)時(shí)候就要從電信、聯(lián)通、移動(dòng)等 ISP 來(lái)排查問(wèn)題了。
路由
  • 路由表: 包括了目的IP地址與下一跳IP地址的映射關(guān)系;

GET 和 POST 的區(qū)別

  1. get參數(shù)通過(guò)url傳遞，post放在request body中。
  2. get請(qǐng)求在url中傳遞的參數(shù)是有長(zhǎng)度限制的，而post沒(méi)有。
  3. get比post更不安全，因?yàn)閰?shù)直接暴露在url中，所以不能用來(lái)傳遞敏感信息。
  4. get請(qǐng)求只能進(jìn)行url編碼，而post支持多種編碼方式。
  5. get請(qǐng)求會(huì)瀏覽器主動(dòng)cache，請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽歷史記錄里，而post中的參數(shù)不會(huì)被保留。
  6. GET和POST本質(zhì)上就是TCP鏈接，并無(wú)差別。但是由于HTTP的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們?cè)趹?yīng)用過(guò)程中體現(xiàn)出一些不同。

無(wú)線網(wǎng)絡(luò)

  • 網(wǎng)絡(luò)的分類：按作用范圍分為廣域網(wǎng)，城域網(wǎng)，局域網(wǎng)；按使用者可分為公用網(wǎng)絡(luò)，專用網(wǎng)絡(luò)；按傳輸介質(zhì)分為有線網(wǎng)絡(luò)，無(wú)線網(wǎng)絡(luò)；
  • 有線通信：在實(shí)體物質(zhì)上傳播，使用銅線、光纖等有線介質(zhì)
  • 無(wú)線通信：利用電磁波進(jìn)行通信，常用的無(wú)線網(wǎng)絡(luò)類型：WiFi、蜂窩網(wǎng)絡(luò)、藍(lán)牙、NFC；
  • 無(wú)線網(wǎng)絡(luò)的瓶頸：?jiǎn)螚l光纖最大速度已達(dá)到了26Tbps，目前主流的移動(dòng)通信標(biāo)準(zhǔn)，4G LTE，理論速率只有150Mbps（不包括載波聚合）。
    這個(gè)和有線是完全沒(méi)辦法相比的，所以，5G如果要實(shí)現(xiàn)端到端的高速率，重點(diǎn)是突破無(wú)線這部分的瓶頸;

電磁波

  • 電磁波的功能特性，是由它的頻率決定的。不同頻率的電磁波，有不同的屬性特點(diǎn)，從而有不同的用途。例如，高頻的γ射線，具有很大的殺傷力，可以用來(lái)治療腫瘤。
  • 電波和光波，都屬于電磁波，目前主要使用電波進(jìn)行通信。當(dāng)然，光波通信也在崛起，例如LiFi；電波的頻率資源是有限的，為了避免干擾和沖突，我們?cè)陔姴ㄟ@條公路上進(jìn)一步劃分車道，分配給不同的對(duì)象和用途。目前全球主流的4G LTE技術(shù)標(biāo)準(zhǔn)，屬于特高頻和超高頻。

無(wú)線通信的頻率

  • 先說(shuō)一個(gè)公式：c=λv, 即 光速=波長(zhǎng)×頻率，無(wú)論是1G、2G、3G，還是4G、5G，萬(wàn)變不離其宗，全部都是在它身上做文章;
  • 隨著1G、2G、3G、4G的發(fā)展，使用的電波頻率是越來(lái)越高的,主要是因?yàn)椋l率越高，能使用的頻率資源越豐富。頻率資源越豐富，能實(shí)現(xiàn)的傳輸速率就越高。(頻率資源就像車廂，越高的頻率，車廂越多，相同時(shí)間內(nèi)能裝載的信息就越多。)
  • 既然，頻率高這么好，你一定會(huì)問(wèn)：“為什么以前我們不用高頻率呢？”,原因很簡(jiǎn)單,不是不想用，是用不起。電磁波的顯著特點(diǎn)就是頻率越高，波長(zhǎng)越短，越趨近于直線傳播（繞射能力越差），在傳播介質(zhì)中的衰減也越大，移動(dòng)通信如果用了高頻段，那么它最大的問(wèn)題，就是傳輸距離大幅縮短，覆蓋能力大幅減弱。相反的，頻率越低，網(wǎng)絡(luò)建設(shè)就越省錢，競(jìng)爭(zhēng)起來(lái)就越有利。這就是為什么，這些年，電信、移動(dòng)、聯(lián)通為了低頻段而爭(zhēng)得頭破血流。
  • 5G的一大技術(shù)特點(diǎn)就是 毫米波, 覆蓋同一個(gè)區(qū)域，需要的5G基站數(shù)量，將大大超過(guò)4G。

基站

  • 基站有兩種，微基站和宏基站?？疵志椭?，微基站很小(城區(qū)和室內(nèi)常見(jiàn)，5G時(shí)代更將隨處可見(jiàn))，宏基站很大(室外常見(jiàn)，建一個(gè)覆蓋一大片))
  • 那么多基站在身邊，會(huì)不會(huì)對(duì)人體造成影響？其實(shí)，和傳統(tǒng)認(rèn)知恰好相反，事實(shí)上，基站數(shù)量越多，輻射反而越小?。ɑ拘。β实?，對(duì)大家都好。如果只采用一個(gè)大基站，離得近，輻射大，離得遠(yuǎn)，沒(méi)信號(hào)，反而不好。）（頻率：電波<過(guò)度頻帶<紅外線<可見(jiàn)光<紫外線<x射線<γ射線，可見(jiàn)電波的最高頻率仍小于可見(jiàn)光頻率）

天線去哪了

  • 以前大哥大都有很長(zhǎng)的天線，早期的手機(jī)也有突出來(lái)的小天線，為什么現(xiàn)在我們的手機(jī)都沒(méi)有天線了，其實(shí)，我們并不是不需要天線，而是我們的天線變小了，根據(jù)天線特性，天線長(zhǎng)度應(yīng)與波長(zhǎng)成正比，大約在1/10~1/4之間，手機(jī)的通信頻率越來(lái)越高，波長(zhǎng)越來(lái)越短，天線也就跟著變短啦;

Massive MIMO（多天線技術(shù)）

  • MIMO就是“多進(jìn)多出”（Multiple-Input Multiple-Output），多根天線發(fā)送，多根天線接收，在LTE時(shí)代，我們就已經(jīng)有MIMO了，但是天線數(shù)量并不算多，只能說(shuō)是初級(jí)版的MIMO，到了5G時(shí)代，繼續(xù)把MIMO技術(shù)發(fā)揚(yáng)光大，現(xiàn)在變成了加強(qiáng)版的Massive　MIMO（Massive：大規(guī)模的；5G是毫米波通信，天線也變成毫米級(jí)，手機(jī)里就可以集成很多根天線）;

千兆級(jí) LTE

  • 指的是蜂窩網(wǎng)絡(luò)在理論上速度可以達(dá)到光纖級(jí)別的 1Gbps（125MB/s）。雖然基于 4G 標(biāo)準(zhǔn)，但通過(guò)MIMO（多輸入多輸出）、使用載波聚合的LAA等技術(shù)，現(xiàn)在已經(jīng)發(fā)展到千兆級(jí) LTE。

Link Turbo

  • 手機(jī)廠商為了提升用戶的網(wǎng)絡(luò)體驗(yàn)，也會(huì)做各種各樣的定制優(yōu)化，華為推出的Link Turbo 網(wǎng)絡(luò)聚合加速技術(shù)就是其中比較硬核的一種“黑科技”。
  • 從硬件角度來(lái)說(shuō)，WiFi 和蜂窩網(wǎng)絡(luò)屬于基帶芯片的不同模塊，我們可以簡(jiǎn)單的把它們理解為類似雙網(wǎng)卡的情形。所謂的 Link Turbo 就是在使用 WiFi 的同時(shí)使用移動(dòng)網(wǎng)絡(luò)加速。雙通道的技術(shù)以前也有，偵測(cè)到 WiFi 網(wǎng)絡(luò)不穩(wěn)定時(shí)，自動(dòng)切換到移動(dòng)網(wǎng)絡(luò)，而 Link Turbo 硬核的地方在于可以同時(shí)使用兩條通道傳輸數(shù)據(jù)，而且支持 TCP 與 UDP。

網(wǎng)絡(luò)I/O

Socket 描述符（socket fd）

  • 一切皆文件”，Linux 內(nèi)核會(huì)把所有外部設(shè)備都看作一個(gè)文件來(lái)操作。在網(wǎng)絡(luò) I/O 中系統(tǒng)對(duì)一個(gè) Socket 的讀寫(xiě)也會(huì)有相應(yīng)的描述符，稱為 socket fd;

同步

  • 同步就是一個(gè)任務(wù)的完成需要依賴另外一個(gè)任務(wù)時(shí)，只有等待被依賴的任務(wù)完成后，依賴的任務(wù)才能算完成，這是一種可靠的任務(wù)序列。要么成功都成功，失敗都失敗，兩個(gè)任務(wù)的狀態(tài)可以保持一致

異步

  • 異步是不需要等待被依賴的任務(wù)完成，只是通知被依賴的任務(wù)要完成什么工作，依賴的任務(wù)也立即執(zhí)行，只要自己完成了整個(gè)任務(wù)就算完成了。至于被依賴的任務(wù)最終是否真正完成，依賴它的任務(wù)無(wú)法確定，所以它是不可靠的任務(wù)序列。
  • 異步操作是可以被阻塞住的，只不過(guò)它不是在處理消息時(shí)阻塞，而是在等待消息通知時(shí)被阻塞

阻塞

  • 是指調(diào)用結(jié)果返回之前，當(dāng)前線程會(huì)被掛起，一直處于等待消息通知，不能夠執(zhí)行其他業(yè)務(wù)。函數(shù)只有在得到結(jié)果之后才會(huì)返回。

非阻塞

  • 非阻塞和阻塞的概念相對(duì)應(yīng)，指在不能立刻得到結(jié)果之前，該函數(shù)不會(huì)阻塞當(dāng)前線程，而會(huì)立刻返回。

小明的故事

  • 以小明下載文件為例
  1. 同步阻塞：小明一直盯著下載進(jìn)度條，到 100% 的時(shí)候就完成。
  2. 同步非阻塞：小明提交下載任務(wù)后就去干別的，每過(guò)一段時(shí)間就去瞄一眼進(jìn)度條，看到 100% 就完成。
  3. 異步阻塞：小明換了個(gè)有下載完成通知功能的軟件，下載完成就“?！币宦?。不過(guò)小明仍然一直等待“叮”的聲音
  4. 異步非阻塞：仍然是那個(gè)會(huì)“?！币宦暤南螺d軟件，小明提交下載任務(wù)后就去干別的，聽(tīng)到“?！钡囊宦暰椭劳瓿闪?/li>

網(wǎng)絡(luò)I/O 模型

  • 《UNIX 網(wǎng)絡(luò)編程》中將 UNIX 網(wǎng)絡(luò) I/O 模型分為以下五種（前四種均為同步）:
1. 阻塞I/O
  • 阻塞I/O：用戶空間的應(yīng)用程序執(zhí)行一個(gè)系統(tǒng)調(diào)用，這會(huì)導(dǎo)致應(yīng)用程序阻塞，什么也不干，直到數(shù)據(jù)準(zhǔn)備好，并且將數(shù)據(jù)從內(nèi)核復(fù)制到用戶進(jìn)程，最后進(jìn)程再處理數(shù)據(jù)，在等待數(shù)據(jù)到處理數(shù)據(jù)的兩個(gè)階段，整個(gè)進(jìn)程都被阻塞。不能處理別的網(wǎng)絡(luò)IO。
2. 非阻塞I/O
  • 非阻塞I/O：非阻塞的recvform系統(tǒng)調(diào)用調(diào)用之后，進(jìn)程并沒(méi)有被阻塞，內(nèi)核馬上返回給進(jìn)程，如果數(shù)據(jù)還沒(méi)準(zhǔn)備好，此時(shí)會(huì)返回一個(gè)error。進(jìn)程在返回之后，可以干點(diǎn)別的事情，然后再發(fā)起recvform系統(tǒng)調(diào)用。重復(fù)上面的過(guò)程，循環(huán)往復(fù)的進(jìn)行recvform系統(tǒng)調(diào)用。這個(gè)過(guò)程通常被稱之為輪詢。輪詢檢查內(nèi)核數(shù)據(jù)，直到數(shù)據(jù)準(zhǔn)備好，再拷貝數(shù)據(jù)到進(jìn)程，進(jìn)行數(shù)據(jù)處理。
3. 多路復(fù)用I/O
  • 由于同步非阻塞方式需要不斷主動(dòng)輪詢，輪詢占據(jù)了很大一部分過(guò)程，輪詢會(huì)消耗大量的CPU時(shí)間，而 “后臺(tái)” 可能有多個(gè)任務(wù)在同時(shí)進(jìn)行，人們就想到了循環(huán)查詢多個(gè)任務(wù)的完成狀態(tài)，只要有任何一個(gè)任務(wù)完成，就去處理它。如果輪詢不是進(jìn)程的用戶態(tài)，而是有人幫忙就好了。那么這就是所謂的 “IO 多路復(fù)用”。UNIX/Linux 下的 select、poll、epoll 就是干這個(gè)的（epoll 比 poll、select 效率高，做的事情是一樣的）。
4. 信號(hào)驅(qū)動(dòng)式I/O
  • 首先我們?cè)试SSocket進(jìn)行信號(hào)驅(qū)動(dòng)IO,并安裝一個(gè)信號(hào)處理函數(shù)，進(jìn)程繼續(xù)運(yùn)行并不阻塞。當(dāng)數(shù)據(jù)準(zhǔn)備好時(shí)，進(jìn)程會(huì)收到一個(gè)SIGIO信號(hào)，可以在信號(hào)處理函數(shù)中調(diào)用I/O操作函數(shù)處理數(shù)據(jù)。
5. 異步I/O
  • 相對(duì)于同步IO，異步IO不是順序執(zhí)行。用戶進(jìn)程進(jìn)行aio_read系統(tǒng)調(diào)用之后，無(wú)論內(nèi)核數(shù)據(jù)是否準(zhǔn)備好，都會(huì)直接返回給用戶進(jìn)程，然后用戶態(tài)進(jìn)程可以去做別的事情。等到socket數(shù)據(jù)準(zhǔn)備好了，內(nèi)核直接復(fù)制數(shù)據(jù)給進(jìn)程，然后從內(nèi)核向進(jìn)程發(fā)送通知。IO兩個(gè)階段，進(jìn)程都是非阻塞的。

網(wǎng)絡(luò)性能評(píng)估與優(yōu)化

性能評(píng)估

延遲與帶寬

  • 延遲：數(shù)據(jù)從信息源發(fā)送到目的地所需的時(shí)間。
  • 帶寬：邏輯或物理通信路徑最大的吞吐量。
  • 延遲和帶寬涉及的因素也非常多，例如信號(hào)的強(qiáng)度、附近有沒(méi)有基站、距離有多遠(yuǎn)等；還跟使用的網(wǎng)絡(luò)制式，正在使用 3G、4G 還是 5G 網(wǎng)絡(luò)有關(guān)，并且網(wǎng)絡(luò)的擁塞情況也會(huì)產(chǎn)生影響
  • 不同的應(yīng)用對(duì)延遲和帶寬的側(cè)重點(diǎn)可能不太一樣。對(duì)于直播類應(yīng)用或者“王者榮耀”來(lái)說(shuō)，延遲會(huì)更重要一些；對(duì)騰訊視頻、愛(ài)奇藝這種點(diǎn)播的應(yīng)用來(lái)說(shuō)，帶寬會(huì)更加重要一些。
不同網(wǎng)絡(luò)制式的帶寬與延遲參考值
網(wǎng)絡(luò)制式       帶寬（下行/上行）      延遲
2.75 G     384KB/48KB         600~700ms
3 G            7MB/2MB                150~400ms
4 G            128MB/56MB         40~50ms
5G         >100MB/>50MB       <10ms

弱網(wǎng)絡(luò)

  • 高延遲、低帶寬的網(wǎng)絡(luò)場(chǎng)景也就是我們常說(shuō)的“弱網(wǎng)絡(luò)”
特點(diǎn)：
  1. 丟包率高：信號(hào)問(wèn)題，用戶過(guò)多，誤碼包，用戶移動(dòng)，基站切換
  2. 誤碼率高：環(huán)境電波，用戶距離遠(yuǎn)
  3. 不穩(wěn)定的延遲：用戶數(shù)量，信令分配，丟包，誤碼包
  4. 不穩(wěn)定的帶寬：基站距離，用戶數(shù)量，擁塞控制

性能測(cè)量

  • 吞吐量：網(wǎng)絡(luò)接口接收和傳輸?shù)拿棵胱止?jié)數(shù)。
  • 延遲：系統(tǒng)調(diào)用發(fā)送 / 接收延時(shí)、連接延遲、首包延遲、網(wǎng)絡(luò)往返時(shí)間等。
  • 連接數(shù)：每秒的連接數(shù)。
  • 錯(cuò)誤：丟包計(jì)數(shù)、超時(shí)等。

網(wǎng)絡(luò)性能分析工具

  • strace: 跟蹤Socket相關(guān)的系統(tǒng)調(diào)用
  • netstat：多種網(wǎng)絡(luò)棧和接口統(tǒng)計(jì)信息
  • ifconfig：接口配置
  • ip：網(wǎng)絡(luò)接口統(tǒng)計(jì)信息
  • ping：測(cè)試網(wǎng)絡(luò)連通性
  • traceroute：測(cè)試網(wǎng)絡(luò)路由
  • tcpdump：網(wǎng)絡(luò)數(shù)據(jù)包嗅探器
  • 抓包工具Wireshark，F(xiàn)iddler，Charles等：圖形化的網(wǎng)絡(luò)數(shù)據(jù)報(bào)檢查
  • 如果你對(duì) Linux 底層更加熟悉，可以直接查看 /proc/net，它里面包含了許多網(wǎng)絡(luò)統(tǒng)計(jì)信息的文件。例如Android 的TrafficState接口就是利用 /proc/net/xt_qtaguid/stats 和 /proc/net/xt_qtaguid/iface_stat_fmt 文件來(lái)統(tǒng)計(jì)應(yīng)用的流量信息。

TPC 優(yōu)化

  • 因特網(wǎng)有兩個(gè)核心協(xié)議:IP 和 TCP，IP負(fù)責(zé)聯(lián)網(wǎng)主機(jī)之間的路由選擇和尋址;TCP負(fù)責(zé)在不可靠的傳輸信道之上提供可靠的抽象層。而 TCP/IP 也常被稱為 “因特網(wǎng)協(xié)議套件”(Internet Protocol Suite)。
1. 重用連接
  • 三次握手帶來(lái)的延遲使得每創(chuàng)建一個(gè)新 TCP 連接都要付出很大代價(jià)。而這也決定了提高 TCP 應(yīng)用性能的關(guān)鍵，在于想辦法重用連接。
TFO（TCP Fast Open，TCP快速打開(kāi))
  • TFO 致力于減少新建 TCP 連接帶來(lái)的性能損失。但卻只能在某些情況下有效。比如，隨同 SYN 分組一起發(fā)送的數(shù)據(jù)凈荷有最大尺寸限制、只能發(fā)送某些類型的 HTTP 請(qǐng) 求，以及由于依賴加密 cookie，只能應(yīng)用于重復(fù)的連接。
2. 擁塞預(yù)防及控制
流量控制
  • (滑動(dòng)窗口)為實(shí)現(xiàn)流量控制，TCP 連接的每一方都要通告自己的接收窗口(rwnd)，其中包含能夠保存數(shù)據(jù)的緩沖區(qū)空間大小信息。這個(gè)過(guò)程貫穿于每個(gè) TCP 連接的整個(gè)生命周期: 每個(gè) ACK 分組都會(huì)攜帶相應(yīng)的最新 rwnd 值，以便兩端動(dòng)態(tài)調(diào)整數(shù)據(jù)流速，使之適應(yīng)發(fā)送端和接收端的容量及處理能力。
慢啟動(dòng)
  • 由小到大逐漸增加發(fā)送數(shù)據(jù)量；每收到一個(gè)報(bào)文確認(rèn)，就加一；超過(guò)慢啟動(dòng)閾值(ssthresh) 則不再增長(zhǎng)。
擁塞預(yù)防
  • 擁塞預(yù)防算法把丟包作為網(wǎng)絡(luò)擁塞的標(biāo)志，即路徑中某個(gè)連接或路由器已經(jīng)擁堵了，以至于必須采取刪包措施。因此，必須調(diào)整窗口大小，以避免造成更多的包丟失， 從而保證網(wǎng)絡(luò)暢通
TCP PRR(Proportional Rate Reduction，比例降速)
  • 最初，TCP 使用 AIMD(Multiplicative Decrease and Additive Increase，倍減加增) 算法，即發(fā)生丟包時(shí)，先將擁塞窗口減半，然后每次往返再緩慢地給窗口增加一 個(gè)固定的值。后來(lái)，出現(xiàn)了 PRR(Proportional Rate Reduction，比例降速)，它是 RFC 6937 規(guī)定的一個(gè)新算法，其目標(biāo)就是 改進(jìn)丟包后的恢復(fù)速度。使用它因丟包造成的平均連接延遲減少了 3%~10%。此外，PRR 現(xiàn)在也是 Linux 3.2+ 內(nèi)核默認(rèn)的擁塞預(yù)防算法。
客戶端優(yōu)化
  1. 少發(fā)或者不發(fā)網(wǎng)絡(luò)情況（請(qǐng)求合并）：消除不必要的數(shù)據(jù)傳輸本身就是很大的優(yōu)化。比如，減少下載不必要的資源，或者通過(guò)壓縮算法把要發(fā)送的比特?cái)?shù)降到最低。
  2. 使用 CDN，讓通信距離更短：通過(guò)在不同的地區(qū)部署服務(wù)器，把數(shù)據(jù)放到接近客戶端的地方，可以減少網(wǎng)絡(luò)往返的延遲，從而顯著提升 TCP 性能。
  3. 重用 TCP 連接：把慢啟動(dòng)和其他擁塞控制機(jī)制的影響降到最低。

UDP 優(yōu)化

  • UDP 的特色在于它所省略的那些功能:連接狀態(tài)、握手、重發(fā)、重組、重排、擁塞控制、擁塞預(yù)防、流量控制，甚至可選的錯(cuò)誤檢測(cè)，統(tǒng)統(tǒng)沒(méi)有。
在 RFC 5405 中，對(duì)設(shè)計(jì)單播 UDP 應(yīng)用程序給出了很多設(shè)計(jì)建議（WebRTC 協(xié)議是下述規(guī)則的設(shè)計(jì)典范），如下所示：
1. 必須容忍各種因特網(wǎng)路徑條件;
2. 應(yīng)該控制傳輸速度;
3. 應(yīng)該對(duì)所有流量進(jìn)行擁塞控制;
4. 應(yīng)該使用與 TCP 相近的帶寬;
5. 應(yīng)該準(zhǔn)備基于丟包的重發(fā)計(jì)數(shù)器;
6. 應(yīng)該不發(fā)送大于路徑 MTU 的數(shù)據(jù)報(bào);
7. 應(yīng)該處理數(shù)據(jù)報(bào)丟失、重復(fù)和重排;
8. 應(yīng)該足夠穩(wěn)定以支持 2 分鐘以上的交付延遲;
9. 應(yīng)該支持 IPv4 UDP 校驗(yàn)和，必須支持 IPv6 校驗(yàn)和;
10. 可以在需要時(shí)使用 keep-alive(最小間隔 15 秒)。

TLS（Transport Layer Security，傳輸層安全）

  • IETF 在標(biāo)準(zhǔn)化 SSL 協(xié)議時(shí)，將其改名為 Transport Layer Security (TLS，傳輸層安全)。很多人會(huì)混用 TLS 和 SSL，但嚴(yán)格來(lái)講它們并不相 同，因?yàn)樗鼈冎复膮f(xié)議版本不同。
  • TLS 也可以實(shí)現(xiàn)在 UDP 之上，DTLS(Datagram Transport Layer Security，數(shù)據(jù)報(bào)傳輸層安全)（RFC 6347）就旨在以 TLS 協(xié)議為基礎(chǔ)，同時(shí)兼顧數(shù)據(jù)報(bào)交付模式并提供類似的安全保障。
TLS 協(xié)議的目標(biāo)是為在它之上運(yùn)行的應(yīng)用提供三個(gè)基本服務(wù)：
  1. 加密：混淆數(shù)據(jù)的機(jī)制。
  2. 身份驗(yàn)證：驗(yàn)證身份標(biāo)識(shí)有效性的機(jī)制。
  3. 數(shù)據(jù)完整性：檢測(cè)消息是否被篡改或偽造的機(jī)制。
TLS 優(yōu)化
  1. 盡早完成握手
  2. 使用會(huì)話緩存與無(wú)狀態(tài)恢復(fù)
  3. TLS 記錄大小(小記錄會(huì)造成浪費(fèi)，大記錄會(huì)導(dǎo)致延遲)
  4. 證書(shū)鏈的長(zhǎng)度：如果證書(shū)鏈長(zhǎng)度超過(guò)了 TCP 的初始擁塞窗口，那我們無(wú)意間就會(huì)讓握手多了一次往返:證書(shū)長(zhǎng)度超過(guò)擁塞窗口，從而導(dǎo)致服務(wù)器停下來(lái)等待 客戶端的 ACK 消息。（解決方法：增大擁塞窗口，減少證書(shū)大?。?/li>
  5. OCSP 封套：服務(wù)器可以在證書(shū)鏈中包含(封套)證書(shū)頒發(fā)機(jī)構(gòu)的 OCSP 響應(yīng)，讓瀏覽器跳過(guò)在線查詢。把查詢 OCSP 操作轉(zhuǎn)移到服務(wù)器可以讓服務(wù)器緩存簽名的 OCSP 響應(yīng)，從而節(jié)省很多客戶端的請(qǐng)求。
  6. HTTP 嚴(yán)格傳輸安全：一種安全策略機(jī)制，讓服務(wù)器通過(guò)簡(jiǎn)單的 HTTP 首部(如 Strict-Transport-Security: max-age=31536000) 對(duì)適用的瀏覽器聲明訪問(wèn)規(guī)則。

移動(dòng)端優(yōu)化

何為網(wǎng)絡(luò)庫(kù)

  • 實(shí)際開(kāi)發(fā)中，我們很少會(huì)直接操作底層的網(wǎng)絡(luò)接口，而是使用網(wǎng)絡(luò)庫(kù)；
網(wǎng)絡(luò)庫(kù)的核心作用
  1. 統(tǒng)一編程接口：簡(jiǎn)單易用，便于統(tǒng)一進(jìn)行策略管理，流解析(JSON，XNML等)
  2. 全局網(wǎng)絡(luò)控制：統(tǒng)一的網(wǎng)絡(luò)調(diào)度，流量監(jiān)控，容災(zāi)管理（跳維護(hù)頁(yè)），控制日志輸出，增加攔截器等
  3. 高性能：
網(wǎng)絡(luò)庫(kù)對(duì)比
xUtils:
  • 這個(gè)框架非常全面，可以進(jìn)行網(wǎng)絡(luò)請(qǐng)求，可以進(jìn)行圖片加載處理，可以數(shù)據(jù)儲(chǔ)存，還可以對(duì)view進(jìn)行注解，使用這個(gè)框架非常方便，但是缺點(diǎn)也是非常明顯的，使用這個(gè)項(xiàng)目，會(huì)導(dǎo)致項(xiàng)目對(duì)這個(gè)框架依賴非常的嚴(yán)重，一旦這個(gè)框架出現(xiàn)問(wèn)題，那么對(duì)項(xiàng)目來(lái)說(shuō)影響非常大的。
Volley：
  • Volley是Google官方出的一套小而巧的異步請(qǐng)求庫(kù)，該框架封裝的擴(kuò)展性很強(qiáng)，支持HttpClient、HttpUrlConnection，甚至支持OkHttp，而且Volley里面也封裝了ImageLoader，所以如果你愿意你甚至不需要使用圖片加載框架，不過(guò)這塊功能沒(méi)有一些專門的圖片加載框架強(qiáng)大，對(duì)于簡(jiǎn)單的需求可以使用，稍復(fù)雜點(diǎn)的需求還是需要用到專門的圖片加載框架。Volley也有缺陷，比如不支持post大數(shù)據(jù)，所以不適合上傳文件。不過(guò)Volley設(shè)計(jì)的初衷本身也就是為頻繁的、數(shù)據(jù)量小的網(wǎng)絡(luò)請(qǐng)求而生。
  • 優(yōu)勢(shì)在于封裝的更好
Retrofit：
  • Retrofit是Square公司出品的默認(rèn)基于OkHttp封裝的一套R(shí)ESTful網(wǎng)絡(luò)請(qǐng)求框架。Retrofit的封裝可以說(shuō)是很強(qiáng)大， 里面涉及到一堆的設(shè)計(jì)模式,可以通過(guò)注解直接配置請(qǐng)求，可以使用不同的http客戶端，雖然默認(rèn)是用http ，可以使用不同Json Converter 來(lái)序列化數(shù)據(jù)，同時(shí)提供對(duì)RxJava的支持，使用Retrofit + OkHttp + RxJava + Dagger2可以說(shuō)是目前比較潮的一套框架，但是需要有比較高的門檻。
  • Retrofit解耦的更徹底
  • 默認(rèn)使用OkHttp,性能上也要比Volley占優(yōu)勢(shì)
okHttp：
  • okHttp針對(duì)Java和Android程序，封裝的一個(gè)高性能的http請(qǐng)求庫(kù)，支持同步，異步，而且封裝了線程池，封裝了數(shù)據(jù)轉(zhuǎn)換， 封裝了參數(shù)的使用，錯(cuò)誤處理等。API使用起來(lái)更加的方便。但是我們?cè)陧?xiàng)目中使用的時(shí)候仍然需要自己在做一層封裝，這樣才能使用的更加的順手。
  • OkHttp的優(yōu)勢(shì)在于性能更高
  • DNS管理：支持DNS緩存，支持對(duì)接自己的HTTPDNS
  • 并發(fā)模型：使用多線程實(shí)現(xiàn)并發(fā)，實(shí)際執(zhí)行線程數(shù)受隊(duì)列機(jī)制控制，最大64，單個(gè)Host限制5個(gè)；
  • 連接管理：對(duì)于http連接，每個(gè)域名最多緩存5個(gè)連接，默認(rèn)KeepTime是5分鐘,對(duì)于HTTP/2連接，每個(gè)域名都共用一個(gè)H/2連接；
  • IO模型：阻塞Socket，使用OKio包裝Socket進(jìn)行流讀寫(xiě)；
  • 網(wǎng)絡(luò)質(zhì)量監(jiān)控：默認(rèn)不支持，有一些第三方插件；
  • 長(zhǎng)連接：默認(rèn)不支持；
  • 跨平臺(tái)：java實(shí)現(xiàn)，無(wú)法跨平臺(tái)；
  • 二次開(kāi)發(fā)：容易；
  • 協(xié)議支持：HTTP/1.1,HTTP/2.0,TLS1.1,TLS1.2
Chromium 的Cronet：
  • 蘑菇街、頭條、UC 瀏覽器都在 Chromium 網(wǎng)絡(luò)庫(kù)上做了二次開(kāi)發(fā)；
  • DNS管理：支持DNS緩存，支持對(duì)接自己的HTTPDNS；
  • 并發(fā)模型：每個(gè)host對(duì)應(yīng)一條線程，每個(gè)線程可以創(chuàng)建6個(gè)非阻塞socket請(qǐng)求網(wǎng)絡(luò)；
  • 連接管理：對(duì)于HTTP連接每個(gè)域名最多緩存6個(gè)連接,對(duì)于HTTP/2連接，每個(gè)域名都共用一個(gè)H/2連接；
  • IO模型：epll+非阻塞socket；
  • 網(wǎng)絡(luò)質(zhì)量監(jiān)控：Predictor用于收集使用數(shù)據(jù)并預(yù)測(cè)網(wǎng)絡(luò)行為，NQE提供當(dāng)前網(wǎng)絡(luò)質(zhì)量評(píng)估；
  • 長(zhǎng)連接：默認(rèn)不支持；
  • 跨平臺(tái)：c++實(shí)現(xiàn)，可以跨平臺(tái)；
  • 二次開(kāi)發(fā)：實(shí)現(xiàn)復(fù)雜，不容易擴(kuò)展；
  • 協(xié)議支持：HTTP/1.1,HTTP/2.0,QUIC,TLS1.1,TLS1.2,TLS1.3
微信 Mars：
  • 在弱網(wǎng)絡(luò)方面做了大量?jī)?yōu)化，拼多多、虎牙、鏈家、美麗說(shuō)這些應(yīng)用都在使用 Mars；
  • DNS管理：支持DNS緩存，支持對(duì)接自己的HTTPDNS；
  • 并發(fā)模型：每個(gè)短連都是一個(gè)線程，沒(méi)有線程限制；
  • 連接管理：支持復(fù)合連接，沒(méi)有連接管理；
  • IO模型：epll+非阻塞socket；
  • 網(wǎng)絡(luò)質(zhì)量監(jiān)控：SDT模塊支持網(wǎng)絡(luò)偵測(cè)與診斷；
  • 長(zhǎng)連接：默認(rèn)支持；
  • 跨平臺(tái)：c++實(shí)現(xiàn)，可以跨平臺(tái)；
  • 二次開(kāi)發(fā)：相比Cronet簡(jiǎn)單一些；
  • 協(xié)議支持：信令網(wǎng)絡(luò)，只支持TCP；
  • 查看更多：https://github.com/Tencent/mars/wiki
大網(wǎng)絡(luò)平臺(tái)
  • 阿里的ACCS、螞蟻的mPaaS、攜程的網(wǎng)絡(luò)服務(wù)都是公司級(jí)的網(wǎng)絡(luò)中臺(tái)服務(wù)，這樣所有的網(wǎng)絡(luò)優(yōu)化可以讓整個(gè)集團(tuán)的所有接入應(yīng)用受益。

為何優(yōu)化

  • 等待網(wǎng)絡(luò)是我們 App 最大的性能瓶頸，直接影響到用戶體驗(yàn)，用戶粘性，用戶忠誠(chéng)度，以及轉(zhuǎn)化率；

何為優(yōu)化

  • 一個(gè)數(shù)據(jù)包從手機(jī)出發(fā)要經(jīng)過(guò)無(wú)線網(wǎng)絡(luò)、核心網(wǎng)絡(luò)以及外部網(wǎng)絡(luò)（互聯(lián)網(wǎng)），才能到達(dá)我們的服務(wù)器；
    （手機(jī) => 無(wú)線網(wǎng)絡(luò) => 基站 => 運(yùn)營(yíng)商核心網(wǎng) => 互聯(lián)網(wǎng) => 服務(wù)器）
影響網(wǎng)絡(luò)請(qǐng)求速度的因素：
  1. 客戶端網(wǎng)絡(luò)庫(kù)的內(nèi)部設(shè)計(jì)和策略：IO并發(fā)模型，針對(duì)網(wǎng)絡(luò)問(wèn)題的優(yōu)化
  2. 服務(wù)器性能：并發(fā)能力，帶寬能力
  3. 網(wǎng)絡(luò)相關(guān)：用戶網(wǎng)絡(luò)（弱網(wǎng)，強(qiáng)網(wǎng)），運(yùn)營(yíng)商，網(wǎng)絡(luò)鏈路
網(wǎng)絡(luò)優(yōu)化的核心：
  • 速度，弱網(wǎng)絡(luò)，安全，其他的還有造成的耗電，流量問(wèn)題；
網(wǎng)絡(luò)請(qǐng)求步驟：
  1. DNS解析：通過(guò)DNS服務(wù)器拿到對(duì)應(yīng)域名的IP，需要關(guān)注 DNS解析耗時(shí)，運(yùn)營(yíng)商LocalDns劫持，DNS調(diào)度等；
  2. 創(chuàng)建連接：與服務(wù)器建連接，包括TCP三次握手，TLS密鑰協(xié)商等，需要關(guān)注 多個(gè)IP/端口如何選擇，是否使用HTTPS，能否減少創(chuàng)建連接的時(shí)間；
  3. 發(fā)送/接受數(shù)據(jù)：數(shù)據(jù)的組裝，發(fā)送，接收，解析，需要關(guān)注 根據(jù)網(wǎng)絡(luò)狀況利用帶寬，偵測(cè)網(wǎng)絡(luò)延時(shí)，弱網(wǎng)下調(diào)整包大??；
  4. 關(guān)閉連接：需要關(guān)注 主動(dòng)關(guān)閉和被動(dòng)關(guān)閉兩種情況；

HTTPDNS

  • DNS解析是網(wǎng)絡(luò)請(qǐng)求的第一步，默認(rèn)使用運(yùn)營(yíng)商的LocalDNS服務(wù)；
LocalDNS存在的問(wèn)題：
  1. 解析慢，4G約100ms，3G約200~300ms
  2. 穩(wěn)定性：UDP協(xié)議，無(wú)狀態(tài)，容易域名劫持（難復(fù)現(xiàn)，難定位，難解決）
  3. 準(zhǔn)確性：調(diào)度經(jīng)常不準(zhǔn)確，跨地域，跨運(yùn)營(yíng)商調(diào)度會(huì)導(dǎo)致訪問(wèn)慢，甚至訪問(wèn)不了
  4. 及時(shí)性：運(yùn)營(yíng)商可能修改DNS的TTL，導(dǎo)致DNS修改生效延遲
  • 為了解決上述問(wèn)題就有了HTTPDNS，即自己做域名解析，通過(guò)http請(qǐng)求后臺(tái)去拿到域名對(duì)應(yīng)的IP地址，大網(wǎng)絡(luò)平臺(tái)會(huì)有統(tǒng)一的HTTPDNS服務(wù)，并和運(yùn)維系統(tǒng)打通，還會(huì)增加精準(zhǔn)的流量調(diào)度，網(wǎng)絡(luò)撥測(cè)/灰度，網(wǎng)絡(luò)容災(zāi)等；

連接復(fù)用

  • 前面對(duì)比網(wǎng)絡(luò)庫(kù)中講的連接管理，網(wǎng)絡(luò)庫(kù)不會(huì)吧連接立刻釋放，而是放到連接池中，如果有另一個(gè)請(qǐng)求的域名和端口是一樣的，就可以復(fù)用，減少建立連接耗時(shí)（TCP三次握手，TLS密鑰協(xié)商等）；
  • 原理：利用HTTP協(xié)議里的keep-alive，或HTTP/2.0的多路復(fù)用（多條請(qǐng)求在這條連接上并發(fā)進(jìn)行）
  • 問(wèn)題：常用的OkHttp對(duì)應(yīng)HTTP/2.0的連接，同一個(gè)域名只會(huì)保留一條連接，網(wǎng)絡(luò)擁塞的時(shí)候容易出現(xiàn)TCP隊(duì)首擁塞問(wèn)題，這種情況可以通過(guò)修改網(wǎng)絡(luò)庫(kù)或者禁用HTTP/2.0解決；

壓縮與加密

  • 講完連接，再來(lái)看看發(fā)送和接收的優(yōu)化，第一重要的就是減少傳輸?shù)臄?shù)據(jù)量，也就是數(shù)據(jù)壓縮；
對(duì)于HTTP請(qǐng)求數(shù)據(jù)主要有三部分：
  1. 請(qǐng)求header：HTTP/2.0本身有頭部壓縮技術(shù)
  2. 請(qǐng)求URL：一般我們會(huì)有很多公共參數(shù)，這些參數(shù)大部分是不變的，可以只上傳一次，在統(tǒng)一接入層進(jìn)行參數(shù)擴(kuò)展
  3. 請(qǐng)求body：一是通信協(xié)議的選擇，在網(wǎng)絡(luò)傳輸中目前最流行的兩種數(shù)據(jù)序列化方式是 JSON 和 Protocol Buffers，Protocol Buffers 使用起來(lái)更加復(fù)雜一些，但在數(shù)據(jù)壓縮率、序列化與反序列化速度上面都有很大的優(yōu)勢(shì)。二是壓縮算法的選擇，通用的壓縮算法主要是如 gzip，Google 的Brotli或者 Facebook 的Z-standard都是壓縮率更高的算法。
  • 針對(duì)特定數(shù)據(jù)我們還有其他的壓縮方法，例如針對(duì)圖片我們可以使用 webp、hevc、SharpP等壓縮率更高的格式。另外一方面，基于 AI 的圖片超清化也是一大神器，QQ 空間通過(guò)這個(gè)技術(shù)節(jié)約了大量的帶寬成本。

安全

  • 數(shù)據(jù)安全也是網(wǎng)絡(luò)重中之重的一個(gè)環(huán)節(jié)，在大網(wǎng)絡(luò)平臺(tái)中是基于 HTTPS 的 HTTP/2 通道，已經(jīng)有了 TLS 加密。
  • 但是 HTTPS 帶來(lái)的代價(jià)也是不小的，它需要 2-RTT 的協(xié)商成本，在弱網(wǎng)絡(luò)下時(shí)延不可接受。同時(shí)后臺(tái)服務(wù)解密的成本也十分高昂，在大型企業(yè)中需要單獨(dú)的集群來(lái)做這個(gè)事情。

HTTPS 的優(yōu)化

  1. 連接復(fù)用率：多個(gè)域名共用同一個(gè) HTTP/2 連接、長(zhǎng)連接等方式
  2. 減少握手次數(shù)：TLS 1.3可以實(shí)現(xiàn) 0-RTT 協(xié)商，事實(shí)上在 TLS 1.3 release 之前，微信的mmtls、Facebook 的fizz、阿里的 SlightSSL 都已在企業(yè)內(nèi)部大規(guī)模部署。
  3. 性能提升:使用 ecc 證書(shū)代替 RSA，服務(wù)端簽名的性能可以提升 4～10 倍，但是客戶端校驗(yàn)性能降低了約 20 倍，從 10 微秒級(jí)降低到 100 微秒級(jí)。另外一方面可以通過(guò) Session Ticket 會(huì)話復(fù)用，節(jié)省一個(gè) RTT 耗時(shí)。
  4. 其他優(yōu)化：一些方案可能是需要用錢堆出來(lái)的，比如部署跨國(guó)的專線、加速點(diǎn)，多 IDC 就近接入等。除此之外，使用CDN 服務(wù)、P2P 技術(shù)也是比較常用的手段，特別在直播這類場(chǎng)景。
    1. 異地多活：多個(gè)地區(qū)同時(shí)存在對(duì)等的多個(gè)機(jī)房，以用戶維度劃分，多機(jī)房共同承擔(dān)全量用戶的流量。
    2. 抗抖動(dòng)優(yōu)化：應(yīng)用一種有策略的重試機(jī)制，將網(wǎng)絡(luò)請(qǐng)求以是否發(fā)送到 socket 緩沖區(qū)作為分割
    3. SYNC 機(jī)制：同步差量數(shù)據(jù)，達(dá)到節(jié)省流量，提高通信效率與請(qǐng)求成功率?？蛻舳擞脩舨辉诰€時(shí)，SYNC 服務(wù)端將差量數(shù)據(jù)保持在數(shù)據(jù)庫(kù)中。當(dāng)客戶端下次連接到服務(wù)器時(shí)，再同步差量數(shù)據(jù)給用戶。
    4. 高并發(fā)流量處理：服務(wù)端接入層多級(jí)限流，
    5. JobScheduler：結(jié)合 JobScheduler 來(lái)根據(jù)實(shí)際情況做網(wǎng)絡(luò)請(qǐng)求. 比方說(shuō) Splash 閃屏廣告圖片, 我們可以在連接到 Wifi 時(shí)下載緩存到本地; 新聞?lì)惖?App 可以在充電, Wifi 狀態(tài)下做離線緩存。
    6. 網(wǎng)絡(luò)請(qǐng)求優(yōu)先級(jí)排序：app應(yīng)該對(duì)網(wǎng)絡(luò)請(qǐng)求劃分優(yōu)先級(jí)盡可能快地展示最有用的信息給用戶。（高優(yōu)先級(jí)的服務(wù)優(yōu)先使用長(zhǎng)連接）
    7. 建立長(zhǎng)連通道：將眾多請(qǐng)求放入等待發(fā)送隊(duì)列中，待長(zhǎng)連通道建立完畢后再將等待隊(duì)列中的請(qǐng)求放在長(zhǎng)連通道上依次送出。
    8. 減少域名和避免重定向
    9. 沒(méi)有請(qǐng)求的請(qǐng)求，才是最快的請(qǐng)求。

移動(dòng)端監(jiān)控

  • 不論是基站故障、光纖被挖斷、運(yùn)營(yíng)商挾持，還是我們的機(jī)房、CDN 服務(wù)商出現(xiàn)故障，都有可能會(huì)引起用戶網(wǎng)絡(luò)出現(xiàn)問(wèn)題。
  • 即使我們使用了OkHttp網(wǎng)絡(luò)庫(kù)，也可能會(huì)有一些開(kāi)發(fā)人員或者第三方組件使用了系統(tǒng)的網(wǎng)絡(luò)庫(kù)。那應(yīng)該如何統(tǒng)一的監(jiān)控客戶端的所有的網(wǎng)絡(luò)請(qǐng)求呢？
1. 插樁：
  • 360 開(kāi)源的性能監(jiān)控工具ArgusAPM就是利用 Aspect 切換插樁，實(shí)現(xiàn)監(jiān)控系統(tǒng)和 OkHttp 網(wǎng)絡(luò)庫(kù)的請(qǐng)求。(參考其TraceNetTrafficMonitor，OkHttp3Aspect)
  • 插樁的方法看起來(lái)很好，但是并不全面。如果使用的不是系統(tǒng)和 OkHttp 網(wǎng)絡(luò)庫(kù)，又或者使用了 Native 代碼的網(wǎng)絡(luò)請(qǐng)求，都無(wú)法監(jiān)控到。
2. Native Hook：
3. 統(tǒng)一網(wǎng)絡(luò)庫(kù)
  • 盡管拿到了所有的網(wǎng)絡(luò)調(diào)用，想想會(huì)有哪些使用場(chǎng)景呢？模擬網(wǎng)絡(luò)數(shù)據(jù)、統(tǒng)計(jì)應(yīng)用流量，或者是單獨(dú)代理 WebView 的網(wǎng)絡(luò)請(qǐng)求。

如何監(jiān)控流量

  • 應(yīng)用流量監(jiān)控的方法非常簡(jiǎn)單，一般通過(guò) TrafficStats 類。TrafficState 是 Android API 8 加入的接口，用于獲取整個(gè)手機(jī)或者某個(gè) UID 從開(kāi)機(jī)算起的網(wǎng)絡(luò)流量。至于如何使用可以參考https://github.com/facebook/network-connection-class；
getMobileRxBytes()        //從開(kāi)機(jī)開(kāi)始Mobile網(wǎng)絡(luò)接收的字節(jié)總數(shù)，不包括Wifi
getTotalRxBytes()         //從開(kāi)機(jī)開(kāi)始所有網(wǎng)絡(luò)接收的字節(jié)總數(shù)，包括Wifi
getMobileTxBytes()        //從開(kāi)機(jī)開(kāi)始Mobile網(wǎng)絡(luò)發(fā)送的字節(jié)總數(shù)，不包括Wifi
getTotalTxBytes()         //從開(kāi)機(jī)開(kāi)始所有網(wǎng)絡(luò)發(fā)送的字節(jié)總數(shù)，包括Wifi
//原理：讀取 proc，并將目標(biāo) UID 下面所有網(wǎng)絡(luò)接口的流量相加。
//Android 7.0 之后只能通過(guò) TrafficStats 拿到自己應(yīng)用的流量信息
網(wǎng)絡(luò)測(cè)試模式：
  • Android 手機(jī)跟 iPhone 都有一個(gè)網(wǎng)絡(luò)測(cè)試模式
  • iPhone：打開(kāi)撥號(hào)界面，輸入“3001#12345#”，然后按撥號(hào)鍵。
  • Android 手機(jī)：打開(kāi)撥號(hào)界面，輸入“##4636##”，然后按撥號(hào)鍵（可進(jìn)入工程測(cè)試模式，部分版本可能不支持）。

參考

我是今陽(yáng)，如果想要進(jìn)階和了解更多的干貨，歡迎關(guān)注微信公眾號(hào) “今陽(yáng)說(shuō)” 接收我的最新文章

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容