一、DNS解析ip和埠號

二、建立TCP連線 -- 三次握手

TCP為可靠協議，通過使用滑動視窗協議，來保證資料的有序完整

TCP對網路阻塞的處理

（1)慢開始：每收到一個報文確認，視窗大小加一；傳輸資料時，剛開始時發的慢，如果不丟包，則調快傳送速率，如果丟包，則調低傳送速率；

（2）擁塞避免：當傳輸視窗大小到達閾值時，每次往返視窗，大小加一，加快傳送速率；當出現超時網路速率時，慢開始閾值為當前視窗的一半，重新開始慢開始階段；

（3）訊息補償：①快重傳：遇到報文丟失，接受方重複三次最近確認；②快恢復：傳送方收到三次確認，將視窗大小降一半併發送缺失報文。

UDP為不可靠協議：

• 不保證訊息交付：不確認，不重傳，無超時
• 不保證交付順序：不設定包序號，不重排，不會發生隊首阻塞
• 不跟蹤連線狀態： 不必建立連線或重啟狀態機
• 不需要擁塞控制： 不內建客戶端或網路反饋機制

三、在TCP連線的基礎上，進行http協議

http的發展：

1.0：基礎的HTTP協議，每一個通訊都需要建立一個TCP連線；

1.1：增加長連線：保持已建立的連線，可以重複使用；

​ 增加管道化功能：允許一個TCP連線傳送多個請求，不過會按順序處理，先處理完a請求，再處理b請求；但產生了請求隊頭阻塞問題，即先處理完a請求才能響應b請求；

2.0：將管道化改進為stream模型：將每一個請求或響應稱為一個數據流（stream），每一個數據流都有獨一無二的id，通過編號區分請求和響應，客戶端傳送的資料流id為奇數，服務端傳送的資料流id為偶數。http2可以取消某一次的請求，但保持tcp的連線，可以被其它請求使用。

增加了多工特性：同時受到了a請求和b請求，按順序處理a請求，處理中途發現a請求處理過程非常耗時，於是先發送a請求已經處理完的部分資料，然後去處理b請求，處理完b請求，再繼續處理a請求。解決了隊頭阻塞問題，但仍存在tcp滑動視窗資料幀隊頭阻塞問題。

頭資訊壓縮功能：將每次重複的欄位維護在客戶端和服務端的一張表中，頭資訊只攜帶索引，以減少寬頻消耗。

3.0：基於QUIC協議重新實現http2.0的特性

基於UDP和DH演算法建立連線，實現1RTT的安全握手，如果客戶端快取了會話資訊，則不需要建立連線，可以直接通訊；

基於UDP進行通訊，沒有tcp滑動視窗控制協議，沒有了tcp滑動視窗資料幀隊頭阻塞問題；

傳輸的基本單位是packet，加密單元也是packet，沒有了https加密隊頭阻塞問題；

將擁塞控制演算法從運輸層提升到應用層處理，可以更加靈活的切換不同演算法。

HTTPS協議

HTTPS協議是基於HTTP協議，通過SSL協議或者TSL協議提供加密處理資料、驗證對方身份以及資料完整性保護；

ssl協議過程：

1、客戶端給出協議版本號，一個隨機數a和客戶端支援的加密方法；

2、伺服器從客戶端支援的加密方法選擇一個，給出數字證書和一個隨機數b，數字證書可以公證伺服器，防止中間人假冒攻擊；

3、客戶端對伺服器資料證書進行檢驗，通過使用數字證書中的公鑰加密一個隨機數c；

4、伺服器根據私鑰解密隨機數c，此時客戶端和伺服器都知道隨機數a,b,c;

5、伺服器和客戶端根據三個隨機數和約定的加密方法生成對稱性金鑰加密接下來的通訊。

四、通訊完成，斷開TCP連線 -- 四次揮手

1、FIN-WAIT-2階段的作用：

因為伺服器接受到客戶端FIN報文，傳送確認後，會把CLOST-WAIT階段未傳送完的資料繼續傳送，而客戶端在FIN-WAIT-2階段等待伺服器傳送完資料，伺服器傳送完資料後會傳送一個FIN報文表示傳送完成，可以斷開連線。

2、為什麼客戶端在往伺服器傳送FIN報文後，會等待固定時間2MS的時間

因為服務端傳送的FIN報文後，可能因為網路阻塞到達不了伺服器，即使伺服器重新ping客戶端，也無法確定客戶端是網路阻塞還是已經關閉，為了防止無休止的等待，客戶端傳送後等待2MS的時間，出現網路阻塞，報文可能能到達服務端告訴服務端可以關閉了，即便服務端無法接收到FIN報文，也知道客戶端只等待2MS，時間到了，因此超過2MS後，可以直接關閉連線。

網路七層結構圖

五層協議：

物理層、鏈路層、網路層、運輸層、應用層

四層協議：

物理層、網路層、運輸層、應用層