OSI 參考模型 與 TCP/IP 五層模型
我們主要關注於 TCP/IP 五層模型 的 應用層 和 傳輸層 就足夠了。
應用層:
- 作用：為應用程序提供服務。
- 常見協議：HTTP、HTTPS、FTP、POP3、SMTP等。
傳輸層:
- 作用：實現應用程序之間的數據傳輸。
- 協議：UDP、TCP
UDP 與 TCP
UDP
UDP 是面向無連接的協議，它只會把數據傳遞給接收端，但不會關注接收端是否已經正確接收了數據，所以有時候 UDP 會被認為是不可靠的數據報協議。但這種特性反而適合多播，實時的視頻和音頻傳輸。
優點：
- 無需建立連接（減少了延遲）
- 實現簡單（效率高）
- 頭部開銷小（ 8 字節）
- 沒有擁塞控制（更好的控制發送時間和速率）
缺點：
- 沒有建立連接（數據想發就發，不可靠）
- 沒有擁塞控制（網絡條件不好時會導致丟包）
TCP
TCP 是面向有連接的協議，在使用 TCP 協議 傳輸數據之前一定需要在發送方和接收方之間建立連接。建立連接三次握手，斷開連接四次揮手~
TCP 建立連接三次握手
第一次握手：
客戶端向服務端發送一個 SYN（Seq=X） 包，客戶端進入 SYN-SENT 狀態，等待服務端的 ACK（Ack=X+1）回覆。
ps: Seq 是序號，Ack 是確認序號。
第二次握手：
服務端根據接收到客戶端發來的 SYN（Seq=X） 包後返回一個 ACK（Ack=X+1） 以及 SYN（Seq=Y） 包給客戶端，服務端進入 SYN-RECIVED 狀態，等待客戶端 的 ACK（Ack=Y+1） 回覆。
第三次握手：
客戶端接收到 ACK（X+1） 後，進入 ESTABLISHED 狀態。根據服務端發來的 SYN（Y） 返回一個 ACK（Y+1） 包給服務端。
服務端 接收 ACK（Y+1）後進入 ESTABLISHED 狀態。此時連接建立成功。
這個過程可以用以下三句形象表示：
- (客戶端)：我想建立連接了，服務端你準備好沒有呀？
- (服務端)：我準備好了，你準備好沒有？
- (客戶端)：我也準備好了，開始吧~
TCP 關閉連接四次揮手
這個過程可以用以下四句句形象表示：
- (客戶端)：我想關閉連接了。
- (服務端)：我知道了。
- (服務端)：我現在準備關閉連接了，ok 嗎？
- (客戶端)：ok，你關閉吧。
UDP 與 TCP 的區別
- UDP 協議是面向無連接的，它不能保證數據有序且不丟失的傳到對端，但是 UDP 比 TCP 更高效。
- TCP 協議是面向有連接的，建立和斷開連接都需要握手，在傳輸數據的過程中，通過滑動窗口（流量控制）、擁塞處理（慢開始，擁塞避免，快速重傳，快速恢復），能夠正確處理丟包問題，保證接收方能夠收到數據，與此同時還能夠有效利用網絡帶寬。
HTTP
HTTP (HyperText Transfer Protocol) 超文本傳輸協議 是一個基於 TCP (傳輸層) 的應用層協議，是客戶端與服務端之間請求和響應的標準。
主要特點
- 簡單快速
客戶端向服務器請求服務時，只需請求方法和請求路徑。
- 無狀態
客戶端再次向服務器請求服務時，服務器並不知道客戶端之前是否請求過。
- 無連接
每次請求都會建立一個 TCP 連接，請求處理完成後連接斷開。
HTTP 報文
請求行：
GET https://www.baidu.com/ HTTP/1.1 由請求方法、URL、協議版本組成
響應行：
HTTP/1.1 200 OK
協議版本、狀態碼、狀態信息組成
HTTP 請求方法
請求方法分為很多種，最常用的也就是 GET 和 POST 了。雖然請求方法很多，但更多的是為了傳達語義。更多的方法的語義描述可以閱讀 文檔 。
GET 和 POST 的區別
- GET
能緩存、請求長度限制、 有歷史記錄
GET 多用於 無副作用(不修改資源)、冪等(請求次數與資源無關)的場景。
- POST
POST 相對 GET 安全一點點，因為 GET 請求發送的數據包含在 URL 裡。
兩者詳細對比：
狀態碼
狀態碼錶示了響應的狀態，可以讓我們知道這一次的請求是成功還是失敗，如果失敗，是什麼原因導致的。
2XX 成功
- 200 OK ，請求成功並返回數據
- 204 No Content ，成功但無內容
- 206 Partial Content ,範圍請求
3XX 重定向
- 301 永久重定向，表示資源已被分配了新的 URL
- 302 臨時重定向，資源臨時被分配新的 URL
- 304 資源未修改，可使用緩存
4XX 客戶端錯誤
- 400 請求語法錯誤
- 401 要求身份認證
- 403 請求被服務器拒絕
- 404 資源不存在
5XX 服務器錯誤
- 500 服務器錯誤
- 503 服務器超負載或停機維護
HTTPS
更安全的網絡傳輸協議
- 需要安裝證書（公鑰）
- 經過 SSL/TLS 協議 加密，傳輸的內容是經過加密的
- 使用 443 端口
HTTP/2
- 多路複用
在同一個 TCP 連接上傳輸所有的請求數據，避免 隊頭阻塞(瀏覽器限制同一個域名下的連接數)問題
- Header 壓縮
使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減少了 header 的大小。並在兩端維護了索引表，用於記錄出現過的 header ，避免 header 重複傳輸。
- 二進制傳輸
在之前的 HTTP 版本中，我們是通過文本的方式傳輸數據。在 HTTP/2 中引入了新的編碼機制，所有傳輸的數據都會被分割，並採用二進制格式編碼。
- 服務端推送
服務端可以在客戶端的某個請求後，主動推送其他客戶端在之後會用到的資源。省去了客戶端重複請求的步驟，降低了延遲。
https://juejin.im/post/5c64d15d6fb9a049d37f9c20#heading-49
https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A?
http://www.alloyteam.com/2016/07/httphttp2-0spdyhttps-reading-this-is-enough/
https://juejin.im/book/5bdc715fe51d454e755f75ef/section/5bdc72b151882516f039fce3
閱讀更多 cpp軟件架構獅 的文章
