一、從一個HTTP請求來看網路分層原理

比如現在要實作這樣一個需求，將一個資料包從A主機傳輸到B主機，

傳輸的中間程序中可能發生以下問題：

為了更清楚的解決這些問題，就需要進行分層，

1、網路分層

業內普遍的分層方式有兩種：OSI七層模型 和TCP/IP四層模型，

2、一個HTTP請求的分層決議流程

二、HTTP協議

超文本傳輸協議（HyperText Transfer Protocol, HTTP）：一種無狀態的（不會存盤用戶的資訊），以請求/應答方式的協議，它使用可拓展的語意（頭部添加引數）和字描述訊息格式（文本、音視頻），與基于網路的超文本資訊系統（HTML）靈活的互動，

HTTP中雖然有傳輸，但是真正的傳輸是交由TCP來完成的，

2.1 HTTP報文格式

HTTP協議的請求報文和回應報文的結構基本相同，由三大部分組成：

• 起始行（start line）：描述請求或回應的基本資訊
• 頭部欄位集合（header）：使用key-value形式更詳細的說明報文
• 訊息正文（entity）：實際傳輸的資料，它不一定是純文本，可以是圖片、視頻等二進制資料

2.2 請求報文格式

• 請求方法：如GET/HEAD/PUT/POST，表示對資源的操作；
• 請求目標：通常是一個URI，標記了請求方法要操作的資源；
• 版本號：表示報文使用的HTTP協議版本，

2.3 回應行報文格式

2.4 HTTP頭欄位

頭部欄位是key-value的形式，key和value之間用“:”分隔，最后用CRLF換行表示欄位結束，比如前后端分離是經常遇到要與后端協商傳輸資料的型別“Content-type:application/json”，這里key就是“Content-type”，value就是“:application/json”，HTTP頭欄位非常靈活，不僅可以使用標準的Host、Connection等已有頭，也可以任意添加自定義頭，這就給HTTP協議帶來了無限的拓展可能，

頭欄位注意事項：

• 欄位名不區分大小寫，欄位里不允許出現空格，可以使用連字符“-”，但不能使用下劃線“” （有的服務器不會決議帶""的頭欄位），欄位名后面必須緊接著：“:”，不能有空格，而“:”后的欄位值可以有多個空格；
• 欄位的順序是沒有意義的，可以任意排列不影響語意；
• 欄位原則上不能重復，除非這個欄位本身的語意允許，例如Set-Cookie，

2.5 常用頭欄位

HTTP協議中有非常多的頭欄位，但基本上可以分為四大類：

• 請求欄位：請求頭中的頭欄位，如Host，Referer；
• 回應欄位：回應頭中的頭欄位，如Server，Date；
• 通用欄位：在請求頭和回應頭里都可以出現，如Content-type，Connection，

三、HTTP請求的完整程序

當用戶在瀏覽器輸入網址回車之后，網路協議都做了哪些作業呢？

1、首先干活的是瀏覽器應用程式，它要決議出URL中的域名
2、根據域名獲取對應的IP地址，首先從瀏覽器快取中查看，如下可以查看瀏覽器中域名對應IP的決議

chrome://net-internals/#events

如果沒有從本機域名決議檔案hosts（/etc/hosts）中查看，還沒有則從LDNS（Localdnsserver）、RootServer域名服務器、國際頂級域名服務商的DNS的層層決議

3、拿到IP地址之后，瀏覽器就可以發起與服務器的三次握手
4、握手建立之后，就開始組裝http請求報文，發送報文
5、服務器收到請求報文之后開始，請求報文決議，生成相應資料，發送相應資料
6、瀏覽器收到回應之后，開始渲染頁面

四、TCP協議

TCP（Transmission Control Protocol）：面向連接的、可靠的、基于位元組流的傳輸層通信協議，

特點：

• 基于連接的：資料傳輸之前需要建立連接
• 全雙工的：雙向傳輸
• 位元組流：不限制資料大小，打包成報文段，保證有序接收，重復報文自動丟棄
• 流量緩沖：解決雙方處理能力的不匹配
• 可靠的傳輸服務：保證可達，丟包時通過重發機制實作可靠性
• 擁塞控制：防止網路出現惡性擁塞

報文：

4.1 TCP連接管理

1、TCP連接：四元組【原地址，源埠，目的地址，目的埠】

2、確立連接：TCP三次握手（基于報文實作）

