計算機網路-HTTP篇

HTTP的一些問題

HTTP 基本概念

HTTP 是超⽂本傳輸協議，也就是HyperText Transfer Protocol。

HTTP 是⼀個在計算機世界⾥專⻔在「兩點」之間「傳輸」⽂字、圖⽚、⾳頻、視訊等「超⽂本」資料的「約定和規範」。

常見狀態碼

1xx

1xx 類狀態碼屬於提示資訊，是協議處理中的⼀種中間狀態，實際⽤到的⽐較少。

2xx

2xx 類狀態碼錶示伺服器成功處理了客戶端的請求，也是我們最願意看到的狀態。

「200 OK」是最常⻅的成功狀態碼，表示⼀切正常。如果是⾮ HEAD 請求，伺服器返回的響應頭都會有 body資料。

「204 No Content」也是常⻅的成功狀態碼，與 200 OK 基本相同，但響應頭沒有 body 資料。

「206 Partial Content」是應⽤於 HTTP 分塊下載或斷點續傳，表示響應返回的 body 資料並不是資源的全部，⽽是其中的⼀部分，也是伺服器處理成功的狀態。

3xx

3xx 類狀態碼錶示客戶端請求的資源傳送了變動，需要客戶端⽤新的 URL 重新發送請求獲取資源，也就是重定向。

「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改⽤新的 URL 再次訪問。

「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要⽤另⼀個 URL 來訪問。

301 和 302 都會在響應頭⾥使⽤欄位 Location ，指明後續要跳轉的 URL，瀏覽器會⾃動重定向新的 URL。

「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩衝⽂件，也稱快取重定向，⽤於快取控制。

4xx

4xx 類狀態碼錶示客戶端傳送的報⽂有誤，伺服器⽆法處理，也就是錯誤碼的含義。

「400 Bad Request」表示客戶端請求的報⽂有錯誤，但只是個籠統的錯誤。

「403 Forbidden」表示伺服器禁⽌訪問資源，並不是客戶端的請求出錯。

「404 Not Found」表示請求的資源在伺服器上不存在或未找到，所以⽆法提供給客戶端。

5xx

5xx 類狀態碼錶示客戶端請求報⽂正確，但是伺服器處理時內部發⽣了錯誤，屬於伺服器端的錯誤碼。

「500 Internal Server Error」與 400 型別，是個籠統通⽤的錯誤碼，伺服器發⽣了什麼錯誤，我們並不知道。

「501 Not Implemented」表示客戶端請求的功能還不⽀持，類似“即將開業，敬請期待”的意思。

「502 Bad Gateway」通常是伺服器作為⽹關或代理時返回的錯誤碼，表示伺服器⾃身⼯作正常，訪問後端伺服器發⽣了錯誤。

「503 Service Unavailable」表示伺服器當前很忙，暫時⽆法響應伺服器，類似“⽹絡服務正忙，請稍後重試”的意思。

常見欄位

Host 欄位

有了 Host 欄位，就可以將請求發往「同⼀臺」伺服器上的不同⽹站。

Content-Length 欄位

伺服器在返回資料時，會有 Content-Length 欄位，表明本次迴應的資料⻓度。

Connection 欄位

Connection 欄位最常⽤於客戶端要求伺服器使⽤ TCP 持久連線，以便其他請求復⽤。

Content-Type 欄位

Content-Type 欄位⽤於伺服器迴應時，告訴客戶端，本次資料是什麼格式。

Content-Encoding 欄位

Content-Encoding 欄位說明資料的壓縮⽅法。表示伺服器返回的資料使⽤了什麼壓縮格式

Get 與 Post

Get ⽅法的含義是請求從伺服器獲取資源，這個資源可以是靜態的⽂本、⻚⾯、圖⽚視訊等。

⽽ POST ⽅法則是相反操作，它向 URI 指定的資源提交資料，資料就放在報⽂的 body ⾥。

GET 和 POST ⽅法都是安全和冪等的嗎？

先說明下安全和冪等的概念：

  • 在 HTTP 協議⾥，所謂的「安全」是指請求⽅法不會「破壞」伺服器上的資源。
  • 所謂的「冪等」，意思是多次執⾏相同的操作，結果都是「相同」的。

