作者 | 蔡柱梁
1.目錄
- 網絡協議
- HTTP
- HTTPS
希望通過這篇文章能讓讀者了解什么是網絡協議，以及目前我們最常接觸的 http 和 https。
2.網絡協議
網絡協議是為計算機網絡中進行數據交換而建立的規則、標準或約定。
眾所周知，網絡是一臺臺的計算機構成的一張“大網”，彼此通訊，交互數據。我們也都知道不同的計算機廠家生產的計算機肯定是存在差異的，那么它們是如何克服這些差異進行通信呢?顯然就是“語言”，我們的語言能彼此交流是因為我們對這些定義產生了共識，比如蘋果指代的就是具體的一種水果等等。而計算機也是通過建立這種約定來完成通信的。不過要注意!這網絡協議不僅僅是給計算機互相間使用的，而是給網絡上所有設備(服務器、個人PC、交換機、路由器、防火墻等)使用的。大多數網絡都采用分層的體系結構，每一層都建立在它的下層之上，向它的上一層提供一定的服務，而把如何實現這一服務的細節對上一層加以屏蔽(這就類似我們代碼中的接口)。一臺設備上的第 n層與另一臺設備上的第n層進行通信的規則就是第n層協議。在網絡的各層中存在著許多協議，接收方和發送方同層的協議必須一致，否則一方將無法識別另一方發出的信息。網絡協議使網絡上各種設備能夠相互交換信息。上面提到了大多數網絡都采用分層，這里說下分層模型：
- OSI 模型(Open System Interconnection Reference Model)，一種概念模型，由國際標準化組織提出，是一個試圖使各種計算機在世界范圍內互連為網絡的標準框架。它具體分為七層：
- 應用層(第七層)
- 為應用軟件而設的接口，用于應用間的通信
- 表示層(第六層)
- 將數據轉為接收系統可以使用的格式
- 會話層(第五層)
- 會話層是建立在傳輸層之上，利用傳輸層提供的接口，使應用建立和維持會話，并能使會話獲得同步(簡單理解成數據傳輸的一個通道)
- 傳輸層(第四層)
- 將傳輸表頭(TH，傳輸表頭包含了所使用的協議等信息)加至數據(我們要傳輸的數據)形成數據包
- 網絡層(第三層)
- 網絡層決定了數據的傳輸路徑和轉寄，它會將網絡表頭(NH，包含了網絡數據：IP 等)加入數據包中
- 數據鏈路層(第二層)
- 數據鏈路層(Data Link Layer)負責網絡尋址、錯誤偵測和改錯物理層(第一層)
- 物理層確保原始數據可以在各種物理媒體上傳輸
TCP/IP 協議族分層方式與 OSI 分層的同異，如下圖：
下面會對一個簡單的場景進行網絡請求畫圖。
場景：我給公司寫了一個 hello world 的簡單的靜態頁面部署在公司的服務器上，我用自己的電腦在家里通過公網訪問這個靜態頁面，比如網址是“http://www.xxx.com”。
當我訪問這個網址時，瀏覽器都做了些什么呢?我們看下圖：
TCP
TCP(Transmission Control Protocol，傳輸控制協議)是一種面向連接的，可靠的，基于字節流的，雙向傳輸的傳輸層通信協議。它在建立連接時會經過三次握手，三次握手完成后才會開始傳輸數據;在終止連接時，它需要四次揮手。具體如下：
(1)建立連接
圖源：百度百科
三次握手：
- 客戶端發送 SYN 報文給服務端，進入 SYN_SEND 狀態
- 服務器回復 SYN，進入 SYN_RECV 狀態
- 客戶端收到來自服務端的 SYN 報文后，回復 ACK
客戶端和服務端進入 Established 狀態，可以開始收發數據了。
(2)終止連接
圖源：百度百科
- 四次揮手(注意：close 動作可以由任意一端先發起，這里以 client 發起為例)：
- 客戶端先調用 close，執行 active close，并發送 FIN 表示數據發送完畢，進入 FIN_WAIT_1 狀態
- 服務端接收到 FIN 后，執行 passive close，并給客戶端發送 ACK，進入 CLOSE_WAIT 狀態
- 服務端給客戶端發送一個 FIN，進入 LAST_ACK 狀態
主動發起 close 的一方負責最終確認 FIN，這個例子就是客戶端需要接收 FIN 并回復 ACK 給服務端，進入 TIME_WAIT 狀態，服務端收到 ACK 后進入 CLOSED 狀態
為什么終止的時候是四次揮手呢?
因為一方主動發起 close 并發送 FIN 僅僅代表它不再發送數據，可是還能接收數據，所以需要另一方也進行 close 并發送 FIN 通知對方。至于為什么要將 ACK 和 FIN 分開呢?是因為 ACK 是告訴對方“我知道了”，而 FIN 是告訴對方“我也沒有數據給你了”。而實際情況不一定是我收到 FIN 就剛好也把數據都給完對方了，所以是需要分開的。
HTTP
HTTP(HyperText Transfer Protocol)，超文本傳輸協議，它是基于 TCP 協議實現的。
HTTP 是一種無狀態協議，像我們作為游客訪問一個頁面時，無狀態協議是簡單且高效的。不過像電商場景是需要記錄用戶登錄狀態或記錄購物車商品信息的(除了電商像一些中臺系統也是需要記錄用戶狀態的，這里僅是舉例)，這時就需要一些額外的技術協助了，如：Cookie。
HTTP 報文格式
HTTP 協議的請求報文和響應報文的結構基本相同。
報文由三大部分組成：
- 起始行
- 描述請求或響應的基本信息，如：GET /** HTTP/1.1、HTTP/1.1 200 OK 等
- 頭部字段集合
- 使用 key-value 說明報文(想想請求頭和響應頭)
- 消息正文
HTTPS
HTTP 是基于 TCP 實現的，它的報文是明文，整個傳輸過程完全是透明的，任何環節都可以輕松獲截、修改，這是很不安全的。因此，安全的 HTTP 協議應運而生—— HTTPS。HTTPS其實就是在HTTP之上增加了SSL。
(1) SSL/TLS
SSL 即安全套接層(Secure Sockets Layer)，1999年改名為 TLS(傳輸層安全， Transport Layer Security)
有幾個概念要先說清楚：
- 對稱加密
- 通過同一把“鑰匙”進行加密和解密
- 非對稱加密
- 有兩把“鑰匙”——公鑰，私鑰，使用公鑰加密的，需要使用私鑰解密;使用私鑰加密的，需要公鑰解密
- 摘要算法
- 將一個隨機長度的內容生成一個定長的內容，常見算法有：MD5、sha1、sha2等等
- 安全性
- 沒有絕對的安全，我們所說的數據安全都是基于一個信任點，認為它是安全的，我們所說的安全才能成立，否則不存在安全一說。如：非對稱加密和對稱加密，我們相信這些算法的安全性，因此認為只要密鑰不泄露，那么就是安全的
(2)HTTPS 工作流程大致如下：
先完成三次握手，這里和 HTTP 是一致的
- 瀏覽器給服務器發送加密套件列表(就是告訴服務器自己支持的加密算法)
- 服務器根據加密套件列表挑選加密算法，并給瀏覽器發送公鑰
- 瀏覽器獲取公鑰后，隨機生成對稱加密算法使用的密鑰，通過公鑰加密該密鑰，然后發送密文給服務器
- 服務器使用私鑰解密，對于該會話的內容信息都使用該密鑰加密傳輸給瀏覽器
(3)優點
- 通過非對稱加密保證瀏覽器傳輸的密鑰不會被破解(因為私鑰在自己手上，沒有經歷過網絡傳輸)
- 使用對稱加密算法加解密內容效率高
(4)缺點
- 服務器給瀏覽器傳輸公鑰時沒法保證該瀏覽器不會泄露公鑰
基于這個缺點，我們需要依賴第三方機構協助，讓我們的 HTTPS 更安全可靠。
具體如下：
- 對于第三步的傳輸公鑰改成傳輸公鑰數字證書
- 數字證書組成：
公鑰用戶信息
公鑰
簽名
通過 hash(公鑰，公司信息，域名等申請信息) 獲取數據摘要;CA 再對摘要信息進行加密，這個密文就是簽名
CA 信息
有效期
證書序列號
- 數字證書由第三方機構(CA 機構)頒發
- 公司信息、系統的域名和公鑰需要到 CA 機構進行認證，認證通過后 CA 再給我們頒發證書，證書內容如上不累述。因為這證書有簽名，所以證書內容不可被篡改，從而證書里面的公鑰用戶信息和公鑰的安全性就得到了保證。
- CA 機構頒發的證書的可靠性依賴于根證書，而根證書是操作系統或瀏覽器內置的(換句話說，我們就是要相信操作系統或者瀏覽器的安全性)
綜上所述，我們 HTTPS 的安全性是基于對根證書的信任和加密算法的信任，從而認為自己是安全的。
上面也提到了，基于某個信任點，我們的安全才能聊下去，所以是沒有絕對的安全的。如果黑客劫持了瀏覽器，讓你所有請求先到他，他再到服務器，那么你請求的所有數據都會先到黑客手上，那么就不安全了。舉例：我們的梯子很多就是代理，瀏覽器發出的請求被它代理，然后走到可以翻墻的服務器上再去請求資源，得到的數據自然也是原路返還，那么這個中轉服務器就可以做很多操作了。
相信到這里，大家已經知道我們常說的網絡分層架構一般是定義成5層或者7層，而我們所說的網絡協議是針對里面某一層的通信協議。這里以我們最常接觸的 http 和 https 為例做了說明，并且講了它們的區別，還延申了下網絡安全方面的內容。
作者介紹
蔡柱梁，51CTO社區編輯，從事Java后端開發8年，做過傳統項目廣電BOSS系統，后投身互聯網電商，負責過訂單，TMS，中間件等。
