這是在學(xué)習(xí)中的總結(jié)，若有錯誤請大家不吝指正（^.^）

目前成都創(chuàng)新互聯(lián)公司已為近千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站運(yùn)營、企業(yè)網(wǎng)站設(shè)計、雷州網(wǎng)站維護(hù)等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

關(guān)于TCP/IP的三次握手：

當(dāng)服務(wù)端的狀態(tài)為LISTEN，客戶端的狀態(tài)為CLOSED時，客戶端發(fā)起連接

客戶端發(fā)送有SYN字段報文，此時狀態(tài)為SYN_SENT狀態(tài)

服務(wù)端接收該報文時，狀態(tài)處于SYN_REVD狀態(tài)，并向客戶端發(fā)送有SYN與ACK字段的報文

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

服務(wù)端接收到報文后，狀態(tài)處于ESTALISHED（建立）狀態(tài)，并開始數(shù)據(jù)的交互

關(guān)于糊涂窗口：

當(dāng)在網(wǎng)絡(luò)數(shù)據(jù)傳輸中，大量發(fā)送含有少量數(shù)據(jù)的報文（極端情況一個報文只有一字節(jié)數(shù)據(jù)），因為在協(xié)議層中對數(shù)據(jù)是層層封裝的過程，因此對于數(shù)據(jù)來說有大量的協(xié)議頭，傳輸開銷過大；或接收端在緩存區(qū)接受數(shù)據(jù)過慢；

解決方法：

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

直到所有發(fā)送的小包都有ACK回復(fù)且未設(shè)置TCP_CORK時；

直到有FIN字段時；

直到數(shù)據(jù)長度達(dá)到MSS時；

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

設(shè)置TCP_NODELAY且沒有設(shè)置TCP_CORK時；（就是不使用優(yōu)化算法啦）

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

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

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

沒有設(shè)置TCP_CORK并設(shè)置TCP_NODELAY時；（就是不使用優(yōu)化算法啦）

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

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

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

關(guān)于粘包問題：

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

解決方法：

當(dāng)數(shù)據(jù)傳輸是一次交互后立即斷開（多個Client與一個Server）時，數(shù)據(jù)無結(jié)構(gòu)時（文件傳輸，一方發(fā)另一方收），使用UDP時（有消息邊界）不會產(chǎn)生粘包問題；

發(fā)送端設(shè)置強(qiáng)制數(shù)據(jù)立即發(fā)送，不必等待緩存區(qū)滿（無處理優(yōu)化，效率降低）；

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

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

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