那麼很明顯 GET ⽅法就是安全且冪等的，因為它是「只讀」操作，⽆論操作多少次，伺服器上的資料都是安全的，且每次的結果都是相同的。

POST 因為是「新增或提交資料」的操作，會修改伺服器上的資源，所以是不安全的，且多次提交資料就會建立多個資源，所以不是冪等的。

HTTP 特性

HTTP（1.1）

HTTP 最凸出的優點是「簡單、靈活和易於擴充套件、應⽤⼴泛和跨平臺」。

優點

  1. 簡單

    HTTP 基本的報⽂格式就是 header + body ，頭部資訊也是 key-value 簡單⽂本的形式，易於理解，降低了學習和使⽤的⻔檻。

  2. 靈活和易於擴充套件

    HTTP協議⾥的各類請求⽅法、URI/URL、狀態碼、頭欄位等每個組成要求都沒有被固定死，都允許開發⼈員⾃定義和擴充。

同時 HTTP 由於是⼯作在應⽤層（ OSI 第七層），則它下層可以隨意變化。

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

  1. 應⽤⼴泛和跨平臺

    互聯⽹發展⾄今，HTTP 的應⽤範圍⾮常的⼴泛，從桌上型電腦的瀏覽器到⼿機上的各種 APP，同時天然具有跨平臺的優越性。

缺點

HTTP 協議⾥有優缺點⼀體的雙刃劍，分別是「⽆狀態、明⽂傳輸」，同時還有⼀⼤缺點「不安全」。

  1. ⽆狀態雙刃劍

⽆狀態的好處，因為伺服器不會去記憶 HTTP 的狀態，所以不需要額外的資源來記錄狀態資訊，這能減輕伺服器的負擔，能夠把更多的 CPU 和記憶體⽤來對外提供服務。

⽆狀態的壞處，既然伺服器沒有記憶能⼒，它在完成有關聯性的操作時會⾮常麻煩。

例如登入->新增購物⻋->下單->結算->⽀付，這系列操作都要知道⽤戶的身份才⾏。但伺服器不知道這些請求是有關聯的，每次都要問⼀遍身份資訊。

這樣每操作⼀次，都要驗證資訊，這樣的購物體驗還能愉快嗎？

對於⽆狀態的問題，解法⽅案有很多種，其中⽐較簡單的⽅式⽤ Cookie 技術。

Cookie 通過在請求和響應報⽂中寫⼊ Cookie 資訊來控制客戶端的狀態。

相當於，在客戶端第⼀次請求後，伺服器會下發⼀個裝有客戶資訊的「⼩貼紙」，後續客戶端請求伺服器的時候，帶上「⼩貼紙」，伺服器就能認得了了。

  1. 明⽂傳輸雙刃劍

明⽂意味著在傳輸過程中的資訊，是可⽅便閱讀的，通過瀏覽器的 F12 控制檯或 Wireshark 抓包都可以直接⾁眼檢視，為我們除錯⼯作帶了極⼤的便利性。

但是這正是這樣，HTTP 的所有資訊都暴露在了光天化⽇下，相當於資訊裸奔。在傳輸的漫⻓的過程中，資訊的內容都毫⽆隱私可⾔，很容易就能被竊取，如果⾥⾯有你的賬號密碼資訊，那你號沒了。

  1. 不安全

HTTP ⽐較嚴重的缺點就是不安全：

通訊使⽤明⽂（不加密），內容可能會被竊聽。⽐如，賬號資訊容易洩漏，那你號沒了。

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

⽆法證明報⽂的完整性，所以有可能已遭篡改。⽐如，⽹⻚上植⼊垃圾⼴告，視覺汙染，眼沒了。

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

HTTP/1.1

HTTP 協議是基於 TCP/IP，並且使⽤了「請求 - 應答」的通訊模式，所以效能的關鍵就在這兩點⾥。

  1. ⻓連線

    HTTP/1.0 效能上的⼀個很⼤的問題，那就是每發起⼀個請求，都要新建⼀次 TCP 連線（三次握⼿），⽽且是串⾏請求，做了⽆謂的 TCP 連線建⽴和斷開，增加了通訊開銷。

    為了解決上述 TCP 連線問題，HTTP/1.1 提出了⻓連線的通訊⽅式，也叫持久連線。這種⽅式的好處在於減少了TCP 連線的重複建⽴和斷開所造成的額外開銷，減輕了伺服器端的負載。

    持久連線的特點是，只要任意⼀端沒有明確提出斷開連線，則保持 TCP 連線狀態。

  2. 管道⽹絡傳輸

