-
當(dāng)前位置:首頁 > 創(chuàng)意學(xué)院 > 技術(shù) > 專題列表 > 正文
tcp建立連接的三次握手過程(tcp建立連接的三次握手過程,已知第三次)
大家好!今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于tcp建立連接的三次握手過程的問題,以下是小編對此問題的歸納整理,讓我們一起來看看吧。
開始之前先推薦一個非常厲害的Ai人工智能工具,一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等
只需要輸入關(guān)鍵詞,就能返回你想要的內(nèi)容,越精準(zhǔn),寫出的就越詳細(xì),有微信小程序端、在線網(wǎng)頁版、PC客戶端
官網(wǎng):https://ai.de1919.com
本文目錄:
一、TCP的連接建立——三報文握手
三報文握手(three way handshake)以前都稱為三次握手,其實(shí)這是一次握手過程中交換中交換了三個報文,而并不是進(jìn)行了三次握手。handshake使用的是單數(shù)并不是復(fù)數(shù),表明只是一次握手。
1.SYN_SENT
SYN_SENT表示請求連接,當(dāng)你要訪問其它的計算機(jī)的服務(wù)時首先要發(fā)個 同步信號 給該端口,此時狀態(tài)為SYN_SENT,如果連接成功了就變?yōu)?ESTABLISHED ,此時SYN_SENT狀態(tài)非常短暫。
2.ACK
ACK (Acknowledgement)即是確認(rèn)字符,在數(shù)據(jù)通信中,接收站發(fā)給發(fā)送站的一種傳輸類 控制字符 。表示發(fā)來的數(shù)據(jù)已確認(rèn)接收無誤。
3.SYN_RCVD(同步收到)
4.ESTAB_LISHED(已建立連接)
5.傳輸控制模塊TCB
傳輸控制模塊TCB(Transmission Control Block)存儲了每一個連接中的一些重要信息。
一開始,B的PCP服務(wù)器進(jìn)程先創(chuàng)建 傳輸控制模塊TCB ,準(zhǔn)備接受客戶進(jìn)程的連接請求。然后服務(wù)器進(jìn)程就處于 LISTEN (收聽)狀態(tài),等待客戶的連接請求。
1.SYN=1,seq=x
A的TCP客戶進(jìn)程也是首先創(chuàng)建 傳輸控制模塊TCB ,然后,在打算建立TCP連接時,向B發(fā)出請求報文段,這時首部中的同步位 SYN=1 ,同時選擇一個初始序號 seq=x 。即 SYN=1,seq=x 。TCP規(guī)定,SYN報文段(即SYN=1的報文段)不能攜帶數(shù)據(jù),但要 消耗一個序號 。這時,TCP客戶進(jìn)程進(jìn)入 SYN_SENT (同步已發(fā)送)狀態(tài)。
2.SYN=1,ACK=1,seq=y,ack=x+1
B收到連接請求報文段后,如同意建立連接,則向A發(fā)送確認(rèn)。在確認(rèn)報文段中應(yīng)把SYN位和ACK位都置1,確認(rèn)號是 ack=x+1 ,同時也為自己選擇一個初始號 seq=y 。即 SYN=1,ACK=1,seq=y,ack=x+1
請注意:這個報文段也不能攜帶數(shù)據(jù),但同時 要消耗一個序號 。這時TCP服務(wù)器進(jìn)程進(jìn)入 SYN_RCVD (同步收到)狀態(tài)。
3.ACK=1,seq=x+1,ack=y+1
TCP客戶進(jìn)程收到B的確認(rèn)后,還要向B給出確認(rèn)。確認(rèn)報文段的ACK置1,確認(rèn)號 ack=y+1 ,而自己的序號 seq=x+1 。即 ACK=1,seq=x+1,ack=y+1 TCP的標(biāo)準(zhǔn)規(guī)定,ACK報文段可以攜帶數(shù)據(jù)。但 如果不攜帶數(shù)據(jù)則不消耗序號 ,在這中情況下,下一個數(shù)據(jù)報文段仍然是 seq=x+1 。這時。TCP連接已經(jīng)建立,A進(jìn)入 ESTAB_LISHED (已建立連接)狀態(tài)。
4 .當(dāng)B收到A的確認(rèn)后,也進(jìn)入 ESTAB_LISHED 狀態(tài)。
二、一文搞懂TCP的三次握手和四次揮手
TCP的三次握手和四次揮手實(shí)質(zhì)就是TCP通信的連接和斷開。
三次握手:為了對每次發(fā)送的數(shù)據(jù)量進(jìn)行跟蹤與協(xié)商,確保數(shù)據(jù)段的發(fā)送和接收同步,根據(jù)所接收到的數(shù)據(jù)量而確認(rèn)數(shù)據(jù)發(fā)送、接收完畢后何時撤消聯(lián)系,并建立虛連接。
四次揮手:即終止TCP連接,就是指斷開一個TCP連接時,需要客戶端和服務(wù)端總共發(fā)送4個包以確認(rèn)連接的斷開。
TCP三次握手、四次揮手時序圖
TCP協(xié)議位于傳輸層,作用是提供可靠的字節(jié)流服務(wù),為了準(zhǔn)確無誤地將數(shù)據(jù)送達(dá)目的地,TCP協(xié)議采納三次握手策略。
三次握手原理:
第1次握手:客戶端發(fā)送一個帶有SYN(synchronize)標(biāo)志的數(shù)據(jù)包給服務(wù)端;
第2次握手:服務(wù)端接收成功后,回傳一個帶有SYN/ACK標(biāo)志的數(shù)據(jù)包傳遞確認(rèn)信息,表示我收到了;
第3次握手:客戶端再回傳一個帶有ACK標(biāo)志的數(shù)據(jù)包,表示我知道了,握手結(jié)束。
其中:SYN標(biāo)志位數(shù)置1,表示建立TCP連接;ACK標(biāo)志表示驗(yàn)證字段。
可通過以下趣味圖解理解三次握手:
三次握手過程詳細(xì)說明:
1、客戶端發(fā)送建立TCP連接的請求報文,其中報文中包含seq序列號,是由發(fā)送端隨機(jī)生成的,并且將報文中的SYN字段置為1,表示需要建立TCP連接。(SYN=1,seq=x,x為隨機(jī)生成數(shù)值);
2、服務(wù)端回復(fù)客戶端發(fā)送的TCP連接請求報文,其中包含seq序列號,是由回復(fù)端隨機(jī)生成的,并且將SYN置為1,而且會產(chǎn)生ACK字段,ACK字段數(shù)值是在客戶端發(fā)送過來的序列號seq的基礎(chǔ)上加1進(jìn)行回復(fù),以便客戶端收到信息時,知曉自己的TCP建立請求已得到驗(yàn)證。(SYN=1,ACK=x+1,seq=y,y為隨機(jī)生成數(shù)值)這里的ack加1可以理解為是確認(rèn)和誰建立連接;
3、客戶端收到服務(wù)端發(fā)送的TCP建立驗(yàn)證請求后,會使自己的序列號加1表示,并且再次回復(fù)ACK驗(yàn)證請求,在服務(wù)端發(fā)過來的seq上加1進(jìn)行回復(fù)。(SYN=1,ACK=y+1,seq=x+1)。
由于TCP連接是全雙工的,因此每個方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數(shù)據(jù)流動,一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動關(guān)閉,而另一方執(zhí)行被動關(guān)閉。
四次揮手原理:
第1次揮手:客戶端發(fā)送一個FIN,用來關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)傳送,客戶端進(jìn)入FIN_WAIT_1狀態(tài);
第2次揮手:服務(wù)端收到FIN后,發(fā)送一個ACK給客戶端,確認(rèn)序號為收到序號+1(與SYN相同,一個FIN占用一個序號),服務(wù)端進(jìn)入CLOSE_WAIT狀態(tài);
第3次揮手:服務(wù)端發(fā)送一個FIN,用來關(guān)閉服務(wù)端到客戶端的數(shù)據(jù)傳送,服務(wù)端進(jìn)入LAST_ACK狀態(tài);
第4次揮手:客戶端收到FIN后,客戶端t進(jìn)入TIME_WAIT狀態(tài),接著發(fā)送一個ACK給Server,確認(rèn)序號為收到序號+1,服務(wù)端進(jìn)入CLOSED狀態(tài),完成四次揮手。
其中:FIN標(biāo)志位數(shù)置1,表示斷開TCP連接。
可通過以下趣味圖解理解四次揮手:
四次揮手過程詳細(xì)說明:
1、客戶端發(fā)送斷開TCP連接請求的報文,其中報文中包含seq序列號,是由發(fā)送端隨機(jī)生成的,并且還將報文中的FIN字段置為1,表示需要斷開TCP連接。(FIN=1,seq=x,x由客戶端隨機(jī)生成);
2、服務(wù)端會回復(fù)客戶端發(fā)送的TCP斷開請求報文,其包含seq序列號,是由回復(fù)端隨機(jī)生成的,而且會產(chǎn)生ACK字段,ACK字段數(shù)值是在客戶端發(fā)過來的seq序列號基礎(chǔ)上加1進(jìn)行回復(fù),以便客戶端收到信息時,知曉自己的TCP斷開請求已經(jīng)得到驗(yàn)證。(FIN=1,ACK=x+1,seq=y,y由服務(wù)端隨機(jī)生成);
3、服務(wù)端在回復(fù)完客戶端的TCP斷開請求后,不會馬上進(jìn)行TCP連接的斷開,服務(wù)端會先確保斷開前,所有傳輸?shù)紸的數(shù)據(jù)是否已經(jīng)傳輸完畢,一旦確認(rèn)傳輸數(shù)據(jù)完畢,就會將回復(fù)報文的FIN字段置1,并且產(chǎn)生隨機(jī)seq序列號。(FIN=1,ACK=x+1,seq=z,z由服務(wù)端隨機(jī)生成);
4、客戶端收到服務(wù)端的TCP斷開請求后,會回復(fù)服務(wù)端的斷開請求,包含隨機(jī)生成的seq字段和ACK字段,ACK字段會在服務(wù)端的TCP斷開請求的seq基礎(chǔ)上加1,從而完成服務(wù)端請求的驗(yàn)證回復(fù)。(FIN=1,ACK=z+1,seq=h,h為客戶端隨機(jī)生成)
至此TCP斷開的4次揮手過程完畢。
LISTEN:等待從任何遠(yuǎn)端TCP 和端口的連接請求。
SYN_SENT:發(fā)送完一個連接請求后等待一個匹配的連接請求。
SYN_RECEIVED:發(fā)送連接請求并且接收到匹配的連接請求以后等待連接請求確認(rèn)。
ESTABLISHED:表示一個打開的連接,接收到的數(shù)據(jù)可以被投遞給用戶。連接的數(shù)據(jù)傳輸階段的正常狀態(tài)。
FIN_WAIT_1:等待遠(yuǎn)端TCP 的連接終止請求,或者等待之前發(fā)送的連接終止請求的確認(rèn)。
FIN_WAIT_2:等待遠(yuǎn)端TCP 的連接終止請求。
CLOSE_WAIT:等待本地用戶的連接終止請求。
CLOSING:等待遠(yuǎn)端TCP 的連接終止請求確認(rèn)。
LAST_ACK:等待先前發(fā)送給遠(yuǎn)端TCP 的連接終止請求的確認(rèn)(包括它字節(jié)的連接終止請求的確認(rèn))
TIME_WAIT:等待足夠的時間過去以確保遠(yuǎn)端TCP 接收到它的連接終止請求的確認(rèn)。
TIME_WAIT 兩個存在的理由:
1.可靠的實(shí)現(xiàn)tcp全雙工連接的終止;
2.允許老的重復(fù)分節(jié)在網(wǎng)絡(luò)中消逝。
CLOSED:不在連接狀態(tài)(這是為方便描述假想的狀態(tài),實(shí)際不存在)。
三、TCP/IP三次握手具體過程是什么?
端口掃描,這種入侵檢測方法大家想必都經(jīng)常用到,但是你對這些方法的基本原理又了解多少呢?
首先,你可以選擇都種工具,本人喜歡nmap for linux,但不是常在linux下混,畢竟還是windows方便點(diǎn),呵呵,高手別笑我哦!
下面談下端口掃描方式!大體可以分為兩種,TCP掃描和秘密掃描
TCP掃描最常見的有兩種
全掃描、半掃描
說到TCP,就一定要談3次握手
客戶端——SYN——>服務(wù)器
客戶端<——SYN+ACK——服務(wù)器
客戶端——ACK——〉服務(wù)器
這就是3次握手,也就是全掃描的全過程,但是,由于這種方式要與目標(biāo)建立連接,所以一定會被記錄下來,所以,這種掃描方式是不隱密的,容易暴露身份。
所以,就有了半掃描這種掃描方式,會發(fā)送一個SYN包給目標(biāo)服務(wù)器,然后如果對方在特定端口監(jiān)聽,就會回復(fù)一個ACK+SYN,如果主機(jī)在活動,但沒有監(jiān)聽特定端口,就會回一個RST包。這種方法并沒有完成3次握手,所以一般不會被主機(jī)記錄。
下面,我們就拋開TCP協(xié)議,看看有沒有辦法通過其他方式掃描!
說到文件傳送,大家最先想到的就應(yīng)該是FTP協(xié)議了,那么,能不能通過FTP掃描呢?
答案是可以,出于設(shè)計上的需要,當(dāng)FTP客戶端要以主動模式請求傳送數(shù)據(jù)時,服務(wù)器必須要建立一個返回到客戶機(jī)端口上的連接客戶端發(fā)出PORT命令,以IP和端口作為參數(shù),如果參數(shù)中有另一臺主機(jī)的IP數(shù)據(jù),服務(wù)器將與這臺主機(jī)相連。
我們就利用FTP的這種特點(diǎn)來執(zhí)行代理端口掃描。
還有FIN,ident,XMAS掃描等等,由于時間關(guān)系和其他種種原因,我現(xiàn)在就不講了,lz有興趣,可以加我大家一起探討~
四、簡述TCP三次握手原理
CP/IP 是很多的不同的協(xié)議組成,實(shí)際上是一個協(xié)議組,TCP 用戶數(shù)據(jù)報表協(xié)議(也
稱作TCP 傳輸控制協(xié)議,Transport Control Protocol??煽康闹鳈C(jī)到主機(jī)層協(xié)議。這里要先
強(qiáng)調(diào)一下,傳輸控制協(xié)議是OSI 網(wǎng)絡(luò)的第四層的叫法,TCP 傳輸控制協(xié)議是TCP/IP 傳輸?shù)?
6 個基本協(xié)議的一種。兩個TCP 意思非相同。)。TCP 是一種可靠的面向連接的傳送服務(wù)。
它在傳送數(shù)據(jù)時是分段進(jìn)行的,主機(jī)交換數(shù)據(jù)必須建立一個會話。它用比特流通信,即數(shù)據(jù) 明報文接收計算機(jī)上的應(yīng)用程序地址接口。
TCP 序列號(序列碼,Sequence Number):32 位的序列號由接收端計算機(jī)使用,重
新分段的報文成最初形式。當(dāng)SYN 出現(xiàn),序列碼實(shí)際上是初始序列碼(ISN),而第一個數(shù)
據(jù)字節(jié)是ISN+1。這個序列號(序列碼)是可以補(bǔ)償傳輸中的不一致。
TCP 應(yīng)答號(Acknowledgment Number):32 位的序列號由接收端計算機(jī)使用,重
組分段的報文成最初形式。,如果設(shè)置了ACK 控制位,這個值表示一個準(zhǔn)備接收的包的序
列碼。
數(shù)據(jù)偏移量(HLEN):4 位包括TCP 頭大小,指示何處數(shù)據(jù)開始。
保留(Reserved):6 位值域,這些位必須是0。為了將來定義新的用途所保留。
標(biāo)志(Code Bits):6 位標(biāo)志域。表示為:緊急標(biāo)志、有意義的應(yīng)答標(biāo)志、推、重置
連接標(biāo)志、同步序列號標(biāo)志、完成發(fā)送數(shù)據(jù)標(biāo)志。按照順序排列是:URG、ACK、PSH、
RST、SYN、FIN。
窗口(Window):16 位,用來表示想收到的每個TCP 數(shù)據(jù)段的大小。
校驗(yàn)位(Checksum):16 位TCP 頭。源機(jī)器基于數(shù)據(jù)內(nèi)容計算一個數(shù)值,收信息機(jī)
要與源機(jī)器數(shù)值結(jié)果完全一樣,從而證明數(shù)據(jù)的有效性。
優(yōu)先指針(緊急,Urgent Pointer):16 位,指向后面是優(yōu)先數(shù)據(jù)的字節(jié),在URG
標(biāo)志設(shè)置了時才有效。如果URG 標(biāo)志沒有被設(shè)置,緊急域作為填充。加快處理標(biāo)示為緊急
的數(shù)據(jù)段。
選項(xiàng)(Option):長度不定,但長度必須以字節(jié)。如果沒有選項(xiàng)就表示這個一字節(jié)
的域等于0。
填充:不定長,填充的內(nèi)容必須為0,它是為了數(shù)學(xué)目的而存在。目的是確???
間的可預(yù)測性。保證包頭的結(jié)合和數(shù)據(jù)的開始處偏移量能夠被32 整除,一般額外的零以保
證TCP 頭是32 位的整數(shù)倍。
標(biāo)志控制功能
URG:緊急標(biāo)志
緊急(The urgent pointer) 標(biāo)志有效。緊急標(biāo)志置位,
ACK:確認(rèn)標(biāo)志
確認(rèn)編號(Acknowledgement Number)欄有效。大多數(shù)情況下該標(biāo)志位是置位的。
TCP 報頭內(nèi)的確認(rèn)編號欄內(nèi)包含的確認(rèn)編號(w+1,F(xiàn)igure:1)為下一個預(yù)期的序列編號,同
時提示遠(yuǎn)端系統(tǒng)已經(jīng)成功接收所有數(shù)據(jù)。
PSH:推標(biāo)志
該標(biāo)志置位時,接收端不將該數(shù)據(jù)進(jìn)行隊列處理,而是盡可能快將數(shù)據(jù)轉(zhuǎn)由應(yīng)用
處理。在處理telnet 或rlogin 等交互模式的連接時,該標(biāo)志總是置位的。
RST:復(fù)位標(biāo)志
復(fù)位標(biāo)志有效。用于復(fù)位相應(yīng)的TCP 連接。
SYN:同步標(biāo)志
同步序列編號(Synchronize Sequence Numbers)欄有效。該標(biāo)志僅在三次握手建立
TCP 連接時有效。它提示TCP 連接的服務(wù)端檢查序列編號,該序列編號為TCP 連接初始端
(一般是客戶端)的初始序列編號。在這里,可以把TCP 序列編號看作是一個范圍從0 到4,
294,967,295 的32 位計數(shù)器。通過TCP 連接交換的數(shù)據(jù)中每一個字節(jié)都經(jīng)過序列編號。
在TCP 報頭中的序列編號欄包括了TCP 分段中第一個字節(jié)的序列編號。
FIN:結(jié)束標(biāo)志
帶有該標(biāo)志置位的數(shù)據(jù)包用來結(jié)束一個TCP 回話,但對應(yīng)端口仍處于開放狀態(tài),
準(zhǔn)備接收后續(xù)數(shù)據(jù)。
服務(wù)端處于監(jiān)聽狀態(tài),客戶端用于建立連接請求的數(shù)據(jù)包(IP packet)按照TCP/IP
協(xié)議堆棧組合成為TCP 處理的分段(segment)。
分析報頭信息: TCP 層接收到相應(yīng)的TCP 和IP 報頭,將這些信息存儲到內(nèi)存中。
檢查TCP 校驗(yàn)和(checksum):標(biāo)準(zhǔn)的校驗(yàn)和位于分段之中(Figure:2)。如果檢驗(yàn)
失敗,不返回確認(rèn),該分段丟棄,并等待客戶端進(jìn)行重傳。
查找協(xié)議控制塊(PCB{}):TCP 查找與該連接相關(guān)聯(lián)的協(xié)議控制塊。如果沒有找
到,TCP 將該分段丟棄并返回RST。(這就是TCP 處理沒有端口監(jiān)聽情況下的機(jī)制) 如果該
協(xié)議控制塊存在,但狀態(tài)為關(guān)閉,服務(wù)端不調(diào)用connect()或listen()。該分段丟棄,但不返
回RST??蛻舳藭L試重新建立連接請求。
建立新的socket:當(dāng)處于監(jiān)聽狀態(tài)的socket 收到該分段時,會建立一個子socket,
同時還有socket{},tcpcb{}和pub{}建立。這時如果有錯的socket 和釋放內(nèi)存,TCP 連接失敗。如果緩存隊列處于填滿狀態(tài),TCP 認(rèn)為有錯誤發(fā)生,
所有的后續(xù)連接請求會被拒絕。這里可以看出SYN Flood 攻擊是如何起作用的。
丟棄:如果該分段中的標(biāo)志為RST 或ACK,或者沒有SYN 標(biāo)志,則該分段丟棄。
并釋放相應(yīng)的內(nèi)存。
發(fā)送序列變量
SND.UNA : 發(fā)送未確認(rèn)
SND.NXT : 發(fā)送下一個
SND.WND : 發(fā)送窗口
SND.UP : 發(fā)送優(yōu)先指針
SND.WL1 : 用于最后窗口更新的段序列號
SND.WL2 : 用于最后窗口更新的段確認(rèn)號
ISS : 初始發(fā)送序列號
接收序列號
RCV.NXT : 接收下一個
RCV.WND : 接收下一個
RCV.UP : 接收優(yōu)先指針
IRS : 初始接收序列號
當(dāng)前段變量
SEG.SEQ : 段序列號
SEG.ACK : 段確認(rèn)標(biāo)記
SEG.LEN : 段長
SEG.WND : 段窗口
SEG.UP : 段緊急指針
SEG.PRC : 段優(yōu)先級
CLOSED 表示沒有連接,各個狀態(tài)的意義如下:
LISTEN : 監(jiān)聽來自遠(yuǎn)方TCP 端口的連接請求。
SYN-SENT : 在發(fā)送連接請求后等待匹配的連接請求。
SYN-RECEIVED : 在收到和發(fā)送一個連接請求后等待對連接請求的確認(rèn)。
ESTABLISHED : 代表一個打開的連接,數(shù)據(jù)可以傳送給用戶。
FIN-WAIT-1 : 等待遠(yuǎn)程TCP 的連接中斷請求,或先前的連接中斷請求的確認(rèn)。
FIN-WAIT-2 : 從遠(yuǎn)程TCP 等待連接中斷請求。
CLOSE-WAIT : 等待從本地用戶發(fā)來的連接中斷請求。
CLOSING : 等待遠(yuǎn)程TCP 對連接中斷的確認(rèn)。
LAST-ACK : 等待原來發(fā)向遠(yuǎn)程TCP 的連接中斷請求的確認(rèn)。
TIME-WAIT : 等待足夠的時間以確保遠(yuǎn)程TCP 接收到連接中斷請求的確認(rèn)。
CLOSED : 沒有任何連接狀態(tài)。
TCP 連接過程是狀態(tài)的轉(zhuǎn)換,促使發(fā)生狀態(tài)轉(zhuǎn)換的是用戶調(diào)用:OPEN,SEND,
RECEIVE,CLOSE,ABORT 和STATUS。傳送過來的數(shù)據(jù)段,特別那些包括以下標(biāo)記的數(shù)
據(jù)段SYN,ACK,RST 和FIN。還有超時,上面所說的都會時TCP 狀態(tài)發(fā)生變化。
序列號
請注意,我們在TCP 連接中發(fā)送的字節(jié)都有一個序列號。因?yàn)榫幜颂?,所以可?
確認(rèn)它們的收到。對序列號的確認(rèn)是累積性的。TCP 必須進(jìn)行的序列號比較操作種類包括
以下幾種:
①決定一些發(fā)送了的但未確認(rèn)的序列號。
②決定所有的序列號都已經(jīng)收到了。
③決定下一個段中應(yīng)該包括的序列號。
對于發(fā)送的數(shù)據(jù)TCP 要接收確認(rèn),確認(rèn)時必須進(jìn)行的:
SND.UNA = 最老的確認(rèn)了的序列號。
SND.NXT = 下一個要發(fā)送的序列號。
SEG.ACK = 接收TCP 的確認(rèn),接收TCP 期待的下一個序列號。
SEG.SEQ = 一個數(shù)據(jù)段的第一個序列號。
SEG.LEN = 數(shù)據(jù)段中包括的字節(jié)數(shù)。
SEG.SEQ+SEG.LEN-1 = 數(shù)據(jù)段的最后一個序列號。
如果一個數(shù)據(jù)段的序列號小于等于確認(rèn)號的值,那么整個數(shù)據(jù)段就被確認(rèn)了。而
在接收數(shù)據(jù)時下面的比較操作是必須的:
RCV.NXT = 期待的序列號和接收窗口的最低沿。
RCV.NXT+RCV.WND:1 = 最后一個序列號和接收窗口的最高沿。
SEG.SEQ = 接收到的第一個序列號。
SEG.SEQ+SEG.LEN:1 = 接收到的最后一個序列號。
誤發(fā)生,會通過標(biāo)志位來拆除相應(yīng)
被作為無結(jié)構(gòu)的字節(jié)流。通過每個TCP 傳輸?shù)淖侄沃付樞蛱?,以獲得可靠性。是在OSI
參考模型中的第四層,TCP 是使用IP 的網(wǎng)間互聯(lián)功能而提供可靠的數(shù)據(jù)傳輸,IP 不停的把
報文放到網(wǎng)絡(luò)上,而TCP 是負(fù)責(zé)確信報文到達(dá)。在協(xié)同IP 的操作中TCP 負(fù)責(zé):握手過程、
報文管理、流量控制、錯誤檢測和處理(控制),可以根據(jù)一定的編號順序?qū)Ψ钦m樞虻?
報文給予從新排列順序。關(guān)于TCP 的RFC 文檔有RFC793、RFC791、RFC1700。
在TCP 會話初期,有所謂的“三握手”:對每次發(fā)送的數(shù)據(jù)量是怎樣跟蹤進(jìn)行協(xié)商使
數(shù)據(jù)段的發(fā)送和接收同步,根據(jù)所接收到的數(shù)據(jù)量而確定的數(shù)據(jù)確認(rèn)數(shù)及數(shù)據(jù)發(fā)送、接收完
畢后何時撤消聯(lián)系,并建立虛連接。為了提供可靠的傳送,TCP 在發(fā)送新的數(shù)據(jù)之前,以
特定的順序?qū)?shù)據(jù)包的序號,并需要這些包傳送給目標(biāo)機(jī)之后的確認(rèn)消息。TCP 總是用來
發(fā)送大批量的數(shù)據(jù)。當(dāng)應(yīng)用程序在收到數(shù)據(jù)后要做出確認(rèn)時也要用到TCP。由于TCP 需要
時刻跟蹤,這需要額外開銷,使得TCP 的格式有些顯得復(fù)雜。下面就讓我們看一個TCP 的
經(jīng)典案例,這是后來被稱為MITNICK 攻擊中KEVIN 開創(chuàng)了兩種攻擊技術(shù):
TCP 會話劫持
SYN FLOOD(同步洪流)
在這里我們討論的時TCP 會話劫持的問題。
先讓我們明白TCP 建立連接的基本簡單的過程。為了建設(shè)一個小型的模仿環(huán)境我們假
設(shè)有3 臺接入互聯(lián)網(wǎng)的機(jī)器。A 為攻擊者操縱的攻擊機(jī)。B 為中介跳板機(jī)器(受信任的服務(wù)
器)。C 為受害者使用的機(jī)器(多是服務(wù)器),這里把C 機(jī)器鎖定為目標(biāo)機(jī)器。A 機(jī)器向B
機(jī)器發(fā)送SYN 包,請求建立連接,這時已經(jīng)響應(yīng)請求的B 機(jī)器會向A 機(jī)器回應(yīng)SYN/ACK
表明同意建立連接,當(dāng)A 機(jī)器接受到B 機(jī)器發(fā)送的SYN/ACK 回應(yīng)時,發(fā)送應(yīng)答ACK 建立
A 機(jī)器與B 機(jī)器的網(wǎng)絡(luò)連接。這樣一個兩臺機(jī)器之間的TCP 通話信道就建立成功了。
B 終端受信任的服務(wù)器向C 機(jī)器發(fā)起TCP 連接,A 機(jī)器對服務(wù)器發(fā)起SYN 信息,使
C 機(jī)器不能響應(yīng)B 機(jī)器。在同時A 機(jī)器也向B 機(jī)器發(fā)送虛假的C 機(jī)器回應(yīng)的SYN 數(shù)據(jù)包,
接收到SYN 數(shù)據(jù)包的B 機(jī)器(被C 機(jī)器信任)開始發(fā)送應(yīng)答連接建立的SYN/ACK 數(shù)據(jù)包,
這時C 機(jī)器正在忙于響應(yīng)以前發(fā)送的SYN 數(shù)據(jù)而無暇回應(yīng)B 機(jī)器,而A 機(jī)器的攻擊者預(yù)
測出B 機(jī)器包的序列號(現(xiàn)在的TCP 序列號預(yù)測難度有所加大)假冒C 機(jī)器向B 機(jī)器發(fā)送
應(yīng)答ACK 這時攻擊者騙取B 機(jī)器的信任,假冒C 機(jī)器與B 機(jī)器建立起TCP 協(xié)議的對話連
接。這個時候的C 機(jī)器還是在響應(yīng)攻擊者A 機(jī)器發(fā)送的SYN 數(shù)據(jù)。
TCP 協(xié)議棧的弱點(diǎn):TCP 連接的資源消耗,其中包括:數(shù)據(jù)包信息、條件狀態(tài)、序列
號等。通過故意不完成建立連接所需要的三次握手過程,造成連接一方的資源耗盡。
通過攻擊者有意的不完成建立連接所需要的三次握手的全過程,從而造成了C 機(jī)器的
資源耗盡。序列號的可預(yù)測性,目標(biāo)主機(jī)應(yīng)答連接請求時返回的SYN/ACK 的序列號時可預(yù)
測的。(早期TCP 協(xié)議棧,具體的可以參見1981 年出的關(guān)于TCP 雛形的RFC793 文檔)
TCP 頭結(jié)構(gòu)
TCP 協(xié)議頭最少20 個字節(jié),包括以下的區(qū)域(由于翻譯不禁相同,文章中給出
相應(yīng)的英文單詞):
TCP 源端口(Source Port):16 位的源端口其中包含初始化通信的端口。源端口和
源IP 地址的作用是標(biāo)示報問的返回地址。
TCP 目的端口(Destination port):16 位的目的端口域定義傳輸?shù)哪康?
以上就是關(guān)于tcp建立連接的三次握手過程相關(guān)問題的回答。希望能幫到你,如有更多相關(guān)問題,您也可以聯(lián)系我們的客服進(jìn)行咨詢,客服也會為您講解更多精彩的知識和內(nèi)容。
推薦閱讀:
南京歐式庭院景觀設(shè)計公司(南京歐式庭院景觀設(shè)計公司地址)
日本參與的侵華戰(zhàn)爭有哪些(日本參與的侵華戰(zhàn)爭有哪些國家)