tcp協議在能夠傳送資料之前就建立起了「連線」。要實現這個連線，啟動tcp連線的那一方首先將傳送乙個syn資料報。這只是乙個不包含資料的資料報， 然後，開啟syn標記。如果另一方同時在它收到syn標記的埠通話，它將發回乙個syn+ack:syn和ack標誌位都被開啟，並將ack(確認)編 號字段設定為剛收到的那個資料報的順序號欄位的值。接下來，連線發起方為了表示收到了這個syn+ack資訊，會向傳送方傳送乙個最終的確認資訊（ack 包）。這種syn、syn+ack、ack的步驟被稱為tcp連線建立時的「三次握手」。在這之後，連線就建立起來了。這個連線將一直保持活動狀態，直到 超時或者任何一方發出乙個fin(結束)訊號。
任何一方都可以關閉乙個tcp連線，要求雙方傳送乙個fin訊號關閉自己的通訊頻道。一方可以在另 一方之前關閉，或者雙方同時關閉tcp連線。因此，當一方傳送乙個fin訊號時，另一方可傳送「fin+ack」，開始關閉自己一方的通訊並且確認收到了 第乙個fin訊號。傳送第乙個fin訊號的人接下來再傳送乙個「fin+ack」資訊，確認收到第二個fin訊號。另一方就知道這個連線已經關閉了，並且 關閉了自己的連線。傳送第乙個fin的人沒有辦法收到最後乙個ack訊號的確認資訊。這時它會進入「time_wait」(等待時間)狀態並啟動乙個定時 器，防止另一方沒有收到ack資訊並且認為連線仍是開啟的。一般來說，這個狀態會持續1至2分鐘。
現在，我們來討論第乙個問題。如果有人(假如一 個黑客)在你的web伺服器上留下乙個半開或者半關的連線，那就是乙個壞訊息。每乙個連線都要消耗記憶體，開啟數千個虛假的tcp連線可能導致伺服器癱瘓。 當然，你實際上不可能在不影響tcp正常工作的情況下調整tcp定時器。如果你聽說過tcp syn 攻擊的話，那就是這個意思。為了防止出現這種情況，大多數作業系統都要限制半開連線的數量。例如，linux預設的限制一般是256個。
關於持續 流控制問題，現在我們就來討論這個問題。tcp中實現它的機制是tcp滑動視窗機制。tcp協議使用「重新傳送與正向ack」來保證資料傳輸的可靠性。發 送方將等待一段時間，如果沒有收到其傳送的資料報的ack確認資訊，傳送方就要重新傳送。順便說一下，tcp協議中有許多定時器。這只是其中乙個定時器。 ack的概念對於流控制是非常重要的，因為tcp滑動視窗協議使tcp的往復確認變得更有效率。如果tcp要傳送乙個資料報並且等待每乙個ack確認信 息，它實際上就把資料吞吐量削減了一半。
理想的情況是，我們能夠一次傳送許多資料報，然後等待收到乙個確認收到全部資料報的ack資訊，而不用對 方發來更多的資料。但是，我們如何知道傳送了多少個資料報呢?tcp視窗尺寸可以控制在「已傳送但是沒有確認」的狀態下能夠容納多少個資料報。如果這個窗 口尺寸很大，我們不必等待ack資訊就可以傳送大量的資料報。這實際上就是流控制。
接收方就是控制視窗大小的那一方。如果接收方將視窗大小設為 「0」，那麼，傳送方根本就不能傳送任何資料。如果這個視窗的尺寸是「1」，那麼，我們就回到了簡單的「傳送和等待ack」的協議。如果最後的視窗尺寸是 「0」，傳送者將發出乙個探測訊號以搞清這個視窗什麼時間再次開啟。如果傳送方從來沒有收到ack資訊，它就一直不斷地重試，直到定時器過期。請記住，這 個視窗尺寸在tcp頭中是乙個16位欄位。如果你要乙個視窗尺寸(按位元組計算)大於16位可以表示的容量（2的16次方個位元組），還可以使用乙個名為「窗 口縮放」的tcp協議選項。這個選項允許視窗尺寸乘以比例因子。如果沒有極大的視窗尺寸，tcp協議就就無法充分利用gb級別的高速連線。這也是我們需要 針對這些新的高速連線調整tcp引數的原因，
關於tcp流控制的問題，我們不能不提一下nagle演算法。如果我們在乙個telnet連線上使用一 個大的tcp視窗會發生什麼事情呢?你會輸入乙個指令（例如敲了乙個字母），然後一直等待回應它卻遲遲不出現在終端回顯上。這對於實時通訊來說是乙個大問 題。而且，telnet也會增加網路的阻塞度，因為乙個位元組的資料（例如我們的一次擊鍵）需要40個位元組的包頭。於是rfc 896定義這個nagle演算法，用以消除小的資料報。這個思路是我們應該在資料傳送之前給先把小資料集中起來然後一次性傳送，以便提高效率。為了更有效 率，它還限定只允許存在乙個未經確認的資料段，你在得到確認資訊之前不能傳送更多的資料。telnet和互動ssh連線使用tcp_nodelay套介面 選項啟用這個功能，這樣當你按下乙個按鍵的時候，你能夠立即得到乙個回應。
當然，我們仍是忽略了有關tcp協議的許多事情。然而，通過這兩篇文章的了解，你應該能夠理解其它一些更專業的tcp著作。阻塞控制與流控制不同，本文沒有討論。如果你真的對了解tcp協議的全部工作原理感興趣，你可以詳細閱讀tcp rfc。
小結
tcp 協議非常善於解決流控制問題，因此非常適應於許多應用程式。tcp協議中的流控制的含義是:「在收到對傳送的資料的確認資訊這前，我可以傳送多少資料?」 這就是tcp視窗。學習阻塞控制的問題可以留作讀者的練習。需要指出的是，在tcp協議之下連線速度開始很慢，然後速度逐漸加快。這個做法並不總是最理想 的
TCP視窗機制
視窗機制原理 比如主機a主機 b傳送資料，為了更高的通話效率，主機 a一次給主機 b發了三次資料。主機 a給主機 b傳送了乙個大的資料 主機 b收到資料以後他的視窗大小只能處理其中的一部分資料那麼主機 b就會向主機 a恢復乙個確認值三個資料都收到了，但是他的視窗大小只顯示處理了 2個資料，那麼主機 ...
tcp歡動視窗機制 TCP滑動視窗機制
滑動視窗 tcp流量控制 介紹udp時我們描述了這樣的問題 如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。tcp協議通過 滑動視窗 sliding window 機制解決這一問題。看下圖的通訊過程 滑動視窗 1.傳送端發起連線，宣告最大段尺寸是...
TCP滑動視窗機制
tcp協議在能夠傳送資料之前就建立起了 連線 要實現這個連線，啟動tcp連線的那一方首先將傳送乙個syn資料報。這只是乙個不包含資料的資料報，然後，開啟syn標記。如果另一方同時在它收到syn標記的埠通話，它將發回乙個syn ack syn和ack標誌位都被開啟，並將ack 確認 編 號字段設定為剛...