• 同步通信雙方初始化序號（INS，initial sequence number）
• 協商TCP通信引數（MESS，視窗資訊，指定校驗和演算法）

4.2 TCP三次握手詳解

TCP是屬于網路分層中的運輸層(有的書也翻譯為傳輸層)，因為OSI分為7層，感覺太麻煩了，所以分為四層就好了，簡單，

分層以及每層的協議，TCP是屬于運輸層(有的書也翻譯為傳輸層)，

要想簡單了解TCP三次握手，我們首先要了解TCP頭部結構，如下：

TCP三次握手如圖：

第一次握手

客戶端給服務器發送一個SYN段(在 TCP 標頭中 SYN 位欄位為 1 的 TCP/IP 資料包), 該段中也包含客戶端的初始序列號(Sequence number = J)，

SYN是同步的縮寫，SYN 段是發送到另一臺計算機的 TCP 資料包，請求在它們之間建立連接

第二次握手

服務器回傳客戶端 SYN +ACK 段(在 TCP 標頭中SYN和ACK位欄位都為 1 的 TCP/IP 資料包)， 該段中包含服務器的初始序列號(Sequence number = K)；同時使 Acknowledgment number = J + 1來表示確認已收到客戶端的 SYN段(Sequence number = J)，

ACK 是“確認”的縮寫， ACK 資料包是任何確認收到一條訊息或一系列資料包的 TCP 資料包

第三次握手

客戶端給服務器回應一個ACK段(在 TCP 標頭中 ACK 位欄位為 1 的 TCP/IP 資料包), 該段中使 Acknowledgment number = K + 1來表示確認已收到服務器的 SYN段(Sequence number = K)，

參考文章：https://blog.csdn.net/jun2016425/article/details/81506353，里面有更詳細的程序，

4.3 握手程序中的內核

4.4 TCP四次揮手

客戶端：發送FIN資料包，代表客戶端不再發送資料（但是服務端還是可以收資料的）
服務端：收到請求，開始應答，避免了A重新發送FIN重試（應答機制）
服務端：處理完資料之后關閉，關閉連接及發送FIN請求
客戶端：收到請求后發送ACK應答，服務端可以釋放連接

為什么要等到2MSL之后釋放連接？
1、防止報文丟失，導致服務端重復發送FIN
2、防止滯留在網路中的報文，對新建立的連接造成資料擾亂

4.5 位元組流的協議

TCP把應用交付的資料僅僅看成是一連串的無結構的位元組流，TCP并不知道位元組流的含義，TCP并不關心應用程式一次將多大的報文發送到TCP的快取匯總，而是根據對方給出的視窗只和當前網路擁堵的程度來決定一個報文段應該包含多少個位元組，

MSS：Max Segment Size，默認536byte實際資料，

以上圖說明，資料并不是一次發過去的，而是被分成了segment在TCP之間進行傳輸，所以傳輸的程序中，可能會出現很多問題：

1、有一部分可能到服務端，有一部分可能還在路由器中傳輸
2、程序中順序也有可能被打亂，所以TCP要根據報文的序列號進行排序
3、如果由于傳輸慢，可能需要重復發送報文
4、如果TCP判斷收到了重復報文，還需要去重

4.6 資料可靠性傳輸

停止等待協議：

重傳機制：

4.7 滑動視窗協議與累計確認（延時ack）

滑動視窗大小通過tcp三次握手和對端協商，而且受網路影響：

這樣只需要重新傳丟失的報文，對于已經ack的就不需要再傳輸了，

五、HTTPS協議

由于HTTP天生“明文”的特點，整個傳輸程序完全透明，任何人多能夠在鏈路中截獲、修改或者偽造請求/相應報文，資料不具有可信性，

因此就誕生了為安全而生的HTTPS協議，

使用HTTPS時，所有的HTTP請求和相應在發送到網路之前，都要進行加密，

HTTPS沒有對HTTP進行直接修改，而是提供了一些API，使得HTTP不再直接與TCP進行互動，而是與SSL/TSL（安全層）先互動（進行資料加密），而SSL/TSL再與TCP層進行互動，反過來，服務端到客戶端也是一樣，到達之前要先經過SSL/TSL進行解密，

5.1 SSL/TSL

