寫在前邊
TCP 三次握手過程對於面試是必考的一個，所以不但要掌握 TCP 整個握手的過程，其中有些小細節也更受到面試官的青睞。
對於這部分掌握以及 TCP 的四次揮手，小鹿將會以動畫的形式呈現給每個人，這樣將複雜的知識簡單化，理解起來也容易了很多，尤其對於一個初學者來說。
思維導圖
1 TCP 是什麼？
<code>TCP（Transmission Control Protocol 傳輸控制協議）/<code>是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。
我們知道了上述瞭解到了 TCP 的定義，通俗一點的講，TCP 就是一個雙方通信的一個規範標準（協議）。
我們在學習 TCP 握手過程之前，首先必須瞭解 TCP 報文頭部的一些標誌信息，因為在 TCP 握手的過程中，會使用到這些報文信息，如果沒有掌握這些信息，在學習握手過程中，整個人處於懵逼狀態，也是為了能夠深入 TCP 三次握手的原理。
2 TCP 頭部報文
2.1 <code>source port/<code> 和 distination port
兩者分別為「源端口號」和「目的端口號」。
源端口號就是指本地端口，目的端口就是遠程端口。
一個數據包（<code>pocket/<code>）被解封裝成數據段（<code>segment/<code>）後就會涉及到連接上層協議的端口問題。
可以這麼理解，我們可以想象發送方很多的窗戶，接收方也有很多的窗戶，這些窗口都標有不同的端口號，源端口號和目的端口號就分別代表從哪個規定的串口發送到對方接收的窗口。不同的應用程度都有著不同的端口，之前網絡分層的文章中有提到過。
擴展：應用程序的端口號和應用程序所在主機的 IP 地址統稱為 socket（套接字），IP:端口號, 在互聯網上 socket 唯一標識每一個應用程序，源端口+源IP+目的端口+目的IP稱為”套接字對“，一對套接字就是一個連接，一個客戶端與服務器之間的連接。 2.2 Sequence Numbe
稱為「序列號」。用於 TCP 通信過程中某一傳輸方向上字節流的每個字節的編號，為了確保數據通信的有序性，避免網絡中亂序的問題。接收端根據這個編號進行確認，保證分割的數據段在原始數據包的位置。
再通俗一點的講，每個字段在傳送中用序列號來標記自己位置的，而這個字段就是用來完成雙方傳輸中確保字段原始位置是按照傳輸順序的。（發送方是數據是怎樣一個順序，到了接受方也要確保是這個順序）
PS：初始序列號由自己定，而後緒的序列號由對端的 ACK 決定：SN_x = ACK_y (x 的序列號 = y 發給 x 的 ACK)，這裡後邊會講到。2.3 Acknowledgment Numbe
稱為「確認序列號」。確認序列號是接收確認端所期望收到的下一序列號。確認序號應當是上次已成功收到數據字節序號加1，只有當標誌位中的 ACK 標誌為 1 時該確認序列號的字段才有效。主要用來解決不丟包的問題。
若確認號=N，則表明：到序號N-1為止的所有數據都已正確收到。
在這裡，現在我們只需知道它的作用是什麼，就是在數據傳輸的時候是一段一段的，都是由序列號進行標識的，所以說，接收端每接收一段，之後就想要的下一段的序列號就稱為「確認序列號」。
2.4 TCP Flag
TCP 首部中有 6 個標誌比特，它們中的多個可同時被設置為 1，主要是用於操控 TCP 的狀態機的，依次為URG，ACK，PSH，RST，SYN，FIN。
不要求初學者全部掌握，在這裡只講三個重點的標誌：
2.4.1 ACK
這個標識可以理解為發送端發送數據到接收端，發送的時候 ACK 為 0，標識接收端還未應答，一旦接收端接收數據之後，就將 ACK 置為 1，發送端接收到之後，就知道了接收端已經接收了數據。
此標誌表示「應答域有效」，就是說前面所說的TCP應答號將會包含在 TCP 數據包中；有兩個取值：0 和 1，為 1 的時候表示應答域有效，反之為 0；2.4.2 SYN
表示「同步序列號」，是 TCP 握手的發送的第一個數據包。
用來建立 TCP 的連接。SYN 標誌位和 ACK 標誌位搭配使用，當連接請求的時候，<code>SYN=1，ACK=0/<code>連接被響應的時候，<code>SYN=1/<code>，ACK=1；這個標誌的數據包經常被用來進行端口掃描。掃描者發送一個只有 SYN 的數據包，如果對方主機響應了一個數據包回來 ，就表明這臺主機存在這個端口。看下面動畫：
2.4.3 FIN
表示發送端已經達到數據末尾，也就是說雙方的數據傳送完成，沒有數據可以傳送了，發送<code>FIN/<code>
標誌位的 TCP 數據包後，連接將被斷開。這個標誌的數據包也經常被用於進行端口掃描。這個很好理解，就是說，發送端只剩最後的一段數據了，同時要告訴接收端後邊沒有數據可以接受了，所以用<code>FIN/<code>標識一下，接收端看到這個<code>FIN/<code>之後，哦！這是接受的最後的數據，接受完就關閉了。動畫如下：
2.5 Window size
稱為滑動窗口大小。所說的滑動窗口，用來進行流量控制。
3 為什麼進行 TCP 三次握手？
如果之前你不瞭解網絡分層的話，建議看看寫的文章。
你真的懂網絡分層模型嗎？
第一，為了確認雙方的接收與發送能力是否正常。第二，指定自己的初始化序列號，為後面的可靠傳送做準備。第三，如果是 https 協議的話，三次握手這個過程，還會進行數字證書的驗證以及加密密鑰的生成到。
如果你瞭解 UDP 的話，TCP 的出現正式彌補了 UDP 不可靠傳輸的缺點。但是 TCP 的誕生，也必然增加了連接的複雜性。
4 TCP 三次握手過程？
TCP 三次握手的過程掌握最重要的兩點就是客戶端和服務端狀態的變化，另一個是三次握手過程標誌信息的變化，那麼掌握 TCP 的三次握手就簡單多了。下面我們就以動畫形式進行拆解三次握手過程。
初始狀態：客戶端處於<code>closed/<code> 狀態，服務器處於<code>listen/<code>(監聽) 狀態。
第一次握手：客戶端發送請求報文將<code>SYN = j（1）/<code>初始化序列號發送給客戶端，發送完之後客戶端處於<code>SYN_Send/<code>狀態。
第二次握手：服務端受到 SYN 請求報文之後，如果同意連接，會以自己的<code>SYN(服務端) = K（0）/<code>和<code>ack（1） = SYN(客戶端) + 1(ACK = 1)/<code>報文作為應答，服務器為<code>SYN_Receive/<code>狀態。
第三次握手：客戶端接收到服務端的<code>SYN + ACK/<code>，然後發送<code>ack = SYN(服務端) + 1(ACK = 1)/<code>確認包作為應答，客戶端轉為<code>established/<code>狀態。
5 為什麼不是一次、二次握手？
防止了服務器端的一直等待而浪費資源。
為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。如果此時客戶端發送的延遲的握手信息服務器收到，然後服務器進行響應，認為客戶端要和它建立連接，此時客戶端並沒有這個意思，但 server 卻以為新的運輸連接已經建立，並一直等待 client 發來數據。這樣，server 的很多資源就白白浪費掉了。
-END-
如果看到這裡，說明你喜歡這篇文章，請轉發、點贊。微信搜索「web_resource」，關注後回覆「進群」或者掃描下方二維碼即可進入無廣告交流群。
閱讀更多 程序猿久一 的文章
