早期的計算機被用來進行科學計算，在單機上即可完成，但為了滿足不同主機間的數據交換，滿足通信需求，TCP / IP 協議划分的五層模型物理層、數據鏈路層、網絡層、傳輸層和應用層實現了互聯網通信。
另外補充一句，叫做 TCP / IP 協議而不是 UDP / IP 協議是因為 UDP 協議太過簡單了，只是將應用層交下來的報文添加 UDP 首部后即交付給 IP 層，所起到的作用僅僅是分發路由，將報文發送給對應的端口號；相比之下，TCP 協議則實現了面向連接的可靠交付，更能代表傳輸層協議的作用，也與網絡層協議有一定的區分度（網絡層協議為了設計盡量簡單，采用了數據報服務，沒有承擔可靠交付的責任）。
TCP 是面向連接的協議，其連接的建立采用客戶 / 服務器的方式，即 C / S 模式。C / S 模式實現了主機間應用進程之間的通信，它將客戶進程和服務器進程區分開來，每一個客戶進程都可以向服務器進程發送連接請求，進行雙方的數據交換。
連接的過程被形象地比作握手，就像我走來伸手向你問候“你好”，你伸手回應“你好”。但我們現實生活中好像只進行了兩次信息傳送的過程就能建立連接，即兩次問好，而 TCP 的連接需要三報文握手才能建立，原因是要解決網絡信道不可靠的問題。網絡信道本身是不可靠的，丟包的現象時有發生，所以才需要通過協議來實現可靠交付。
首先，服務器進程 B 創建傳輸控制塊 TCB ，進入收聽狀態，等待客戶進程的連接請求。客戶進程 A 也是首先創建傳輸控制塊 TCB 。
- 第一次握手（連接請求報文段）：A 主動發送連接請求，為自己隨機選擇一個初始序號 seq = x 。A 消耗一個序號。
- 第二次握手（應答報文段）：B 同意建立連接，回復確認號 ack = x + 1 ，以便核對，同時也為自己隨機選擇一個初始序號 seq = y 。B 消耗一個序號。
- 第三次握手（確認報文段）：A 收到確認，進入已建立連接狀態，並發送確認號 ack = y + 1 。如果不攜帶數據則 A 不消耗序號。
B 收到確認后也進入已建立連接狀態，TCP 連接成功建立，雙方可進行數據交換。
Q1：序號是什么意思？
A1：文件分塊通常不是順序到達的，而且也方便對收到的文件進行確認。
Q2：為什么要讓客戶進程對應答報文段進行確認，進行第三次握手？B 在第一次接收請求報文段時就進入已建立連接狀態，A 在接收到應答報文段后也進入已建立連接狀態，雙方也成功建立了連接不是嗎？
A2：因為網絡信道本身是不可靠的，如果 A 的連接請求報文丟失而未及時收到確認，就會再重傳一個連接請求，此時當然也能成功建立連接。但是如果第一個連接請求報文段並沒有丟失，而是在某些網絡節點中長時間滯留，以致延誤到連接釋放以后的某個時間才到達 B 。本來這是個已失效的連接請求報文段，B 收到這個報文段后，會以為是 A 又發出了一次新的連接請求，如果不采用第三次報文握手，B 直接進入已建立連接狀態，兩者狀態不對等，無法進行數據交換，B 的許多資源將白白浪費；而采用第三次握手，這個已失效的連接請求報文段送到 B 后，B 會發送應答報文段，現在 A 並沒有發出建立連接的請求，自然不會理睬 B 的應答，B 收不到確認報文段，也就進入了關閉狀態，沒有為這個已失效的連接請求報文段建立起連接。
- 第一次握手：
- 第二次握手：
- 第三次握手：
- 第四次握手：
我們首先看一下客戶端和服務器的具體連接過程，客戶端首先向服務器發送請求報文段，服務器收到請求報文段后，如同意建立連接，則向客戶端發送應答報文段，客戶端接收到回應后進入已建立連接狀態，並且還要再給服務器發送確認報文段，服務器接收到確認后也進入已建立連接狀態。我們將這三個過程叫做三報文握手，因為總共發送了三個報文建立了連接。客戶端的請求報文段的首部置同步位 SYN = 1 ，同時隨機選擇一個初始序號 seq = x ；服務器的應答報文段首部中的同步位 SYN 和確認位 ACK 都置為 1 ，確認號是 ack = x + 1 ，同時也為自己選擇一個隨機初始序號 seq = y ；客戶端的確認報文段的首部置確認位 ACK = 1 ，確認號 ack = y + 1 ，而自己的序號 seq = x + 1 。TCP 的標准規定，確認報文段可以攜帶數據，但如果不攜帶數據則不消耗序號，即下一個數據報文段的序號仍是 seq = x + 1 。
強調序號的原因是發送的數據報到達的先后順序不同，TCP 協議需要處理數據報亂序問題，即通過滑動窗口的方式實現數據報的按序到達。
需要注意的是，TCP 連接是全雙工的，因此不需要特地區分哪個是數據的發送方哪個是接收方，接收方需要在建立連接后的接收數據過程中不斷對數據報文段進行確認（當然是根據接收窗口的情況進行確認）。確認號就是表示該確認號之前的所有數據均已正確收到，希望下次接收序號為該確認號的數據。
確認報文段不攜帶數據則不消耗序號我們也可以來分析一下加深印象，前兩次握手分別消耗了一個各自的序號，因為分別發送了各自的初始序號用以接收的確認，而第三次握手只有一個確認號，服務器不需要再對這個確認號再進行一次確認，除非有新的數據發送過來，此時客戶端才需要消耗序號。
那么為什么需要讓客戶端對服務器發來的應答報文段進行確認，進行第三次握手呢？服務器在第一次接收請求報文段時就進入已建立連接狀態，客戶端在接收到應答報文段時也進入已建立連接狀態，雙方也成功建立了連接不是嗎？
因為網絡信道本身是不可靠的，客戶端發送的請求報文段有可能在網絡中滯留或丟失，如果客戶端的請求報文段丟失而沒有及時收到服務器的確認，就會再重傳一個連接請求，此時當然也能成功建立連接，但是如果第一個請求報文段並沒有丟失，而是在某個網絡節點中滯留，導致服務器會收到兩個來自客戶端的連接請求。如果是兩次握手，服務器會同時為客戶端建立兩個已連接狀態，其中一條連接會一直等待客戶端發來數據，而那一條是無效連接，服務器的許多資源將白白浪費；如果是三次握手，服務器會為這兩個連接請求分別進行應答，而客戶端認為只有一個連接，只會為其中一個應答報文段進行確認，成功建立連接。因此連接確認的過程中使用三報文握手。
處於連接狀態的客戶端和服務端，都可以發起關閉連接請求，此時需要四報文握手進行釋放連接。假設客戶端主動發起連接關閉請求，向服務器發送連接釋放報文段，並停止再發送數據，關閉 TCP 連接，進入終止等待 1 狀態；服務器接收到連接釋放報文段后會立即發送確認報文段，此時從客戶端到服務器方向的連接就關閉了，即客戶端已經沒有數據要發送給服務器了，TCP 連接處於半關閉狀態，但從服務器到客戶端方向的連接並未關閉，並且這個狀態可能會持續一段時間，所以服務器可以在這段時間內繼續發完剩余的數據；客戶端在接收到服務器的確認報文段后就進入終止等待 2 狀態，等待服務器發出的連接釋放報文段；若服務器已經沒有要發送的數據了，就會發送連接釋放報文段給客戶端，並進入最終確認狀態，等待客戶端的確認；客戶端在接收到服務器的連接釋放報文段后，必須對此發出確認報文段，必須經過時間等待計時器設置的時間 2MSL 后才能進入到 CLOSED 狀態，當客戶端撤銷相應的傳輸控制塊 TCB 后，就結束了這次的 TCP 連接；服務器只要接到了確認報文段后就會進入 CLOSED 狀態，同樣，當服務器撤銷相應的傳輸控制塊 TCB 后，就結束了這次的 TCP 連接。上述的 TCP 連接釋放過程是四報文握手。