HTTP總結(jié)

• 一：HTTP 基本概念

• 1、HTTP 是什么？2、什么是超文本傳輸協(xié)議？（1） 「超文本」（2） 「傳輸」（3） 「協(xié)議」

• 二：HTTP 常見的狀態(tài)碼，有哪些？http 常見字段有哪些？

• HTTP 常見的狀態(tài)碼（1）1xx（2）2xx（3）3xx（4）4xx（5）5xxhttp 常見字段（1）Host（2）Content-Length 字段（3）Connection 字段（4）Content-Type 字段（5）Content-Encoding 字段

• 三：HTTP 特性

• 1、 HTTP（1.1） 的優(yōu)點？（1）簡單（2）靈活和易于擴展（3）應(yīng)用廣泛和跨平臺2、HTTP（1.1） 的缺點?（1）無狀態(tài)（2）明文傳輸（3）不安全3、HTTP/1.1 的性能（1）長連接（2）管道網(wǎng)絡(luò)傳輸（3）隊頭阻塞

一：HTTP 基本概念

1、HTTP 是什么？

??HTTP 是超文本傳輸協(xié)議，也就是HyperText Transfer Protocol。

2、什么是超文本傳輸協(xié)議？

HTTP的名字「超文本協(xié)議傳輸」，它可以拆成三個部分：

• 超文本

• 傳輸

• 協(xié)議

（1） 「超文本」

??HTTP 傳輸?shù)膬?nèi)容是「超文本」。
??我們先來理解「文本」，在互聯(lián)網(wǎng)早期的時候只是簡單的字符文字，但現(xiàn)在「文本」的涵義已經(jīng)可以擴展為圖片、視頻、壓縮包等，在 HTTP 眼里這些都算做「文本」。
??再來理解「超文本」，它就是超越了普通文本的文本，它是文字、圖片、視頻等的混合體，最關(guān)鍵的是它有超鏈接，能從一個超文本跳轉(zhuǎn)到另外一個超文本。

?比如：HTML 就是最常見的超文本了，它本身只是純文字文件，但內(nèi)部用很多標(biāo)簽定義了圖片、視頻等的鏈接，在經(jīng)過瀏覽器的解釋，呈現(xiàn)給我們的就是一個文字、有畫面的網(wǎng)頁了。

（2） 「傳輸」

??所謂的「傳輸」，就是把一堆東西從 A 點搬到 B 點，或者從 B 點 搬到 A 點。
??HTTP 協(xié)議是一個無狀態(tài)，無連接的雙向協(xié)議。
舉個例子：
我們在上網(wǎng)沖浪時，瀏覽器是請求方 A ，百度網(wǎng)站就是應(yīng)答方 B。雙方約定用 HTTP 協(xié)議來通信，于是瀏覽器把請求數(shù)據(jù)發(fā)送給網(wǎng)站，網(wǎng)站再把一些數(shù)據(jù)返回給瀏覽器，最后由瀏覽器渲染在屏幕，就可以看到圖片、視頻了。

??數(shù)據(jù)雖然是在 A 和 B 之間傳輸，但允許中間有中轉(zhuǎn)或接力。只要中間人遵從 HTTP 協(xié)議，并且不打擾基本的數(shù)據(jù)傳輸，就可以添加任意額外的東西。

（3） 「協(xié)議」

針對 HTTP 協(xié)議，我們可以這么理解:
??HTTP 是一個用在計算機世界里的協(xié)議。它使用計算機能夠理解的語言確立了一種計算機之間交流通信的規(guī)范（兩個以上的參與者），以及相關(guān)的各種控制和錯誤處理方式（行為約定和規(guī)范）。

綜上所述，我們可以說：
??HTTP 是一個在計算機世界里專門在 兩點 之間 傳輸 文字、圖片、音頻、視頻等 超文本 數(shù)據(jù)的 約定和規(guī)范。

注意：我們所說的兩點之間，包括服務(wù)器與服務(wù)器之間，還包括服務(wù)器與客戶端之間。

二：HTTP 常見的狀態(tài)碼，有哪些？http 常見字段有哪些？

HTTP 常見的狀態(tài)碼

（1）1xx

?1xx?類狀態(tài)碼屬于提示信息，是協(xié)議處理中的一種中間狀態(tài)，實際用到的比較少。

