「等待網絡是咱們 App 最大的性能瓶頸,再怎麼優化繪製、內存、卡頓或其它方面,也抵不上網絡優化」!網絡通訊速度越快,則:html
而網絡優化最核心的處理方式就是 「消除和減小沒必要要的網絡延遲,把傳輸的字節數降到最少」。android
手機 => 無線網絡 => 基站 => 運營商核心網 => 互聯網 => 服務器
複製代碼
「數據從信息源發送到目的地所需的時間」。客戶端到服務端的總延遲時間以下所示:git
一路上通過的路由器越多,每一個分組的處理和傳輸延遲就越多。而且,網絡流量越擁擠,分組在入站緩衝區中被延遲的可能性就越大。github
最後,延遲中至關大的一部分每每花在了最後幾千米,經過 traceroute 命令,咱們就能夠知道上網服務商的拓撲結構和速度。web
「邏輯或物理統統信路徑的最大吞吐量」。算法
就是一根「光導管」,比人的頭髮稍粗一點,專門用來從一端向另外一端傳送光信號。數據庫
用於傳送電信號,但信號損失、電磁干擾較大,同時維護成本也較高。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 是重延時的應用仍是重帶寬的應用」。
遺憾的是,人類不太可能跳出物理定律的 「掌心」。若是須要針對延遲採起優化措施,就必須從 「設計和優化協議及應用」 着手,而且時刻牢記光速的限制。
因特網有兩個核心協議:IP 和 TCP。
Internet Protocol(因特網協議)
,負責聯網主機之間的路由選擇和尋址;
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。
TFO 致力於減小新建 TCP 鏈接帶來的性能損失。但卻只能在某些狀況下有效。好比,「隨同 SYN 分組一塊兒發送的數據淨荷有最大尺寸限制、只能發送某些類型的 HTTP 請 求,以及因爲依賴加密 cookie,只能應用於重複的鏈接」。
ARPANET(Advanced Research Projects Agency Network,高級研究計劃局 網絡)
是現代互聯網的前身,是世界上第一個實際運行的分組交換網絡。這個項目於 1959 年正式啓動,「1983 年 TCP/IP 做爲主要通訊協議取代了原來 的 NCP(Network Control Program)協議」。
爲實現流量控制,TCP 鏈接的每一方都要通告本身的接收窗口(rwnd),其中包含可以保存數據的緩衝區空間大小信息。這個過程貫穿於每一個 TCP 鏈接的整個生命週期: 「每一個 ACK 分組都會攜帶相應的最新 rwnd 值,以便兩端動態調整數據流速,使之適應發送端和接收端的容量及處理能力」。
最初的 TCP 規範分配給通告窗口大小的字段是 16 位的,RFC 1323 提供了「TCP 窗口縮放」(TCP Window Scaling)選項,能夠 「把接收窗口大小由 65535 字節提升到 1G 字節」!縮放 TCP 窗口是在三次握手期間完成的,其中有一個值表示在未來的 ACK 中左移 16 位窗口字段的位數。
擁塞窗口大小(cwnd),即發送端對從客戶端接收確認(ACK)以前能夠發送數據量的限制。
新 TCP 鏈接傳輸的最大數據量取 rwnd 和 cwnd 中的最小值,而服務器實際上能夠 向客戶端發送 4 個 TCP 段,而後就必須停下來等待確認。
爲減小增加到擁塞窗口的時間,能夠減小客戶端與服務器之間的往返時間。好比, 把服務器部署到地理上靠近客戶端的地方。要麼,就把初始擁塞窗口大小增長到 RFC 9828 規定的 10 段。
由於慢啓動限制了可用的吞吐量,而這對於小文件傳輸很是不利。
在鏈接空閒必定時間後重置鏈接的擁塞窗口。道理很簡單, 在鏈接空閒的同時,網絡情況也可能發生了變化,爲了不擁塞,理應將擁塞窗口重置回「安全的」默認值。
可是,「SSR 對於那些會出現突發空閒的長週期 TCP 鏈接(好比 HTTP 的 keep-alive 鏈接)有很大的影響。所以,咱們建議在服務器上禁用 SSR」。
能夠看到,服務器和客戶端之間的 5 Mbit/s 帶寬並不影響 TCP 鏈接的啓動階 段。此時,延遲和擁塞窗口大小纔是限制因素。
慢啓動以保守的窗口初始化鏈接,隨後的 每次往返都會成倍提升傳輸的數據量,直到超過接收端的流量控制窗口,即系統 配置的擁塞閾值(ssthresh)窗口,或者有分組丟失爲止,此時擁塞預防算法介入。
「擁塞預防算法把丟包做爲網絡擁塞的標誌」,即路徑中某個鏈接或路由器已經擁堵了, 以致於必須採起刪包措施。所以,必須調整窗口大小,以免形成更多的包丟失, 從而保證網絡暢通。
重置擁塞窗口後,擁塞預防機制按照本身的算法來增大窗口以儘可能避免丟包。某個 時刻,可能又會有包丟失,因而這個過程再從頭開始。若是你看到過 TCP 鏈接的吞 吐量跟蹤曲線,發現該曲線呈鋸齒狀,那如今就該明白爲何了。這是擁塞控制和 預防算法在調整擁塞窗口,進而消除網絡中的丟包問題。
最初,TCP 使用 AIMD(Multiplicative Decrease and Additive Increase,倍減加增)
算法,即發生丟包時,「先將擁塞窗口減半,而後每次往返再緩慢地給窗口增長一 個固定的值」。
後來,出現了 PRR(Proportional Rate Reduction,比例降速)
,它是 RFC 6937 規定的一個新算法,其目標就是 「改進丟包後的恢復速度。使用它因丟包形成的平均鏈接延遲減小了 3%~10%。此外,PRR 如今也是 Linux 3.2+ 內核默認的擁塞預防算法」。
接收窗口(rwnd)會隨每次 ACK 一塊兒發送,而 擁塞窗口(cwnd)則由發送端根據擁塞控制和預防算法動態調整。
不管發送端發送的數據仍是接收端接收的數據超過了未確認的最大數據量,都必須停 下來等待另外一方 ACK 確認某些分組才能繼續。
而 BDP(Bandwidth-delay product,帶寬延遲積) 就是 「任意時刻處於在途未確認狀態的最大數據量」。
BDP = 數據鏈路的容量 * 其端到端延遲
複製代碼
「在高速鏈接的客戶端與服務器之間,若是實際傳輸速度只有可用帶寬的幾分之一,那窗口大小極可能就是 罪魁禍首。要麼由於某一飽和端通告的接收窗口很小,要麼由於網絡擁堵和丟包致使擁塞窗口重置,更可能由於流量增加過快致使對鏈接吞吐量施加了限制」。
TCP 在不可靠的信道上實現了可靠的網絡傳輸。基本的分組錯誤檢測與糾正、按 序交付、丟包重發,以及保證網絡最高效率的流量控制、擁塞控制和預防機制,讓 TCP 成爲大多數網絡應用中最多見的傳輸協議。
可是,其中的按序交付和可靠交付有時候並沒必要要,反而會致使額外的延遲,對性能形成負面影響。例如:每一個 TCP 分組都會帶着一個惟一的序列號被髮出,而 全部分組必須按順序傳送到接收端。若是中途有一個分組沒能到達接收 端,那麼後續分組必須保存在接收端的 TCP 緩衝區,等待丟失的分組重發併到達接 收端。這一切都發生在 TCP 層,應用程序對 TCP 重發和緩衝區中排隊的分組一無所 知,必須等待分組所有到達才能訪問數據。在此以前,應用程序只能在經過套接字 讀數據時感受到延遲交付。這種效應稱爲 TCP 的隊首(HOL,Head of Line)阻塞。
「隊首阻塞使得分組到達時間會存在沒法預知的延遲變化,而這個時間變化一般被稱爲抖動」。
所以,對於無需按序交付數據或可以處理分組丟失的應用程序,以及對延遲或抖動要求很高的應用程序,最好選擇 UDP 等協議。
丟包是讓 TCP 達到最佳性能的關鍵。被刪除的包偏偏是一種反饋機制, 可以讓接收端和發送端各自調整速度,以免網絡擁堵,同時保持延遲最短。
對與實時性比較強的音視頻應用來講,就算有個包丟了,音頻編解碼器只要在音頻中插入一個小小的間歇,就能夠繼續 處理後來的包。只要間歇夠小,用戶就注意不到,而等待丟失的包則可能致使音 頻輸出產生沒法預料的暫停。相對來講,後者的用戶體驗更糟糕。
大多數狀況下,「TCP 的瓶頸都是延遲,而非帶寬」。
加大起始擁塞窗口可讓 TCP 在第一次往返就傳輸較多數據,而隨後的速度提 升也會很明顯。對於突發性的短暫鏈接,這也是特別關鍵的一個優化。
在鏈接空閒時禁用慢啓動能夠改善瞬時發送數據的長 TCP 鏈接的性能。
啓用窗口縮放能夠增大最大接收窗口大小,可讓高延遲的鏈接達到更好吞 吐量。
在某些條件下,容許在第一個 SYN 分組中發送應用程序數據。TFO(TCP Fast Open,TCP 快速打開)是一種新的優化選項,注意,TFO 須要客戶端和服務器共同支持。
數據報,即一個完整、獨立的數據實體,攜帶着從源節點到目的地節點的足夠信息,對這些 節點間以前的數據交換和傳輸網絡沒有任何依賴。
數據報(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 通訊,有一個事實上的最佳作法,即引入一個雙向 keep-alive
分組,「週期性地重置傳輸路徑上全部 NAT 設備中轉換記錄的計時器」。
NAT 致使了幾個問題,以下所示:
爲解決 UDP 與 NAT 的這種不搭配,人們發明了不少穿透技術(TURN、STUN、 ICE),用於在 UDP 主機之間創建端到端的鏈接。
STUN 並不能適應全部類型的 NAT 和網絡配置。不只如此,某些狀況下 UDP 還會被防火牆或其餘網絡設備徹底屏蔽。
爲解決這個問題,在 STUN 失敗的狀況下,咱們還能夠使用 TURN(Traversal Using Relays around NAT)協議(RFC 5766)做爲後備。TURN 能夠在最壞的狀況下跳過 UDP 而切換到 TCP。
爲知足傳輸數據的須要,中繼設備的容量必須足夠大。
谷歌的 libjingle
是一個用 C++ 開發的用於構建端到端應用程序的開源庫,其文檔也爲咱們考量現實中的 STUN 與 TURN 性能提供了有價值的參考:
ICE 規定了一套方法,致力於在通訊各端之間創建一條最有效的通道:能直連就直連,必要時 STUN 協商,再不行使用 TURN。以下圖所示:
若是要構建基於 UDP 的 P2P 應用程序,咱們應該選擇現有的平臺 API,或者實現了 ICE、STUN 和 TURN 的第三方庫。
「UDP 的特點在於它所省略的那些功能:鏈接狀態、握手、重發、重組、重排、擁塞控制、擁塞預防、流量控制,甚至可選的錯誤檢測,通通沒有」。
在 RFC 5405 中,對設計單播 UDP 應用程序給出了不少設計建議,以下所示:
而 WebRTC 協議則是上述的設計典範。
SSL 協議在直接位於 TCP 上一層的應用層被實現。
IETF 後來在標準化 SSL 協議時,將其更名爲 Transport Layer Security (TLS,傳輸層安全)。不少人會混用 TLS 和 SSL,但嚴格來說它們並不相 同,由於它們指代的協議版本不一樣。
鑑於 SSL 協議是網景公司專有的,IETF 成立了一個小組負責標準化該協 議,後來就有了 RFC 2246,即 TLS 1.0,也就是 SSL 3.0 的升級版。
TLS 也能夠實如今 UDP 之上,DTLS(Datagram Transport Layer Security,數據報傳輸層安全)(RFC 6347)就旨在以 TLS 協議爲基礎,同時兼顧數據報交付模式並提供相似的安全保障。
TLS 協議的目標是爲在它之上運行的應用提供三個基本服務:
在握手機制中設計最巧妙的地方,就是其使用的公鑰密碼系統 (也稱「非對稱密鑰加密」),這套系統可讓通訊雙方沒必要事先「認識」便可商定共 享的安全密鑰,並且協商過程仍是經過非加密通道完成的。
握手過程當中,TLS 協議還容許通訊兩端互相驗明正身。這個驗證首先須要創建「認證機構信任鏈」(Chain of Trust and Certificate Authorities)。
消息分幀機制,使用 MAC (Message Authentication Code,消息認證碼)簽署每一條消息。MAC 算法是一個單向加密的散列函數(本質上是一個校驗和),「密鑰由鏈接雙方協商肯定。只要發送 TLS 記錄,就會生成一個 MAC 值並附加到該消息中」。接收端經過計算和驗證這個 MAC 值來判斷消息的完整性和可靠性。
NPN(Next Protocol Negotiation,下一代協議協商)是谷歌在 SPDY 協議中開發的一個 TLS 擴展,「目的是經過在 TLS 握手期間協商應用協議來提升效率」。
ALPN 是 IETF 在 NPN 基礎上修訂並批准的版本。在 NPN 中,服務器廣播本身 支持的協議,客戶端選擇和確認協議。而 「在 ALPN 中,交換次序顛倒過來了,客 戶端先聲明本身支持的協議,服務器選擇並確認協議。而這樣修改的目的是爲了讓 ALPN 與其餘協議協商標準保持一致」。
ALPN 做爲 TLS 擴展,讓咱們能在 TLS 握手的同時協商應用協議,從而省掉了 HTTP 的 Upgrade 機制所需的額外往返時間。
只要 TLS 握手完成、創建了加密信道並就應用協議達成一致,客戶端與服務器就可 以當即通訊。
若是服務器想在一個 IP 地址爲多個站點提供服務,而每一個站點都擁有本身的 TLS 證書,那怎麼辦?
爲了解決這個問題,SNI 擴展被引入 TLS 協議,該擴展 「容許客戶端在握手之初就指明要鏈接的主機名」。
即在多個鏈接間共享協商後的安全密鑰。
最先的「會話標識符」機制是在 SSL 2.0 中引入的, 支持服務器建立 32 字節的會話標識符,它是在完整的 TLS 協商期間做爲其「ServerHello」消息的一部分發送。
在內部,服務器會爲每一個客戶端保存一個會話 ID 和協商後的會話參數。相應地,客 戶端也能夠保存會話 ID 信息,並將該 ID 包含在後續會話的「ClientHello」消息中, 從而告訴服務器本身還記着上次握手協商後的加密套件和密鑰,這些均可以重用。
假設客戶端和服務器均可以在本身的緩存中找到共享的會話 ID 參數,那麼就能夠進 行簡短握手。不然,就要從新啓動一次全新的會話協商,生成新的會話 ID。簡短的 TLS 握手以下圖所示:
對於那些天天都要「接待」幾萬甚至幾百萬獨立鏈接的服務器來講,因爲每一個打開的 TLS 鏈接都要佔用內存,所以須要一套會話 ID 緩存和清除策略。
爲了解決上述服務器端部署 TLS 會話緩存的問題,「會話記錄單」 機制出現了。
該機制不用服務器保存每一個客戶端的會話狀態。只要客戶端代表其支持會話記錄單,則「服務器能夠在完整 TLS 握手的最後一次交換中添加一條「新會話記錄單」(New Session Ticket)記錄,包含只有服務器知道的安全密鑰加密過的全部會話數據」。
而後,客戶端將這個會話記錄單保存起來,在後續會話的 ClientHello 消息中,能夠將其包含在 SessionTicket 擴展中。這樣,全部會話數據只保存在客戶端,而因爲 數據被加密過,且密鑰只有服務器知道,所以仍然是安全的。
會話標識符和會話記錄單機制,即「會話緩存」或「無狀態恢復」機制。其優勢「主要是消除了服務器端的緩存負擔,經過要求客戶端在與服務器創建新鏈接時提供會話記錄單簡化了部署(除非記錄單過時)」。
「身份驗證即用本身的私鑰簽名,而後對方用本身的公鑰驗證收到的消息簽名」。但信任是交流的關鍵。
對於瀏覽器來講,它信任誰呢?
「至少有三個答案」:
最多見的方案,就是瀏覽器指定可信任的證書頒發機構(根 CA)。而 「證書頒發機構簽署數字證書的流程」 以下圖所示:
全部瀏覽器都容許用戶檢視本身安全鏈接的信任鏈,「常見的訪問入口就是地址欄頭兒上的鎖圖標」,點擊便可查看。以下圖所示:
「整個鏈條的「信任依據」是根證書頒發機構,而每一個瀏覽器都會內置一個可信任的證書頒發機構(根機構)的名單」。
通訊的任何一端均可以根據嵌入的指令和簽名檢查鏈條中每一個證書的狀態。
現實中,「CRL 和 OCSP 機制是互補存在的,大多數證書既提供指令也支持查詢」。
TLS 記錄協議負責 「識別不一樣的消息類型(握手、警告或數據,經過「內容類型」字段),以及每條消息的安全和完整性驗證」。TLS 記錄結構以下圖所示:
交付應用數據的典型流程以下:
以後,加密數據就會被交給 TCP 層傳輸。「接收端的流程」 相同,順序相反:「使用商定的加密套件解密數據、驗證 MAC、提取並把數據轉交給上層的應用」。
使用 CDN,在世界各地的服務器上緩存或重複部署數據和服務,而不須要讓全部用戶都經過跨海或跨大陸光纜鏈接到一箇中心原始服務器。
小記錄會形成浪費,大記錄會致使延遲。最優 TLS 記錄大小的參考值以下所示:
「默認狀況下,OpenSSL 等經常使用的庫會給每一個鏈接分配 50 KB 空間,而谷歌的服務器把 OpenSSL 緩衝區的大小減小到 了大約 5KB。所以,咱們須要在保障功能的前提下儘量使用最小的內存」。
❝瀏覽器怎麼知道到哪裏去找證書呢?
❞
由於 「子證書中一般包含父證書的 URL」。
咱們應該確保證書鏈的長度最小。「若是證書鏈長度超過了 TCP 的初始擁塞窗口,那咱們無心間就會讓握手多了一次往返:證書長度超過擁塞窗口,從而致使服務器停下來等待 客戶端的 ACK 消息」。
對此,有 「兩種解決方式」:
服務器能夠在證書鏈中包含(封套)證書頒發機構的 OCSP 響應,讓瀏覽器跳過在線查詢。把查詢 OCSP 操做轉移到服務器可讓服務器緩存簽名的 OCSP 響應,從而節省不少客戶端的請求。
「一種安全策略機制,讓服務器經過簡單的 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 恢復發送的會話標識符」。
C= BW × log2(1+S/N) 複製代碼
「它涵蓋了影響大多數無線網絡性能的全部基本因素」。
爲實現通訊,「發送端與接收端必須事先就通訊使用的頻率範圍達成共識」,在這個頻率範圍內雙方纔能夠順暢地交換信息。
影響性能的最主要因素就是頻率範圍的大小(帶寬)。由信道容量的公式可知,信道的整體比特率與分配的帶寬呈正比。
信噪比(SNR,Signal Noise Ratio),「它衡量的是預期信號強度與背景噪聲及干擾之間的比值」。背景噪聲越大,攜帶信息的信號就必須越強。
「若是想在存在干擾的狀況下達到預期的數據傳輸速度,要麼增大 發射功率,也就是提升信號強度,要麼縮短收發兩端的距離——或者左右開弓」。
「信號強度隨距離下降」。
接收端捕獲較強的信號,於是不可能檢測到較弱的信號,其實是「擠出」了較弱的信號。例如你旁邊一個或多個大聲講話的人會阻擋較弱的信號,從而產生遠近效應。
小區覆蓋範圍或信號傳輸距離基於噪聲大小和干擾級別擴展和收縮。例如你周圍交談的人越多,干擾就越嚴重,能讓你識別有用信號的範圍也越小,這就是呼吸效應。
「數字信號(1 和 0)須要轉換成模擬信號(無線電波)」。調製指的就 是這個數模轉換過程,而不一樣調製算法的轉換效率是不同的。
可是,「高階調製的代價是針對噪聲和干擾的可靠性下降」。所以,須要在它們與轉換效率直接作一個權衡。
Wi-Fi 能夠用來指稱任何基於 IEEE 802.11
標準的產品。它工做於免許可的 2.4 GHz ISM
頻段。
在 1971 年夏威夷大學對外公佈了第一個關於無線網絡的協議— ALOHAnet 協議。
以太網協議很大程度上借鑑了 ALOHAnet 協議,以太網一般被稱做局域網(LAN)標準,而 802.11 無線標準主要是做爲既有以太網標準(802.3)的擴展來設計的。所以它也相應地被稱做無線局域網(WLAN,Wireless LAN )標準。
若是檢測到衝突,則雙方都當即中止發送數據並小睡一段隨機的時間(後續時間以指數級增加),從而保證發生衝突 的發送端不會同步,且不會同時從新開始發送數據。
因爲收發無線電的硬件所限,它不能在發送數據期間檢測到衝突。所以,每一個發送方都會在本身認爲信道空閒時發送數據,以免衝突。
好比自適應比特流,來主動適應帶寬變化。自適應比特率並不適合全部資源,但對視頻和音頻這樣的長時間流服務是很是合適的。
在客戶端下載視頻流期間,客戶端或服務器能夠監控每一個視頻塊的下載速度,必要時根據帶寬的變化調整要下載的下一個視頻塊的比特率。事實上,現實中的視頻服務,「開始通常是低比特率的視頻塊,以便視頻播放能更快開始。而後,再根據可用帶寬的動態變化調整後續視頻塊的比特率」。
❝ ❞
❝歡迎關注個人微信:
❞bcce5360
❝微信羣若是不能掃碼加入,麻煩你們想進微信羣的朋友們,加我微信拉你進羣。
❞
❝2千人QQ羣,「Awesome-Android學習交流羣,QQ羣號:959936182」, 歡迎你們加入~
❞