本節將介紹一條tcp連線是如何建立和拆除的。此處假設客戶機a上面的乙個程序想要和服務
器b上的乙個程序建立一條tcp連線。本文前面介紹的是比較正常的連線和拆除，特殊的會在後面介紹。
第一步客戶機a的tcp會向伺服器的tcp傳送乙個不包含應用層資料的資料的tcp報文段。該報文段中首部標誌位s yn被置為1，此報文段也被叫做syn報文段。並且a會隨機地選擇乙個初始序號（client_isn），將其填入首部中的序號字段（注意為了避免某些安全性的攻擊，此處的隨機化選擇有著不少研究，後面會補充）。然後，該報文被封裝進ip資料報，傳送給伺服器。
第二步一旦tcp syn報文段的ip資料報到達伺服器後，伺服器就會從ip資料報中提取出tcp syn報文段，為該tcp連線分配tcp快取和變數，並向客戶機傳送允許tcp連線的報文段，這個報文段也不包含應用層資料。（這裡需要注意如果在完成三次握手的第三步之前分配快取和變數會使得tcp易受到稱為syn洪氾的拒絕服務攻擊服務）
在傳送的報文中，標誌位syn被置為1，確認序號被置為client_isn+1，
伺服器也會選用乙個初始序號將其放入報文中的序號字段。這個報文有時也會被稱為synack報文段（synack segment）。
第三步在收到synack報文段後，客戶也要給這個連線分配快取和變數。然後，客戶機a會向伺服器傳送對允許連線
報文的確認，完成連線的建立。此時報文中，syn置為0，確認序號為sever_isn+1。在此報文段中也可以攜帶客戶機到伺服器的資料了。
完成這三個步驟後，客戶機和伺服器就可以相互傳送包含資料的報文段啦。在以後的每個報文中syn都為0。
建立連線需要傳送三個報文，所以這個過程也叫3次握手（three-way shakehand）。
那麼問題也出來了。為什麼需要三次握手，只交換兩次報文不可以嗎？
可以簡單地解釋下，客戶傳送確認伺服器傳送的接收連線報文是為了防止以前的連線請求即失效連線請求傳送到伺服器而造成錯誤。
有連線必然就有釋放的時候。釋放的過程可以見下圖。
tcp連線釋放示意圖
第一步客戶程序發出關閉tcp連線命令。客戶tcp便會向伺服器程序傳送標誌位fin=1的報文段，便進入fin_wait_1階段。伺服器tcp收到該報文段後就向客戶機傳送確認報文段並通知上層應用程式該tcp連線即將關閉，然後，伺服器進入close_wait階段。
第二步客戶機tcp收到確認報文，然後進入fin_wait_2階段，等待來自伺服器的含有fin=1的報文段。
伺服器在這段時間還是可以向客戶機傳送含上層應用程式資料的報文段，客戶機接收並傳送確認報文。最後，伺服器tcp向客戶機傳送含fin=1的報文段，便進入lase_ack階段。
第三步客戶機tcp收到含fin=1的報文段向伺服器發出確認報文，便進入time_wait階段，等待2msl後便釋放所有連線所佔資源。如果客戶給伺服器傳送的確認報文丟失，那麼在這段時間內，便可進行重傳操作。這段時間一過，客戶將釋放所有連線所佔資源。
伺服器tcp收到客戶機的確認ack後便釋放連線所佔資源。
記得在前面說過伺服器收到乙個syn後，會分配快取並初始化一些相關變數。然後向客戶傳送synack進行響應，並等待來自客戶的ack報文段。如果某個客戶不傳送ack完成三次握手的第三步，最終（通常在一分多鐘後）伺服器將終止該半開連線並**資源。
這種tcp連線管理協議為經典的dos攻擊即syn洪氾攻擊（syn flood attack）提供了環境。在這種攻擊中，攻擊者傳送大量的tcp syn報文段，而不完成三次握手中的第三步，伺服器為大量的這種半開連線分配資源，最終將導致伺服器的連線資源殆盡。
好的是，現在有一種有效的防禦系統——syn cookie [rfc 4987]，其工作方式可以描述如下：
以上是正常的連線和釋放的過程，下面會對上面進行一些補充。
tcp半關閉
tcp支援半關閉操作，如前描述的釋放連線第二步中，客戶機傳送了乙個fin報文給伺服器，伺服器傳送了確認後，客戶機這邊就進入半關閉狀態，但是仍然可以接收來自伺服器傳送的資料。即「我完成了資料的傳送工作，並傳送了乙個fin給對方，但是我任然希望收到來自對方的資料直到它傳送給乙個fin給我」。在伺服器未傳送fin的這段時間裡，它可以傳任意數量的報文段給客戶。當伺服器傳送fin然後fin被確認，那麼整個連線將完全被關閉。
同時開啟與關閉
兩個應用程式同時主動開啟連線可能不大可能，但是在特定安排的情況下還有可能實現。這要求通訊雙方收到對方syn之前必須先傳送乙個syn，兩個syn必須經網路到達對方，並要求通訊雙方告知對方其ip位址和埠號。伺服器始終未被動開啟，所以不會出現這種情況。
與正常連線相比，多了乙個報文段。資料報的syn將置位直到接收到乙個ack資料報為止。
同時關閉與前面的正常關閉並沒有太大的區別。在通訊中，雙方都會主動傳送fin，然後進行關閉。
同時關閉和正常關閉是相同數量的報文段。兩者真正的區別在於報文段序列是交叉的還是順序的。
將tcp首部rst欄位置位的報文段被稱為「重置報文段」或者「重置」。一般來說，當發現乙個到達的報文段對於相關連線而言不正確時，tcp會傳送乙個重置報文段。（此處，相關連線是指由重置報文段的tcp與ip首部的四元組所指定的連線）。
針對不存在的埠的連線請求
通常，當乙個連線請求到達本地卻沒有相關程序在目的埠偵聽時就會產生重置報文段。
udp協議中規定，當乙個資料報到達不能使用的目的埠時就會生成乙個icmp目的地不可達（埠不可達）的訊息。
tcp則是使用重置報文段來代替相關工作。
對於被tcp重置的報文段而言，它的ack位欄位必須被置位，並且ack號字段的數值必須在正確視窗範圍內。這樣有助於防止他人攻擊。
終止一條連線
終止一條正常連線的方法是由通訊一方傳送fin。這種方法也被稱為有序釋放。在這種情況下，tcp快取中所有排隊的資料都被傳送，通常沒有資料丟失。
然而，在任何時刻，我們都可以通過傳送乙個重置報文段替代fin來終止一條連線。這種方式也被稱為終止釋放。
終止一條連線為應用程式提供兩大特性：
需要注意：
重置報文段不會被通訊另外一端做出任何響應，即它不會被確認。接收重置報文段的另一段會終止連線並通知應用程式當前連線已被重置。
半開連線
如果在未告知另一端的情況下通訊的一端關閉或者終止連線，那麼就認為該tcp連線處於半開狀態。這種情況一般發生在通訊一方的主機崩潰。只要不嘗試通過半開連線傳輸資料，正常工作的一端不會檢測另一端已經崩潰。產生半開連線的另外乙個共同原因是某台主機的電源被切斷而非正常關機。
時間等待錯誤
設計time_wait狀態的目的是允許任何受制於一條關閉連線的資料報被丟棄。在這段期間，等待tcp通常不需要做任何操作，它只需要維持當前狀態直到2msl的計時結束。然而，如果它在這段時間內收到任何關於這條連線的一些報文段，或者是更加特殊的重置報文，它將被破壞。這種情況被稱為時間等待錯誤（time-wait assaaination twa rfc[1337]）。
為解決這個問題，許多系統規定當處於time-wait狀態時不對重置報文做出反應。
TCP連線管理
tcp是面向連線的協議，因此每個tcp連線都有三個階段 連線建立 資料傳送和連線釋放。tcp連線的管理就是使運輸連線的建立和釋放都能正常進行。在tcp連線建立的過程中，要解決以下三個問題 要使每一方都能確知對方的存在。要允許雙方協商一些引數 如最大視窗值 是否使用視窗擴 項 時間戳選項以及服務質量等...
TCP連線管理
一些基本的概念可以先看另一篇部落格 這篇直接對tcp連線過程做筆記 1.tcp連線詳細過程 假設執行在主機 客戶 的乙個程序想跟另一台主機 伺服器 上程序建立乙個連線 第一步 客戶端的tcp首先向服務端的tcp傳送乙個特殊的tcp報文段。該報文段不包含應用層資訊。報文段的syn 標誌位 置1。因此這...
TCP的連線管理
tcp是面向連線的協議。運輸連線是用來傳送tcp報文的。連線運輸就有三個階段，即 連線建立 資料傳送和連線釋放。在tcp連線建立過程中要解決以下三個問題 1 要使每一方能夠確知對方的存在。2 要允許雙方協商一些引數 如最大視窗值 是否使用視窗擴 項和時間戳選項以及服務質量等 3 能夠對運輸實體資源 ...