TCP的運輸鏈接管理

TCP的運輸鏈接管理

TCP是面向鏈接的協議，有三個階段：鏈接創建、數據傳送 和 鏈接釋放。運輸鏈接的管理就是使運輸鏈接的簡歷和釋放都能正常地進行。

在TCP鏈接創建過程當中要解決一下三個問題：

一、  要使每一方都可以確知對方的存在： 因此須要三次握手。

二、  要容許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量等）。

三、  可以對運輸實體資源（如緩存大小、鏈接表中的項目等）進行分配：創建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