粘包/拆包問題一直都存在,只是到TCP就拆不動了.

• 
  

• ??OSI open-system-Interconnection

• ??TCP/IP 5層協(xié)議棧

  • ??應(yīng)用層和操作系統(tǒng)的邊界是 系統(tǒng)調(diào)用 ，對應(yīng)到網(wǎng)絡(luò)編程是socket api

• ??TCP/UDP 概況

• ??TCP粘包問題

• ??結(jié)合TCP/IP報(bào)頭再回顧，柳暗花明

OSI開放系統(tǒng)互聯(lián)

定義了網(wǎng)絡(luò)框架，以層為單位實(shí)現(xiàn)協(xié)議，同時(shí)控制權(quán)逐層傳遞。

OSI實(shí)際并沒有落地，TCP/IP5層協(xié)議棧是目前主流的落地實(shí)現(xiàn)。

TCP/IP 5層協(xié)議棧

TCP/IP協(xié)議棧不止是傳輸層tcp/網(wǎng)絡(luò)層ip， 還包括應(yīng)用層等，這是一個(gè)協(xié)議簇，只是因?yàn)門CP/IP很具代表性。

不管是OSI還是TCP/IP5層協(xié)議棧，均會出現(xiàn)應(yīng)用程序和操作系統(tǒng)邊界(代碼執(zhí)行在用戶態(tài)/內(nèi)核態(tài))。

邊界調(diào)用被稱為系統(tǒng)調(diào)用system call，?socket api便是TCP/IP協(xié)議棧中應(yīng)用層的網(wǎng)絡(luò)編程接口。

TCP/UDP概覽

• ? TCP：?Transmission Control Protocol是面向連接的，可靠的，基于字節(jié)、雙向流式傳輸層協(xié)議。

• ? UDP：?USer Datagram Protocol面向消息的傳輸服務(wù)，傳輸?shù)臄?shù)據(jù)是有邊界的。

• 區(qū)別：

TCP可靠性是tcp三次握手的基礎(chǔ)，在此之上，增加了seq、ack數(shù)據(jù)確認(rèn)機(jī)制、 擁塞控制， 其中ack= seq+len(data)。

UDP：想法就發(fā)，不用三次握手建連，無粘包問題。

我們目前常見的應(yīng)用場景底層都是tcp，比如http請求、sql數(shù)據(jù)庫請求。

建立TCP連接之后，才能做http請求、sql請求，tcp連接很耗時(shí)，故服務(wù)器都存在連接池化機(jī)制。

這里我要給自己強(qiáng)調(diào)的是：開發(fā)者對于tcp一定不要帶入http請求-響應(yīng)模型,tcp是雙向通信流。

TCP粘包/拆包

粘包拆包問題在數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層以及傳輸層都有可能發(fā)生。

數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層的粘包和拆包問題都由協(xié)議自行處理了，日常應(yīng)用開發(fā)都在對接傳輸層，故面臨的是TCP粘包。

TCP粘包并不是TCP協(xié)議造成的問題，因?yàn)閠cp協(xié)議本就規(guī)定字節(jié)流式傳輸（算法決定：利用緩沖區(qū)，有擁塞控制，大小包合并），它不含消息、數(shù)據(jù)包等概念，需要應(yīng)用層自己設(shè)計(jì)消息邊界。

HTTP 超文本傳輸協(xié)議的規(guī)定如下：

---

附:TCP報(bào)頭、IP報(bào)頭

tcp報(bào)頭結(jié)構(gòu)：[源端口、目標(biāo)端口、SEQ/ACK在這定義]

ip報(bào)頭結(jié)構(gòu)：[源ip、目標(biāo)ip在這定義]

旁白

結(jié)合TCP報(bào)頭/IP報(bào)頭， 我們知道粘包、拆包一直都存在（TCP/IP報(bào)頭附錄里利用數(shù)據(jù)長度/偏移量，協(xié)助封包、拆包）。

只是協(xié)議棧一層層幫我們拆到TCP層的時(shí)候，如果沒有特殊機(jī)制，我們是沒有辦法區(qū)分應(yīng)用層斷續(xù)發(fā)送的請求/調(diào)用。?故同理應(yīng)對TCP粘包問題，上次應(yīng)用層需要使用特殊分隔符或者長度來協(xié)助封包/拆包。

點(diǎn)“贊”戳“在看”

體現(xiàn)態(tài)度很有必要!