TCP的運輸連接管理
TCP是面向連接的協議，有三個階段：連接建立、數據傳送 和 連接釋放。運輸連接的管理就是使運輸連接的簡歷和釋放都能正常地進行。
在TCP連接建立過程中要解決一下三個問題：
1、 要使每一方都能夠確知對方的存在： 所以需要三次握手。
2、 要允許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量等）。
3、 能夠對運輸實體資源（如緩存大小、連接表中的項目等）進行分配：建立TCB。
TCP連接的建立采用跟客戶-服務器模式。主動發起連接建立的應用進程叫做客戶端，而被動等待連接建立的應用進程叫做服務器。
*TCP三次握手 四次揮手
http://blog.csdn.net/whuslei/article/details/6667471
建立連接時：首先服務器被動打開處於listen狀態，客戶端啟動后向服務器發送syn報文，服務器收到后發送syn+ack報文，然后客戶端再向服務器發送ack報文；此時連接建立；可以發送數據；
當客戶端已經沒有數據要發送給服務器時，客戶端想服務器發送fin報文，服務器收到后發送ack確認自己收到了，此時客戶端不能在向服務器發送數據了，但服務器仍然可給客戶端發送數據，當服務器發送完數據后，服務器發送一個fin報文告訴客戶端我已經發完數據了，客戶端回復一個ack確認報文，接下來，客戶端會等待2MSL時間，因為確認報文可能中途丟失，如果在這2MSL等待時間內服務器沒有發來任何消息說明服務器已經收到了報文，這是客戶端就可以關閉了，服務端在收到ack報文時也可以關閉；
MSL（Maximum Segment Lifetime）即最長報文段壽命，RFC建議為2分鍾，具體實現時可以使用更小的值。
保活計時器（keepalive timer）：
當客戶端發生故障時，服務端不能再收到客戶端的數據，因此應當有措施是服務器不要白白等待下去。服務器每收到一次客戶的數據，就重新設置保活計時器，時間的設置通常是兩小時。若兩小時沒有收到客戶的數據，服務器就發送一個探測報文段，以后則每隔75秒發送一次。若一連發送了10個探測報文段后仍無客戶的響應，服務器就認為客戶端出了故障，接着就關閉這個連接。在這期間，若客戶端重新啟動收到了探測報文，則客戶端發送一個復位信息，讓服務器關閉連接。
狀態轉移圖，異常轉移，課后習題。
為什么需要三次握手和四次揮手？
三次握手：嚴格來說即使N次握手也不能保證雙方百分百成功建立連接，因為只要最后一次確認丟失，雙方就處於一種信息不對稱的狀態（這種不對稱是當前時間點的不對稱，對這個時間點以前的信息對稱的）。成功建立連接的標志應該是：互相都知道對方都准備好傳輸數據，這種情況至少需要三次握手。以A為客戶端，B為服務器端為例， 假如只使用一次握手：A向B發送了一個報文，然后雙方都認為連接建立，這種情況其實已經相當於UDP無連接了，沒有任何意義；假如使用二次握手：A向B發送syn報文，B向A發送一個ACK報文（可能也報文syn字段），這時B已經知道了A要向他建立連接，雙方的信息基本對稱了，然而此時B到A的報文段有可能丟失，那么A就無法判斷B是否收到了自己的連接請求，A狀態未知，B也知道A的這種情況，所以需要第三次握手，即A想B發出ACK報文，這時雙方都知道對方都已經准備好傳輸數據（之前的的時間點准備好，當前的狀態仍然是不對稱）。
以上只是考慮了數據包丟失的情況，如果出現數據包延遲達到，就會出現“已失效的連接請求報文段”，比如A向B發送的連接請求報文延遲達到B，B誤以為是新的連接請求，然后接受發出ACK報文，如果是二次握手B此時就進入了establishing 狀態，但這是種錯誤的狀態，因為A早已放棄這個連接了。
總之多少次握手都無法保證百分百成功建立連接，因為最后一次報文可能出現丟失，延遲達到等各種情況。三次握手成功只是能說明雙方現在已經有相當高的概率可以正常通信了。
四次揮手：四次揮手實際上就是兩個FIN報文和兩個ACK報文，這四個報文必不可少。A沒有數據要發送了必然會向B發送一個fin報文，B必然要回復個ACK報文。為什么B不能學習三次握手將fin和ack合二為一？，因為B受到fin報文后要通知上層應用程序，上層應用程序可能數據沒有發送完畢，這時就不能發送fin，即使是發送完了，B也不應該將兩者合二為一（通知上層應用可能需要很多時間，這些都是不確定的），最好的方法就是先發送ACK告訴對方，然后在合適的時機發送自己的fin。
在 TCP C/S 模式下，當 TCP 客戶端想斷開的時候，不能用 shutdown 和 closesocket 與 TCP 服務器斷開，只有讓 TCP 服務器端主動斷開（TCP 客戶端被動斷開），TCP 客戶端的端口才能立刻被釋放。http://blog.csdn.net/HackerJLY/article/details/6116857
服務器端能不能主動斷開連接？
可以，但是主動斷開連接的一方要等待2MSL，在這期間內核不會釋放資源，這對服務器來說是不利的。
斷開連接后需要做哪些處理工作？
回收資源：socket、內存、端口號。
TCP 長連接和短連接
參考文獻：http://www.cnblogs.com/liuyong/archive/2011/07/01/2095487.html
http://www.cnblogs.com/cswuyg/p/3653263.html
http://blog.chinaunix.net/uid-26000296-id-3758651.html
http://blog.sina.com.cn/s/blog_9720724f0101feg4.html
短連接: 指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成后，則斷開此TCP連接;
一般銀行、http服務器都使用短連接。短連接一般是一對多。
長連接: 指在一個TCP連接上可以連續發送多個數據包，在TCP連接保持期間，如果沒有數據包發送，需要雙方發檢測包以維持此連接；p2p、數據庫連接。
通常的短連接操作步驟是： 連接→數據傳輸→關閉連接；
而長連接通常就是： 連接→數據傳輸→保持連接(心跳)→數據傳輸→保持連接(心跳)→……→關閉連接；
KeepAlive
參考文獻：
http://www.bubuko.com/infodetail-260176.html
http://www.cnblogs.com/cswuyg/p/3653263.html
KeepAlive在TCP和http中有不同的含義；
TCP中keepalive在上文中的保活計時器中已經說明；
http中的keepalive的意義實際上是使用持久連接（長連接），以前對於每個http請求都是建立一次連接。這樣每個連接只能傳輸一個http請求和響應，為了提高效率，可以在HTTP的頭域中增加Connection選項。當設置為Connection:keep-alive表示開啟，設置為Connection:close表示關閉。顯示一個頁面往往需要幾十個請求，用持久連接的方式只需要建立一次連接就行。
網絡編程之TCP和UDP
