TCP粘包， UDP丟包， nagle算法

1、TCP粘包

1. 何時考慮粘包

1.   若是利用tcp每次發送數據，就與對方創建鏈接，而後雙方發送完一段數據後，就關閉鏈接，這樣就不會出現粘包問題（由於只有一種包結構,相似於http協議,UDP不會出現粘包現象）。關閉鏈接主要要雙方都發送close鏈接（參考tcp關閉協議）。如：A須要發送一段字符串給B，那麼A與B創建鏈接，而後發送雙方都默認好的協議字符如"hello give me sth abour yourself"，而後B收到報文後，就將緩衝區數據接收,而後關閉鏈接，這樣粘包問題不用考慮到，由於你們都知道是發送一段字符。

2. 若是發送數據無結構，如文件傳輸，這樣發送方只管發送，接收方只管接收存儲就ok，也不用考慮粘包

3. 若是雙方創建鏈接，須要在鏈接後一段時間內發送不一樣結構數據，如鏈接後，有好幾種結構：
    1)"hello give me sth abour yourself" 
    2)"Don't give me sth abour yourself" 
      那這樣的話，若是發送方連續發送這個兩個包出去，接收方一次接收可能會是"hello give me sth abour yourselfDon't give me sth abour yourself" 這樣接收方就傻了，究竟是要幹嗎？不知道，由於協議沒有規定這麼詭異的字符串，因此要處理把它分包，怎麼分也須要雙方組織一個比較好的包結構，因此通常可能會在頭加一個數據長度之類的包，以確保接收。

2. 粘包出現的緣由 ：  在流傳輸中會出現（如TCP），UDP不會出現粘包（數據報傳輸）

     發送端須要等緩衝區滿才發送出去，形成粘包  （nalge算法也可能形成粘包現象）
     接收方不及時接收緩衝區的包，形成多個包接收    

3. 粘包解決的辦法

一是對於發送方引發的粘包現象，用戶可經過編程設置來避免，TCP提供了強制數據當即傳送的操做指令push，TCP軟件收到該操做指令後，就當即將本段數據發送出去，而沒必要等待發送緩衝區滿；

二是對於接收方引發的粘包，則可經過優化程序設計、精簡接收進程工做量、提升接收進程優先級等措施，使其及時接收數據，從而儘可能避免出現粘包現象；

三是由接收方控制，將一包數據按結構字段，人爲控制分屢次接收，而後合併，經過這種手段來避免粘包。

還有的笨方法是在兩次send函數之間添加 sleep函數， 顯然會下降數據傳輸效率

以上提到的三種措施，都有其不足之處。

第一種編程設置方法雖然能夠避免發送方引發的粘包，但它關閉了優化算法，下降了網絡發送效率，影響應用程序的性能，通常不建議使用。

第二種方法只能減小出現粘包的可能性，但並不能徹底避免粘包，當發送頻率較高時，或因爲網絡突發可能使某個時間段數據包到達接收方較快，接收方仍是有可能來不及接收，從而致使粘包。

第三種方法雖然避免了粘包，但應用程序的效率較低，對實時應用的場合不適合。

4.  解決粘包的工程方法：

上面處理TCP粘包的方案： 存在不一樣程度的硬傷 ， 在工程上並不適用，工程項目中，根據數據傳輸的特色，推薦兩種可選擇的方案：

     1. 添加標誌字段，在每次發送數據是添加標記字段：A： =>size 標記數據長度的方式  B：特定標記字段標記數據的結尾（模仿幀的設計方式）＝>結束符的方式

    2. 定義應用層的數據通信協議 ：=>若是數據按照必定的方式存儲或着優加密的需求， 能夠經過本身定製 數據通信協議對數據封裝，並實現本身的數據 封包｜ 拆包函數。

細節： 

1. 環形緩衝實現方案是定義兩個指針,分別指向有效數據的頭和尾.在存放數據和刪除數據時只是進行頭尾指針的移動.

2、UDP丟包

1.丟包的主要緣由

1. 接收端處理時間過長致使丟包：調用recv方法接收端收到數據後，處理數據花了一些時間，處理完後再次調用recv方法，在這二次調用間隔裏，發過來的包可能丟失。對於這種狀況能夠修改接收端，將包接收後存入一個緩衝區，而後迅速返回繼續recv.

2. 發送的包較大，超過接受者緩存致使丟包：包超過mtu size數倍，幾個大的udp包可能會超過接收者的緩衝，致使丟包

3. 發送的包頻率太快：雖然每一個包的大小都小於mtu size 可是頻率太快

2. 解決方案

1 模擬tcp三次握手協議，經過使用Timer定時器監視發送請求後接受數據的時間，若是一段時間內沒有接受到數據包則斷定丟包，並從新發送本次請求

2. 換TCP 

3、nagle算法

  nagle 算法   糊塗窗口綜合症(Silly Windw Syndrome)    TCP_NODELAY 選項  （百度百科）

4、長連接  vs 短連接 

1.長鏈接

           Client方與Server方先創建通信鏈接，鏈接創建後不斷開， 而後再進行報文發送和接收。

2.短鏈接

          Client方與Server每進行一次報文收發交易時才進行通信鏈接，交易完畢後當即斷開鏈接。此種方式經常使用於一點對多點