TCP粘"包"問題淺析及解決方案Golang代碼實作

一、粘“包”問題簡介

在socket網路編程中，都是端到端通信，客戶端埠+客戶端IP+服務端埠+服務端IP+傳輸協議就組成一個可以唯一可以明確的標識一條連接，在TCP的socket編程中，發送端和接收端也同樣遵循這樣的規則，

1、部分字符和亂碼的可能原因

如果發送端多次發送字串，接收端從socket讀取資料放到接收資料的recv陣列，由于recv陣列初始化為\0，僅收到部分字串就開始列印，該部分字串放在recv陣列中，末尾仍是以\0結尾，列印函式見到\0則默認結束列印輸出，后部分資料還未讀取到就出現讀取字符不完整的情況，如果出現亂碼，則可能是因為，定義的recv陣列容量不夠，接收端的資料占滿recv陣列之后，列印函式仍會尋找以\0為邊界的字符作為結束標志，這樣從記憶體中就會讀取資料的時候越界，記憶體中存在的資料不一定可讀，列印函式在按照字符的格式輸出就會顯示亂碼，所以有時候在socket編程的時候，會出現讀取字串不完整或者亂碼的現象，

接收雙方收發資料的時候直接在這樣一條連接中進行，TCP是面向位元組流的協議，資料像是在管道中流動一樣，在TCP看來，資料之間并沒有明確的邊界，

2、粘“包”的可能原因

TCP并沒有包這一概念，而所謂的包可能是報文段或者，發送端一次發送的資料被誤稱為包，而粘包的現象主要表現在兩方面：
1、發送端在發送資料的時候，為了避免頻繁發送負載量極小的報文段導致的傳輸性價比低的問題，默認使用優化演算法，在收集多個小的報文之后，在適當的條件一次發送，由于TCP發送的資料沒有邊界，發送方發送的資料就看起來像粘在一起形成一個包一樣，
2、接收端在接受資料的時候，由于快取的存在，并不會直接把接受的資料直接移交上層應用層，而是會考慮時間和快取容量從快取中讀取資料，如果TCP接收資料包的快取的速度大于應用層從快取中讀取資料包的速度，多個包就會被快取，應用程式就有可能讀取到多個首尾相接像是粘到一起的包，

3、粘“包”的發生

粘“包”問題也并不是一直都需要解決，如果發送方發送的多組資料本來就是同一塊資料的不同部分，比如說一個檔案被分成多個部分發送，這時則不需要處理粘包現象，當時更多的情況下，發送的多個資料包并不相關，則需要去解決粘包問題，

比如甲和乙要進行通信，甲先后給乙發送大小為200位元組和100位元組的資料包A和B，如果將資料包A分為a1和a2兩個負載量更小的資料包，那么這兩個資料包之間就不存在粘包問題，因為它們本來就屬于同一組資料，但是由于是順序發送的，a2和B就可能產生粘包問題，發送端應用層知道A和B的邊界，但是對于接收端TCP接受的是位元組流，所以乙的應用層并不知道要把哪些作為一個有效的資料包，

4、解決方案

所以粘包根本問題還是在于，TCP是面向位元組流的，而位元組流是沒有邊界的，因此要解決粘包問題就要發送端和接收端約定某個位元組作為資料包的邊界或者規定固定大小的資料作為一個包，放在了上層應用層來實作，

方案一：結束標志控制，以指定字符（串）為包的結束標志，這種協議就是接收端在位元組流中每次遇到標志符號，比如"\r\n"就認為是一個包的末尾，把每次遇到"\r\n"之前的資料進行封裝當做一個資料包，但是有時候發送的資料本身就攜帶這些標志字符，因此需要做轉義，以免接收方誤地當成包結束標志而錯誤的進行資料打包，
方案二：固定資料包長度，就是每次發送的資料包的長度固定，如果資料不夠，需要用特殊填充填滿資料包，如果過長，則需要分包，
方案三：包頭包體格式資料(TLV：Type, Lenght, Value)，也就是發送方接收方事先約定好，每個包由包頭和資料負載部分組成，包頭長度固定，包含資料型別和資料長度，這兩個欄位占用的長度固定，假設分別為4個位元組，資料負載部分占用的長度由包頭中資料長度欄位的值決定，比如一個資料包如下，那么接收端的先接收到8個位元組的資料就取出包頭，從而得到資料的型別，知道資料的長度為個位元組，依次從接下來的資料流中讀取10個位元組，就可以得到該資料包的完整內容，

上述例子假設采用UTF-8編碼，一個英文字符等于一個位元組，一個中文（含繁體）等于三個位元組，

無法決議？
那會不會出現個別位元組的丟失，導致某些資料包的包頭無法決議，從而錯誤封包呢？
至少在發送端和發送程序中不會，因為TCP是可靠通信，可以通過序列號和重傳機制保證資料包有序并且正確的到達接收端，

二、Golang代碼實作

基于上述方案三，代碼實作采用的是發送端和接收端兩方約定好資料(訊息)的封包和拆包機制，那么接收方發送的時候按照訊息頭(訊息ID或者訊息型別+訊息長度)和訊息物體部分發送，接收方按照同樣的格式讀取，從訊息頭中讀取訊息型別和訊息長度，然后從管道中讀取訊息長度的位元組數，

