通過實驗取證：TCP三次握手的過程

理解TCP/IP協議的工作原理

多年來TCP/IP協議一直被公眾稱呼為“一個協議”，事實上它是一組協議的集合，IP工作在OSI七層模型的網絡層，提供網絡傳輸，但是并不提供其可靠性傳輸控制。而TCP工作在OSI七層模型的傳輸層，并提供其可靠性傳輸控制。那么首先需要說明的是：“什么是可靠性傳輸控制？”所謂可靠性傳輸控制是指面向連接的一種確認數據交付方式，具體的說，就是在數據正式傳輸之前，利用一種觸發和認定的方式來保證發送方與接收方之間的可靠性，以防止數據在傳輸的過程中出現丟包及其他傳輸不可達的現象。這好比人類世界在交換價值產品之前，必須保證接收的人能真正地收到發出的產品，接收方在收到產品之后用一種回應的方式告知發送方，產品已經成功到達。

TCP協議的特點：由于提供了面向連接的可靠交付，所以TCP協議常用于可靠性較差的網絡環境中,比如Internet。但是,正是由于TCP協議面向連接的可靠交付使其傳輸的速度較慢，至少比UDP協議更慢，這無疑證實了技術界的一個觀念：“無所謂最好的傳輸協議，一切皆應需而動，任何技術都是一把“雙刃劍”，如果需求是穩定，那么就必須犧牲速度，如果需求是速度，就必須犧牲可靠性！”

注意：上面描述了TCP協議的核心價值是確保傳輸的可靠性，并使用了人類世界在交換價值產品的一個實例來說明了如何完成可靠性交付。但是現在的問題在于在計算機網絡技術領域里，兩臺通信設備或者計算機之間將采用一種什么樣的方式來完成可靠性交付？

TCP協議的“三次握手”是學習的核心

TCP協議的“三次握手”是完成可靠性交付過程的核心，所以本小節將以描述TCP協議的網絡世界中著名的“三次握手”為重點。

TCP協議是一個相互觸發、相互確認的過程。客戶機要觸發服務器，服務器也要觸發客戶機。建立握手狀態的標記syn=1表示開始觸發，ack=1表示對觸發的回應確認。并且在TCP建立可靠連接時只會使用這兩個標記。正確的TCP握手過程如圖4.44所示。

n客戶機要觸發服務器，向服務器發出syn=1的信號。

n服務器向客戶機發送ack=1的確認信號。

n服務器再向客戶機發送syn=1的觸發信號，以達到相互觸發的效果。

n客戶機再回應服務器的觸發信號ack=1。

上述為TCP握手過程，但是過程卻就是四次握手了，并非所謂的“TCP三次握手”。那么為什么會叫“TCP三次握手”呢？這是因為服務器與其將給客戶機的ack=1確認信息和觸發客戶機的syn=1分成兩次發送，倒不如將其兩次合并成一個信號：syn=1，ack=1。其實syn=1是觸發客戶機的，而ack=1是響應客戶機觸發的消息。所以將四次握手變三次，這是“TCP三次握手”的得名，也是對TCP正確的理解，如圖4.45所示。

? ?

關于TCP的滑動窗口與確認機制

在面向連接的數據傳辦輸過程中，任何數據在傳遞的過程中都可能損壞、丟失、或者重傳，在這種情況下如果沒有一種保障機制，那么數據在傳輸的過程中可能導致協議出錯。所以面向連接的協議提出了一種保障機制，讓接收方在收到數據后進行確認，如下圖４.46所示，發送方發送１，接收方接收１并反回發送確認ACK2，發送方收到接收的ACK2就發送2，這種方式叫做TCP使用期待確認方式，也就是確認號就是所期待發送的下一數據。當接收方收到接收2后發送確認ACK３,發送方收到ACK3后發送數據３。這個過程中TCP的窗口大小為１，也就是收送一個數據，確定一個數據，然后再發送一個數據，這種方式確保了數據的可靠性，但是喪失了效率，那么網絡的吞吐量將變得很低，更好的辦法是將TCP窗口的大小調高，比如將原有窗口１調整為3，如下圖4.47所示，發送方一次發送三次１、２、３接收方接收1、2、3后返回確認ACK４,后繼發送同理，通過調整TCP窗口后，網絡的吞吐量與使用率明顯提高。事實上這是TCP的一種流控機制，這一點應試人員要特別小心，后面會出現相應的試題分析。

