HTTP/1.1 的優(yōu)點(diǎn)有哪些？

「簡單、靈活和易于擴(kuò)展、應(yīng)用廣泛和跨平臺」

1. 簡單

HTTP 基本的報(bào)文格式就是?header + body，頭部信息也是?key-value?簡單文本的形式，易于理解。

2. 靈活和易于擴(kuò)展

HTTP 協(xié)議里的各類請求方法、URI/URL、狀態(tài)碼、頭字段等每個組成要求都沒有被固定死，都允許開發(fā)人員自定義和擴(kuò)充。

同時 HTTP 由于是工作在應(yīng)用層（?OSI?第七層），則它下層可以隨意變化，比如：

• HTTPS 就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層；
• HTTP/1.1 和 HTTP/2.0 傳輸協(xié)議使用的是 TCP 協(xié)議，而到了 HTTP/3.0 傳輸協(xié)議改用了 UDP 協(xié)議。

3. 應(yīng)用廣泛和跨平臺

HTTP/1.1 的缺點(diǎn)有哪些？

HTTP 協(xié)議里有優(yōu)缺點(diǎn)一體的雙刃劍，分別是「無狀態(tài)、明文傳輸」，同時還有一大缺點(diǎn)「不安全」。

1. 無狀態(tài)雙刃劍

無狀態(tài)的好處，因?yàn)榉?wù)器不會去記憶 HTTP 的狀態(tài)，所以不需要額外的資源來記錄狀態(tài)信息，這能減輕服務(wù)器的負(fù)擔(dān)。

無狀態(tài)的壞處，沒有記憶能力，那么在完成有關(guān)聯(lián)性的操作時會非常麻煩。

例如登錄->添加購物車->下單->結(jié)算->支付，這系列操作都要知道用戶的身份才行。但服務(wù)器不知道這些請求是有關(guān)聯(lián)的，每次都要問一遍身份信息。

通常使用?Cookie?技術(shù)來解決無狀態(tài)問題。

Cookie?通過在請求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。

相當(dāng)于，在客戶端第一次請求后，服務(wù)器會下發(fā)一個裝有客戶信息的「小貼紙」，后續(xù)客戶端請求服務(wù)器的時候，帶上「小貼紙」，服務(wù)器就能認(rèn)得了

2. 明文傳輸雙刃劍

明文傳輸雖然易于閱讀，但也增加了信息泄露的風(fēng)險(xiǎn)。

HTTP/1.1 的性能如何？

HTTP 協(xié)議是基于?TCP/IP，并且使用了「請求 - 應(yīng)答」的通信模式，所以性能的關(guān)鍵就在這兩點(diǎn)里。

1. 長連接

早期 HTTP/1.0 性能上的一個很大的問題，那就是每發(fā)起一個請求，都要新建一次 TCP 連接（三次握手），而且是串行請求，做了無謂的 TCP 連接建立和斷開，增加了通信開銷。

HTTP/1.1 提出了長連接的通信方式，也叫持久連接。這種方式減少了 TCP 連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器端的負(fù)載。

持久連接的特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。

如果某個 HTTP 長連接超過一定時間沒有任何數(shù)據(jù)交互，服務(wù)端就會主動斷開這個連接。

2. 管道網(wǎng)絡(luò)傳輸

HTTP/1.1 采用了長連接的方式，這使得管道（pipeline）網(wǎng)絡(luò)傳輸成為了可能。

即可在同一個 TCP 連接里面，客戶端可以發(fā)起多個請求，只要第一個請求發(fā)出去了，不必等其回來，就可以發(fā)第二個請求出去，可以減少整體的響應(yīng)時間。

舉例來說，客戶端需要請求兩個資源。以前的做法是，在同一個 TCP 連接里面，先發(fā)送 A 請求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出 B 請求。那么，管道機(jī)制則是允許瀏覽器同時發(fā)出 A 請求和 B 請求，如下圖：

但是服務(wù)器必須按照接收請求的順序發(fā)送對這些管道化請求的響應(yīng)。

如果服務(wù)端在處理 A 請求時耗時比較長，那么后續(xù)的請求的處理都會被阻塞住，這稱為「隊(duì)頭堵塞」。

所以，HTTP/1.1 管道解決了請求的隊(duì)頭阻塞，但是沒有解決響應(yīng)的隊(duì)頭阻塞。

注意：

實(shí)際上 HTTP/1.1 管道化技術(shù)不是默認(rèn)開啟，而且瀏覽器基本都沒有支持，知道有這個功能，但是沒有被使用就行了。

3. 隊(duì)頭阻塞

「請求 - 應(yīng)答」的模式會造成 HTTP 的性能問題。

當(dāng)順序發(fā)送的請求序列中的一個請求因?yàn)槟撤N原因被阻塞時，在后面排隊(duì)的所有請求也一同被阻塞了，會招致客戶端一直請求不到數(shù)據(jù)，這就是「隊(duì)頭阻塞」，好比上班的路上塞車。

總之 HTTP/1.1 的性能一般，后續(xù)的 HTTP/2 和 HTTP/3 就是在優(yōu)化 HTTP 的性能。

HTTP/1.1采用了長連接來提高性能，只要客戶端和服務(wù)器端沒有一方主動斷開連接，就會在一定時間內(nèi)保持連接，從而避免了多次連接和斷開產(chǎn)生的開銷，長連接使得管道網(wǎng)絡(luò)傳輸成為可能，之前的情況是必須等第一個請求得到響應(yīng)時才能發(fā)送第二個請求，如果使用管道網(wǎng)絡(luò)傳輸，那么就可以在發(fā)送的第一個請求沒有得到響應(yīng)時就發(fā)送第二個請求，但是服務(wù)器必須按照接收請求的順序發(fā)送對這些管道化請求的響應(yīng)，如果服務(wù)端在處理某一個請求時耗時比較長，那么后續(xù)的請求的處理都會被阻塞住，這稱為「隊(duì)頭堵塞」，就和堵車一樣，會導(dǎo)致客戶端一直請求不到數(shù)據(jù)。

所以，HTTP/1.1 管道解決了請求的隊(duì)頭阻塞，但是沒有解決響應(yīng)的隊(duì)頭阻塞，不過管道網(wǎng)絡(luò)傳輸默認(rèn)關(guān)閉，且大多數(shù)瀏覽器沒有支持，知道就行。文章來源地址http://www.zghlxwxcb.cn/news/detail-860986.html

到了這里，關(guān)于HTTP/1.1 特性（計(jì)算機(jī)網(wǎng)絡(luò)）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！