“三次握手，四次揮手”你確定你了解么？（之二）
那我們?yōu)槭裁匆叭挝帐?，四次揮手”呢？
三次握手
換個易于理解的視角來看為什么要3次握手。
客戶端和服務(wù)端通信前要進行連接，“3次握手”的作用就是雙方都能明確自己和對方的收、發(fā)能力是正常的。
第一次握手：客戶端發(fā)送網(wǎng)絡(luò)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。
第二次握手：服務(wù)端發(fā)包，客戶端收到了。這樣客戶端就能得出結(jié)論：服務(wù)端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。
從客戶端的視角來看，我接到了服務(wù)端發(fā)送過來的響應(yīng)數(shù)據(jù)包，說明服務(wù)端接收到了我在第一次握手時發(fā)送的網(wǎng)絡(luò)包，并且成功發(fā)送了響應(yīng)數(shù)據(jù)包，這就說明，服務(wù)端的接收、發(fā)送能力正常。而另一方面，我收到了服務(wù)端的響應(yīng)數(shù)據(jù)包，說明我第一次發(fā)送的網(wǎng)絡(luò)包成功到達服務(wù)端，這樣，我自己的發(fā)送和接收能力也是正常的。
第三次握手：客戶端發(fā)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的接收、發(fā)送能力，服務(wù)端的發(fā)送、接收能力是正常的。
第一、二次握手后，服務(wù)端并不知道客戶端的接收能力以及自己的發(fā)送能力是否正常。而在第三次握手時，服務(wù)端收到了客戶端對第二次握手作的回應(yīng)。從服務(wù)端的角度，我在第二次握手時的響應(yīng)數(shù)據(jù)發(fā)送出去了，客戶端接收到了。所以，我的發(fā)送能力是正常的。而客戶端的接收能力也是正常的。
經(jīng)歷了上面的三次握手過程，客戶端和服務(wù)端都確認了自己的接收、發(fā)送能力是正常的。之后就可以正常通信了。
每次都是接收到數(shù)據(jù)包的一方可以得到一些結(jié)論，發(fā)送的一方其實沒有任何頭緒。我雖然有發(fā)包的動作，但是我怎么知道我有沒有發(fā)出去，而對方有沒有接收到呢？
而從上面的過程可以看到，最少是需要三次握手過程的。兩次達不到讓雙方都得出自己、對方的接收、發(fā)送能力都正常的結(jié)論。其實每次收到網(wǎng)絡(luò)包的一方至少是可以得到：對方的發(fā)送、我方的接收是正常的。而每一步都是有關(guān)聯(lián)的，下一次的“響應(yīng)”是由于第一次的“請求”觸發(fā)，因此每次握手其實是可以得到額外的結(jié)論的。比如第三次握手時，服務(wù)端收到數(shù)據(jù)包，表明看服務(wù)端只能得到客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的，但是結(jié)合第二次，說明服務(wù)端在第二次發(fā)送的響應(yīng)包，客戶端接收到了，并且作出了響應(yīng)，從而得到額外的結(jié)論：客戶端的接收、服務(wù)端的發(fā)送是正常的。
用表格總結(jié)一下：
| 視角 | 客收 | 客發(fā) | 服收 | 服發(fā) |
|---|---|---|---|---|
| 客視角 | 二 | 一 + 二 | 一 + 二 | 二 |
| 服視角 | 二 + 三 | 一 | 一 | 二 + 三 |
四次揮手
TCP連接是雙向傳輸?shù)膶Φ鹊哪Ｊ?，就是說雙方都可以同時向?qū)Ψ桨l(fā)送或接收數(shù)據(jù)。當(dāng)有一方要關(guān)閉連接時，會發(fā)送指令告知對方，我要關(guān)閉連接了。這時對方會回一個ACK，此時一個方向的連接關(guān)閉。但是另一個方向仍然可以繼續(xù)傳輸數(shù)據(jù)，等到發(fā)送完了所有的數(shù)據(jù)后，會發(fā)送一個FIN段來關(guān)閉此方向上的連接。接收方發(fā)送ACK確認關(guān)閉連接。注意，接收到FIN報文的一方只能回復(fù)一個ACK, 它是無法馬上返回對方一個FIN報文段的，因為結(jié)束數(shù)據(jù)傳輸?shù)摹爸噶睢笔巧蠈討?yīng)用層給出的，我只是一個“搬運工”，我無法了解“上層的意志”。
“三次握手，四次揮手”怎么完成？
其實3次握手的目的并不只是讓通信雙方都了解到一個連接正在建立，還在于利用數(shù)據(jù)包的選項來傳輸特殊的信息，交換初始序列號ISN。
3次握手是指發(fā)送了3個報文段，4次揮手是指發(fā)送了4個報文段。注意，SYN和FIN段都是會利用重傳進行可靠傳輸?shù)摹?/p>
三次握手
客戶端發(fā)送一個SYN段，并指明客戶端的初始序列號，即ISN(c).
服務(wù)端發(fā)送自己的SYN段作為應(yīng)答，同樣指明自己的ISN(s)。為了確認客戶端的SYN，將ISN(c)+1作為ACK數(shù)值。這樣，每發(fā)送一個SYN，序列號就會加1. 如果有丟失的情況，則會重傳。
為了確認服務(wù)器端的SYN，客戶端將ISN(s)+1作為返回的ACK數(shù)值。
四次揮手
客戶端發(fā)送一個FIN段，并包含一個希望接收者看到的自己當(dāng)前的序列號K. 同時還包含一個ACK表示確認對方最近一次發(fā)過來的數(shù)據(jù)。
服務(wù)端將K值加1作為ACK序號值，表明收到了上一個包。這時上層的應(yīng)用程序會被告知另一端發(fā)起了關(guān)閉操作，通常這將引起應(yīng)用程序發(fā)起自己的關(guān)閉操作。
服務(wù)端發(fā)起自己的FIN段，ACK=K+1, Seq=L
客戶端確認。ACK=L+1
為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢？
這是因為服務(wù)端在LISTEN狀態(tài)下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發(fā)送給客戶端。而關(guān)閉連接時，當(dāng)收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，己方是否現(xiàn)在關(guān)閉發(fā)送數(shù)據(jù)通道，需要上層應(yīng)用來決定，因此，己方ACK和FIN一般都會分開發(fā)送。
“三次握手，四次揮手”進階
ISN
三次握手的一個重要功能是客戶端和服務(wù)端交換ISN(Initial Sequence Number), 以便讓對方知道接下來接收數(shù)據(jù)的時候如何按序列號組裝數(shù)據(jù)。
如果ISN是固定的，攻擊者很容易猜出后續(xù)的確認號。
1 | ISN = M + F(localhost, localport, remotehost, remoteport) |
M是一個計時器，每隔4毫秒加1。
F是一個Hash算法，根據(jù)源IP、目的IP、源端口、目的端口生成一個隨機數(shù)值。要保證hash算法不能被外部輕易推算得出。
序列號回繞
因為ISN是隨機的，所以序列號容易就會超過2^31-1. 而tcp對于丟包和亂序等問題的判斷都是依賴于序列號大小比較的。此時就出現(xiàn)了所謂的tcp序列號回繞（sequence wraparound）問題。怎么解決？
1 2 3 4 5 6 7 8 9 10 | /* * 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) |
上述代碼是內(nèi)核中的解決回繞問題代碼。__s32是有符號整型的意思，而__u32則是無符號整型。序列號發(fā)生回繞后，序列號變小，相減之后，把結(jié)果變成有符號數(shù)了，因此結(jié)果成了負數(shù)。
1 2 3 4 5 6 7 8 9 10 11 12 13 | 假設(shè)seq1=255， seq2=1（發(fā)生了回繞）。 seq1 = 1111 1111 seq2 = 0000 0001 我們希望比較結(jié)果是 seq1 - seq2= 1111 1111 -0000 0001 ----------- 1111 1110 ? 由于我們將結(jié)果轉(zhuǎn)化成了有符號數(shù)，由于最高位是1，因此結(jié)果是一個負數(shù)，負數(shù)的絕對值為 0000 0001 + 1 = 0000 0010 = 2 ? 因此seq1 - seq2 < 0 |
syn flood攻擊
最基本的DoS攻擊就是利用合理的服務(wù)請求來占用過多的服務(wù)資源，從而使合法用戶無法得到服務(wù)的響應(yīng)。syn flood屬于Dos攻擊的一種。
如果惡意的向某個服務(wù)器端口發(fā)送大量的SYN包，則可以使服務(wù)器打開大量的半開連接，分配TCB（Transmission Control Block）, 從而消耗大量的服務(wù)器資源，同時也使得正常的連接請求無法被相應(yīng)。當(dāng)開放了一個TCP端口后，該端口就處于Listening狀態(tài)，不停地監(jiān)視發(fā)到該端口的Syn報文，一 旦接收到Client發(fā)來的Syn報文，就需要為該請求分配一個TCB，通常一個TCB至少需要280個字節(jié)，在某些操作系統(tǒng)中TCB甚至需要1300個字節(jié)，并返回一個SYN ACK命令，立即轉(zhuǎn)為SYN-RECEIVED即半開連接狀態(tài)。系統(tǒng)會為此耗盡資源。
常見的防攻擊方法有：
無效連接的監(jiān)視釋放
監(jiān)視系統(tǒng)的半開連接和不活動連接，當(dāng)達到一定閾值時拆除這些連接，從而釋放系統(tǒng)資源。這種方法對于所有的連接一視同仁，而且由于SYN Flood造成的半開連接數(shù)量很大，正常連接請求也被淹沒在其中被這種方式誤釋放掉，因此這種方法屬于入門級的SYN Flood方法。
延緩TCB分配方法
消耗服務(wù)器資源主要是因為當(dāng)SYN數(shù)據(jù)報文一到達，系統(tǒng)立即分配TCB，從而占用了資源。而SYN Flood由于很難建立起正常連接，因此，當(dāng)正常連接建立起來后再分配TCB則可以有效地減輕服務(wù)器資源的消耗。常見的方法是使用Syn Cache和Syn Cookie技術(shù)。
Syn Cache技術(shù)
系統(tǒng)在收到一個SYN報文時，在一個專用HASH表中保存這種半連接信息，直到收到正確的回應(yīng)ACK報文再分配TCB。這個開銷遠小于TCB的開銷。當(dāng)然還需要保存序列號。
Syn Cookie技術(shù)
Syn Cookie技術(shù)則完全不使用任何存儲資源，這種方法比較巧妙，它使用一種特殊的算法生成Sequence Number，這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS(Maximum Segment Size，最大報文段大小，指的是TCP報文的最大數(shù)據(jù)報長度，其中不包括TCP首部長度。)、時間等，在收到對方 的ACK報文后，重新計算一遍，看其是否與對方回應(yīng)報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。
使用SYN Proxy防火墻
一種方式是防止墻dqywb連接的有效性后，防火墻才會向內(nèi)部服務(wù)器發(fā)起SYN請求。防火墻代服務(wù)器發(fā)出的SYN ACK包使用的序列號為c, 而真正的服務(wù)器回應(yīng)的序列號為c’, 這樣，在每個數(shù)據(jù)報文經(jīng)過防火墻的時候進行序列號的修改。另一種方式是防火墻確定了連接的安全后，會發(fā)出一個safe reset命令，client會進行重新連接，這時出現(xiàn)的syn報文會直接放行。這樣不需要修改序列號了。但是，client需要發(fā)起兩次握手過程，因此建立連接的時間將會延長。
下載文檔
