這篇文章將為大家詳細(xì)講解有關(guān)http1.1相對http2有什么缺點(diǎn)，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

在仁壽等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需開發(fā)網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),成都營銷網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站建設(shè),仁壽網(wǎng)站建設(shè)費(fèi)用合理。

服務(wù)器搭建完成之后，我們在public文件夾新建一個(gè)頁面，這個(gè)頁面中的資源主要由圖片、css、js構(gòu)成，代碼如下:

觀察html部分我們發(fā)現(xiàn)，頁面設(shè)置了許多img標(biāo)簽，此時(shí)我們訪問這個(gè)頁面，觀察瀏覽器的network，截圖如下：

仔細(xì)觀察其規(guī)律，瀏覽器請求圖片資源時(shí)，最大并發(fā)數(shù)為6，這里要解釋一下，瀏覽器針對同一個(gè)域名的網(wǎng)站最大的tcp鏈接數(shù)是根據(jù)瀏覽器規(guī)定的，谷歌瀏覽器默認(rèn)的針對同一個(gè)域名的最大tcp鏈接數(shù)是6，這樣的話頁面中所有的圖片資源，必須通過這6個(gè)tcp長連接來完成請求響應(yīng)。

這里有一個(gè)比較形象的比喻，假如有一百個(gè)人要往返跨過一條河，河面上有6座橋，每座橋每次只能有一個(gè)人通過，那么同一時(shí)刻最多只能6個(gè)人同時(shí)過河，不能再多了，http1.1協(xié)議下的請求響應(yīng)就是基于這個(gè)模型的。

在這里引入一個(gè)名詞RTT：RTT(Round-Trip Time): 往返時(shí)延。在計(jì)算機(jī)網(wǎng)絡(luò)中它是一個(gè)重要的性能指標(biāo)，表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認(rèn)（接收端收到數(shù)據(jù)后便立即發(fā)送確認(rèn)），總共經(jīng)歷的時(shí)延。

一個(gè)http請求響應(yīng)最少要經(jīng)歷一個(gè)RTT，如果這個(gè)請求或者響應(yīng)攜帶的數(shù)據(jù)量比較大，那么可能會(huì)需要經(jīng)歷多次傳輸，也就是需要經(jīng)歷多個(gè)RTT，我們這里簡單計(jì)算，假設(shè)一個(gè)http請求只需要一個(gè)RTT，一個(gè)RTT所用時(shí)間為n秒。

如果在一個(gè)頁面中只一個(gè)TCP長連接，現(xiàn)在100個(gè)資源所用時(shí)間為100*RTT*n，如果用6個(gè)TCP鏈接，那么時(shí)間縮短為100*RTT*n/6。

在http1.1協(xié)議下，針對瀏覽器對每個(gè)域名最大并發(fā)數(shù)的限制，我們可以利用域名分片的技術(shù)來進(jìn)一步縮短時(shí)間，什么叫域名分片呢，給同一個(gè)網(wǎng)站設(shè)置多個(gè)域名，比如a.com和b.com都指向同一個(gè)網(wǎng)站，這樣瀏覽器對同一個(gè)網(wǎng)站的最大并發(fā)數(shù)就會(huì)隨著域名的增加而增加，時(shí)間進(jìn)一步縮短為：100*RTT*n/(6*域名個(gè)數(shù))。

但是，隨著域名增多也會(huì)出現(xiàn)一些問題：

1、服務(wù)器壓力增大。

2、瀏覽器解析域名也會(huì)花費(fèi)時(shí)間，域名越多花費(fèi)時(shí)間也越多。

上文關(guān)注的的技巧主要是利用瀏覽器的特性突破了其最大并發(fā)數(shù)，但是這樣做治標(biāo)不治本。

TCP本身存在一些問題，如慢啟動(dòng)，當(dāng)網(wǎng)速發(fā)生變化時(shí)，TCP的速度也會(huì)隨之波動(dòng)，速度同樣受影響。

