傳輸鏈路

鏈路指無(wú)源的點(diǎn)到點(diǎn)的物理連接。鏈路是計(jì)算機(jī)網(wǎng)絡(luò)中的一個(gè)重要概念，它指的是連接兩個(gè)網(wǎng)絡(luò)設(shè)備的物理或邏輯路徑。簡(jiǎn)單來(lái)說(shuō)，鏈路就是電信號(hào)或數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)穆窂健Ｔ谟?jì)算機(jī)網(wǎng)絡(luò)中，鏈路可以分為物理鏈路和邏輯鏈路兩種。物理鏈路是指連接兩個(gè)網(wǎng)絡(luò)設(shè)備的物理媒介，例如網(wǎng)線、光纖等。邏輯鏈路則是指通過(guò)網(wǎng)絡(luò)協(xié)議建立的邏輯連接，例如TCP/IP協(xié)議中的連接。

鏈路是計(jì)算機(jī)網(wǎng)絡(luò)中非常重要的概念，它負(fù)責(zé)連接網(wǎng)絡(luò)設(shè)備并保證數(shù)據(jù)的可靠傳輸。

前端優(yōu)化

以?xún)?yōu)化鏈路傳輸為目的的前端設(shè)計(jì)原則未來(lái)或許不再使用，比如

1. Minimize HTTP Requests，減少請(qǐng)求數(shù)量
   減少請(qǐng)求數(shù)量的手段有：

• a.雪碧圖（CSS Sprites）
• b.CSS、JS文件合并/內(nèi)聯(lián)（Concatenation/Inline）
• c.分段文檔（Multipart Document）
• d.媒體（圖片、音頻）內(nèi)聯(lián)（Data Base64 URI）
• e.合并Ajax請(qǐng)求（Batch Ajax Request）
• f. … …

2. Split Components Across Domains，擴(kuò)大并發(fā)請(qǐng)求數(shù)
   現(xiàn)代瀏覽器（Chrome、Firefox）一般可以為每個(gè)域名支持6個(gè)（IE為8～13個(gè)）并發(fā)請(qǐng)求。如果想要更快地加載大量圖片或其他資源，就需要進(jìn)行域名分片（Domain Sharding），將圖片同步到不同主機(jī)或者同一個(gè)主機(jī)的不同域名上。
3. GZip Components，啟用壓縮傳輸
   啟用壓縮傳輸能夠大幅減少需要在網(wǎng)絡(luò)上傳輸?shù)膬?nèi)容大小，節(jié)省流量。
4. Avoid Redirects，避免頁(yè)面重定向
   當(dāng)頁(yè)面發(fā)生重定向，就會(huì)延遲整個(gè)文檔的傳輸。
5. Put Stylesheets at the Top, Put Scripts at the Bottom，按重要性調(diào)節(jié)資源優(yōu)先級(jí)
   將重要的資源放在HTML的頭部，以便優(yōu)先下載。
6. … …

連接數(shù)優(yōu)化

HTTP是以TCP為傳輸層的應(yīng)用層協(xié)議，但HTTP over TCP這種搭配，只能說(shuō)是TCP目前在互聯(lián)網(wǎng)的統(tǒng)治地位所造就的結(jié)果，而不能說(shuō)它們兩者配合工作就是合適的。

• 一方面，HTTP傳輸對(duì)象（HTML、JS、CSS、圖片等）的主要特征是數(shù)量多、時(shí)間短、資源小、切換快。
• 另一方面，TCP協(xié)議要求三次握手完成后才能開(kāi)始數(shù)據(jù)傳輸，TCP還有慢啟動(dòng)特性，導(dǎo)致通信建立連接時(shí)傳輸速率最低，后面逐步加速穩(wěn)定。

由于TCP協(xié)議本身是面向長(zhǎng)時(shí)間、大數(shù)據(jù)傳輸來(lái)設(shè)計(jì)的，所以只有在一段較長(zhǎng)的時(shí)間尺度內(nèi)，TCP協(xié)議才能展現(xiàn)出穩(wěn)定性和可靠性的優(yōu)勢(shì)，不會(huì)因?yàn)榻⑦B接的成本太高，成為了使用瓶頸。

開(kāi)發(fā)Tricks的使用困境

為緩解HTTP與TCP之間的矛盾，程序猿們一方面致力于減少發(fā)出的請(qǐng)求數(shù)量，另一方面致力于增加客戶(hù)端到服務(wù)端的連接數(shù)量。即前面提到的Minimize HTTP Requests和Split Components Across Domains兩條優(yōu)化措施的根本依據(jù)。

HTTP Archive對(duì)近2016～2020年數(shù)百萬(wàn)個(gè)URL地址進(jìn)行了采樣，得出一個(gè)結(jié)論：頁(yè)面平均請(qǐng)求沒(méi)有改變的情況下（桌面端下降3.8%，移動(dòng)端上升1.4%），TCP連接正在持續(xù)且幅度較大地下降（桌面端下降36.4%，移動(dòng)端下降28.6%），如下圖

開(kāi)發(fā)Tricks可以節(jié)省TCP連接外，也會(huì)帶來(lái)不少副作用。比如，

• CSS Sprites合并多張圖片后，只要使用其中一張小圖片，也必須加載整個(gè)大圖片；如果某張小圖片需要修改，會(huì)導(dǎo)致整個(gè)大圖的緩存失效；樣式、腳本等文件的合并同理；
• 媒體內(nèi)嵌時(shí)，除了要承受Base64編碼導(dǎo)致的傳輸容量膨脹1/3的代價(jià)以外，也會(huì)無(wú)法有效利用緩存；
• 合并異步請(qǐng)求后，導(dǎo)致所有請(qǐng)求的返回時(shí)間，都要受最慢請(qǐng)求的拖累，頁(yè)面整體響應(yīng)速度下降；
• 圖片放到不同子域下面，將會(huì)導(dǎo)致更大的DNS解析負(fù)擔(dān)；