SSL即安全套接層（Secure Sockets Layer），有網景公司與1994年發明，IEFT在1999年把它改名為TLS（傳輸層安全，Transport Layer Security），正式標準化，到今天TSL已經發展出了主流的三個版本，分別是2006年的1.1、2008年的1.2、2018年的1.3，每個新版本都緊跟著密碼學的發展和互聯網的現狀，持續強化安全和性能，已經成為了資訊安全領域中的權威標準，

摘要演算法

摘要演算法能夠把任意長度的資料壓縮成固定長度、而且獨一無二的“摘要”字串，就好像是給這段資料生成了一個數字“指紋”，任意微小的資料差異，都可以生成完全不同的摘要，所以可以通過把明文資訊的摘要和明文一起加密進行傳輸，資料傳輸到對方之后再進行解密，重新對資料進行摘要，再比對就能發現資料有沒有被篡改，這樣就保證了資料的完整性，

加密演算法

對稱秘鑰加密演算法

編、解碼使用相同秘鑰的演算法，如（AES，RC4，ChaCha20），

比如對原密碼進行一些亦或運算，需要有一個秘鑰，然后用原密碼和秘鑰進行亦或運算進行加密和解密，

非對稱秘鑰加密演算法

他有兩個秘鑰，一個叫“公鑰”，一個叫“私鑰”，兩個秘鑰是不同的，公鑰可以公開給任何人使用，而私鑰必須要嚴格保密，非對稱加密可以解決“秘鑰交換”的問題，網站秘密保管私鑰，在網上任意分發公鑰，你想要登錄網站只要用公鑰加密就行了，密文只能有私鑰持有者才能解密，而黑客因為沒有私鑰，所以就無法破解密文，非對稱秘鑰加密系統通常需要大量的數學運算，比較慢，如DH、DSA、RSA、ECC，

使用公鑰加密，就需要使用私鑰解密，
使用私鑰加密，就需要使用公鑰解密，

TLS里使用的是混合加密方式，即把對稱加密和非對稱加密結合起來，兩者互相取長補短，即能高效的加密解密，又能安全地進行秘鑰交換，大致流程如下：

1、通信開始的時候使用非對稱演算法如RSA，ECDHE先解決秘鑰交換的問題；

2、用亂數產生對稱演算法使用的“會話秘鑰”，再使用公鑰加密，會話秘鑰很短，所以即便使用非對稱加密演算法也可以很快的完成加解密，

3、對方拿到密文后用私鑰解密，取出會話秘鑰，完成對稱秘鑰的安全交換，后續就使用對稱演算法完成資料交換，

5.2 身份驗證

數字證書組成

CA資訊，公鑰用戶資訊，公鑰，權威機構的簽名，有效期，

數字證書作用

1、通過數字證書向瀏覽器證明身份
2、數字證書里包含了公鑰

建立TCP三次握手的前提是客戶端要拿到服務器的IP地址，如果在獲取的程序中被別人截獲了DNS的資訊，然后故意將DNS的IP地址故意指向到黑客自己的服務器，這樣就會偽裝成你客戶端要訪問的那臺服務器，這時候客戶端就會將資料直接發送到黑客的服務器上，而不是目標DNS服務器，所以一定要驗證目標服務器是準確的，而不是被人偽裝的服務器，

沒有數字證書，黑客會攔截TCP三次握手，讓服務器直接將資料發送到黑客自己的服務器上，

數字證書的申請和驗證

如何申請

1、生成自己的公鑰和私鑰，服務器自己保留私鑰
2、向CA機構提交公鑰，公司，域名資訊等認證
3、CA機構通過線上，線下等多種途徑驗證你提交資訊的真實性、合法性
4、資訊審核通過，CA機構則會向你簽發認證的數字證書，包含了公鑰、組織資訊、CA資訊、有效時間、證書序列號，同時生成一個簽名；

簽名步驟：hash（你用戶申請證書鎖提交的明文資訊）= 資訊摘要；CA再使用私鑰對資訊摘要進行加密，密文就是證書的數字簽名，

瀏覽器如何驗證

有了CA簽名過的數字證書，當瀏覽器訪問服務器時，服務器會回傳數字證書給瀏覽器，瀏覽器收到證書后會對數字證書進行驗證，

首先瀏覽器讀取證書中相關的明文資訊，采用CA簽名時相同的hash函式計算得到資訊摘要A，再利用對應的CA公鑰解密數字簽名資料得到資訊摘要B，如果摘要A和只要B一致，則可以確認證書是合法的，