TCP本身存在競爭關(guān)系，多個(gè)tcp同時(shí)連接會(huì)互相搶占網(wǎng)速。最重要的一點(diǎn)是：基于http1.1的tcp長連接有隊(duì)頭阻塞的現(xiàn)象，如果你不明白什么是http1.1的隊(duì)頭阻塞，歡迎閱讀這篇文章：白話http隊(duì)頭阻塞。

聊完http1.1協(xié)議下瀏覽器TCP連接的特性，咱們來思考一個(gè)問題：頁面解析過程中最先需要加載的是什么文件呢？ 

當(dāng)然是CSS文件和js文件，但是大家思考一下css文件和js文件是什么時(shí)候加載的，是在html文件這個(gè)響應(yīng)完成之后，瀏覽器快速掃描頁面中的關(guān)鍵資源，而后下載js和css。這中間就可能出現(xiàn)一個(gè)空閑時(shí)間，這個(gè)空閑時(shí)間有兩種可能，html中標(biāo)簽太多，解析比較費(fèi)勁，雖然css下載完成但是依然需要等待DOM解析完成，另外一種是DOM解析完成CSS卻沒有下載完成，依然需要等待，這里無論我們怎么做，兩者基本不會(huì)同步，我們應(yīng)該如何做呢？在http1.1版本下我們能做的就是盡量縮短關(guān)鍵資源的加載，不管是html、css還是js。

在http1.1協(xié)議下，我們可以通過如下幾種方案來做：

1、壓縮代碼，去掉注釋

2、對不依賴dom的js文件合理應(yīng)用async和defer避免dom解析的阻塞

3、對css應(yīng)用媒體查詢，對某些特定場景的css避免加載。

4、合理調(diào)整文件的個(gè)數(shù)和大小，這里不能一味的合并所有css或者js，如果某個(gè)css或者js體積過大，同樣影響效率，只能不斷的調(diào)整測試。本質(zhì)就是減少資源加載花費(fèi)的RTT，并且不要超過瀏覽器對同一域名最大的并發(fā)數(shù)。

5、合理利用cdn。

6、應(yīng)用域名分片技術(shù)。

以上便是今天文章的內(nèi)容，總結(jié)一下：

1、在http1.1版本中我們可以針對瀏覽器對同一個(gè)域名支持的最大TCP鏈接數(shù)這個(gè)特性，使用域名分片技術(shù)來加快資源下載，但是這樣會(huì)也會(huì)隨之帶來一些問題，服務(wù)器壓力增大，瀏覽器解析域名花費(fèi)時(shí)間增多，看似并沒有很好的解決我們的問題。

2、http1.1中的TCP長連接存在隊(duì)頭阻塞的問題，針對同一個(gè)tcp鏈接中的每一http請求必須響應(yīng)之后后面的http才能繼續(xù)。

3、TCP本身的一些不好的特性，慢啟動(dòng)，多條TCP鏈接競爭網(wǎng)速。

針對這些問題我們給出了一下解決方案，但是終歸不是太優(yōu)雅，隨著互聯(lián)網(wǎng)的高速發(fā)展http1.1似乎越來越不能滿足當(dāng)下用戶的需求了，http2在這眾望所歸的時(shí)刻到來了，下篇文章帶領(lǐng)大家利用http2來改善http1.1的這些不足。

最后提兩個(gè)問題，在http1.1版本中我們能實(shí)現(xiàn)如下需求嗎？

1、假如頁面中要加載多個(gè)資源，有的資源比較重要，我們想要使其優(yōu)先加載，應(yīng)該怎么做呢？

2、當(dāng)我們請求某個(gè)網(wǎng)址的時(shí)候，服務(wù)器能不能提前將頁面需要的重要資源推送過來，而不是等待瀏覽器掃描html后再去加載？

3、既然多個(gè)TCP鏈接存在競爭關(guān)系，我們能不能讓瀏覽器將針對同一個(gè)域名的所有http請求都基于同一個(gè)tcp鏈接呢？這樣既減少了競爭，也減少了tcp鏈接的耗時(shí)操作。

關(guān)于“http1.1相對http2有什么缺點(diǎn)”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，請把它分享出去讓更多的人看到。