上個星期介紹TCP協議時曾許諾本文將更具體地講解TCP協議。現在我們來介紹一下TCP協議的運行問題，因為我們對TCP協議實際上是什么樣子知道的并不多。

我們說過，TCP協議在能夠發送數據之前就建立起了“連接”。要實現這個連接，啟動TCP連接的那一方首先將發送一個SYN(回憶一下在上一篇文章中講到的TCP包頭格式)數據包。這只是一個不包含數據的數據包，然后，打開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協議之下連接速度開始很慢，然后速度逐漸加快。這個做法并不總是最理想的。