【原创】“三次握手，四次挥手”你真的懂吗？
記得剛畢業找工作面試的時候，經常會被問到：你知道“3次握手，4次揮手”嗎？這時候我會“胸有成竹”地“背誦”前期準備好的“答案”，第一次怎么怎么，第二次……答完就沒有下文了，面試官貌似也沒有深入下去的意思，深入下去我也不懂，皆大歡喜！
作為程序員，要有“刨根問底”的精神。知其然，更要知其所以然。這篇文章希望能抽絲剝繭，還原背后的原理。
為了便于整體把握文章，手動加上文章目錄：
什么是“3次握手，4次揮手”
TCP是一種面向連接的單播協議，在發送數據前，通信雙方必須在彼此間建立一條連接。所謂的“連接”，其實是客戶端和服務器的內存里保存的一份關于對方的信息，如ip地址、端口號等。
TCP可以看成是一種字節流，它會處理IP層或以下的層的丟包、重復以及錯誤問題。在連接的建立過程中，雙方需要交換一些連接的參數。這些參數可以放在TCP頭部。
TCP提供了一種可靠、面向連接、字節流、傳輸層的服務，采用三次握手建立一個連接。采用4次揮手來關閉一個連接。
TCP服務模型
在了解了建立連接、關閉連接的“三次握手和四次揮手”后，我們再來看下TCP相關的東西。
一個TCP連接由一個4元組構成，分別是兩個IP地址和兩個端口號。一個TCP連接通常分為三個階段：啟動、數據傳輸、退出（關閉）。
當TCP接收到另一端的數據時，它會發送一個確認，但這個確認不會立即發送，一般會延遲一會兒。ACK是累積的，一個確認字節號N的ACK表示所有直到N的字節（不包括N）已經成功被接收了。這樣的好處是如果一個ACK丟失，很可能后續的ACK就足以確認前面的報文段了。
一個完整的TCP連接是雙向和對稱的，數據可以在兩個方向上平等地流動。給上層應用程序提供一種雙工服務。一旦建立了一個連接，這個連接的一個方向上的每個TCP報文段都包含了相反方向上的報文段的一個ACK。
序列號的作用是使得一個TCP接收端可丟棄重復的報文段，記錄以雜亂次序到達的報文段。因為TCP使用IP來傳輸報文段，而IP不提供重復消除或者保證次序正確的功能。另一方面，TCP是一個字節流協議，絕不會以雜亂的次序給上層程序發送數據。因此TCP接收端會被迫先保持大序列號的數據不交給應用程序，直到缺失的小序列號的報文段被填滿。
TCP頭部
源端口和目的端口在TCP層確定雙方進程，序列號表示的是報文段數據中的第一個字節號，ACK表示確認號，該確認號的發送方期待接收的下一個序列號，即最后被成功接收的數據字節序列號加1，這個字段只有在ACK位被啟用的時候才有效。
當新建一個連接時，從客戶端發送到服務端的第一個報文段的SYN位被啟用，這稱為SYN報文段，這時序列號字段包含了在本次連接的這個方向上要使用的第一個序列號，即初始序列號ISN，之后發送的數據是ISN加1，因此SYN位字段會消耗一個序列號，這意味著使用重傳進行可靠傳輸。而不消耗序列號的ACK則不是。
頭部長度（圖中的數據偏移）以32位字為單位，也就是以4bytes為單位，它只有4位，最大為15，因此頭部最大長度為60字節，而其最小為5，也就是頭部最小為20字節（可變選項為空）。
ACK —— 確認，使得確認號有效。 RST —— 重置連接（經常看到的reset by peer）就是此字段搞的鬼。 SYN —— 用于初如化一個連接的序列號。 FIN —— 該報文段的發送方已經結束向對方發送數據。
當一個連接被建立或被終止時，交換的報文段只包含TCP頭部，而沒有數據。
狀態轉換
三次握手和四次揮手的狀態轉換如下圖。
為什么要“三次握手，四次揮手”
三次握手
換個易于理解的視角來看為什么要3次握手。
客戶端和服務端通信前要進行連接，“3次握手”的作用就是雙方都能明確自己和對方的收、發能力是正常的。
第一次握手：客戶端發送網絡包，服務端收到了。這樣服務端就能得出結論：客戶端的發送能力、服務端的接收能力是正常的。
第二次握手：服務端發包，客戶端收到了。這樣客戶端就能得出結論：服務端的接收、發送能力，客戶端的接收、發送能力是正常的。 從客戶端的視角來看，我接到了服務端發送過來的響應數據包，說明服務端接收到了我在第一次握手時發送的網絡包，并且成功發送了響應數據包，這就說明，服務端的接收、發送能力正常。而另一方面，我收到了服務端的響應數據包，說明我第一次發送的網絡包成功到達服務端，這樣，我自己的發送和接收能力也是正常的。
第三次握手：客戶端發包，服務端收到了。這樣服務端就能得出結論：客戶端的接收、發送能力，服務端的發送、接收能力是正常的。 第一、二次握手后，服務端并不知道客戶端的接收能力以及自己的發送能力是否正常。而在第三次握手時，服務端收到了客戶端對第二次握手作的回應。從服務端的角度，我在第二次握手時的響應數據發送出去了，客戶端接收到了。所以，我的發送能力是正常的。而客戶端的接收能力也是正常的。
經歷了上面的三次握手過程，客戶端和服務端都確認了自己的接收、發送能力是正常的。之后就可以正常通信了。
每次都是接收到數據包的一方可以得到一些結論，發送的一方其實沒有任何頭緒。我雖然有發包的動作，但是我怎么知道我有沒有發出去，而對方有沒有接收到呢？
而從上面的過程可以看到，最少是需要三次握手過程的。兩次達不到讓雙方都得出自己、對方的接收、發送能力都正常的結論。其實每次收到網絡包的一方至少是可以得到：對方的發送、我方的接收是正常的。而每一步都是有關聯的，下一次的“響應”是由于第一次的“請求”觸發，因此每次握手其實是可以得到額外的結論的。比如第三次握手時，服務端收到數據包，表明看服務端只能得到客戶端的發送能力、服務端的接收能力是正常的，但是結合第二次，說明服務端在第二次發送的響應包，客戶端接收到了，并且作出了響應，從而得到額外的結論：客戶端的接收、服務端的發送是正常的。
用表格總結一下：
四次揮手
TCP連接是雙向傳輸的對等的模式，就是說雙方都可以同時向對方發送或接收數據。當有一方要關閉連接時，會發送指令告知對方，我要關閉連接了。這時對方會回一個ACK，此時一個方向的連接關閉。但是另一個方向仍然可以繼續傳輸數據，等到發送完了所有的數據后，會發送一個FIN段來關閉此方向上的連接。接收方發送ACK確認關閉連接。注意，接收到FIN報文的一方只能回復一個ACK, 它是無法馬上返回對方一個FIN報文段的，因為結束數據傳輸的“指令”是上層應用層給出的，我只是一個“搬運工”，我無法了解“上層的意志”。
“三次握手，四次揮手”怎么完成？
其實3次握手的目的并不只是讓通信雙方都了解到一個連接正在建立，還在于利用數據包的選項來傳輸特殊的信息，交換初始序列號ISN。
3次握手是指發送了3個報文段，4次揮手是指發送了4個報文段。注意，SYN和FIN段都是會利用重傳進行可靠傳輸的。
三次握手
客戶端發送一個SYN段，并指明客戶端的初始序列號，即ISN(c).
服務端發送自己的SYN段作為應答，同樣指明自己的ISN(s)。為了確認客戶端的SYN，將ISN(c)+1作為ACK數值。這樣，每發送一個SYN，序列號就會加1. 如果有丟失的情況，則會重傳。
為了確認服務器端的SYN，客戶端將ISN(s)+1作為返回的ACK數值。
四次揮手
1. 客戶端發送一個FIN段，并包含一個希望接收者看到的自己當前的序列號K. 同時還包含一個ACK表示確認對方最近一次發過來的數據。?
2. 服務端將K值加1作為ACK序號值，表明收到了上一個包。這時上層的應用程序會被告知另一端發起了關閉操作，通常這將引起應用程序發起自己的關閉操作。
3. 服務端發起自己的FIN段，ACK=K+1, Seq=L 4. 客戶端確認。ACK=L+1
為什么建立連接是三次握手，而關閉連接卻是四次揮手呢？
這是因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方是否現在關閉發送數據通道，需要上層應用來決定，因此，己方ACK和FIN一般都會分開發送。
“三次握手，四次揮手”進階
ISN
三次握手的一個重要功能是客戶端和服務端交換ISN(Initial Sequence Number), 以便讓對方知道接下來接收數據的時候如何按序列號組裝數據。
如果ISN是固定的，攻擊者很容易猜出后續的確認號。
ISN = M + F(localhost, localport, remotehost, remoteport)M是一個計時器，每隔4微秒加1。 F是一個Hash算法，根據源IP、目的IP、源端口、目的端口生成一個隨機數值。要保證hash算法不能被外部輕易推算得出。
序列號回繞
因為ISN是隨機的，所以序列號容易就會超過2^31-1. 而tcp對于丟包和亂序等問題的判斷都是依賴于序列號大小比較的。此時就出現了所謂的tcp序列號回繞（sequence wraparound）問題。怎么解決？
/** The next routines deal with comparing 32 bit unsigned ints * and worry about wraparound (automatic with unsigned arithmetic).*/static inline int before(__u32 seq1, __u32 seq2){return (__s32)(seq1-seq2) < 0;}#define after(seq2, seq1) before(seq1, seq2)上述代碼是內核中的解決回繞問題代碼。s32是有符號整型的意思，而u32則是無符號整型。序列號發生回繞后，序列號變小，相減之后，把結果變成有符號數了，因此結果成了負數。
假設seq1=255， seq2=1（發生了回繞）。 seq1 = 1111 1111 seq2 = 0000 0001 我們希望比較結果是seq1 - seq2=1111 1111 -0000 0001 -----------1111 1110由于我們將結果轉化成了有符號數，由于最高位是1，因此結果是一個負數，負數的絕對值為0000 0001 + 1 = 0000 0010 = 2因此seq1 - seq2 < 0syn flood攻擊
最基本的DoS攻擊就是利用合理的服務請求來占用過多的服務資源，從而使合法用戶無法得到服務的響應。syn flood屬于Dos攻擊的一種。
如果惡意的向某個服務器端口發送大量的SYN包，則可以使服務器打開大量的半開連接，分配TCB（Transmission Control Block）, 從而消耗大量的服務器資源，同時也使得正常的連接請求無法被相應。當開放了一個TCP端口后，該端口就處于Listening狀態，不停地監視發到該端口的Syn報文，一 旦接收到Client發來的Syn報文，就需要為該請求分配一個TCB，通常一個TCB至少需要280個字節，在某些操作系統中TCB甚至需要1300個字節，并返回一個SYN ACK命令，立即轉為SYN-RECEIVED即半開連接狀態。系統會為此耗盡資源。
常見的防攻擊方法有：
無效連接的監視釋放
監視系統的半開連接和不活動連接，當達到一定閾值時拆除這些連接，從而釋放系統資源。這種方法對于所有的連接一視同仁，而且由于SYN Flood造成的半開連接數量很大，正常連接請求也被淹沒在其中被這種方式誤釋放掉，因此這種方法屬于入門級的SYN Flood方法。
延緩TCB分配方法
消耗服務器資源主要是因為當SYN數據報文一到達，系統立即分配TCB，從而占用了資源。而SYN Flood由于很難建立起正常連接，因此，當正常連接建立起來后再分配TCB則可以有效地減輕服務器資源的消耗。常見的方法是使用Syn Cache和Syn Cookie技術。
Syn Cache技術
系統在收到一個SYN報文時，在一個專用HASH表中保存這種半連接信息，直到收到正確的回應ACK報文再分配TCB。這個開銷遠小于TCB的開銷。當然還需要保存序列號。
Syn Cookie技術
Syn Cookie技術則完全不使用任何存儲資源，這種方法比較巧妙，它使用一種特殊的算法生成Sequence Number，這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS(Maximum Segment Size，最大報文段大小，指的是TCP報文的最大數據報長度，其中不包括TCP首部長度。)、時間等，在收到對方 的ACK報文后，重新計算一遍，看其是否與對方回應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。
使用SYN Proxy防火墻
一種方式是防止墻dqywb連接的有效性后，防火墻才會向內部服務器發起SYN請求。防火墻代服務器發出的SYN ACK包使用的序列號為c, 而真正的服務器回應的序列號為c', 這樣，在每個數據報文經過防火墻的時候進行序列號的修改。另一種方式是防火墻確定了連接的安全后，會發出一個safe reset命令，client會進行重新連接，這時出現的syn報文會直接放行。這樣不需要修改序列號了。但是，client需要發起兩次握手過程，因此建立連接的時間將會延長。
連接隊列
在外部請求到達時，被服務程序最終感知到前，連接可能處于SYN_RCVD狀態或是ESTABLISHED狀態，但還未被應用程序接受。
對應地，服務器端也會維護兩種隊列，處于SYN_RCVD狀態的半連接隊列，而處于ESTABLISHED狀態但仍未被應用程序accept的為全連接隊列。如果這兩個隊列滿了之后，就會出現各種丟包的情形。
查看是否有連接溢出 netstat -s | grep LISTEN半連接隊列滿了
在三次握手協議中，服務器維護一個半連接隊列，該隊列為每個客戶端的SYN包開設一個條目(服務端在接收到SYN包的時候，就已經創建了request_sock結構，存儲在半連接隊列中)，該條目表明服務器已收到SYN包，并向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連接在服務器處于Syn_RECV狀態，當服務器收到客戶的確認包時，刪除該條目，服務器進入ESTABLISHED狀態。
目前，Linux下默認會進行5次重發SYN-ACK包，重試的間隔時間從1s開始，下次的重試間隔時間是前一次的雙倍，5次的重試時間間隔為1s, 2s, 4s, 8s, 16s, 總共31s, 稱為指數退避，第5次發出后還要等32s才知道第5次也超時了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s, TCP才會把斷開這個連接。由于，SYN超時需要63秒，那么就給攻擊者一個攻擊服務器的機會，攻擊者在短時間內發送大量的SYN包給Server(俗稱SYN flood攻擊)，用于耗盡Server的SYN隊列。對于應對SYN 過多的問題，linux提供了幾個TCP參數：tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 來調整應對。全連接隊列滿
當第三次握手時，當server接收到ACK包之后，會進入一個新的叫 accept 的隊列。
當accept隊列滿了之后，即使client繼續向server發送ACK的包，也會不被響應，此時ListenOverflows+1，同時server通過tcp_abort_on_overflow來決定如何返回，0表示直接丟棄該ACK，1表示發送RST通知client；相應的，client則會分別返回read timeout?或者?connection reset by peer。另外，tcp_abort_on_overflow是0的話，server過一段時間再次發送syn+ack給client（也就是重新走握手的第二步），如果client超時等待比較短，就很容易異常了。而客戶端收到多個 SYN ACK 包，則會認為之前的 ACK 丟包了。于是促使客戶端再次發送 ACK ，在 accept隊列有空閑的時候最終完成連接。若 accept隊列始終滿員，則最終客戶端收到 RST 包（此時服務端發送syn+ack的次數超出了tcp_synack_retries）。
服務端僅僅只是創建一個定時器，以固定間隔重傳syn和ack到服務端
命令
netstat -s命令
[root@server ~]# netstat -s | egrep "listen|LISTEN"?上面看到的 667399 times ，表示全連接隊列溢出的次數，隔幾秒鐘執行下，如果這個數字一直在增加的話肯定全連接隊列偶爾滿了。[root@server ~]# netstat -s | grep TCPBacklogDrop?查看 Accept queue 是否有溢出ss命令
[root@server ~]# ss -lnt如果State是listen狀態，Send-Q 表示第三列的listen端口上的全連接隊列最大為50，第一列Recv-Q為全連接隊列當前使用了多少。 非 LISTEN 狀態中 Recv-Q 表示 receive queue 中的 bytes 數量；Send-Q 表示 send queue 中的 bytes 數值。小結
當外部連接請求到來時，TCP模塊會首先查看max_syn_backlog，如果處于SYN_RCVD狀態的連接數目超過這一閾值，進入的連接會被拒絕。根據tcp_abort_on_overflow字段來決定是直接丟棄，還是直接reset.
從服務端來說，三次握手中，第一步server接受到client的syn后，把相關信息放到半連接隊列中，同時回復syn+ack給client. 第三步當收到客戶端的ack, 將連接加入到全連接隊列。
一般，全連接隊列比較小，會先滿，此時半連接隊列還沒滿。如果這時收到syn報文，則會進入半連接隊列，沒有問題。但是如果收到了三次握手中的第3步(ACK)，則會根據tcp_abort_on_overflow字段來決定是直接丟棄，還是直接reset.此時，客戶端發送了ACK, 那么客戶端認為三次握手完成，它認為服務端已經準備好了接收數據的準備。但此時服務端可能因為全連接隊列滿了而無法將連接放入，會重新發送第2步的syn+ack, 如果這時有數據到來，服務器TCP模塊會將數據存入隊列中。一段時間后，client端沒收到回復，超時，連接異常，client會主動關閉連接。
“三次握手，四次揮手”redis實例分析
我在dev機器上部署redis服務，端口號為6379,
通過tcpdump工具獲取數據包，使用如下命令：
在dev2機器上用redis-cli訪問dev:6379, 發送一個ping, 得到回復pong
停止抓包，用tcpdump讀取捕獲到的數據包
共收到了7個包。
抓到的是IP數據包，IP數據包分為IP頭部和IP數據部分，IP數據部分是TCP頭部加TCP數據部分。
IP的數據格式為：
它由固定長度20B+可變長度構成。
對著IP頭部格式，來拆解數據包的具體含義。
剩余的數據部分即為TCP協議相關的。TCP也是20B固定長度+可變長度部分。
可變長度部分，協議如下：
這樣第一個包分析完了。dev2向dev發送SYN請求。也就是三次握手中的第一次了。?SYN seq(c)=4133153791
第二個包，dev響應連接，ack=4133153792. 表明dev下次準備接收這個序號的包，用于tcp字節注的順序控制。dev（也就是server端）的初始序號為seq=4264776963, syn=1.?SYN ack=seq(c)+1 seq(s)=4264776963
第三個包，client包確認，這里使用了相對值應答。seq=4133153792, 等于第二個包的ack. ack=4264776964.?ack=seq(s)+1, seq=seq(c)+1?至此，三次握手完成。接下來就是發送ping和pong的數據了。
接著第四個包。
tcp首部長度為32B, 可選長度為12B. IP報文的總長度為66B, 首部長度為20B, 因此TCP數據部分長度為14B. seq=0xf65a ec00=4133153792 ACK, PSH. 數據部分為2a31 0d0a 2434 0d0a 7069 6e67 0d0a
0x2a31 ? ? ? ? -> *1 0x0d0a ? ? ? ? -> \r\n 0x2434 ? ? ? ? -> $4 0x0d0a ? ? ? ? -> \r\n 0x7069 0x6e67 ?-> ping 0x0d0a ? ? ? ? -> \r\ndev2向dev發送了ping數據，第四個包完畢。
第五個包，dev2向dev發送ack響應。 序列號為0xfe33 5504=4264776964, ack確認號為0xf65a ec0e=4133153806=(4133153792+14).
第六個包，dev向dev2響應pong消息。序列號fe33 5504，確認號f65a ec0e, TCP頭部可選長度為12B, IP數據報總長度為59B, 首部長度為20B, 因此TCP數據長度為7B. 數據部分2b50 4f4e 470d 0a, 翻譯過來就是+PONG\r\n.
至此，Redis客戶端和Server端的三次握手過程分析完畢。
總結
“三次握手，四次揮手”看似簡單，但是深究進去，還是可以延伸出很多知識點的。比如半連接隊列、全連接隊列等等。以前關于TCP建立連接、關閉連接的過程很容易就會忘記，可能是因為只是死記硬背了幾個過程，沒有深入研究背后的原理。
所以，“三次握手，四次揮手”你真的懂了嗎？
參考資料
【redis】https://segmentfault.com/a/1190000015044878
【tcp option】https://blog.csdn.net/wdscq1234/article/details/52423272
【滑動窗口】https://www.zhihu.com/question/32255109
【全連接隊列】http://jm.taobao.org/2017/05/25/525-1/
【client fooling】 https://github.com/torvalds/linux/commit/5ea8ea2cb7f1d0db15762c9b0bb9e7330425a071
【backlog RECV_Q】http://blog.51cto.com/59090939/1947443
【定時器】https://www.cnblogs.com/menghuanbiao/p/5212131.html
【隊列圖示】https://www.itcodemonkey.com/article/5834.html
【tcp flood攻擊】https://www.cnblogs.com/hubavyn/p/4477883.html
【MSS MTU】https://blog.csdn.net/LoseInVain/article/details/53694265
注：本文首發于博客園個人博客：
https://www.cnblogs.com/qcrao-2018/p/10182185.html
本文為原創文章，轉載注明出處，歡迎長按以下圖片關注公眾號CoderPark ，第一時間閱讀后續精彩文章。覺得好的話，請猛擊文章右下角「好看」，感謝支持。一線互聯網工程師帶你“精進”職業技能，趕快來吧!
本文作者：饒全成，中科院計算所碩士，滴滴出行后端研發工程師。
點擊「閱讀原文」，給本文作者饒全成點贊！
總結
以上是生活随笔為你收集整理的【原创】“三次握手，四次挥手”你真的懂吗？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： count sort, radix so
- 下一篇： Golang之变量去哪儿