傳輸鏈路
鏈路指無(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ù)穆窂健T谟?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)或許不再使用,比如
- 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. … …
- 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ī)的不同域名上。 - GZip Components,啟用壓縮傳輸
啟用壓縮傳輸能夠大幅減少需要在網(wǎng)絡(luò)上傳輸?shù)膬?nèi)容大小,節(jié)省流量。 - Avoid Redirects,避免頁(yè)面重定向
當(dāng)頁(yè)面發(fā)生重定向,就會(huì)延遲整個(gè)文檔的傳輸。 - Put Stylesheets at the Top, Put Scripts at the Bottom,按重要性調(diào)節(jié)資源優(yōu)先級(jí)
將重要的資源放在HTML的頭部,以便優(yōu)先下載。 - … …
連接數(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)。文章來(lái)源:http://www.zghlxwxcb.cn/news/detail-568124.html
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)!