（2）2xx

?2xx?類狀態(tài)碼表示服務(wù)器成功處理了客戶端的請求，也是身為程序員最愿意看到的狀態(tài)。

狀態(tài)碼	狀態(tài)詳情
「200 OK」	是最常見的成功狀態(tài)碼，表示一切正常。如果是非 HEAD 請求，服務(wù)器返回的響應(yīng)頭都會有 body 數(shù)據(jù)。
「204 No Content」	也是常見的成功狀態(tài)碼，與 200 OK 基本相同，但響應(yīng)頭沒有 body 數(shù)據(jù)。
「206 Partial Content」	是應(yīng)用于 HTTP 分塊下載或斷電續(xù)傳，表示響應(yīng)返回的 body 數(shù)據(jù)并不是資源的全部，而是其中的一部分，也是服務(wù)器處理成功的狀態(tài)。

（3）3xx

?3xx?類狀態(tài)碼表示客戶端請求的資源發(fā)送了變動，需要客戶端用新的 URL 重新發(fā)送請求獲取資源，也就是重定向。

狀態(tài)碼	狀態(tài)詳情
「301 Permanently Moved」	表示永久重定向，說明請求的資源已經(jīng)不存在了，需改用新的 URL 再次訪問。
「302 Found 」	表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。
「304 Not Modified」	不具有跳轉(zhuǎn)的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，用于緩存控制。

（4）4xx

?4xx?類狀態(tài)碼表示客戶端發(fā)送的報文有誤，服務(wù)器無法處理，也就是錯誤碼的含義。

狀態(tài)碼	狀態(tài)詳情
「400 Bad Request」	表示客戶端請求的報文有錯誤，但只是個籠統(tǒng)的錯誤。
「403 Forbidden」	表示服務(wù)器禁止訪問資源，并不是客戶端的請求出錯。
「404 Not Found」	表示請求的資源在服務(wù)器上不存在或未找到，所以無法提供給客戶端。

（5）5xx

?5xx?類狀態(tài)碼表示客戶端請求報文正確，但是服務(wù)器處理時內(nèi)部發(fā)生了錯誤，屬于服務(wù)器端的錯誤碼。

狀態(tài)碼	狀態(tài)詳情
「500 Internal Server Error」	與 400 類型，是個籠統(tǒng)通用的錯誤碼，服務(wù)器發(fā)生了什么錯誤，我們并不知道。
「501 Not Implemented」	表示客戶端請求的功能還不支持，類似“即將開業(yè)，敬請期待”的意思。
「502 Bad Gateway」	通常是服務(wù)器作為網(wǎng)關(guān)或代理時返回的錯誤碼，表示服務(wù)器自身工作正常，訪問后端服務(wù)器發(fā)生了錯誤。
「503 Service Unavailable」	表示服務(wù)器當(dāng)前很忙，暫時無法響應(yīng)服務(wù)器，類似“網(wǎng)絡(luò)服務(wù)正忙，請稍后重試”的意思。

http 常見字段

（1）Host

??客戶端發(fā)送請求時，用來指定服務(wù)器的域名。

Host: www.A.com
有了 Host 字段，就可以將請求發(fā)往「同一臺」服務(wù)器上的不同網(wǎng)站

（2）Content-Length 字段

??服務(wù)器在返回數(shù)據(jù)時，會有 Content-Length字段，表明本次回應(yīng)的數(shù)據(jù)長度。

如上面則是告訴瀏覽器，本次服務(wù)器回應(yīng)的數(shù)據(jù)長度是 1000 個字節(jié)，后面的字節(jié)就屬于下一個回應(yīng)了。

（3）Connection 字段

??Connection字段最常用于客戶端要求服務(wù)器使用 TCP 持久連接，以便其他請求復(fù)用。

一個可以復(fù)用的 TCP 連接就建立了，直到客戶端或服務(wù)器主動關(guān)閉連接。但是，這不是標(biāo)準(zhǔn)字段。

（4）Content-Type 字段

??Content-Type字段用于服務(wù)器回應(yīng)時，告訴客戶端，本次數(shù)據(jù)是什么格式。

上面的類型表明，發(fā)送的是網(wǎng)頁，而且編碼是UTF-8。
客戶端請求的時候，可以使用Accept字段聲明自己可以接受哪些數(shù)據(jù)格式。上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)。

