HOME 首頁
SERVICE 服務(wù)產(chǎn)品
XINMEITI 新媒體代運營
CASE 服務(wù)案例
NEWS 熱點資訊
ABOUT 關(guān)于我們
CONTACT 聯(lián)系我們
創(chuàng)意嶺
讓品牌有溫度、有情感
專注品牌策劃15年

    tcp抓包解密(tcp協(xié)議抓包分析代碼)

    發(fā)布時間:2023-03-19 12:54:38     稿源: 創(chuàng)意嶺    閱讀: 128        問大家

    大家好!今天讓創(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抓包解密(tcp協(xié)議抓包分析代碼)

    一、TCP協(xié)議詳解及實戰(zhàn)解析【精心整理收藏】

    TCP協(xié)議是在TCP/IP協(xié)議模型中的運輸層中很重要的一個協(xié)議、負(fù)責(zé)處理主機端口層面之間的數(shù)據(jù)傳輸。主要有以下特點:

    1.TCP是面向鏈接的協(xié)議,在數(shù)據(jù)傳輸之前需要通過三次握手建立TCP鏈接,當(dāng)數(shù)據(jù)傳遞完成之后,需要通過四次揮手進(jìn)行連接釋放。

    2.每一條TCP通信都是兩臺主機和主機之間的,是點對點傳輸?shù)膮f(xié)議。

    3.TCP提供可靠的、無差錯、不丟失、不重復(fù),按序到達(dá)的服務(wù)。

    4.TCP的通信雙方在連接建立的任何時候都可以發(fā)送數(shù)據(jù)。TCP連接的兩端都設(shè)有發(fā)送緩存和接收緩存,用來臨時存放雙向通信的數(shù)據(jù)。

    5.面向字節(jié)流。在數(shù)據(jù)傳輸?shù)倪^程中如果報文比較長的話TCP會進(jìn)行數(shù)據(jù)分段傳輸,每一條分段的TCP傳輸信息都帶有分段的序號,每一段都包含一部分字節(jié)流。接收方根據(jù)每段攜帶的的序號信息進(jìn)行數(shù)據(jù)拼接,最終拼接出來初始的傳輸數(shù)據(jù)。但是在整個傳輸?shù)倪^程中每一段TCP攜帶的都是被切割的字節(jié)流數(shù)據(jù)。所以說TCP是面向字節(jié)流的。

    a.TCP和UDP在發(fā)送報文時所采用的方式完全不同。TCP并不關(guān)心應(yīng)用程序一次把多長的報文發(fā)送到TCP緩存中,而是根據(jù)對方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來決定一個報文段應(yīng)包含多少個字節(jié)(UDP發(fā)送的報文長度是應(yīng)用程序給出的)。

    b.如果應(yīng)用程序傳送到TCP緩存的數(shù)據(jù)塊太大,TCP就可以把它劃分短一些再傳。TCP也可以等待積累有足夠多的字節(jié)后再構(gòu)建成報文段發(fā)送出去。

    各字段含義:

    源端口:發(fā)送端的端口號

    目的端口:接收端的端口號

    序號:TCP將發(fā)送報文分段傳輸?shù)臅r候會給每一段加上序號,接收端也可以根據(jù)這個序號來判斷數(shù)據(jù)拼接的順序,主要用來解決網(wǎng)絡(luò)報亂序的問題

    確認(rèn)號:確認(rèn)號為接收端收到數(shù)據(jù)之后進(jìn)行排序確認(rèn)以及發(fā)送下一次期待接收到的序號,數(shù)值 = 接收到的發(fā)送號 + 1

    數(shù)據(jù)偏移:占4比特,表示數(shù)據(jù)開始的地方離TCP段的起始處有多遠(yuǎn)。實際上就是TCP段首部的長度。由于首部長度不固定,因此數(shù)據(jù)偏移字段是必要的。數(shù)據(jù)偏移以32位為長度單位,因此TCP首部的最大長度是60(15*4)個字節(jié)。

    控制位:

    URG:此標(biāo)志表示TCP包的緊急指針域有效,用來保證TCP連接不被中斷,并且督促 中間層設(shè)備要盡快處理這些數(shù)據(jù);

    ACK:此標(biāo)志表示應(yīng)答域有效,就是說前面所說的TCP應(yīng)答號將會包含在TCP數(shù)據(jù)包中;有兩個取值:0和1, 為1的時候表示應(yīng)答域有效,反之為0;

    PSH:這個標(biāo)志位表示Push操作。所謂Push操作就是指在數(shù)據(jù)包到達(dá)接收端以后,立即傳送給應(yīng)用程序, 而不是在緩沖區(qū)中排隊;

    RST:這個標(biāo)志表示連接復(fù)位請求。用來復(fù)位那些產(chǎn)生錯誤的連接,也被用來拒絕錯誤和非法的數(shù)據(jù)包;

    SYN:表示同步序號,用來建立連接。SYN標(biāo)志位和ACK標(biāo)志位搭配使用,當(dāng)連接請求的時候,SYN=1, ACK=0;連接被響應(yīng)的時候,SYN=1,ACK=1;這個標(biāo)志的數(shù)據(jù)包經(jīng)常被用來進(jìn)行端口掃描。掃描者發(fā)送 一個只有SYN的數(shù)據(jù)包,如果對方主機響應(yīng)了一個數(shù)據(jù)包回來 ,就表明這臺主機存在這個端口;但是由于這 種掃描方式只是進(jìn)行TCP三次握手的第一次握手,因此這種掃描的成功表示被掃描的機器不很安全,一臺安全 的主機將會強制要求一個連接嚴(yán)格的進(jìn)行TCP的三次握手;

    FIN: 表示發(fā)送端已經(jīng)達(dá)到數(shù)據(jù)末尾,也就是說雙方的數(shù)據(jù)傳送完成,沒有數(shù)據(jù)可以傳送了,發(fā)送FIN標(biāo)志 位的TCP數(shù)據(jù)包后,連接將被斷開。這個標(biāo)志的數(shù)據(jù)包也經(jīng)常被用于進(jìn)行端口掃描。

    窗口:TCP里很重要的一個機制,占2字節(jié),表示報文段發(fā)送方期望接收的字節(jié)數(shù),可接收的序號范圍是從接收方的確認(rèn)號開始到確認(rèn)號加上窗口大小之間的數(shù)據(jù)。后面會有實例講解。

    校驗和:校驗和包含了偽首部、TCP首部和數(shù)據(jù),校驗和是TCP強制要求的,由發(fā)送方計算,接收方驗證

    緊急指針:URG標(biāo)志為1時,緊急指針有效,表示數(shù)據(jù)需要優(yōu)先處理。緊急指針指出在TCP段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號,使接收方可以知道緊急數(shù)據(jù)共有多長。

    選項:最常用的選項是最大段大小(Maximum Segment Size,MSS),向?qū)Ψ酵ㄖ緳C可以接收的最大TCP段長度。MSS選項只在建立連接的請求中發(fā)送。

    放在以太網(wǎng)幀里看TCP的位置

    TCP 數(shù)據(jù)包在 IP 數(shù)據(jù)包的負(fù)載里面。它的頭信息最少也需要20字節(jié),因此 TCP 數(shù)據(jù)包的最大負(fù)載是 1480 - 20 = 1460 字節(jié)。由于 IP 和 TCP 協(xié)議往往有額外的頭信息,所以 TCP 負(fù)載實際為1400字節(jié)左右。

    因此,一條1500字節(jié)的信息需要兩個 TCP 數(shù)據(jù)包。HTTP/2 協(xié)議的一大改進(jìn), 就是壓縮 HTTP 協(xié)議的頭信息,使得一個 HTTP 請求可以放在一個 TCP 數(shù)據(jù)包里面,而不是分成多個,這樣就提高了速度。

    以太網(wǎng)數(shù)據(jù)包的負(fù)載是1500字節(jié),TCP 數(shù)據(jù)包的負(fù)載在1400字節(jié)左右

    一個包1400字節(jié),那么一次性發(fā)送大量數(shù)據(jù),就必須分成多個包。比如,一個 10MB 的文件,需要發(fā)送7100多個包。

    發(fā)送的時候,TCP 協(xié)議為每個包編號(sequence number,簡稱 SEQ),以便接收的一方按照順序還原。萬一發(fā)生丟包,也可以知道丟失的是哪一個包。

    第一個包的編號是一個隨機數(shù)。為了便于理解,這里就把它稱為1號包。假定這個包的負(fù)載長度是100字節(jié),那么可以推算出下一個包的編號應(yīng)該是101。這就是說,每個數(shù)據(jù)包都可以得到兩個編號:自身的編號,以及下一個包的編號。接收方由此知道,應(yīng)該按照什么順序?qū)⑺鼈冞€原成原始文件。

    收到 TCP 數(shù)據(jù)包以后,組裝還原是操作系統(tǒng)完成的。應(yīng)用程序不會直接處理 TCP 數(shù)據(jù)包。

    對于應(yīng)用程序來說,不用關(guān)心數(shù)據(jù)通信的細(xì)節(jié)。除非線路異常,否則收到的總是完整的數(shù)據(jù)。應(yīng)用程序需要的數(shù)據(jù)放在 TCP 數(shù)據(jù)包里面,有自己的格式(比如 HTTP 協(xié)議)。

    TCP 并沒有提供任何機制,表示原始文件的大小,這由應(yīng)用層的協(xié)議來規(guī)定。比如,HTTP 協(xié)議就有一個頭信息Content-Length,表示信息體的大小。對于操作系統(tǒng)來說,就是持續(xù)地接收 TCP 數(shù)據(jù)包,將它們按照順序組裝好,一個包都不少。

    操作系統(tǒng)不會去處理 TCP 數(shù)據(jù)包里面的數(shù)據(jù)。一旦組裝好 TCP 數(shù)據(jù)包,就把它們轉(zhuǎn)交給應(yīng)用程序。TCP 數(shù)據(jù)包里面有一個端口(port)參數(shù),就是用來指定轉(zhuǎn)交給監(jiān)聽該端口的應(yīng)用程序。

    應(yīng)用程序收到組裝好的原始數(shù)據(jù),以瀏覽器為例,就會根據(jù) HTTP 協(xié)議的Content-Length字段正確讀出一段段的數(shù)據(jù)。這也意味著,一次 TCP 通信可以包括多個 HTTP 通信。

    服務(wù)器發(fā)送數(shù)據(jù)包,當(dāng)然越快越好,最好一次性全發(fā)出去。但是,發(fā)得太快,就有可能丟包。帶寬小、路由器過熱、緩存溢出等許多因素都會導(dǎo)致丟包。線路不好的話,發(fā)得越快,丟得越多。

    最理想的狀態(tài)是,在線路允許的情況下,達(dá)到最高速率。但是我們怎么知道,對方線路的理想速率是多少呢?答案就是慢慢試。

    TCP 協(xié)議為了做到效率與可靠性的統(tǒng)一,設(shè)計了一個慢啟動(slow start)機制。開始的時候,發(fā)送得較慢,然后根據(jù)丟包的情況,調(diào)整速率:如果不丟包,就加快發(fā)送速度;如果丟包,就降低發(fā)送速度。

    Linux 內(nèi)核里面 設(shè)定 了(常量TCP_INIT_CWND),剛開始通信的時候,發(fā)送方一次性發(fā)送10個數(shù)據(jù)包,即"發(fā)送窗口"的大小為10。然后停下來,等待接收方的確認(rèn),再繼續(xù)發(fā)送。

    默認(rèn)情況下,接收方每收到 兩個 TCP 數(shù)據(jù)包,就要 發(fā)送 一個確認(rèn)消息。"確認(rèn)"的英語是 acknowledgement,所以這個確認(rèn)消息就簡稱 ACK。

    ACK 攜帶兩個信息。

    發(fā)送方有了這兩個信息,再加上自己已經(jīng)發(fā)出的數(shù)據(jù)包的最新編號,就會推測出接收方大概的接收速度,從而降低或增加發(fā)送速率。這被稱為"發(fā)送窗口",這個窗口的大小是可變的。

    注意,由于 TCP 通信是雙向的,所以雙方都需要發(fā)送 ACK。兩方的窗口大小,很可能是不一樣的。而且 ACK 只是很簡單的幾個字段,通常與數(shù)據(jù)合并在一個數(shù)據(jù)包里面發(fā)送。

    即使對于帶寬很大、線路很好的連接,TCP 也總是從10個數(shù)據(jù)包開始慢慢試,過了一段時間以后,才達(dá)到最高的傳輸速率。這就是 TCP 的慢啟動。

    TCP 協(xié)議可以保證數(shù)據(jù)通信的完整性,這是怎么做到的?

    前面說過,每一個數(shù)據(jù)包都帶有下一個數(shù)據(jù)包的編號。如果下一個數(shù)據(jù)包沒有收到,那么 ACK 的編號就不會發(fā)生變化。

    舉例來說,現(xiàn)在收到了4號包,但是沒有收到5號包。ACK 就會記錄,期待收到5號包。過了一段時間,5號包收到了,那么下一輪 ACK 會更新編號。如果5號包還是沒收到,但是收到了6號包或7號包,那么 ACK 里面的編號不會變化,總是顯示5號包。這會導(dǎo)致大量重復(fù)內(nèi)容的 ACK。

    如果發(fā)送方發(fā)現(xiàn)收到 三個 連續(xù)的重復(fù) ACK,或者超時了還沒有收到任何 ACK,就會確認(rèn)丟包,即5號包遺失了,從而再次發(fā)送這個包。通過這種機制,TCP 保證了不會有數(shù)據(jù)包丟失。

    TCP是一個滑動窗口協(xié)議,即一個TCP連接的發(fā)送端在某個時刻能發(fā)多少數(shù)據(jù)是由滑動窗口控制的,而滑動窗口的大小實際上是由兩個窗口共同決定的,一個是接收端的通告窗口,這個窗口值在TCP協(xié)議頭部信息中有,會隨著數(shù)據(jù)的ACK包發(fā)送給發(fā)送端,這個值表示的是在接收端的TCP協(xié)議緩存中還有多少剩余空間,發(fā)送端必須保證發(fā)送的數(shù)據(jù)不超過這個剩余空間以免造成緩沖區(qū)溢出,這個窗口是接收端用來進(jìn)行流量限制的,在傳輸過程中,通告窗口大小與接收端的進(jìn)程取出數(shù)據(jù)的快慢有關(guān)。另一個窗口是發(fā)送端的擁塞窗口(Congestion window),由發(fā)送端維護這個值,在協(xié)議頭部信息中沒有,滑動窗口的大小就是通告窗口和擁塞窗口的較小值,所以擁塞窗口也看做是發(fā)送端用來進(jìn)行流量控制的窗口?;瑒哟翱诘淖筮呇叵蛴乙苿臃Q為窗口合攏,發(fā)生在發(fā)送的數(shù)據(jù)被確認(rèn)時(此時,表明數(shù)據(jù)已被接收端收到,不會再被需要重傳,可以從發(fā)送端的發(fā)送緩存中清除了),滑動窗口的右邊沿向右移動稱為窗口張開,發(fā)生在接收進(jìn)程從接收端協(xié)議緩存中取出數(shù)據(jù)時。隨著發(fā)送端不斷收到的被發(fā)送數(shù)據(jù)的ACK包,根據(jù)ACK包中的確認(rèn)序號和通告窗口大小使滑動窗口得以不斷的合攏和張開,形成滑動窗口的向前滑動。如果接收進(jìn)程一直不取數(shù)據(jù),則會出現(xiàn)0窗口現(xiàn)象,即滑動窗口左邊沿與右邊沿重合,此時窗口大小為0,就無法再發(fā)送數(shù)據(jù)。

    在TCP里,接收端(B)會給發(fā)送端(A)報一個窗口的大小,叫Advertised window。

    1.在沒有收到B的確認(rèn)情況下,A可以連續(xù)把窗口內(nèi)的數(shù)據(jù)都發(fā)送出去。凡是已經(jīng)發(fā)送過的數(shù)據(jù),在

    未收到確認(rèn)之前都必須暫時保留,以便在超時重傳時使用。

    2.發(fā)送窗口里面的序號表示允許發(fā)送的序號。顯然,窗口越大,發(fā)送方就可以在收到對方確認(rèn)之前連續(xù)

    發(fā)送更多數(shù)據(jù),因而可能獲得更高的傳輸效率。但接收方必須來得及處理這些收到的數(shù)據(jù)。

    3.發(fā)送窗口后沿的后面部分表示已發(fā)送且已收到確認(rèn)。這些數(shù)據(jù)顯然不需要再保留了。

    4.發(fā)送窗口前沿的前面部分表示不允許發(fā)送的,應(yīng)為接收方都沒有為這部分?jǐn)?shù)據(jù)保留臨時存放的緩存空間。

    5.發(fā)送窗口后沿的變化情況有兩種:不動(沒有收到新的確認(rèn))和前移(收到了新的確認(rèn))

    6.發(fā)送窗口前沿的變化情況有兩種:不斷向前移或可能不動(沒收到新的確認(rèn))

    TCP的發(fā)送方在規(guī)定時間內(nèi)沒有收到確認(rèn)就要重傳已發(fā)送的報文段。這種重傳的概念很簡單,但重傳時間的選擇確是TCP最復(fù)雜的問題之一。TCP采用了一種自適應(yīng)算法,它記錄一個報文段發(fā)出的時間,以及收到響應(yīng)的確認(rèn)的時間

    這兩個時間之差就是報文段的往返時間RTT。TCP保留了RTT的一個加權(quán)平均往返時間。超時重傳時間RTO略大于加權(quán)平均往返時間

    RTT:

    即Round Trip Time,表示從發(fā)送端到接收端的一去一回需要的時間,tcp在數(shù)據(jù)傳輸過程中會對RTT進(jìn)行采樣(即對發(fā)送的數(shù)據(jù)包及其ACK的時間差進(jìn)行測量,并根據(jù)測量值更新RTT值,具體的算法TCPIP詳解里面有),TCP根據(jù)得到的RTT值更新RTO值,即Retransmission TimeOut,就是重傳間隔,發(fā)送端對每個發(fā)出的數(shù)據(jù)包進(jìn)行計時,如果在RTO時間內(nèi)沒有收到所發(fā)出的數(shù)據(jù)包的對應(yīng)ACK,則任務(wù)數(shù)據(jù)包丟失,將重傳數(shù)據(jù)。一般RTO值都比采樣得到的RTT值要大。

    如果收到的報文段無差錯,只是未按序號,中間還缺少一些序號的數(shù)據(jù),那么能否設(shè)法只傳送缺少的數(shù)據(jù)而不重傳已經(jīng)正確到達(dá)接收方的數(shù)據(jù)?

    答案是可以的,選擇確認(rèn)就是一種可行的處理方法。

    如果要使用選項確認(rèn)SACK,那么在建立TCP連接時,就要在TCP首部的選項中加上“允許SACK”的選項,而雙方必須都事先商定好。如果使用選擇確認(rèn),

    那么原來首部中的“確認(rèn)號字段”的用法仍然不變。SACK文檔并沒有明確發(fā)送方應(yīng)當(dāng)怎么響應(yīng)SACK.因此大多數(shù)的實現(xiàn)還是重傳所有未被確認(rèn)的數(shù)據(jù)塊。

    一般說來,我們總是希望數(shù)據(jù)傳輸?shù)母煲恍?,但如果發(fā)送方把數(shù)據(jù)發(fā)送的過快,接收方就可能來不及接收,這會造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快,要讓接收方來得及接收。

    在計算機網(wǎng)絡(luò)中的鏈路容量,交換節(jié)點中的緩存和處理機等,都是網(wǎng)絡(luò)的資源。在某段時間,若對網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分,網(wǎng)絡(luò)的性能就要變壞。這種情況就叫做擁塞。

    擁塞控制方法:

    1.慢開始和擁塞避免

    2.快重傳和快恢復(fù)

    3.隨機早期檢測

    1.一開始,客戶端和服務(wù)端都處于CLOSED狀態(tài)

    2.先是服務(wù)端主動監(jiān)聽某個端口,處于LISTEN狀態(tài)(比如服務(wù)端啟動,開始監(jiān)聽)。

    3.客戶端主動發(fā)起連接SYN,之后處于SYN-SENT狀態(tài)(第一次握手,發(fā)送 SYN = 1 ACK = 0 seq = x ack = 0)。

    4.服務(wù)端收到發(fā)起的連接,返回SYN,并且ACK客戶端的SYN,之后處于SYN-RCVD狀態(tài)(第二次握手,發(fā)送 SYN = 1 ACK = 1 seq = y ack = x + 1)。

    5.客戶端收到服務(wù)端發(fā)送的SYN和ACK之后,發(fā)送ACK的ACK,之后處于ESTABLISHED狀態(tài)(第三次握手,發(fā)送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1)。

    6.服務(wù)端收到客戶端的ACK之后,處于ESTABLISHED狀態(tài)。

    (需要注意的是,有可能X和Y是相等的,可能都是0,因為他們代表了各自發(fā)送報文段的序號。)

    TCP連接釋放四次揮手

    1.當(dāng)前A和B都處于ESTAB-LISHED狀態(tài)。

    2.A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報文段,并停止再發(fā)送數(shù)據(jù),主動關(guān)閉TCP連接。

    3.B收到連接釋放報文段后即發(fā)出確認(rèn),然后B進(jìn)入CLOSE-WAIT(關(guān)閉等待)狀態(tài)。TCP服務(wù)器進(jìn)程這時應(yīng)通知高層應(yīng)用進(jìn)程,因而從A到B這個方向的連接就釋放了,這時TCP連接處于半關(guān)閉狀態(tài),即A已經(jīng)沒有數(shù)據(jù)發(fā)送了。

    從B到A這個方向的連接并未關(guān)閉,這個狀態(tài)可能會持續(xù)一些時間。

    4.A收到來自B的確認(rèn)后,就進(jìn)入FIN-WAIT-2(終止等待2)狀態(tài),等待B發(fā)出的連接釋放報文端。

    5.若B已經(jīng)沒有向A發(fā)送的數(shù)據(jù),B發(fā)出連接釋放信號,這時B進(jìn)入LAST-ACK(最后確認(rèn))狀態(tài)等待A的確認(rèn)。

    6.A再收到B的連接釋放消息后,必須對此發(fā)出確認(rèn),然后進(jìn)入TIME-WAIT(時間等待)狀態(tài)。請注意,現(xiàn)在TCP連接還沒有釋放掉,必須經(jīng)過時間等待計時器(TIME-WAIT timer)設(shè)置的時間2MSL后,A才進(jìn)入CLOSED狀態(tài)。

    7。B收到A發(fā)出的確認(rèn)消息后,進(jìn)入CLOSED狀態(tài)。

    以請求百度為例,看一下三次握手真實數(shù)據(jù)的TCP連接建立過程

    我們再來看四次揮手。TCP斷開連接時,會有四次揮手過程,標(biāo)志位是FIN,我們在封包列表中找到對應(yīng)位置,理論上應(yīng)該找到4個數(shù)據(jù)包,但我試了好幾次,實際只抓到3個數(shù)據(jù)包。查了相關(guān)資料,說是因為服務(wù)器端在給客戶端傳回的過程中,將兩個連續(xù)發(fā)送的包進(jìn)行了合并。因此下面會按照合并后的三次揮手解釋,若有錯誤之處請指出。

    第一步,當(dāng)主機A的應(yīng)用程序通知TCP數(shù)據(jù)已經(jīng)發(fā)送完畢時,TCP向主機B發(fā)送一個帶有FIN附加標(biāo)記的報文段(FIN表示英文finish)。

    第二步,主機B收到這個FIN報文段之后,并不立即用FIN報文段回復(fù)主機A,而是先向主機A發(fā)送一個確認(rèn)序號ACK,同時通知自己相應(yīng)的應(yīng)用程序:對方要求關(guān)閉連接(先發(fā)送ACK的目的是為了防止在這段時間內(nèi),對方重傳FIN報文段)。

    第三步,主機B的應(yīng)用程序告訴TCP:我要徹底的關(guān)閉連接,TCP向主機A送一個FIN報文段。

    第四步,主機A收到這個FIN報文段后,向主機B發(fā)送一個ACK表示連接徹底釋放。

    這是因為服務(wù)端在LISTEN狀態(tài)下,收到建立連接請求的SYN報文后,把ACK和SYN放在一個報文里發(fā)送給客戶端。而關(guān)閉連接時,當(dāng)收到對方的FIN報文時,僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù),己方也未必全部數(shù)據(jù)都發(fā)送給對方了,所以己方可以立即close,也可以發(fā)送一些數(shù)據(jù)給對方后,再發(fā)送FIN報文給對方來表示同意現(xiàn)在關(guān)閉連接,因此,己方ACK和FIN一般都會分開發(fā)送。

    原因有二:

    一、保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉

    二、保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失

    先說第一點,如果Client直接CLOSED了,那么由于IP協(xié)議的不可靠性或者是其它網(wǎng)絡(luò)原因,導(dǎo)致Server沒有收到Client最后回復(fù)的ACK。那么Server就會在超時之后繼續(xù)發(fā)送FIN,此時由于Client已經(jīng)CLOSED了,就找不到與重發(fā)的FIN對應(yīng)的連接,最后Server就會收到RST而不是ACK,Server就會以為是連接錯誤把問題報告給高層。這樣的情況雖然不會造成數(shù)據(jù)丟失,但是卻導(dǎo)致TCP協(xié)議不符合可靠連接的要求。所以,Client不是直接進(jìn)入CLOSED,而是要保持TIME_WAIT,當(dāng)再次收到FIN的時候,能夠保證對方收到ACK,最后正確的關(guān)閉連接。

    再說第二點,如果Client直接CLOSED,然后又再向Server發(fā)起一個新連接,我們不能保證這個新連接與剛關(guān)閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發(fā)生什么問題,但是還是有特殊情況出現(xiàn):假設(shè)新連接和已經(jīng)關(guān)閉的老連接端口號是一樣的,如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中,這些延遲數(shù)據(jù)在建立新連接之后才到達(dá)Server,由于新連接和老連接的端口號是一樣的,又因為TCP協(xié)議判斷不同連接的依據(jù)是socket pair,于是,TCP協(xié)議就認(rèn)為那個延遲的數(shù)據(jù)是屬于新連接的,這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。所以TCP連接還要在TIME_WAIT狀態(tài)等待2倍MSL,這樣可以保證本次連接的所有數(shù)據(jù)都從網(wǎng)絡(luò)中消失。

    硬件速度

    網(wǎng)絡(luò)和服務(wù)器的負(fù)載

    請求和響應(yīng)報文的尺寸

    客戶端和服務(wù)器之間的距離

    TCP 協(xié)議的技術(shù)復(fù)雜性

    TCP 連接建立握手;

    TCP 慢啟動擁塞控制;

    數(shù)據(jù)聚集的 Nagle 算法;

    用于捎帶確認(rèn)的 TCP 延遲確認(rèn)算法;

    TIME_WAIT 時延和端口耗盡。

    介紹完畢,就這?

    是的,就這。

    補充:

    大部分內(nèi)容為網(wǎng)絡(luò)整理,方便自己學(xué)習(xí)回顧,參考文章:

    TCP 協(xié)議簡介

    TCP協(xié)議圖文詳解

    什么是TCP協(xié)議?

    wireshark抓包分析——TCP/IP協(xié)議

    TCP協(xié)議的三次握手和四次揮手

    TCP協(xié)議詳解

    TCP帶寬和時延的研究(1)

    二、tcpdump常用的抓包命令

    做OTT-IP TV這一行的,遇到問題經(jīng)常需要抓網(wǎng)絡(luò)包,tcpdump就是一個很好用的工具。如果不會tcpdump出門都不好意思打招呼。

    別看tcpdump有很多的選項,其實常用的也就那么幾個,比如

    tcpdump -i 網(wǎng)絡(luò)接口 -s 網(wǎng)絡(luò)數(shù)據(jù)包長度 -w 文件名

    -i: 后面是網(wǎng)卡名。一般有eth0,eth1等網(wǎng)卡名,可以用ifconfig來查看你的設(shè)備上有哪些網(wǎng)卡名。

    -s: 要抓取的網(wǎng)絡(luò)包長度。我喜歡寫0,這就表示抓取完整長度的網(wǎng)絡(luò)包,一個也不落下。

    -w: 表示要將抓取到的網(wǎng)絡(luò)包寫入一個文件,將來可以用wireshark這款網(wǎng)絡(luò)包分析軟件打開查看。

    三、初識Socket,通過抓包分析TCP的三次握手,四次揮手

    通過這張圖,我們更容易的去理解這些API,客戶端和服務(wù)端的不同點就是建立連接部分。服務(wù)端需要bind listen accept ,多個客戶端可以連接一個服務(wù)端。

    連接上Socket后,發(fā)消息時,用Wireshark網(wǎng)絡(luò)封包分析工具,抓到以下數(shù)據(jù)。我們來看一下TCP的三次握手。

    用上面藍(lán)色線代表服務(wù)端,下面代表客戶端。中間箭頭代表發(fā)起和響應(yīng)的網(wǎng)絡(luò)請求。綠色框代表滑動窗口。

    滑動窗口是控制接收以及同步數(shù)據(jù)范圍的,通知發(fā)送端目前接收的數(shù)據(jù)范圍,用于流量控制,接收端使用。

    擁塞窗口是控制發(fā)送速率的,避免發(fā)的過多,發(fā)送端使用。

    兩個窗口的維護是獨立的,滑動窗口主要由接收方反饋緩存情況來維護,擁塞窗口主要由發(fā)送方的擁塞控制算法檢測出的網(wǎng)絡(luò)擁塞程度來決定的。

    Scoket連接和HTTP連接的區(qū)別

    GET和POST的區(qū)別:

    參考資料: https://objccn.io/issue-10-6/

    SocketDemo: https://github.com/TeeMoYan/TMSocketDemo.git

    四、抓包分析tcp連接及斷開過程六個標(biāo)志位中,怎么看值為一的是

    TCP協(xié)議中的6個重要標(biāo)志位

    URG:(Urgent Pointer field significant)緊急指針。⽤到的時候值為1,⽤來處理避免TCP數(shù)據(jù)流中斷。

    ACK:(Acknowledgment fieldsignificant)置1時表⽰確認(rèn)號(AcknowledgmentNumber)為合法,為0的時候表⽰數(shù)據(jù)段不包含確認(rèn)信息,確認(rèn)號被忽略。

    PSH:(Push Function),PUSH標(biāo)志的數(shù)據(jù),置1時請求的數(shù)據(jù)段在接收⽅得到后就可直接送到應(yīng)⽤程序,⽽不必等到緩沖區(qū)滿時才傳送。

    RST:(Reset the connection)⽤于復(fù)位因某種原因引起出現(xiàn)的錯誤連接,也⽤來拒絕⾮法數(shù)據(jù)和請求。如果接收到RST位時候,通常發(fā)⽣了某些錯誤。

    SYN:(Synchronize sequence numbers)⽤來建⽴連接,在連接請求中,SYN=1,ACK=0,連接響應(yīng)時,SYN=1,ACK=1。

    即,SYN和ACK來區(qū)分Connection Request和Connection Accepted。

    FIN:(No more data from sender)⽤來釋放連接,表明發(fā)送⽅已經(jīng)沒有數(shù)據(jù)發(fā)送了。

    滑動窗⼝:控制報⽂流量,⽤來告訴對⽅⽬前接收端緩沖器⼤⼩。當(dāng)為0時標(biāo)識緩沖器已滿,需要停⽌發(fā)包,單位為byte。

    5.9

    百度文庫VIP限時優(yōu)惠現(xiàn)在開通,立享6億+VIP內(nèi)容

    立即獲取

    TCP協(xié)議中的6個重要標(biāo)志位

    TCP協(xié)議中的6個重要標(biāo)志位

    URG:(Urgent Pointer field significant)緊急指針。⽤到的時候值為1,⽤來處理避免TCP數(shù)據(jù)流中斷。

    ACK:(Acknowledgment fieldsignificant)置1時表⽰確認(rèn)號(AcknowledgmentNumber)為合法,為0的時候表⽰數(shù)據(jù)段不包含確認(rèn)信息,確認(rèn)號被忽略。

    PSH:(Push Function),PUSH標(biāo)志的數(shù)據(jù),置1時請求的數(shù)據(jù)段在接收⽅得到后就可直接送到應(yīng)⽤程序,⽽不必等到緩沖區(qū)滿時才傳送。

    第 1 頁

    RST:(Reset the connection)⽤于復(fù)位因某種原因引起出現(xiàn)的錯誤連接,也⽤來拒絕⾮法數(shù)據(jù)和請求。如果接收到RST位時候,通常發(fā)⽣了某些錯誤。

    SYN:(Synchronize sequence numbers)⽤來建⽴連接,在連接請求中,SYN=1,ACK=0,連接響應(yīng)時,SYN=1,ACK=1。

    即,SYN和ACK來區(qū)分Connection Request和Connection Accepted。

    FIN:(No more data from sender)⽤來釋放連接,表明發(fā)送⽅已經(jīng)沒有數(shù)據(jù)發(fā)送了。

    以上就是關(guān)于tcp抓包解密相關(guān)問題的回答。希望能幫到你,如有更多相關(guān)問題,您也可以聯(lián)系我們的客服進(jìn)行咨詢,客服也會為您講解更多精彩的知識和內(nèi)容。


    推薦閱讀:

    tcpmss影響網(wǎng)速

    ns怎么用paypal付款(switch怎么用paypal付款)

    watchGPT怎么聊天(watch怎么聊微信)

    同城推廣(同城推廣方法)

    無錫綠化景觀設(shè)計公司(無錫綠化景觀設(shè)計公司有哪些)