TCP三次握手

telnet連線虛擬機器192.168.0.107。用tcpdump抓包，然後用wireshark分析報文。

以上過程如下圖：

上圖2，3，4就是三次握手的過程。本地埠號為52368，telnet埠號23。

上面截圖就是第一次握手的資料分析，可以清晰的看出tcp報文頭的結構：

1、16位源目的埠號；

2、32的sequence number號(e4 6d 0c 3c)和32位的確認號（acknowledgment number）：ack number是接收到的報文的sequence+1。這裡截圖顯示seq number和ack number都是0，但看最下面的內容會發現不是0，這裡wireshark只是為了大家看著方便，所以把它簡化成邏輯sequence number 0，否則看乙個32位的數，然後再+1，看著累伐。sequence number用來解決網路報文亂序的問題，32位，超過2^32-1後，從0重新開始。 acknowledgment number用於確認收到報文，解決丟包的問題。

3、4位首部長度（header length）：表示tcp報文頭的大小=20位元組的正常報文頭大小+可選項所佔位元組數。整個首部長度等於header length *4(首部是4位元組的整數倍)；

4、12位標誌位-flags（一般是前6位保留，後6位有效）：（urgent, acknowledgment,push,reset,synchronized,finish）

5、16位視窗大小（window size value）：視窗大小為位元組數，視窗大小是16欄位，因而視窗大小最大65535，具體怎麼控制流程，以後再細說；

6、16位校驗和（checksum）和16位緊急指標（urgent pointer）。

7、選項（options）：tcp報文頭正常長度一共20個位元組，這是固定的。但是tcp報文頭有時還有可選項（options），本例中為24位元組，所以4整個報文頭我們可以認為是44位元組，因此之前的首部長度的值為1011，即44位元組。options可選字段最常見的內容是mss(maximum segment size)，即最長報文大小。每個連線方通常都會在第乙個報文中指明這個選項，它表示本端能接受的最大報文長度。

下圖是107回應的報文：

可以看出該確認報文的ack標誌位已經被置1，而32位的acknowledgment是收到報文的seqence number+1得到的。自己的sequence number是c1 bf 5a 89(當然，為了簡單檢視，顯示的是relative seqence number 0)。我們還注意到options中同樣有mss 1460位元組，因為這是107第一次給108發報文，前面我們說到第一次通訊一般都會告知對方自己能接收的最長報文大小。接下來108收到這個報文要做同樣的事情，回覆乙個確認報文給107，該報文截圖如下：

同樣看到ack被設定成1.而options中沒有mss了，因為這是108第二次和107通訊了，第一次已經告知對方自己的mss了。sequence numer=e4 6d 0c 3d(上乙個報文的sequence number e4 6d 0c 3c加1), acknowledgment number = c1 bf 5a 8a(c1 bf 5a 89+1)。

tcp要保證所有的資料報都可以到達，所以，必需要有重傳機制。

注意，接收端給傳送端的ack確認只會確認最後乙個連續的包，比如，傳送端發了1,2,3,4,5一共五份資料，接收端收到了1，2，於是回ack 3，然後收到了4（注意此時3沒收到），此時的tcp會怎麼辦？我們要知道，因為正如前面所說的，seqnum和ack是以位元組數為單位，所以ack的時候，不能跳著確認，只能確認最大的連續收到的包，不然，傳送端就以為之前的都收到了。

一種是不回ack，死等3。當傳送方收不到3的ack後，會等待，超時後重傳報文3。當收到3的ack後，會ack回4，表示報文4也收到了。

但是，這種機制有乙個問題，那就是因為要死等3，會導致即使4、5都收到了，而傳送方沒有收到3的ack，所以傳送方悲觀的的認為4、5也丟了，轉而重傳3、4、5。

對此，有兩種選擇：

1、僅重傳報文3。

2、重傳3之後的所有報文，即重傳3、4、5。

這兩種方式有好有不好。第一種方式節約頻寬，但是慢。第二種快一點，但是會浪費頻寬，也有可能在做無用功。總體來說都不好。因為在等待timeout，timeout時間有可能會很長。

客戶端發出syn報文後，收到服務端確認報文之前的這段時間，客戶端處於syn_sent狀態。

伺服器一開始是listen狀態，當收到客戶端發來的syn報文後，伺服器端tcp狀態就變成syn_rcvd狀態，此時ack和syn標誌位都置1，並返回ack報文。如果一切順利，伺服器端將會在收到客戶端發來的ack報文後，從syn_rcvd切換到established狀態。正常情況下syn_rcvd狀態非常短暫。如果發現有大量的syn_rcvd狀態，那可能遭到了syn flood的dos(拒絕服務攻擊)攻擊了。

syn flood攻擊原理

三次握手時，攻擊端偽造不存在的ip位址，向伺服器端傳送syn報文，伺服器端收到syn報文後進入syn_rcvd狀態，並返回syn+ack，並等待客戶端的ack。由於這些客戶端位址是假的，伺服器當然不會收到客戶端的ack報文。伺服器遇到這種情況一般會重發syn+ack報文，並等待一段時間，這段時間我們稱之為syn timeout，一般30s-2min。乙個客戶端異常導致伺服器端的乙個執行緒等1分鐘不是什麼問題，但是如果有攻擊端惡意模擬這種情況，導致服務端消耗大量的資源去維護乙個半連線列表，並消耗cpu資源、增加cpu響應正常客戶情況的時間。在客戶端看來，伺服器失去響應，這種情況我們稱做：伺服器端受到了syn flood攻擊（syn洪水攻擊）。

解決方法

TCP三次握手

tcp三次握手 TCP 三次握手總結

TCP 三次握手

TCP三次握手

TCP三次握手

tcp三次握手 TCP 三次握手總結

TCP 三次握手

TCP三次握手

相關推薦