HTTP總結
1 請求、響應格式
1.1 請求格式
1.1.1查看方式
瀏覽器：F12->「網路」->「全部」
1.1.2 請求方法：
- GET
基於「URL」地址問號傳參；一般用於向伺服器獲取資源，例如查詢資料庫的數據等；成功返回200 - POST
基於「請求」主體把消息發送給伺服器；一般用於請求新增或修改資源，例如提交表單，新增用戶等；先發送header，伺服器響應100，再發送data，成功響應201 - PUT
修改資源 - DELETE
刪除某個資源
1.1.3 GET、POST區別
- get重點在從伺服器上獲取資源；post重點在向伺服器發送數據；
- get傳輸數據是通過URL請求，以field（欄位）= value的形式，置於URL後，並用”?”連接，多個請求數據間用”&”連接，這個過程用戶是可見的，不安全；post傳輸數據通過Http的post機制，將欄位與對應值封存在請求實體中發送給伺服器，這個過程對用戶是不可見的，安全性更高；
- Get傳輸的數據量小，因為受URL長度限制，但效率較高；Post可以傳輸大量數據，所以上傳文件時只能用Post方式；
1.2 響應格式
2.1.1 狀態碼
- 1xx：指示資訊–表示請求已接收，繼續處理
- 2xx：成功–表示請求已被成功接收、理解、接受
- 200：請求被正常處理
- 204：請求被受理但沒有資源可以返回
- 3xx：重定向–要完成請求必須進行更進一步的操作
- 301：永久性重定向，說明請求的資源已經被永久移動到了由 Location 頭部指定的 url 上，是固定的不會再改變，搜索引擎會根據該響應修正。
- 302：臨時重定向，表明請求的資源被 暫時 移動到了由 Location 頭部指定的 URL 上。瀏覽器會重定向到這個 URL， 但是搜索引擎不會對該資源的鏈接進行更新。302 跳轉有網站劫持的風險
- 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現
- 400：請求報文語法有誤，伺服器無法識別
- 403：請求的對應資源禁止被訪問
- 404：伺服器無法找到對應資源
- 5xx：伺服器端錯誤–伺服器未能實現合法的請求
- 500：伺服器內部錯誤
- 503：伺服器正忙
2 HTTP請求響應的流程
- 域名解析
- 發起TCP的3次握手
- 建立TCP連接後發起http請求
- 伺服器響應http請求，瀏覽器得到html程式碼
- 瀏覽器解析html程式碼，並請求html程式碼中的資源（如js、css、圖片等）
- 瀏覽器對頁面進行渲染呈現給用戶
3 HTTPS
3.1 HTTP 與 HTTPS 有哪些區別？
- 安全性: HTTP 明文傳輸，不對數據進行加密安全性較差。HTTPS (HTTP + SSL / TLS)的數據傳輸過程是加密的，安全性較好。
- 在相同網路環境中，HTTPS 相比 HTTP 無論是響應時間還是耗電量都有大幅度上升。因為加了一層安全層，建立連接的過程更複雜，也要交換更多的數據，難免影響速度。
- HTTP 的端⼝號是 80，HTTPS 的端⼝號是 443。
3.2 對稱加密和非對稱加密結合的「混合加密」方式
可以參考：//segmentfault.com/a/1190000021494676
HTTPS 的整個通訊過程可以分為兩大階段：證書驗證和數據傳輸階段，數據傳輸階段又可以分為非對稱加密和對稱加密兩個階段。
- 客戶端請求 HTTPS 網址，然後連接到 server 的 443 埠 (HTTPS 默認埠，類似於 HTTP 的80埠)。
- 採用 HTTPS 協議的伺服器必須要有一套數字 CA (Certification Authority)證書
- 伺服器響應客戶端請求，將證書傳遞給客戶端，證書包含公鑰和大量其他資訊
- 客戶端解析證書並對其進行驗證。如果證書不是可信機構頒布，或者證書中的域名與實際域名不一致，或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。如果證書沒有問題，客戶端就會從伺服器證書中取出伺服器的公鑰A。然後客戶端還會生成一個隨機碼 KEY，並使用公鑰A將其加密。
- 客戶端把加密後的隨機碼 KEY 發送給伺服器，作為後面對稱加密的密鑰。
- 伺服器在收到隨機碼 KEY 之後會使用私鑰B將其解密。經過以上這些步驟，客戶端和伺服器終於建立了安全連接，完美解決了對稱加密的密鑰泄露問題，接下來就可以用對稱加密愉快地進行通訊了。
- 伺服器使用密鑰 (隨機碼 KEY)對數據進行對稱加密並發送給客戶端，客戶端使用相同的密鑰 (隨機碼 KEY)解密數據。
- 雙方使用對稱加密愉快地傳輸所有數據。
3..3 為什麼使用混合加密？
- 對稱加密：
- 優點：演算法公開、計算量小、加密速度快、加密效率高，適合加密比較大的數據。
- 缺點：
- 交易雙方需要使用相同的密鑰，也就無法避免密鑰的傳輸，而密鑰在傳輸過程中無法保證不被截獲，因此對稱加密的安全性得不到保證。
- 每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的惟一密鑰，這會使得發收信雙方所擁有的鑰匙數量急劇增長，密鑰管理成為雙方的負擔。對稱加密演算法在分散式網路系統上使用較為困難，主要是因為密鑰管理困難，使用成本較高。
- 非對稱加密
顧名思義，就是加密和解密需要使用兩個不同的密鑰：公鑰（public key）和私鑰（private key）。公鑰與私鑰是一對，如果用公鑰對數據進行加密，只有用對應的私鑰才能解密；如果用私鑰對數據進行加密，那麼只有用對應的公鑰才能解密。非對稱加密演算法實現機密資訊交換的基本過程是：甲方生成一對密鑰並將其中的一把作為公鑰對外公開；得到該公鑰的乙方使用公鑰對機密資訊進行加密後再發送給甲方；甲方再用自己保存的私鑰對加密後的資訊進行解密。
4 HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3
4.1 1.0->1.1
- 連接方式 : HTTP 1.0 為短連接，HTTP 1.1 支援長連接。
- 狀態響應碼 : HTTP/1.1中新加入了大量的狀態碼，光是錯誤響應狀態碼就新增了24種
- 頻寬優化及網路連接的使用 :HTTP1.0 中，存在一些浪費頻寬的現象，例如客戶端只是需要某個對象的一部分，而伺服器卻將整個對象送過來了，並且不支援斷點續傳功能，HTTP1.1 則在請求頭引入了 range 頭域，它允許只請求資源的某個部分
4.2 1.1->2
HTTP/2 協議是基於 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
- 頭部壓縮
HTTP/2 會壓縮頭（Header），如果你同時發出多個請求，他們的頭是一樣的或是相似的，那麼，協議會幫你消除重複的部分。 - 二進位格式
HTTP/2 不再像 HTTP/1.1 里的純文本形式的報文，而是全面採用了二進位格式。 - 數據流
HTTP/2 的數據包不是按順序發送的，同一個連接裡面連續的數據包，可能屬於不同的回應。因此，必須要對數據包做標記，指出它屬於哪個回應。每個請求或回應的所有數據包，稱為一個數據流（Stream）。 - 多路復用
HTTP/2 是可以在一個連接中並發多個請求或回應，而不用按照順序一一對應。移除了 HTTP/1.1 中的串列請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，大幅度提高了連接的利用率。
4.3 2->3
HTTP/2 主要的問題在於：多個 HTTP 請求在復用一個 TCP 連接，下層的 TCP 協議是不知道有多少個 HTTP 請求的。所以一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！
UDP 發生是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的一個丟包全部重傳問題。UDP 是不可靠傳輸的，但基於 UDP 的QUIC 協議可以實現類似 TCP 的可靠性傳輸。
5 TLS4次握手
客戶端 服務端
- 客戶端給服務端隨機數，告訴服務端我能用哪些加密手段 –>
- 服務端給客戶端隨機數，告訴客戶端就用哪種加密手段 <–
- 服務端給客戶證書，(裡面包含了ca加密的服務端公鑰) <–
- 客戶端把會話秘鑰生成 傳給服務端 (服務端公鑰加密 2個隨機數+premaster 搭建會話秘鑰) –>
6 HTTP優化方案
- 內容快取：將經常用到的內容進行快取起來，那麼客戶端就可以直接在記憶體中獲取相應的數據了。
- 壓縮：將文本數據進行壓縮，減少頻寬
- SSL加速（SSL Acceleration）：***L協議對HTTP協議進行加密，在通道內加密並加速
- TCP復用：TCP連接復用是將多個客戶端的HTTP請求復用到一個伺服器端TCP連接上，而HTTP復用則是一個客戶端的多個HTTP請求通過一個TCP連接進行處理。前者是負載均衡設備的獨特功能；而後者是HTTP 1.1協議所支援的新功能，目前被大多數瀏覽器所支援。
- TCP緩衝：通過採用TCP緩衝技術，可以提高伺服器端響應時間和處理效率，減少由於通訊鏈路問題給伺服器造成的連接負擔。
7 參考
WebServer伺服器項目可能會被問到的問題（二）
HTTP 請求方法和應用場景
通俗講解【重定向】及其實踐
HTTPS 詳解一：附帶最精美詳盡的 HTTPS 原理圖
HTTP/1.1、HTTP/2、HTTP/3的演變
HTTP 1.0 vs HTTP 1.1（應用層）
