應用層
負責應用程序之間的數據溝通
網絡通信協議： 網絡數據傳輸中的數據格式規定
自定義協議
序列化： 將數據對象按照持久化存儲或者網絡數據傳輸的格式來排布。
反序列化： 對持久化存儲或者傳輸的數據以指定的協議進行解析的過程。
知名協議
HTTP ——超文本傳輸協議
URL —— 統一資源定位符（網址）
URL編碼
因爲URL中特殊字符都具有特殊含義，因此查詢字符串中有特殊字符時，會造成二義性，因此需要對用戶提交的數據進行編碼。
編碼規則：
將需要轉碼的字符轉爲16進制，然後從右到左，取4位(不足4位直接處理)，每2位做一位，前面加上%（進行標識），編碼成%XY格式。
URL解碼
在查詢字符串中每遇到%，則表示之後的兩個字符需要進行URL解碼。
HTTP協議格式
HTTP請求
首行： [方法] + [URL] + [版本]
Header： 請求的屬性，冒號分割的鍵值對;每組屬性之間使用\n分隔;遇到空行表示Header部分結束。
Body： 空行後面的內容都是Body， Body允許爲空字符串。如果Body存在，則在Header中會有一個 Content-Length屬性來標識Body的長度。
GET所提交的數據在URL中(有長度的限制)，POST所提交的數據在正文中。
HTTP響應
首行： [版本號] + [狀態碼] + [狀態碼解釋]
Header： 請求的屬性,，冒號分割的鍵值對，每組屬性之間使用\n分隔，遇到空行表示Header部分結束。
一些重要頭部： Content-Length、Content-Type、Cookie、Set_Cookie、Transfer-Encoding、Location
Body： 空行後面的內容都是Body，Body允許爲空字符串。如果Body存在，則在Header中會有一個 Content-Length屬性來標識Body的長度。如果服務器返回了一個html頁面，那麼html頁面內容就是在body中。
傳輸層
負責數據能夠從發送端傳輸接收端(進程與進程之間)
端口號
端口號(Port)標識了一個主機上進行通信的不同的應用程序(進程)，在TCP/IP協議中, 用 “源IP”， “源端口號”， “目的IP”，“目的端口號”，“協議號” 這樣一個五元組來標識一個通信(可以通過 netstat -n查看)。操作系統拿到網卡接受的數據之後，通過數據中的端口號知道數據被存放到哪一個socket的緩衝區中
查看知名端口號 cat /etc/services
傳輸層的傳輸協議
UDP
UDP協議包含字段
源端口/目的端口： 傳輸，確定數據應該那個端口處理
校驗和： 二進制的反碼求和
數據包長度： uint_16類型
- 意味着UDP數據報最大的長度是64k，若sendto給予的數據大於64k-8(前面的信息長度爲8)則會報錯，因爲UDP在傳輸層不會進行數據分段。
- 若傳輸的數據大於64k，則用戶需要在應用層將數據分割成一個一個小段進行傳輸。
- UDP傳輸並不保證數據包的有序到達，因此也需要用戶在應用層進行包序管理，所以UDP要求數據整條接受，否則造成數據出錯。
- UDP提供整條數據嚮應用層交付（也不會出現半個數據，因爲頭部中有報文長度標識），也正因爲數據報長度在協議頭中有標識，因此UDP不會產生粘報問題。
UDP協議端格式
UDP的特點
無連接： 知道對端的IP和端口號就直接進行傳輸, 不需要建立連接。
不可靠： 沒有確認機制， 沒有重傳機制；如果因爲網絡故障該段無法發到對方， UDP協議層也不會給應用層返回任何錯誤信息。
面向數據報： 數據整條收發，靈活性低，但是不會造成粘包問題；不能夠靈活的控制讀寫數據的次數和數量。
UDP傳輸速度快，實現了傳輸層廣播數據包。
UDP的緩衝區
- UDP沒有真正意義上的發送緩衝區（不會使用緩衝區，接受到數據後都會直接封裝，然後直接交給網絡層）。調用sendtod會直接交給內核，由內核將數據傳給網絡層協議進行後續的傳輸動作。
- UDP具有接收緩衝區.，但是這個接收緩衝區不能保證收到的UDP報的順序和發送UDP報的順序一致；如果緩衝區滿了，再到達的UDP數據就會被丟棄。
TCP協議
TCP的特點
可靠傳輸
提高性能： 滑動窗口機制、延遲應答機制、捎帶應答機制
因爲tcp爲了實現可靠性傳輸犧牲了部分傳輸性能，並且有可能因爲ACK確認應答丟失也要重傳數據，因此提出了以下幾種機制來避免大量丟包重傳以及ACK丟失重傳來保證性能不再降低。
滑動窗口機制
流量控制+快速重傳機制+擁塞控制
流量控制
- tcp通過雙方協商窗口大小進行流量控制，避免因爲緩衝區數據塞滿而大量丟包重傳。
- 通過協議字段中的窗口大小，雙方進行協商，一次可以能最多傳輸多少條數據，之後等待確認應答，不需要進行一一停留。
- 雙方都維護一個窗口大小，發送方先框住一部分數據，接受到確認應答後，框開始向後移動發送數據，對方同樣在窗口中使用框滑動的方式接受。
快速重傳機制
- 每條數據的確認回覆都必須按序回覆，若前面的數據沒有收到，則不會對後邊的數據進行回覆。意味着若收到一條回覆，表示ACK確認序號之前的數據全部安全到達，不會因爲前邊的數據的ACK丟失而重傳數據。
- 若前邊的數據丟失，則接受方收到後發的數據立即發送重傳請求，並且連發三次，若發送方連續收到三次重傳請求，則認爲數據丟失，進行重傳。
- tcp對相同的數據包會丟棄，這樣就算前面的數據因爲延遲到達或者丟包，都不會對重傳請求造成影響，因爲無論是延遲到達還是重新發送的數據報到達，都可以減少等待確認前面數據丟包的時間。
- 如果數據次序發生錯誤，當前面的數據未收到，收到後面的數據，先將收到的後面的數據放入緩衝區，等待前面的數據到達後，再將緩衝區的數據取出。
擁塞控制
慢啓動，快增長
- 雙方雖然窗口可能很大，但是發送的數據並不大(因爲剛開始時不知道網絡狀態)，發送數據成功後，之後發送的數據按指數的增長形式，直到達到閾值，則不再增長。
- 發送端控制一個擁塞窗口，再進行數據傳輸時進行網絡探測式的發送，若網絡狀態良好時發送的數據快速增長，達到閾值，則不再繼續增長。若傳輸過程中出現丟包，則重新初始化擁塞窗口。
- 擁塞控制爲了避免網絡狀態因爲網絡狀態不好導致通信初始，大量數據包丟失導致重傳的情況，降低性能。
延遲應答機制
接收方收到數據後並不立即確認回覆，而是等待一段時間，因爲這段延遲的時間內，有可能用戶已經recv將緩衝區中的數據取走，窗口就可以儘可能的保證最大大小，保證傳輸吞吐量。
捎帶應答機制
接收方對每一條數據的確認回覆，都需要發送一個tcp數據報，但空包頭的傳輸會降低性能，因此會在即將要發送的數據包頭中包含確認信息（可以少發一個確認的空包頭）。
面向字節流
傳輸靈活
- 發送方每次調用send都會將數據放到發送緩衝區中，然後內核選擇合適的時機發送數據。
- 接收方網卡接受到數據，都會將數據放到接受緩衝區中，用戶recv就是從接受緩衝區取數據。
粘報問題主要發生的位置
- 發送緩衝區中的數據堆積
- 接受緩衝區中的數據堆積
粘包本質原因： 數據之間沒有明顯的邊界，tcp只管傳輸數據的字節流導致發送端/接受端因爲數據的堆積在實際發送或recv時一次獲取到半條或多條數據。
解決辦法： tcp在傳輸層沒有數據邊界，但是用戶可以在應用層進行邊界處理
常見方法： 特殊字符間隔(HTTP)，定長數據(UDP頭中包含長度)
TCP協議段格式
TCP異常
發送端機器掉電/網線斷開，接收端認爲連接還在，一旦接收端有寫入操作，接收端發現連接已經不在了， 就會進行reset。即使沒有寫入操作，TCP自己也內置了一個保活定時器，會定期詢問對方是否還在。如果對方不在，也會把連接釋放。
另外，應用層的某些協議，也有一些這樣的檢測機制。例如HTTP長連接中，也會定期檢測對方的狀態。斷線之後，也會定期嘗試重新連接。
tcp協議棧有自身的保活機制： 長時間無數據通信，則發送保活探測包，進行鏈接探測，若多個探測包都沒有響應，則認爲斷開鏈接。
鏈接斷開的體現： recv返回0，send出發SIGPIPE異常。
注： 具體的TCP/UDP使用可參見博客《Linux — 網絡套接字編程》
https://blog.csdn.net/lw13572259173/article/details/93165915