http://blog.csdn.net/lostyears/article/details/7104349 。此篇博客中詳細講解了TCP連接和斷開方式 和其中存在的一些問題。我在此簡要整理一遍。
一.TCP連接
TCP連接基於三次握手，使得客戶端和服務器都進入數據發送就緒狀態。其與UDP同爲傳輸層協議。
1. 客戶端先服務器發送一個包。包結構主要爲： 發送序列(假設爲200)，同步標識(SYN=1)。然後進入等待狀態，等待服務器的確認幀
2. 服務器收到客戶端的包後向客戶端發送確認包。包結構爲：發送序列(假設爲500)，確認序列201(客戶端發送序列+1), 同步標識(SYN=1), 確認標識(ACK=1)。然後進入等待狀態，等待客戶端的確認幀。
3. 客戶端收到服務器的確認包後，向服務器回覆確認包：確認序號501(服務器發送序號+1)，確認標識(ACK=1)
三次握手完畢後服務器和客戶端變爲連接established狀態可以開始發送數據。
相關問題：
(1). 爲什麼要採用3次而不採用2次
因爲服務器和客戶端要對初始序列進行協商。而二次握手容易產生死鎖：客戶端向服務器發送包後，服務器向客戶端返回確認幀並直接進入數據發送狀態。 如果服務器的確認幀丟失了，則客戶端一直等待確認幀而忽略服務器發來的數據，而服務器由於數據未收到確認幀一直進行超時重傳，從而產生了死鎖。
二.TCP斷開
TCP斷開採用4次握手，先保證雙方都不再發送數據，然後才進入close狀態
1. 客戶端先向服務器發送FIN包(表示數據發送終止) 包結構爲: 發送序列200， 確認序列500，兩個標識ACK=1, FIN=1。 然後等待接受確認幀，此時客戶端仍然可以接受服務器的數據。
2. 服務器接受到FIN包後，先向服務器發送確認幀：發送序列500， 確認序列201，確認標識ACK=1. 此時如果服務器還有數據發送，則可以繼續發送數據。
3. 服務器數據發送完畢後向客戶端發送FIN包： 發送序列501，ACK=1, FIN=1。然後等待客戶端的確認幀。
4. 客戶端收到服務器的FIN包後向服務器發送確認幀：發送序列201,ACK=1。客戶端等待2倍的最大網絡延遲(2msl)後關閉。
相關問題
(1) 斷開爲什麼要採用4次握手
因爲斷開的時候服務器可能仍然有數據要發送，所以不能在發送確認幀的同時發送FIN包。
(2) 客戶端發送完確認幀後爲什麼要等待2msl
因爲客戶端發送的確認幀可能在網絡中丟失，所以預留一點時間進行超時重傳。
三. TCP擁塞機制
http://blog.csdn.net/sicofield/article/details/9708383 此篇博客中詳細講解了TCP的擁塞機制 和其中存在的一些問題。我在此簡要整理一遍。
1. 擁塞的定義
計算機網絡中的帶寬，交換節點中的緩存處理機等都是網絡的資源，在某一段時間內，網絡中對某一資源的請求超過了該資源可用部分從而網絡性能變壞稱爲擁塞。
2. 慢開始
發送方維持一個擁塞窗口，擁塞窗口的大小由小到大自動增長，發送窗口的大小小於等於擁塞窗口(考慮到接受方的接受能力)
慢開始算法：一開始將擁塞窗口設置爲一個很小的值，每發送數據收到一次確認幀後就增加擁塞窗口大小，增加值爲收到確認幀的個數。所以其正則是指數型的。
3. 擁塞避免
爲了防止擁塞窗口過大，設置一個正則門限值ssthresh, 當窗口小於門限值時使用慢開始算法，當大於門限值時使用擁塞避免算法。
擁塞避免算法：每當經過一個往返時間RRT就將擁塞窗口加1而不是加倍。所以窗口增長緩慢。
無論是慢開始階段還是擁塞避免階段，只要判斷爲網絡擁塞（沒有收到確認報文）就將門限值設置爲發送窗口大小的一般，然後擁塞窗口大小重置爲開始時候的字節.。
3. 快重傳
發送方只要一收到三個重複確認，就直接重傳對方未收到的報文段，而不必等待設置的重傳計時器到期。 客戶端收到一個失序的報文後立即發送回一個重傳確認報文。
4. 快恢復
當發送方收到三個重複確認時，就執行乘法減小算法，將ssthresh減小爲一半，但是並不執行慢開始算法，而將擁塞窗口設置爲閾值的大小，然後執行擁塞避免算法。
路由器的丟棄策略對擁塞的影響
路由器採用先進先出的方式轉發分組，當路由器緩存裝不下新到來的分組時候就丟棄分組，使得許多的TCP連接進入擁塞，從而啓動慢開始算法，使得網絡通信量突然降低許多，而網絡恢復後又突然增加許多。這稱爲全局同步。
隨機檢測RED算法
路由器設定一個隊列的最小門限 和 最大門限 並計算隊列的長度。
1.如果新來的分組使得隊列長度小於最小門限則直接加入到隊列中
2. 如果大於最小門限，小於最大門限則隊列中以某一概率將此分組丟棄。
3. 如果大於最大門限，則直接丟棄。
此算法使得網絡中報文數據增長變得平緩，從而增加了網絡通信量。
