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

理解TCP/IP協(xié)議的工作原理

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

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

注意：上面描述了TCP協(xié)議的核心價值是確保傳輸?shù)目煽啃?#xff0c;并使用了人類世界在交換價值產(chǎn)品的一個實例來說明了如何完成可靠性交付。但是現(xiàn)在的問題在于在計算機網(wǎng)絡(luò)技術(shù)領(lǐng)域里，兩臺通信設(shè)備或者計算機之間將采用一種什么樣的方式來完成可靠性交付？

TCP協(xié)議的“三次握手”是學(xué)習(xí)的核心

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

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

n客戶機要觸發(fā)服務(wù)器，向服務(wù)器發(fā)出syn=1的信號。

n服務(wù)器向客戶機發(fā)送ack=1的確認信號。

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

n客戶機再回應(yīng)服務(wù)器的觸發(fā)信號ack=1。

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

? ?

關(guān)于TCP的滑動窗口與確認機制

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

當(dāng)分段的數(shù)據(jù)到達目的地如何重組：

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

關(guān)于TCP協(xié)議的安全威脅

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

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

演示目標(biāo)：在實時通信的環(huán)境下取證TCP協(xié)議的“三次握手”過程。

演示環(huán)境：如圖4.49所示的演示環(huán)境。

4.49

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

演示步驟：

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

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

第三步：現(xiàn)在拆分TCP三次握手的三個數(shù)據(jù)幀，如圖4.52所示為TCP協(xié)議的第一次握手；如圖4.53所示為TCP協(xié)議第二次握手；如圖4.54所示為TCP協(xié)議第三次握手。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。