TCP和UDP處在同一層---運輸層，但是TCP和UDP最不同的地方是，TCP提供了一種可靠的資料傳輸服務，TCP是面向連線的，也就是說，利用TCP通訊的兩臺主機首先要經歷一個“撥打電話”的過程，等到通訊準備結束才開始傳輸資料，最後結束通話。所以TCP要比UDP可靠的多，UDP是把資料直接發出去，而不管對方是不是在收信，就算是UDP無法送達，也不會產生ICMP差錯報文，這一經時重申了很多遍了。
把TCP保證可靠性的簡單工作原理:
應用資料被分割成TCP認為最適合傳送的資料塊。這和UDP完全不同，應用程式產生的 資料報長度將保持不變。由TCP傳遞給IP的資訊單位稱為報文段或段
當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能 及時收到一個確認，將重發這個報文段.
當TCP收到發自TCP連線另一端的資料，它將傳送一個確認。這個確認不是立即傳送，通常將推遲幾分之一秒.
TCP將保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸 過程中的任何變化。如果收到段的檢驗和有差錯， T P將丟棄這個報文段和不確認收到此報文段(希望發端超時並重發)。
既然TCP報文段作為IP資料報來傳輸，而IP資料報的到達可能會失序，因此TCP報文段 的到達也可能會失序。如果必要， TCP將對收到的資料進行重新排序，將收到的資料以正確的順序交給應用層。
TCP還能提供流量控制。TCP連線的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端傳送接收端緩衝區所能接納的資料。這將防止較快主機致使較慢主機的緩衝區溢位。
從這段話中可以看到，TCP中保持可靠性的方式就是超時重發，這是有道理的，雖然TCP也可以用各種各樣的ICMP報文來處理這些，但是這也不是可靠的，最可靠的方式就是隻要不得到確認，就重新發送資料報，直到得到對方的確認為止。
TCP的首部和UDP首部一樣，都有傳送埠號和接收埠號。但是顯然，TCP的首部資訊要比UDP的多，可以看到，TCP協議提供了傳送和確認所需要的所有必要的資訊。可以想象一個TCP資料的傳送應該是如下的一個過程。
雙方建立連線
傳送方給接受方TCP資料報，然後等待對方的確認TCP資料報，如果沒有，就重新發，如果有，就傳送下一個資料報。
接受方等待發送方的資料報，如果得到資料報並檢驗無誤，就傳送ACK(確認)資料報，並等待下一個TCP資料報的到來。直到接收到FIN(傳送完成資料報)
中止連線
可以想見，為了建立一個TCP連線，系統可能會建立一個新的程序(最差也是一個執行緒)，來進行資料的傳送
--
TCP協議
TCP是一個面向連線的協議，在傳送輸送之前 ，雙方需要確定連線。而且，傳送的資料可以進行TCP層的分片處理。
TCP連線的建立過程 ，可以看成是三次握手 。而連線的中斷可以看成四次握手 。
1.連線的建立
在建立連線的時候，客戶端首先向伺服器申請開啟某一個埠(用SYN段等於1的TCP報文)，然後伺服器端發回一個ACK報文通知客戶端請求報文收到，客戶端收到確認報文以後再次發出確認報文確認剛才伺服器端發出的確認報文(繞口麼)，至此，連線的建立完成。這就叫做三次握手。如果打算讓雙方都做好準備的話，一定要傳送三次報文，而且只需要三次報文就可以了。
可以想見，如果再加上TCP的超時重傳機制，那麼TCP就完全可以保證一個數據包被送到目的地。
2.結束連線
TCP有一個特別的概念叫做half-close，這個概念是說，TCP的連線是全雙工(可以同時傳送和接收)連線，因此在關閉連線的`時候，必須關閉傳和送兩個方向上的連線。客戶機給伺服器一個FIN為1的TCP報文，然後伺服器返回給客戶端一個確認ACK報文，並且傳送一個FIN報文，當客戶機回覆ACK報文後(四次握手)，連線就結束了。
3.最大報文長度
在建立連線的時候，通訊的雙方要互相確認對方的最大報文長度(MSS)，以便通訊。一般這個SYN長度是MTU減去固定IP首部和TCP首部長度。對於一個乙太網，一般可以達到1460位元組。當然如果對於非本地的IP，這個MSS可能就只有536位元組，而且，如果中間的傳輸網路的MSS更加的小的話，這個值還會變得更小。
4.客戶端應用程式的狀態遷移圖
客戶端的狀態可以用如下的流程來表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程式正常的情況下應該有的流程，從書中的圖中可以看到，在建立連線時，當客戶端收到SYN報文的ACK以後，客戶端就打開了資料互動地連線。而結束連線則通常是客戶端主動結束的，客戶端結束應用程式以後，需要經歷FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束連線的四次握手。
5.伺服器的狀態遷移圖
伺服器的狀態可以用如下的流程來表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立連線的時候，伺服器端是在第三次握手之後才進入資料互動狀態，而關閉連線則是在關閉連線的第二次握手以後(注意不是第四次)。而關閉以後還要等待客戶端給出最後的ACK包才能進入初始的狀態。
伺服器設計
前面曾經講述過UDP的伺服器設計，可以發現UDP的伺服器完全不需要所謂的併發機制，它只要建立一個數據輸入佇列就可以。但是TCP不同，TCP伺服器對於每一個連線都需要建立一個獨立的程序(或者是輕量級的，執行緒)，來保證對話的獨立性。所以TCP伺服器是併發的。而且TCP還需要配備一個呼入連線請求佇列(UDP伺服器也同樣不需要)，來為每一個連線請求建立對話程序，這也就是為什麼各種TCP伺服器都有一個最大連線數的原因。而根據源主機的IP和埠號碼，伺服器可以很輕鬆的區別出不同的會話，來進行資料的分發。
TCP的互動資料流
對於互動性要求比較高的應用，TCP給出兩個策略來提高發送效率和減低網路負擔：(1)捎帶ACK。(2)Nagle演算法(一次儘量多的發資料)
捎帶ACK的傳送方式
這個策略是說，當主機收到遠端主機的TCP資料報之後，通常不馬上傳送ACK資料報，而是等上一個短暫的時間，如果這段時間裡面主機還有傳送到遠端主機的TCP資料報，那麼就把這個ACK資料報“捎帶”著傳送出去，把本來兩個TCP資料報整合成一個傳送。一般的，這個時間是200ms。可以明顯地看到這個策略可以把TCP資料報的利用率提高很多。
Nagle演算法
上過bbs的人應該都會有感受，就是在網路慢的時候發貼，有時鍵入一串字串以後，經過一段時間，客戶端“發瘋”一樣突然回顯出很多內容，就好像資料一下子傳過來了一樣，這就是Nagle演算法的作用。
Nagle演算法是說，當主機A給主機B傳送了一個TCP資料報並進入等待主機B的ACK資料報的狀態時，TCP的輸出緩衝區裡面只能有一個TCP資料報，並且，這個資料報不斷地收集後來的資料，整合成一個大的資料報，等到B主機的ACK包一到，就把這些資料“一股腦”的傳送出去。雖然這樣的描述有些不準確，但還算形象和易於理解，我們同樣可以體會到這個策略對於低減網路負擔的好處。
在編寫插口程式的時候，可以通過TCP_NODELAY來關閉這個演算法。並且，使用這個演算法看情況的，比如基於TCP的X視窗協議，如果處理滑鼠事件時還是用這個演算法，那麼“延遲”可就非常大了。