1、資料打包介面

先定義資料打包工具的抽象介面

/*
定義一個解決TCP粘包問題的封包和拆包的模塊
——針對Message進行TLV格式的封裝
  ——先后Message的長度，ID和內容
——這對Message進行TLV格式的拆包
  ——先讀取固定長度的head-->訊息內容長度和訊息的型別
  ——再根據訊息的長度，進行一次讀寫，從conn中讀取訊息的內容
 */

//封包，拆包模塊，直接面向TCP連接中的資料流，用于處理TCP粘包的問題

type IDataPack interface {
	// 獲取包的長度
	GetHeadLen() uint32
	//封包方法
	Pack(msg IMessage) ([]byte, error)
	//拆包方法
	Unpack([]byte) (IMessage, error)
}

2、訊息封裝

資料封裝成訊息

//訊息包含訊息ID，訊息長度，訊息內容三部分
type Message struct {
	Id      uint32 //訊息的ID
	DataLen uint32    // 訊息長度
	Data    []byte //訊息內容
}

//創建一個Message訊息包
func NewMsgPackage(id uint32, data []byte) *Message{
	return &Message{
		Id: id,
		DataLen: uint32(len(data)),
		Data: data,
	}
}

//獲取訊息ID
func (m *Message) GetMessageID() uint32{
	return m.Id
}

//獲取訊息內容
func (m *Message) GetMessageData() []byte{
	return m.Data
}

//獲取訊息長度
func (m *Message) GetMessageLen() uint32{
	return m.DataLen
}

//設定訊息相關
func (m *Message) SetMessageID(id uint32){
	m.Id = id
}

//設定訊息相關
func (m *Message) SetMessageData(data []byte){
	m.Data = https://www.cnblogs.com/welan/p/data
}

//設定訊息長度
func (m *Message) SetMessageLen(length uint32){
	m.DataLen = length
}

3、封包拆包實作

具體的拆包和封包邏輯實作

//拆包封包的具體模塊
type DataPack struct {
	dataHeadLen uint32
}

//拆包封包實體的初始化方法
func NewDataPack() *DataPack {
	return &DataPack{}
}

// 獲取包的長度
func (dp *DataPack) GetHeadLen() uint32{
	//DataHeadLen：uint32（4個位元組）+ID：uint32（4個位元組）=8個位元組
	return 8
}

//封包方法, Message結構體變成二進制序列化的格式資料
func (dp *DataPack) Pack(msg *IMessage) ([]byte, error){
	//創建一個存放bytes位元組的緩沖
	dataBuff := bytes.NewBuffer([]byte{})

	//注意寫入的順序
	//將dataLen寫入databuff中
	//這里涉及到一個網路傳輸的大小端問題，大端序，小端序
	if err := binary.Write(dataBuff, binary.LittleEndian, msg.GetMessageLen()); err !=nil{
		return nil, err
	}

	//將MessageID寫入databuff中
	if err := binary.Write(dataBuff, binary.LittleEndian, msg.GetMessageID()); err !=nil{
		return nil, err
	}

	//將data寫入databuff中
	if err := binary.Write(dataBuff, binary.LittleEndian, msg.GetMessageData()); err !=nil{
		return nil, err
	}

	//二進制的序列化回傳
	return dataBuff.Bytes(), nil
}

//拆包方法（）
func (dp *DataPack) Unpack(binaryData []byte) (*Message, error){
	//創建一個輸入二進制資料的ioReader
	dataBuff := bytes.NewBuffer(binaryData)

	//接受訊息,直解壓head，獲得datalen和id
	msg := &Message{}

	//讀取dataLen
	//這里的&msg.DataLen是為了寫入地址
	if err := binary.Read(dataBuff, binary.LittleEndian, &msg.DataLen); err!=nil{
		return nil, err
	}

	//這里的從dataBuff讀取資料，應該是連續讀，先讀len，然后讀id，不會重復
	//讀取dataID
	if err := binary.Read(dataBuff, binary.LittleEndian, &msg.Id); err != nil{
		return nil, err
	}

	//這里還可以加一個判斷datalen是否超出定義的長度的邏輯

	//只需拆包湖區msg的head，然后通過head的長度，從conn中讀取一次資料
	return msg, nil
}

封包拆包的時候還涉及到大小端的問題，具體是指，一個字符需要多個位元組才能表示，在記憶體中這些位元組是按照從大到小的地址空間存盤還是從小到大，發送接收雙方事先約定好，否則就會不同的順尋著對接收資料的決議順序不同出錯，還有從Socket中讀取資料流的時候是按照順序的，因此一旦讀出來socket中就沒了，

其他：具體的建立socket鏈接，創建陣列接收資料就不寫了= _ =...，博客僅作為學習筆記的記錄，如果說的不對，及時改正，輕噴輕噴，感謝感謝，

三、參考

粘包問題：詳解傳送門1
粘包問題：詳解傳送門2
大小端問題：詳解傳送門

標籤：Go

上一篇：C語言 assert 函式 - C語言零基礎入門教程

下一篇：golang 標準庫template的代碼生成