標籤：tcpip
TCP串連的狀態圖
TCP建立串連的三向交握過程，以及關閉串連的四次握手過程
貼一個telnet建立串連，中斷連線的使用wireshark捕獲的packet。
1、建立連線協定（三向交握）
（1）客戶 端發送一個帶SYN標誌的TCP報文到伺服器。這是三向交握過程中的報文1。
（2） 伺服器端回應用戶端的，這是三向交握中的第2個報文，這個報文同時帶ACK標誌和SYN標誌。因此它表示對剛才用戶端SYN報文的回應；同時又標誌SYN給用戶端，詢問用戶端是否準備好進行資料通 訊。
（3） 客戶必須再次回應服務段一個ACK報文，這是報文段3。
2、串連終止協議（四次握手）
由於TCP連 接是全雙工系統的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的資料發送任務後就能發送一個FIN來終止這個方向的串連。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP串連在收到一個FIN後仍能發送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（1） TCP客 戶端發送一個FIN，用來關閉客戶到伺服器的資料傳送（報文段4）。
（2） 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。
（3） 伺服器關閉用戶端的串連，發送一個FIN給用戶端（報文段6）。
（4） 客戶段發回ACK報文確認，並將確認序號設定為收到序號加1（報文段7）。
CLOSED: 這個沒什麼好說的了，表示初始狀態。
LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處 於監聽狀態，可以接受串連了。
SYN_RCVD: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP串連時的三向交握會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個用戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予發送。因此這種狀態時，當收到用戶端的ACK報文 後，它會進入到ESTABLISHED狀態。
SYN_SENT: 這個狀態與SYN_RCVD遙想呼應，當用戶端SOCKET執行CONNECT串連時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三向交握中的第2個報文。SYN_SENT狀態表示用戶端已發送SYN報文。
ESTABLISHED：這個容易理解了，表示串連已經建立了。
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉串連，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。
FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半串連，也即有一方要求close串連，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉串連。
TIME_WAIT: 表示收到了對方的FIN報文，並發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。
CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文後，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET串連。
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料發送給對方，如果沒有的話，那麼你也就可以close這個SOCKET，發送FIN報文給對方，也即關閉串連。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉串連。
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。
補充：
a. 預設情況下(不改變socket選項)，當你調用close( or closesocket，以下說close不再重複)時，如果發送緩衝中還有資料，TCP會繼續把資料發送完。
b. 發送了FIN只是表示這端不能繼續發送資料(應用程式層不能再調用send發送)，但是還可以接收資料。
c. 應用程式層如何知道對端關閉？通常，在最簡單的阻塞模型中，當你調用recv時，如果返回0，則表示對端關閉。在這個時候通常的做法就是也調用close，那麼TCP層就發送FIN，繼續完成四次握手。如果你不調用close，那麼對端就會處於FIN_WAIT_2狀態，而本端則會處於CLOSE_WAIT狀態。這個可以寫代碼試試。
d. 在很多時候，TCP串連的斷開都會由TCP層自動進行，例如你CTRL+C終止你的程式，TCP串連依然會正常關閉，你可以寫代碼試試。
1、 為什麼建立連線協定是三向交握，而關閉串連卻是四次握手呢？
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裡來發送。但關閉串連時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料發送給你了；但未必你所有的資料都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些資料給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉串連了，所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的。
2、 為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態？
什麼是2MSL？MSL即Maximum Segment Lifetime，也就是報文最大存留時間，引用《TCP/IP詳解》中的話：“它(MSL)是任何報文段被丟棄前在網路內的最長時間。”那麼，2MSL也就是這個時間的2倍，當TCP串連完成四個報文段的交換時，主動關閉的一方將繼續等待一定時間(2-4分鐘)，即使兩端的應用程式結束。例如在上面的telnet程式用戶端關閉後，使用netstat查看的結果:
C:\>netstat -na | find "172.29.21.25"
TCP 172.29.132.60:2795 172.29.21.25:23 TIME_WAIT
為什麼需要這個2MSL呢，
第一，雖然雙方都同意關閉串連了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網路是不可靠的，你無法保證你最後發送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為逾時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。
第二，報文可能會被混淆，意思是說，其他時候的串連可能會被當作本次的串連。直接引用《The TCP/IP Guide》的說法：The second is to provide a “buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion.
當某個串連的一端處於TIME_WAIT狀態時，該串連將不能再被使用。事實上，對於我們比較有現實意義的是，這個連接埠將不能再被使用。某個連接埠處於TIME_WAIT狀態(其實應該是這個串連)時，這意味著這個TCP串連並沒有斷開(完全斷開)，那麼，如果你bind這個連接埠，就會失敗。對於伺服器而言，如果伺服器突然crash掉了，那麼它將無法在2MSL內重新啟動，因為bind會失敗。解決這個問題的一個方法就是設定socket的SO_REUSEADDR選項。這個選項意味著你可以重用一個地址。
當建立一個TCP串連時，伺服器端會繼續用原有連接埠監聽，同時用這個連接埠與用戶端通訊。而用戶端預設情況下會使用一個隨機連接埠與伺服器端的監聽連接埠通訊。有時候，為了伺服器端的安全性，我們需要對用戶端進行驗證，即限定某個IP某個特定連接埠的用戶端。用戶端可以使用bind來使用特定的連接埠。對於伺服器端，當設定了SO_REUSEADDR選項時，它可以在2MSL內啟動並listen成功。但是對於用戶端，當使用bind並設定SO_REUSEADDR時，如果在2MSL內啟動，雖然bind會成功，但是在windows平台上connect會失敗。而在linux上則不存在這個問題。(我的實驗平台：winxp, ubuntu7.10)
要解決windows平台的這個問題，可以設定SO_LINGER選項。SO_LINGER選項決定調用close時TCP的行為。SO_LINGER涉及到linger結構體，如果設定結構體中l_onoff為非0，l_linger為0，那麼調用close時TCP串連會立刻斷開，TCP不會將發送緩衝中未發送的資料發送，而是立即發送一個RST報文給對方，這個時候TCP串連(關閉時)就不會進入TIME_WAIT狀態。如你所見，這樣做雖然解決了問題，但是並不安全。通過以上方式設定SO_LINGER狀態，等同於設定SO_DONTLINGER狀態。
當TCP串連發生一些物理上的意外情況時，例如網線斷開，linux上的TCP實現會依然認為該串連有效，而windows則會在一定時間後返回錯誤資訊。這似乎可以通過設定SO_KEEPALIVE選項來解決，不過不知道這個選項是否對於所有平台都有效。
3. 為什麼不能用兩次握手進行串連？
我們知道，3次握手完成兩個重要的功能，既要雙方做好發送資料的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序號進行協商，這個序號在握手過程中被發送和確認。
現在把三向交握改成僅需要兩次握手，死結是可能發生的。作為例子，考慮電腦S和C之間的通訊，假定C給S發送一個串連請求分組，S收到了這個分組，並發送了確認應答分組。按照兩次握手的協定，S認為串連已經成功地建立了，可以開始發送資料分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S是否已準備好，不知道S建立什麼樣的序號，C甚至懷疑S是否收到自己的串連請求分組。在這種情況下，C認為串連還未建立成功，將忽略S發來的任何資料分組，只等待串連確認應答分組。而S在發出的分組逾時後，重複發送同樣的分組。這樣就形成了死結。
4、為何ISN是隨機的
DoS攻擊
DoS攻擊、DDoS攻擊和DRDoS攻擊相信大家已經早有耳聞了吧!DoS是Denial of Service的簡寫就是拒絕服務，而DDoS就是Distributed Denial of Service的簡寫就是分散式阻斷服務,而DRDoS就是Distributed Reflection Denial of Service的簡寫,這是分布反射式拒絕服務的意思。
不過這3中攻擊方法最厲害的還是DDoS，那個DRDoS攻擊雖然是新近出的一種攻擊方法，但它只是DDoS攻擊的變形，它的唯一不同就是不用佔領大量的“肉雞”。這三種方法都是利用TCP三向交握的漏洞進行攻擊的，所以對它們的防禦辦法都是差不多的。
DoS攻擊是最早出現的，它的攻擊方法說白了就是單挑，是比誰的機器效能好、速度快。但是現在的科技飛速發展，一般的網站主機都有十幾台主機，而且各個主機的處理能力、記憶體大小和網路速度都有飛速的發展，有的網路頻寬甚至超過了千兆層級。這樣我們的一對一單挑式攻擊就沒有什麼作用了，搞不好自己的機子就會死掉。舉個這樣的攻擊例子，假如你的機器每秒能夠發送10個攻擊用的資料包，而被你攻擊的機器(效能、網路頻寬都是頂尖的)每秒能夠接受並處理100攻擊資料包，那樣的話，你的攻擊就什麼用處都沒有了，而且非常有死機的可能。要知道，你若是發送這種1Vs1的攻擊，你的機器的CPU佔用率是90%以上的，你的機器要是配置不夠高的話，那你就死定了。
不過，科技在發展，駭客的技術也在發展。正所謂道高一尺，魔高一仗。經過無數次當機，駭客們終於又找到一種新的DoS攻擊方法，這就是DDoS攻擊。它的原理說白了就是群毆，用好多的機器對目標機器一起發動 DoS攻擊，但這不是很多駭客一起參與的，這種攻擊只是由一名駭客來操作的。這名駭客不是擁有很多機器，他是通過他的機器在網路上佔領很多的“肉雞”，並且控制這些“肉雞”來發動DDoS攻擊，要不然怎麼叫做分布式呢。還是剛才的那個例子，你的機器每秒能發送10攻擊資料包，而被攻擊的機器每秒能夠接受100的資料包，這樣你的攻擊肯定不會起作用，而你再用10台或更多的機器來對被攻擊目標的機器進行攻擊的話，嘿嘿!結果我就不說了。
DRDoS分布反射式拒絕服務的攻擊這是DDoS攻擊的變形，它與DDoS的不同之處就是DrDoS不需要在攻擊之前佔領大量的“肉雞”。它的攻擊原理和Smurf攻擊原理相近，不過DRDoS是可以在廣域網路上進行的，而Smurf攻擊是在區域網路進行的。它的作用原理是基於廣播位址與回應請求的。一台電腦向另一台電腦發送一些特殊的資料包如ping請求時，會接到它的回應;如果向本網路的廣播位址發送請求包，實際上會到達網路上所有的電腦，這時就會得到所有電腦的回應。這些回應是需要被接收的電腦處理的，每處理一個就要佔用一份系統資源，如果同時接到網路上所有電腦的回應，接收方的系統是有可能吃不消的，就象遭到了DDoS攻擊一樣。不過是沒有人笨到自己攻擊自己，不過這種方法被駭客加以改進就具有很大的威力了。駭客向廣播位址發送請求包，所有的電腦得到請求後，卻不會把回應發到駭客那裡，而是發到被攻擊主機。這是因為駭客冒充了被攻擊主機。駭客發送請求包所用的軟體是可以偽造源地址的，接到偽造資料包的主機會根據源地址把回應發出去，這當然就是被攻擊主機的地址。駭客同時還會把發送請求包的時間間隔減小，這樣在短時間能發出大量的請求包，使被攻擊主機接到從被欺騙電腦那裡傳來的洪水般的回應，就像遭到了DDoS攻擊導致系統崩潰。駭客藉助了網路中所有電腦來攻擊受害者，而不需要事先去佔領這些被欺騙的主機，這就是Smurf攻擊。而DRDoS攻擊正是這個原理，駭客同樣利用特殊的發包工具，首先把偽造了源地址的SYN串連請求包發送到那些被欺騙的電腦上，根據TCP三向交握的規則，這些電腦會向源IP發出SYN+ACK或RST包來響應這個請求。同Smurf攻擊一樣，駭客所發送的請求包的源IP地址是被攻擊主機的地址，這樣受欺騙的主機就都會把回應發到被攻擊主機處，造成被攻擊主機忙於處理這些回應而癱瘓。
解釋:
SYN:(Synchronize sequence numbers)用來建立串連，在串連請求中，SYN=1，ACK=0，串連響應時，SYN=1，ACK=1。即，SYN和ACK來區分Connection Request和Connection Accepted。
RST:(Reset the connection)用於複位因某種原因引起出現的錯誤串連，也用來拒絕非法資料和請求。如果接收到RST位時候，通常發生了某些錯誤。
ACK:(Acknowledgment field significant)置1時表示確認號(Acknowledgment Number)為合法，為0的時候表示資料區段不包含確認資訊，確認號被忽略。
設我們要準備建立串連，伺服器正處於正常的接聽狀態。
第一步:我們也就是用戶端發送一個帶SYN位的請求，向伺服器表示需要串連，假設請求包的序號為10，那麼則為:SYN=10，ACK=0，然後等待伺服器的回應。
第二步:伺服器接收到這樣的請求包後，查看是否在接聽的是指定的連接埠，如果不是就發送RST=1回應，拒絕建立串連。如果接收請求包，那麼伺服器發送確認回應，SYN為伺服器的一個內碼，假設為100，ACK位則是用戶端的請求序號加1，本例中發送的資料是:SYN=100，ACK=11，用這樣的資料回應給我們。向我們表示，伺服器串連已經準備好了，等待我們的確認。這時我們接收到回應後，分析得到的資訊，準備發送確認串連訊號到伺服器。
第三步:我們發送確認建立串連的資訊給伺服器。確認資訊的SYN位是伺服器發送的ACK位，ACK位是伺服器發送的SYN位加1。即:SYN=11，ACK=101。
這樣我們的串連就建立起來了。
DDoS究竟如何攻擊?目前最流行也是最好用的攻擊方法就是使用SYN-Flood進行攻擊，SYN-Flood也就是SYN洪水攻擊。SYN-Flood不會完成TCP三向交握的第三步，也就是不發送確認串連的資訊給伺服器。這樣，伺服器無法完成第三向交握，但伺服器不會立即放棄，伺服器會不停的重試並等待一定的時間後放棄這個未完成的串連，這段時間叫做SYN timeout，這段時間大約30秒-2分鐘左右。若是一個使用者在串連時出現問題導致伺服器的一個線程等待1分鐘並不是什麼大不了的問題，但是若有人用特殊的軟體大量類比這種情況，那後果就可想而知了。一個伺服器若是處理這些大量的半串連資訊而消耗大量的系統資源和網路頻寬，這樣伺服器就不會再有空餘去處理普通使用者的正常請求(因為客戶的正常請求比率很小)。這樣這個伺服器就無法工作了，這種攻擊就叫做:SYN-Flood攻擊。
到目前為止，進行DDoS攻擊的防禦還是比較困難的。首先，這種攻擊的特點是它利用了TCP/IP協議的漏洞，除非你不用TCP/IP，才有可能完全抵禦住DDoS攻擊。不過這不等於我們就沒有辦法阻擋DDoS攻擊，我們可以儘力來減少DDoS的攻擊。下面就是一些防禦方法:
1.確保伺服器的系統檔案是最新的版本，並及時更新系統補丁。
2.關閉不必要的服務。
3.限制同時開啟的SYN半串連數目。
4.縮短SYN半串連的time out 時間。
5.正確設定防火牆
6.禁止對主機的非開放服務的訪問
7.限制特定IP地址的訪問
8.啟用防火牆的防DDoS的屬性
9.嚴格限制對外開放的伺服器的向外訪問
10.運行連接埠對應程式禍連接埠掃描程式，要認真檢查特權連接埠和非特權連接埠。
11.認真檢查網路裝置和主機/伺服器系統的日誌。只要日誌出現漏洞或是時間變更，那這台機器就可能遭到了攻擊。
12.限制在防火牆外與網路檔案分享權限設定。這樣會給駭客截取系統檔案的機會，主機的資訊暴露給駭客，無疑是給了對方入侵的機會。
TCP/IP的三向交握和四次握手 Dos攻擊
