一、從一個請求來看網絡分層原理
1.1 複雜的網絡
以下為一次請求過程中可能遇到的問題，預示着網絡的複雜性。
1.2 如何簡化複雜度
為了簡化網絡的複雜度，網絡通信的不同方面被分解為多層次結構，每一層隻與緊挨着的上層或者下層進行互動，将網絡分層，這樣就可以修改，甚至替換某一層的軟體，隻要層與層之間的接口保持不變，就不會影響到其他層。
1.2.1 OSI( Open System Interconnection Reference Model): 開放系統互聯參考模型
1.2.2 TCP/IP 協定族
1.2.3 兩種協定的對應關系
應用層：應用程式負責的部分
傳輸層：TCP、UDP、SCTP 等
網絡層：IPv4、IPv6等
資料鍊路層：以太網、無限LAN(WIFI)
實體層：光纖、雙絞線電纜、無線裝置
1.3 一個請求的分層解析流程
請求各層之間都是調用對應層的接口(這個接口可以類比java中的接口，它可以有各種實作方式)。
1.在請求過程中域名是無法直接被計算機識别的，必須先轉換成ip，此時先檢測本地是否配置了host，如果沒有配置的話會發起一個dns請求。
2.DNS使用UDP作為傳輸層,DNS伺服器IP配置在你的作業系統中，可以直接擷取。
3.資料鍊路層在接收到網絡層調用後，會通過IP使用ARP協定擷取目前IP對應的MAC位址。
4.最終通過實體層将資料傳入路由器，路由器進行逆向解析(MAC位址->IP)，如果路由器判斷此資訊不是給自己的會将資訊繼續傳給下遊電信營運商。
5.營運商判斷是DNS請求還是HTTP請求，如果是DNS請求會調用DNS伺服器換取IP并傳回。
6.擷取IP後DNS請求完成，此時再次發送一次HTTP請求，HTTP在傳輸層使用的是TCP協定，其他層同理。
7.營運商判斷如果非DNS請求，那麼電信會通過營運商直接的協定進行消息的發送，最終找到ip對應的伺服器。
8.接收端伺服器的實體層接受到此次請求，通過對應的協定進行資料的層層解析擷取對應的資訊，最終将資料傳給本地伺服器（nginx、tomcat等），伺服器将響應封包通過HTTP方式将資料傳回。
一次請求的流轉如下圖：
二、HTTP協定
超文本傳輸協定(HyperText Transfer Protocol，HTTP)： 一種無狀态的，以請求/應答方式運作的協定，它使用可擴充的語義和自描述消息格式，與 基于網絡的超文本資訊系統靈活的互動
2.1 HTTP封包格式
請求封包和響應封包的結構基本相同。
起始行：描述請求或響應的基本資訊。
頭部字段集合：key-value結構，封包的詳細資訊。
消息體：真實傳輸的内容，可以是文本或二進制等。
2.1.1 HTTP請求封包
一個HTTP請求封包由請求行（request line）、請求頭部（header）、空行和請求資料4個部分組成，下圖給出了請求封包的一般格式。
2.1.1.1 請求行
請求行由請求方法字段、URL字段和HTTP協定版本字段3個字段組成，它們用空格分隔。例如，GET /index.html HTTP/1.1。
HTTP協定的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
2.1.1.2 請求頭部
請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒号“:”分隔。請求頭部通知伺服器有關于用戶端請求的資訊，典型的請求頭有：
User-Agent：産生請求的浏覽器類型。 Accept：用戶端可識别的内容類型清單。 Host：請求的主機名，允許多個域名同處一個IP位址，即虛拟主機。
2.1.1.3 空行
最後一個請求頭之後是一個空行，發送回車符和換行符，通知伺服器以下不再有請求頭。
2.1.1.4 請求資料
請求資料不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客戶填寫表單的場合。與請求資料相關的最常使用的請求頭是Content-Type（這個主體的對象類型）和Content-Length（主體的長度）。
2.1.1.5 頭部字段注意事項
字段名不區分大小寫，字段名裡不允許出現空格，可以使用連字元“-”，但不能使用下劃線“_”（有的伺服器不會解析帶“_”的頭字段）。字段名後面必須緊接着“:”，不能有空格，而“:”後的字段值前可以有多個空格； 字段的順序是沒有意義的，可以任意排列不影響語義； 字段原則上不能重複，除非這個字段本身的語義允許，例如 Set-Cookie。
2.1.2 HTTP響應封包
HTTP響應也由三個部分組成，分别是：狀态行、消息報頭、響應正文。
2.1.2.1 狀态行格式如下
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示伺服器HTTP協定的版本；Status-Code表示伺服器發回的響應狀态代碼；Reason-Phrase表示狀态代碼的文本描述。狀态代碼由三位數字組成，第一個數字定義了響應的類别，且有五種可能取值。
•1xx：訓示資訊–表示請求已接收，繼續處理。
•2xx：成功–表示請求已被成功接收、了解、接受。
•3xx：重定向–要完成請求必須進行更進一步的操作。
•4xx：用戶端錯誤–請求有文法錯誤或請求無法實作。
•5xx：伺服器端錯誤–伺服器未能實作合法的請求。
常見狀态代碼、狀态描述的說明如下：
•200 OK：用戶端請求成功。
•400 Bad Request：用戶端請求有文法錯誤，不能被伺服器所了解。
•401 Unauthorized：請求未經授權，這個狀态代碼必須和WWW-Authenticate報頭域一起使用。
•403 Forbidden：伺服器收到請求，但是拒絕提供服務。
•404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
•500 Internal Server Error：伺服器發生不可預期的錯誤。
•503 Server Unavailable：伺服器目前不能處理用戶端的請求，一段時間後可能恢複正常，舉個例子：HTTP/1.1 200 OK（CRLF）。
百度百科 狀态碼參考網址
2.1.2.1 響應頭
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:Date,X-API-Request-Id
Content-Encoding:gzip
Content-Type:application/json;charset=UTF-8
Date:Sun, 10 Mar 2024 12:00:17 GMT
2.1.2.2 響應實體内容
伺服器發給浏覽器，要讓浏覽器顯示的内容（html，js，css，圖檔，資料等資訊）。
三、HTTP請求完整過程
3.1 請求過程描述
1.首先浏覽器先解析URL中的域名。
2.通過域名擷取對應的ip位址，上邊已經說過ip是通過DNS伺服器擷取，我們可以在谷歌浏覽器中檢視到域名對應ip的解析。
3.擷取到IP位址後，浏覽器就可以發起與伺服器的三次握手
4.建立連接配接後，就開始組裝http請求，發送請求。
5.接收端收到請求後，開始處理請求解析請求頭中的資料，并生成對應的響應資料，給發送端傳回響應資料。
6.浏覽器收到響應後，會通過響應頭類型，解析對應的資料封包。
補充：上邊2中從浏覽器中擷取域名的步驟。
浏覽器中輸入：chrome://net-export/
打開對應檔案搜尋你想找的域名即可。
四、TCP協定
4.1 TCP協定描述
面向連接配接的，可靠的，基于位元組流的傳輸層通信協定
4.2 TCP協定特點
•基于連接配接的：資料傳輸之前需要建立連接配接
•全雙工的：雙向傳輸
◦用戶端和服務端可以互相雙向寫資料
•位元組流：不限制資料大小，打包成封包段，保證有序接收，重複封包自動丢棄
◦發送方：每次傳輸不限制資料大小，不是一次性将所有的資料都傳輸，會将資料切分成多個片段，并進行排序，通過網絡媒體傳輸給接收方。
◦接收方：不同的資料包會通過網絡不同的路線傳入接受方，是以接收方收到的資料有可能是亂序的，是以需要對資料包進行重排序。
•流量緩沖：解決雙方處理能力的不比對
•可靠的傳輸服務：保證可達，丢包時通過重發機制實作可靠性
•擁塞控制：防止網絡出現惡性擁塞
◦當網絡環境比較差的時候，會控制封包大小減小傳輸速率。
4.3 TCP連接配接管理
4.3.1 TCP連接配接四元組
四元組分别為：源位址、 源端口、 目的位址、 目的端口
4.3.2 TCP頭部格式
序列号：在建⽴連接配接時由計算機⽣成的随機數作為其初始值，通過 SYN 包傳給接收端主機，每發送⼀次資料，就累加⼀次該資料位元組數的⼤⼩。⽤來解決⽹絡包亂序問題。
确認應答号：指下⼀次期望收到的資料的序列号，發送端收到這個确認應答以後可以認為在這個序号以前的資料都已經被正常接收。⽤來解決不丢包的問題。
控制位：
ACK：該位為 1 時，确認應答的字段變為有效，TCP 規定除了最初建⽴連接配接時的 SYN 包之外該位必須設定為 1 。
RST：該位為 1 時，表示 TCP 連接配接中出現異常必須強制斷開連接配接。
SYN：該位為 1 時，表示希望建⽴連接配接，并在其序列号的字段進⾏序列号初始值的設定。
FIN：該位為 1 時，表示今後不會再有資料發送，希望斷開連接配接。當通信結束希望斷開連接配接時，通信雙⽅的 主機之間就可以互相交換FIN位為 的 TCP 段。
URG：當URG=1時，表明緊急指針字段有效。它告訴系統此封包段中有緊急資料，應該盡快傳送，而不按照原來的排隊序列來傳送。
PSH：推送（PuSH），當兩個應用程序進行互動式的通信時，有時一端的應用程序希望在鍵入一個指令之後就能立即收到對方的響應。在這樣的情況下，就可以使用推送操作，此時，發送方将PSH置為1，并建立一個封包發送出去，接收端接受到該封包，發現PSH為1，就盡快傳遞接受應用程序，而不用等到整個緩存都滿了之後再向上傳遞。
緊急資料指針：當發送端需要發送一些緊急資料時，可以設定緊急指針來訓示接收端，在接收到該指針之後盡快處理這些資料。緊急指針的值是一個相對于目前序列号的偏移量，用于訓示緊急資料在整個資料流中的位置。
視窗大小：目前伺服器緩存可接受的資料封包大小。
4.4 TCP 三次握手
說明：
1.開始時服務端和用戶端的連接配接處于斷開狀态。
2.服務端啟動後會監聽特定端口，處于監聽狀态，等待用戶端的請求。
3.用戶端發起請求，變更成發送狀态，此時會在請求中攜帶同步序列号 x。
4.服務端接受到請求後，儲存用戶端對應的資訊，并發送确認收到應答消息，此消息的應答碼需要在x的基礎上加1，此時服務端處于等待用戶端确認狀态。
5.用戶端收到服務端确認後，狀态變更為已連接配接，用戶端也需要給服務端回複确認收到，此時應答碼為服務端确認碼y+1。
6.服務端收到用戶端确認消息後，狀态變更為已連接配接。
7.連接配接建立成功，此為三次握手。
8.握手過程中會消耗序号，建立連結後不會消耗。
以下是三次握手的示例過程：
4.5 TCP 四次揮手
說明：
1.用戶端和服務端都可以主動發起關閉連接配接。
2.圖中為用戶端發起關閉連接配接，首先用戶端發起 FIN 關閉連接配接請求。
3.服務端收到關閉請求後，先回複收到關閉請求的确認消息給用戶端，此時用戶端處于等待關閉2狀态，等待服務端完成收尾工作，服務端完成收尾(剩餘未完成傳輸資料同步)，執行關閉連接配接方法，并給用戶端發送FIN 關閉連結請求。
4.用戶端收到關閉請求後，給服務端回複确認關閉應答消息，服務端關閉，用戶端處于等待狀态，此時需要等待兩個最大請求時長(防止服務端由于網絡原因未收到應答消息，服務端會重試發送FIN消息)。
5.等待時間到期後關閉連接配接。
4.5 TCP 可靠性傳輸
4.5.1 停止等待協定
描述：沒傳送一個封包，服務端都回複一個确認消息，效率低下。
4.5.1 重傳機制
4.5.1.1 ack丢失
描述：如果出現丢包如何處理
4.5.1.2 封包丢失
4.5.2 滑動視窗協定與累計确認（延時ack）
說明：
1.約定視窗大小為4，每次發送四個封包。
2.服務端收到後隻收到，1，2，4。 3丢失，此時服務端确認隻确認到2。
3.用戶端收到确認後，從3開始在滑動下一個視窗，進行資料傳輸。
參考文獻
OSI參考模型： https://baike.baidu.com/item/OSI%E5%8F%82%E8%80%83%E6%A8%A1%E5%9E%8B/708028?fr=aladdin
HTTP狀态碼： https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81?fromModule=lemma_search-box
TCP協定： https://baike.baidu.com/item/TCP/33012?fr=ge_ala
TCP與UDP的可靠性傳輸： https://zhuanlan.zhihu.com/p/636141175