防止黏包現象的出現
當視窗數為 0 時，傳送者不能正常傳送資料段，除非:
-urgent資料。比如，使用者想殺掉遠端機器上的程序的時候，可以傳送資料
-傳送者可以傳送乙個位元組的資料段，以便讓接收者再次傳送期待接收的位元組號和視窗數（避免死鎖）
考慮乙個指向某互動式編輯器（遠端）的telnet 連線，該編輯器對使用者的每次擊鍵都作出響應，在最壞的情況下：
當使用者敲入乙個字元的時候，被送到傳輸實體，建立乙個21位元組的資料段，在傳到網路層，變成了41位元組的ip分組
接收方（執行著編輯器的遠端機）收到這個資訊後，會立傳送乙個40位元組的確認分組 （20位元組的 tcp段頭和20位元組的ip頭）
隨後，當編輯器讀取出這個位元組，tcp實體傳送乙個視窗更新， 這個分組也是40位元組
最後，當編輯器處理了這個字元，它傳送乙個41位元組的分組作為該字元的回顯
總共累計起來，對於每個敲入的字元，需要至少 162 位元組的頻寬（還沒有考慮到鏈路層的開銷），傳送4個資料段。
怎樣優化接收端
接收端可以推遲500ms傳送確認分組和視窗更新視窗，以便可以免費搭載在處理後的回顯分組內（free ride）
怎樣優化傳送端
nagle's algorithm (1984):
- 當資料以一次一位元組的速度到達的時候，只傳送第乙個位元組，然後將後續的位元組快取起來，直到發出的位元組得到確認
- 將快取起來的位元組在乙個資料段中發出，再繼續快取，直到發出的資料得到確認
- nagle演算法在很多tcp上實現，但是有些時候最好禁用，比如： 當乙個x-windows應用在網際網路執行的時候，滑鼠的移動事件必須傳送給遠端計算機，把這些移動事件收集起來一批一 批發送出去，使得滑鼠的移動極不連貫
另乙個使tcp效能退化的問題是傻瓜視窗綜合症（silly window syndrome problem）：當有大塊資料被傳遞給傳送端tcp實體，
但接收端的互動式應用每次只讀取乙個位元組的時候，問題就來了
每次接收1位元組
clark解決方案 ：阻止接收方傳送只有1個位元組的視窗更新，相反，它必須等待一段時間，當有了一定數量的空間之後再告訴傳送方
接收方可以可以維護乙個內部緩衝，且阻塞上層應用的 read 請求，直到它有大塊的資料提供
tcp傳輸的是全雙工的位元組流。
tcp適配收發雙方的資料流量
-window size
tcp還需要效率
-發方優化： nagle』s algorithm
-收方優化： clark』s solution
TCP傳輸策略
基於tcp的各類解決方案，可以根據資料吞吐量來大致分成兩大類 1 互動資料型別，例如telnet，ssh，這種型別的協議在大多數情況下只是做小流量的資料交換，比如說按一下鍵盤，回顯一些文字等等。2 資料成塊型別，例如ftp，這種型別的協議要求tcp能盡量的運載資料，把資料的吞吐量做到最大，並盡可能的...
TCP傳輸的三次握手四次揮手策略
tcp傳輸的三次握手 首先傳送端 前端 傳送乙個帶有syn標誌的資料報給對方。1.接收端 後端 收到後，回傳乙個帶有syn ack標誌的資料報以表示傳達確認資訊。2.傳送端 前端 在回傳乙個帶ack標誌的資料報，代表 握手 結束 3.若在握手過程中某個階段莫名中斷，tcp協議會再次以相同的方式傳送相...
說說TCP傳輸的三次握手四次揮手策略
為了準確無誤地把資料送達目標處，tcp協議採用了三次握手策略。用tcp協議把資料報送出去後，tcp不會對傳送 後的情況置之不理，它一定會向對方確認是否成功送達。握手過程中使用了tcp的標誌 syn和ack。傳送端首先傳送乙個帶syn標誌的資料報給對方。接收端收到後，回傳乙個帶有syn ack標誌的資...