當分段的數據到達目的地如何重組：

在OSI模型的傳輸層為了方便更好的傳輸數據，會對大型數據進行分段，將其分割更小的數據塊，以便于傳輸。由于Internet傳輸系統的原因，比如：一個被分割的原始數據的分段，可能通過不同的路由路徑到達目標的數據分段，可能存在著先后不同的到達順序，或者是出現了損環或者重傳，在這種情況下，目標主機怎樣重新組合并還原這些分段，如何對這些分段進行確認將是一個問題。大型數據被分段后，傳輸層協議會為這些分段分別打上序列號，到達目標后可以根據這些序列號來還原數據，關于確認這些分段可靠性的方案是對這些數據分段采取期待確認，比如一個數據分段的序列號是100，那么目標將返回101的序列確認，至于到底是對每個數據分段進行確認還是一次性確認多個數據分段這和TCP的滑動窗口有關。

關于TCP協議的安全威脅

TCP三次握手的漏洞如圖４.48所示。TCP在數據正式發送以前必須與對等端完成三次握手的狀態，然后再進行真正的數據轉發，那么在這個TCP三次握手的狀態完成前，TCP將會處于半開會話狀態。現在假想一種情況：202.202.1.100/24是一個發動惡意***的***，想要***202.202.1.254的Web服務器，于是利用一個假IP為192.168.1.100的地址作為源IP地址，不斷地向202.202.1.254的服務器發送TCP連接請求。服務器收到了許多的TCP的源地址為192.168.1.100的syn=1的數據報文，肯定會對該TCP會話作ack=1的確認，并發出syn=1的觸發192.168.1.100主機的二次會話，但是這個192.168.1.100地址根本就不存在，服務器將永遠都等不到192.168.1.100給它的最后確認。這時的服務器上會存放許多半開的TCP會話，這將直接導致服務器的NIC、內存、CPU的占用率超載,這種***方式叫做基于TCP半開會話的洪水***，是屬于denial of service（DOS）拒絕式服務***的一種。

演示：取證TCP/IP協議的三次握手過程

演示目標：在實時通信的環境下取證TCP協議的“三次握手”過程。

演示環境：如圖4.49所示的演示環境。

4.49

演示背景：為了演示環境更真實，可將192.168.0.100這臺計算機構建成一臺Web服務器，然后192.168.0.101這臺計算機去訪問192.168.0.100所提供的Web服務，然后捕獲并分析整個通信過程中的數據幀，重點觀察TCP協議“三次握手”的取證的過程。

演示步驟：

第一步：為演示環境中的兩臺計算機配置IP地址，并測試連通性，如下圖4.50所示為在192.168.0.101的客戶機上對192.168.0.100的Ping檢測。

第二步：配置192.168.0.100為Web服務器，建議這個過程由CCNA的教員完成。并在該服務器上啟動Wireshark協議分析器軟件，開啟捕獲功能，然后在192.168.0.101的客戶機上打開IE，并在地址欄輸入“http://192.168.0.100”去訪問服務器。當完成訪問后，可在Wireshark協議分析器看到如下圖4.51所示的TCP三次握手的整體效果。

第三步：現在拆分TCP三次握手的三個數據幀，如圖4.52所示為TCP協議的第一次握手；如圖4.53所示為TCP協議第二次握手；如圖4.54所示為TCP協議第三次握手。

總結

以上是生活随笔為你收集整理的通过实验取证：TCP三次握手的过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。