TCP三次握手、糊涂窗口、粘包問題

這是在學習中的總結，若有錯誤請大家不吝指正（^.^）

關于TCP/IP的三次握手：

當服務端的狀態為LISTEN，客戶端的狀態為CLOSED時，客戶端發起連接

客戶端發送有SYN字段報文，此時狀態為SYN_SENT狀態

服務端接收該報文時，狀態處于SYN_REVD狀態，并向客戶端發送有SYN與ACK字段的報文

客戶端接收到該報文時，狀態處于ESTABLISHED（建立）狀態，并發送有ACK字段的報文

服務端接收到報文后，狀態處于ESTALISHED（建立）狀態，并開始數據的交互

關于糊涂窗口：

當在網絡數據傳輸中，大量發送含有少量數據的報文（極端情況一個報文只有一字節數據），因為在協議層中對數據是層層封裝的過程，因此對于數據來說有大量的協議頭，傳輸開銷過大；或接收端在緩存區接受數據過慢；

解決方法：

發送端使用Nagle算法，當發送包長度小于MSS大小時會等待一會，發送條件是：

直到所有發送的小包都有ACK回復且未設置TCP_CORK時；

直到有FIN字段時；

直到數據長度達到MSS時；

直到等待超時（一般200ms）；

設置TCP_NODELAY且沒有設置TCP_CORK時；（就是不使用優化算法啦）

（當小包的ACK字段接收較快時算法的作用不大）

發送端使用CORK算法，會將小包拼接成大包，是協議頭在協議報文的比重減小，發送條件是：

拼接的報文大于MTU或超時；

沒有設置TCP_CORK并設置TCP_NODELAY時；（就是不使用優化算法啦）

（當小包的傳輸時間間隔不短時影響實時性，因為都要等待超時傳輸）

接收端使用Clark解決，只要有數據到達就確認，但宣布窗口大小為0，直到緩存空間夠容納一個MSS或緩存空間一半已空；

接收端延遲確認，直到緩存空間足夠為止，防止TCP發送端窗口的滑動，可以減少通信量，不必確認每個報文段，但延遲的確認會導致重發。

關于粘包問題：

因為要解決糊涂窗口而使數據積攢發送，或收端不及時接受緩存區數據而同時接收多個包，會導致發送的原數據接收后拼接在一起無法分離。

解決方法：

當數據傳輸是一次交互后立即斷開（多個Client與一個Server）時，數據無結構時（文件傳輸，一方發另一方收），使用UDP時（有消息邊界）不會產生粘包問題；

發送端設置強制數據立即發送，不必等待緩存區滿（無處理優化，效率降低）；

接收端優化編程方法，精簡接收過程，提高接收優先級等使其接收效率提高（不能完全避免）；

接收端按結構字段、人為控制多次接收，然后合并（效率低，對實時場合不適用）；

在這里問一下，怎么美化呀，之前看別人的博客很酷炫的