最近半年都是在對接協議，可能是心態問題，這個協議真的是不想看，一大串的數字，亂七八糟的文檔，無從下手的項目；
還好，最終的結果是需要接入的都接入了，什麼國標，企標，tcp，udp，mqttt。 好久就想寫一片文章來總結下，協議，到底是個什麼鬼東西！
百度百科： 協議：* 網絡協議的簡稱，網絡協議是通信計算機雙方必須共同遵從的一組約定。如怎麼樣建立連接、怎麼樣互相識別等。只有遵守這個約定，計算機之間才能相互通信交流。它的三要素是：語法、語義、時序。* 中間幾個關鍵詞，共同遵守，約定。通俗的來講就是規則，鬥地主的規則，麻將的規則，國標就是國家規定的打麻將的規則，企標就是企業規定的打麻將的規則。一起打麻將的人要一起遵守，纔有的玩，要是有人不認。估計得捱揍。 網絡層協議，tcp udp, 應用層協議，http，ftp 這裏所說的網絡層和應用層來自於計算機網絡的五層協議：
除去下面的鏈路層和物理層，tcp 和 udp 應該屬於應用協議的最底層了。而 http 和 ftp 這些協議都是基於 tcp 和 udp 的封裝的應用層協議； TCP：首先，tcp 是一種可靠的協議，很多人都聽過三次握手，什麼是三次握手，上圖 
假設 Client 端發起中斷連接請求，也就是發送 FIN 報文。Server 端接到 FIN 報文後，意思是說 “我 Client 端沒有數據要發給你了”，但是如果你還有數據沒有發送完成，則不必急着關閉 Socket，可以繼續發送數據。所以你先發送 ACK，“告訴 Client 端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息”。這個時候 Client 端就進入 FIN_WAIT 狀態，繼續等待 Server 端的 FIN 報文。當 Server 端確定數據已發送完成，則向 Client 端發送 FIN 報文，“告訴 Client 端，好了，我這邊數據發完了，準備好關閉連接了”。Client 端收到 FIN 報文後，“就知道可以關閉連接了，但是他還是不相信網絡，怕 Server 端不知道要關閉，所以發送 ACK 後進入 TIME_WAIT 狀態，如果 Server 端沒有收到 ACK 則可以重傳。“，Server 端收到 ACK 後，” 就知道可以斷開連接了 "。Client 端等待了 2MSL 後依然沒有收到回覆，則證明 Server 端已正常關閉，那好，我 Client 端也可以關閉連接了。Ok，TCP 連接就這樣關閉了！
斷包，粘包，丟包
斷包，粘包的問題出現的原因 參考了這麼多的文章，感覺自己的程序出現斷包的原因應該是緩衝區的問題，如果一個 tcp 的發送的報文在 1460 字節以內，斷包的出現大部分原因是出現自己的程序裏面。因爲以太網中存在一個對於幀的有效數據大小的限制，即 MTU，以太網的 MTU 爲 1500 字節。 ip 首部有 20 字節，tcp 首部有 20 字節（udp 首部 8 字節），所以除了網絡因素，造成斷包的原因還是出在自己的程序裏面。（還有就是一種就是傳輸的速率太快）
http