HTTP/1.1 採⽤了⻓連線的⽅式，這使得管道（pipeline）⽹絡傳輸成為了可能。

即可在同⼀個 TCP 連線⾥⾯，客戶端可以發起多個請求，只要第⼀個請求發出去了，不必等其回來，就可以發第⼆個請求出去，可以減少整體的響應時間。

但是伺服器還是按照順序，先回應 A 請求，完成後再回應 B 請求。要是前⾯的迴應特別慢，後⾯就會有許多請求排隊等著。這稱為「隊頭堵塞」。

  1. 隊頭阻塞

    「請求 - 應答」的模式加劇了 HTTP 的效能問題。

    因為當順序傳送的請求序列中的⼀個請求因為某種原因被阻塞時，在後⾯排隊的所有請求也⼀同被阻塞了，會招致客戶端⼀直請求不到資料，這也就是「隊頭阻塞」。好⽐上班的路上塞⻋。

總之 HTTP/1.1 的效能⼀般般，後續的 HTTP/2 和 HTTP/3 就是在優化 HTTP 的效能。

HTTPS 與 HTTP

HTTP 與 HTTPS 有哪些區別？

  1. HTTP 是超⽂本傳輸協議，資訊是明⽂傳輸，存在安全⻛險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹絡層之間加⼊了 SSL/TLS 安全協議，使得報⽂能夠加密傳輸。
  2. HTTP 連線建⽴相對簡單， TCP 三次握⼿之後便可進⾏ HTTP 的報⽂傳輸。⽽ HTTPS 在 TCP 三次握⼿之後，還需進⾏ SSL/TLS 的握⼿過程，才可進⼊加密報⽂傳輸。
  3. HTTP 的端⼝號是 80，HTTPS 的端⼝號是 443。
  4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證伺服器的身份是可信的。

  • 混合加密的⽅式實現資訊的機密性，解決了竊聽的⻛險。
  • 摘要演算法的⽅式來實現完整性，它能夠為資料⽣成獨⼀⽆⼆的「指紋」，指紋⽤於校驗資料的完整性，解決了篡改的⻛險。
  • 將伺服器公鑰放⼊到數字證書中，解決了冒充的⻛險。
  1. 混合加密

HTTPS 採⽤的是對稱加密和⾮對稱加密結合的「混合加密」⽅式：

  • 在通訊建⽴前採⽤⾮對稱加密的⽅式交換「會話祕鑰」，後續就不再使⽤⾮對稱加密。
  • 在通訊過程中全部使⽤對稱加密的「會話祕鑰」的⽅式加密明⽂資料。

採⽤「混合加密」的⽅式的原因：

  • 對稱加密只使⽤⼀個金鑰，運算速度快，金鑰必須保密，⽆法做到安全的金鑰交換。
  • ⾮對稱加密使⽤兩個金鑰：公鑰和私鑰，公鑰可以任意分發⽽私鑰保密，解決了金鑰交換問題但速度慢。
  1. 摘要演算法

摘要演算法⽤來實現完整性，能夠為資料⽣成獨⼀⽆⼆的「指紋」，⽤於校驗資料的完整性，解決了篡改的⻛險。

  1. 數字證書

    客戶端先向伺服器端索要公鑰，然後⽤公鑰加密資訊，伺服器收到密⽂後，⽤⾃⼰的私鑰解密。

    藉助第三⽅權威機構 CA （數字證書認證機構），將伺服器公鑰放在數字證書（由數字證書認證

    機構頒發）中，只要證書是可信的，公鑰就是可信的。

HTTPS 是如何建⽴連線的？其間互動了什麼？

SSL/TLS 協議基本流程：

  • 客戶端向伺服器索要並驗證伺服器的公鑰。
  • 雙⽅協商⽣產「會話祕鑰」。
  • 雙⽅採⽤「會話祕鑰」進⾏加密通訊。

前兩步也就是 SSL/TLS 的建⽴過程，也就是握⼿階段。

HTTP/1.1、HTTP/2、HTTP/3

HTTP/1.1 相⽐ HTTP/1.0 提⾼了什麼效能？

