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 對稱加密和非對稱加密結合的「混合加密」方式

可以參考：https://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（應用層）

HTTP總結