連接復(fù)用技術(shù)的優(yōu)勢(shì)和缺陷

HTTP連接復(fù)用技術(shù)，也即持久連接（Persistent Connection），或者叫連接Keep-Alive機(jī)制。它的原理是，讓客戶(hù)端對(duì)同一個(gè)域名長(zhǎng)期持有一個(gè)或多個(gè)不會(huì)用完即斷的TCP連接，典型做法是在客戶(hù)端維護(hù)一個(gè)FIFO隊(duì)列，每次取完數(shù)據(jù)之后的一段時(shí)間內(nèi)，不自動(dòng)斷開(kāi)連接，以便獲取下一個(gè)資源時(shí)可以直接服用，避免創(chuàng)建TCP連接的成本。
但是，連接復(fù)用技術(shù)最明顯的副作用就是“隊(duì)首阻塞”（Head-of-Line Blocking）問(wèn)題。

解決方案：HTTP/2的多路復(fù)用技術(shù)
HTTP/1.x中，HTTP請(qǐng)求就是傳輸過(guò)程中最小粒度的信息單位，難以重組出有效信息；
HTTP/2中，幀（Frame）才是最小粒度的信息單位，它可以用來(lái)描述各種數(shù)據(jù)，比如請(qǐng)求的Headers、Body，或者用來(lái)做控制標(biāo)識(shí)（打開(kāi)流、關(guān)閉流）。
其中流（Stream），是一個(gè)邏輯上的數(shù)據(jù)通道概念，每個(gè)幀都附帶有一個(gè)流ID，以標(biāo)識(shí)這個(gè)幀數(shù)語(yǔ)哪個(gè)流。

與HTTP/1.x相反，HTTP/2本身反而變得更適合傳輸小資源，比如傳輸1000張10K的小圖，HTTP/2要比HTTP/1.x快，但傳輸10張1000K的大圖，則應(yīng)該HTTP/1.x會(huì)更快。

傳輸壓縮

HTTP很早就支持了GZip壓縮，因?yàn)镠TTP傳輸?shù)闹饕獌?nèi)容，比如HTML、CSS、Script等，主要是本文數(shù)據(jù)，因此對(duì)于文本數(shù)據(jù)啟用壓縮的收益是非常高的，傳輸數(shù)據(jù)量一般會(huì)降至原有的20%左右。而對(duì)于不適合壓縮的資源，Web服務(wù)器則能根據(jù)MIME（Multipurpose Internet Mail Extensions）類(lèi)型，來(lái)自動(dòng)判斷是否對(duì)響應(yīng)進(jìn)行壓縮。
幾種壓縮方式：

• 靜態(tài)預(yù)壓縮（Static Precompression）：把靜態(tài)資源預(yù)先壓縮為.gz文件的形式存放起來(lái)；
• 即時(shí)壓縮（On-The-Fly Compression）：在內(nèi)存的數(shù)據(jù)流中完成；

持久連接機(jī)制不再依靠TCP連接是否關(guān)閉，來(lái)判斷資源請(qǐng)求是否結(jié)束了。它會(huì)重用同一個(gè)連接，以便向同一個(gè)域名請(qǐng)求多個(gè)資源。
這個(gè)機(jī)制最初（HTTP/1.0）就是根據(jù)Content-Length判斷傳輸資源是否已經(jīng)結(jié)束。但啟動(dòng)即時(shí)壓縮后就無(wú)法給出Content-Length。依靠Content-Length來(lái)判斷傳輸結(jié)束是有缺陷的。HTTP1.1版本修復(fù)了缺陷，增加了另一種“分塊傳輸編碼”（Chunked Transfer Encoding）的資源結(jié)束判斷機(jī)制，徹底解決了Content-Length與持久連接的沖突問(wèn)題。

快速UDP網(wǎng)絡(luò)連接

要想從根本上改進(jìn)HTTP，就必須直接替換掉HTTP over TCP的根基。使用UDP協(xié)議替換TCP傳輸協(xié)議就是一種思路，2013年，Google在它的服務(wù)器（Google.com、YouTube.com等）啟用了名為快速UDP網(wǎng)絡(luò)連接（Quick UDP Internet Connections,QUIC）的傳輸協(xié)議。2018年末，IETF正式批準(zhǔn)了HTTP over QUIC使用HTTP/3的版本號(hào)，確立為最新一代的互聯(lián)網(wǎng)標(biāo)準(zhǔn)。

QUIC自己實(shí)現(xiàn)的好處是能對(duì)每個(gè)流能做單獨(dú)的控制，如果其中一個(gè)流發(fā)生錯(cuò)誤，協(xié)議棧仍然可以獨(dú)立地繼續(xù)為其他流提供服務(wù)。
QUIC的另一個(gè)設(shè)計(jì)目標(biāo)是面向移動(dòng)設(shè)備的專(zhuān)門(mén)支持，在移動(dòng)設(shè)備上的主要優(yōu)勢(shì)體現(xiàn)在網(wǎng)絡(luò)切換的響應(yīng)速度上，QUIC提出了連接標(biāo)識(shí)符的概念，可以唯一標(biāo)識(shí)客戶(hù)端與服務(wù)器端之間的連接，而無(wú)需依靠IP地址。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-568124.html

到了這里，關(guān)于分布式軟件架構(gòu)——傳輸鏈路的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！