（5）Content-Encoding 字段

??Content-Encoding字段說明數(shù)據(jù)的壓縮方法。表示服務(wù)器返回的數(shù)據(jù)使用了什么壓縮格式

上面表示服務(wù)器返回的數(shù)據(jù)采用了gzip方式壓縮，告知客戶端需要用此方式解壓。

客戶端在請求時，用Accept-Encoding字段說明自己可以接受哪些壓縮方法。

三：HTTP 特性

1、 HTTP（1.1） 的優(yōu)點？

??HTTP 最凸出的優(yōu)點是「簡單、靈活和易于擴展、應(yīng)用廣泛和跨平臺」。

（1）簡單

??HTTP 基本的報文格式就是 header + body，頭部信息也是 key-value簡單文本的形式，易于理解，降低了學(xué)習(xí)和使用的門檻。

（2）靈活和易于擴展

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

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

??HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層，HTTP/3 甚至把 TCPP 層換成了基于 UDP 的 QUIC。

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

??互聯(lián)網(wǎng)發(fā)展至今，HTTP 的應(yīng)用范圍非常的廣泛，從臺式機的瀏覽器到手機上的各種 APP，從看新聞、刷貼吧到購物、理財、吃雞，HTTP 的應(yīng)用片地開花，同時天然具有跨平臺的優(yōu)越性。

2、HTTP（1.1） 的缺點?

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

（1）無狀態(tài)

??無狀態(tài)的好處，因為服務(wù)器不會去記憶 HTTP 的狀態(tài)，所以不需要額外的資源來記錄狀態(tài)信息，這能減輕服務(wù)器的負擔(dān)，能夠把更多的 CPU 和內(nèi)存用來對外提供服務(wù)。

??無狀態(tài)的壞處，既然服務(wù)器沒有記憶能力，它在完成有關(guān)聯(lián)性的操作時會非常麻煩。

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

??這樣每操作一次，都要驗證信息，這樣的購物體驗還能愉快嗎？
對于無狀態(tài)的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術(shù)。Cookie 通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)。
相當(dāng)于，在客戶端第一次請求后，服務(wù)器會下發(fā)一個裝有客戶信息的「小貼紙」，后續(xù)客戶端請求服務(wù)器的時候，帶上「小貼紙」，服務(wù)器就能認得了。

（2）明文傳輸

??明文意味著在傳輸過程中的信息，是可方便閱讀的，通過瀏覽器的 F12 控制臺或 Wireshark 抓包都可以直接肉眼查看，為我們調(diào)試工作帶了極大的便利性。

??但是這正是這樣，HTTP 的所有信息都暴露在了光天化日下，相當(dāng)于信息裸奔。在傳輸?shù)穆L的過程中，信息的內(nèi)容都毫無隱私可言，很容易就能被竊取，如果里面有你的賬號密碼信息，那你號沒了。

（3）不安全

??HTTP 比較嚴(yán)重的缺點就是不安全：

• 通信使用明文（不加密），內(nèi)容可能會被竊聽。比如，賬號信息容易泄漏，那你號沒了。

• 不驗證通信方的身份，因此有可能遭遇偽裝。比如，訪問假的淘寶、拼多多，那你錢沒了。

• 無法證明報文的完整性，所以有可能已遭篡改。比如，網(wǎng)頁上植入垃圾廣告，視覺污染，眼沒了。

HTTP 的安全問題，可以用 HTTPS 的方式解決，也就是通過引入 SSL/TLS 層，使得在安全上達到了極致。

3、HTTP/1.1 的性能

（1）長連接

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

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

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

（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 請求。管道機制則是允許瀏覽器同時發(fā)出 A 請求和 B 請求。
??但是服務(wù)器還是按照順序，先回應(yīng) A 請求，完成后再回應(yīng) B 請求。要是 前面的回應(yīng)特別慢，后面就會有許多請求排隊等著。這稱為「隊頭堵塞」。

（3）隊頭阻塞

??「請求 - 應(yīng)答」的模式加劇了 HTTP 的性能問題。

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

本文就是愿天堂沒有BUG給大家分享的內(nèi)容，大家有收獲的話可以分享下，想學(xué)習(xí)更多的話可以到微信公眾號里找我，我等你哦。