HTTP/1.1 相⽐ HTTP/1.0 效能上的改進：

  • 使⽤ TCP ⻓連線的⽅式改善了 HTTP/1.0 短連線造成的效能開銷。
  • ⽀持管道（pipeline）⽹絡傳輸，只要第⼀個請求發出去了，不必等其回來，就可以發第⼆個請求出去，可以減少整體的響應時間。

但 HTTP/1.1 還是有效能瓶頸：

  • 請求 / 響應頭部（Header）未經壓縮就傳送，⾸部資訊越多延遲越⼤。只能壓縮 Body 的部分；
  • 傳送冗⻓的⾸部。每次互相傳送相同的⾸部造成的浪費較多；
  • 伺服器是按請求的順序響應的，如果伺服器響應慢，會招致客戶端⼀直請求不到資料，也就是隊頭阻塞；
  • 沒有請求優先順序控制；
  • 請求只能從客戶端開始，伺服器只能被動響應。

HTTP/2 做了什麼優化？

HTTP/2 協議是基於 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

  1. 頭部壓縮

    HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是⼀樣的或是相似的，

    那麼，協議會幫你消除重複的部分。

    這就是所謂的 HPACK 演算法：在客戶端和伺服器同時維護⼀張頭資訊表，所有欄位都會存⼊這個表，⽣成⼀個索引號，以後就不傳送同樣欄位了，只發送索引號，這樣就提⾼速度了。

  2. ⼆進位制格式

    HTTP/2 不再像 HTTP/1.1 ⾥的純⽂本形式的報⽂，⽽是全⾯採⽤了⼆進位制格式，頭資訊和資料體都是⼆進位制，並且統稱為幀（frame）：頭資訊幀和資料幀。增加了資料傳輸的效率。

  1. 資料流

    HTTP/2 的資料包不是按順序傳送的，同⼀個連線⾥⾯連續的資料包，可能屬於不同的迴應。

因此，必須要對資料包做標記，指出它屬於哪個迴應。

每個請求或迴應的所有資料包，稱為⼀個數據流（ Stream ）。

每個資料流都標記著⼀個獨⼀⽆⼆的編號，其中規定客戶端發出的資料流編號為奇數， 伺服器發出的資料流編號為偶數，客戶端還可以指定資料流的優先順序。優先順序⾼的請求，伺服器就先響應該請求。

  1. 多路復⽤

    HTTP/2 是可以在⼀個連線中併發多個請求或迴應，⽽不⽤按照順序⼀⼀對應。

移除了 HTTP/1.1 中的串⾏請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，⼤幅度提⾼了連線的利⽤率。

  1. 伺服器推送

    HTTP/2 還在⼀定程度上改善了傳統的「請求 - 應答」⼯作模式，服務不再是被動地響應，也可以主動向客戶端傳送訊息。

    舉例來說，在瀏覽器剛請求 HTML 的時候，就提前把可能會⽤到的 JS、CSS ⽂件等靜態資源主動發給客戶端，減少延時的等待，也就是伺服器推送（Server Push，也叫 Cache Push）。

HTTP/2 有哪些缺陷？HTTP/3 做了哪些優化？

HTTP/2 主要的問題在於，多個 HTTP 請求在復⽤⼀個 TCP 連線，下層的 TCP 協議是不知道有多少個 HTTP 請求的。

所以⼀旦發⽣了丟包現象，就會觸發 TCP 的重傳機制，這樣在⼀個 TCP 連線中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

HTTP/1.1 中的管道（ pipeline）傳輸中如果有⼀個請求阻塞了，那麼佇列後請求也統統被阻塞住了

HTTP/2 多個請求復⽤⼀個TCP連線，⼀旦發⽣丟包，就會阻塞住所有的 HTTP 請求。

這都是基於 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！

QUIC 協議： UIC（Quick UDP Internet Connection）是谷歌制定的一種基於UDP的低時延的網際網路傳輸層協議。

參考：圖解網路

我這裡只是一個自己的學習筆記，大家有興趣一定去看原文！！！ 謝謝大家的閱讀！！

大家有興趣一定去看原文，這只是我自己的一個筆記總結！！

大家有興趣一定去看原文，這只是我自己的一個筆記總結！！

大家有興趣一定去看原文，這只是我自己的一個筆記總結！！