- OSI open-system-Interconnection
- TCP/IP 5層協議棧
- 應用層和作業系統的邊界是 系統呼叫 ，對應到網路程式設計是socket api
- TCP/UDP 概況
- TCP粘包問題
- TCP/IP報頭深思
OSI開放系統互聯
定義了網路框架，以層為單位實現協議，同時控制權逐層傳遞。
OSI實際並沒有落地，TCP/IP 5層協議棧是目前主流的落地實現。
TCP/IP 5層協議棧
TCP/IP協議棧不止是傳輸層tcp/網路層ip， 還包括應用層等，這是一個協議簇，只是因為TCP/IP很具代表性。
不管是OSI還是TCP/IP5層協議棧，均會出現應用程式和作業系統邊界(程式碼執行在使用者態/核心態)。
邊界呼叫被稱為系統呼叫system call， socket api便是TCP/IP協議棧中應用層的網路程式設計介面。
TCP/UDP概覽
-
TCP：
Transmission Control Protocol是面向連線的，可靠的，基於位元組的、雙向流式傳輸層協議。 -
UDP：
USer Datagram Protocol面向訊息的傳輸服務，傳輸的資料是有邊界的。
區別：
TCP可靠性是tcp三次握手的基礎，在此之上，增加了seq、ack資料確認機制、 擁塞控制， 其中ack= seq+len(data)。
UDP： 想法就發，不用三次握手建立連線。
我們目前常見的應用場景底層都是tcp，比如http請求、sql資料庫請求。
建立TCP連線之後，才能做http請求、sql請求，tcp連線很耗時，故伺服器都存在連線池化機制。
這裡我要給自己強調的是：開發者對於tcp一定不要帶入
http請求-響應模型,tcp是雙向通訊流。
TCP粘包/拆包
TCP粘包並不是TCP協議造成的問題，因為tcp協議本就規定流式傳輸（由演算法決定，固定緩衝區、擁塞控制、大小包合併），它不含訊息、資料包等概念，需要應用層自己設計訊息邊界。
粘包拆包問題在資料鏈路層、網路層以及傳輸層都有可能發生。
資料鏈路層，網路層的粘包和拆包問題都由協議自行處理了，我們日常的網路應用開發都在對接傳輸層，故面臨的粘包問題指的是TCP粘包。
HTTP 超文字傳輸協議的規定如下：
附錄： ip報頭結構：[源ip、目標ip在這定義]
旁白
梳理了整個TCP/IP協議棧的流程，結合TCP報頭/IP報頭， 我們就知道粘包、拆包一直都存在，只是拆到TCP層的時候，我們沒有辦法區分應用層斷續傳送的請求/呼叫， 這就是我們口口相傳的TCP粘包/拆包問題， 需要應用層用特殊分隔符或者長度解析。