<p id="p7rr7"><ruby id="p7rr7"><b id="p7rr7"></b></ruby></p><noframes id="p7rr7">

      <address id="p7rr7"></address>

      <track id="p7rr7"><strike id="p7rr7"><rp id="p7rr7"></rp></strike></track>
      <pre id="p7rr7"><strike id="p7rr7"><b id="p7rr7"></b></strike></pre>

        <track id="p7rr7"><strike id="p7rr7"><span id="p7rr7"></span></strike></track><address id="p7rr7"><pre id="p7rr7"><span id="p7rr7"></span></pre></address>

              tcp三次握手抓包格式分析(wireshark抓包分析tcp三次握手過程)

            最后更新:6天前 手機定位技術交流文章

            TCP三次握手的序列號分析

            4、-> ack XXXX(xx表示載荷包。因為第3步僅是一個確認包,它沒有包含任何有效數據,所以這里的Seq仍舊是4071231309。仍舊是對第2步確認) TCP: Sequence number =4071231309TCP: Acknowledgement number =1191340144一般應用都是客戶端先向服務器發數據的。這個過程有幾個規則:規則1、累計確認。接收端對收到的載荷包(數據字段有值的TCP包),回應一個確認包,確認號是所收到包的TCP數據字段最后一個字節+1。規則2、捎帶確認。載荷包必須捎帶確認字段。這樣可以減少網絡流量。 規則3、虛字節。有些數據包(ACK)不攜帶任何數據,所以不消耗序列號,也就是說仍舊保持不變。
            TCP: Sequence number = 1191340145 TCP: Acknowledgement number =40712313101TCP: Sequence number = xTCP: Acknowledgement number =y2TCP: Sequence number = yTCP: Acknowledgement number =x+13TCP: Sequence number = x+1TCP: Acknowledgement number =y+14:TCP: Sequence number = y+1TCP: Acknowledgement number =x+2 ……
            TCP需要三次握手才能建立連接,那么為什么需要三次握手呢?
            TCP三次握手的序列號分析

            Tcpdump 看這一篇就夠了

            tcpdump是一款強大的網絡抓包工具,它使用 libpcap 庫來抓取網絡數據包,這個庫在幾乎在所有的 Linux/Unix 中都有。熟悉 tcpdump 的使用能夠幫助你分析調試網絡數據,本文將通過一個個具體的示例來介紹它在不同場景下的使用方法。不管你是系統管理員,程序員,云原生工程師還是 yaml 工程師,掌握 tcpdump 的使用都能讓你如虎添翼,升職加薪。 tcpdump的常用參數如下:額外再介紹幾個常用參數:-A表示使用ASCII字符串打印報文的全部數據,這樣可以使讀取更加簡單,方便使用grep等工具解析輸出內容。 -X表示同時使用十六進制和ASCII字符串打印報文的全部數據。這兩個參數不能一起使用。例如:后面可以跟上協議名稱來過濾特定協議的流量,以UDP為例,可以加上參數udp或protocol 17 ,這兩個命令意思相同。同理, tcp與protocol 6意思相同。使用過濾器host可以抓取特定目的地和源IP地址的流量。也可以使用src或dst只抓取源或目的地:使用 tcpdump 截取數據報文的時候,默認會打印到屏幕的默認輸出,你會看到按照順序和格式,很多的數據一行行快速閃過,根本來不及看清楚所有的內容。不過,tcpdump 提供了把截取的數據保存到文件的功能,以便后面使用其他圖形工具(比如 wireshark,Snort)來分析。-w選項用來把數據報文輸出到文件:如果想實時將抓取到的數據通過管道傳遞給其他工具來處理,需要使用-l選項來開啟行緩沖模式(或使用-c選項來開啟數據包緩沖模式)。使用 -l選項可以將輸出通過立即發送給其他命令,其他命令會立即響應。過濾的真正強大之處在于你可以隨意組合它們,而連接它們的邏輯就是常用的 與/AND/&& 、 或/OR/|| 和 非/not/!。關于 tcpdump 的過濾器,這里有必要單獨介紹一下。機器上的網絡報文數量異常的多,很多時候我們只關系和具體問題有關的數據報(比如訪問某個網站的數據,或者 icmp 超時的報文等等),而這些數據只占到很小的一部分。把所有的數據截取下來,從里面找到想要的信息無疑是一件很費時費力的工作。而 tcpdump 提供了靈活的語法可以精確地截取關心的數據報,簡化分析的工作量。這些選擇數據包的語句就是過濾器(filter)!Host 過濾器用來過濾某個主機的數據報文。例如:該命令會抓取所有發往主機 1.2.3.4 或者從主機 1.2.3.4 發出的流量。如果想只抓取從該主機發出的流量,可以使用下面的命令:Network 過濾器用來過濾某個網段的數據,使用的是 CIDR[2] 模式??梢允褂盟脑M(x.x.x.x)、三元組(x.x.x)、二元組(x.x)和一元組(x)。四元組就是指定某個主機,三元組表示子網掩碼為 255.255.255.0,二元組表示子網掩碼為 255.255.0.0,一元組表示子網掩碼為 255.0.0.0。例如,抓取所有發往網段 192.168.1.x 或從網段 192.168.1.x 發出的流量:抓取所有發往網段 10.x.x.x 或從網段 10.x.x.x 發出的流量:和 Host 過濾器一樣,這里也可以指定源和目的:也可以使用 CIDR 格式:Proto 過濾器用來過濾某個協議的數據,關鍵字為 proto,可省略。proto 后面可以跟上協議號或協議名稱,支持 icmp, igmp, igrp, pim, ah, esp, carp, vrrp, udp和 tcp。因為通常的協議名稱是保留字段,所以在與 proto 指令一起使用時,必須根據 shell 類型使用一個或兩個反斜杠(/)來轉義。Linux 中的 shell 需要使用兩個反斜杠來轉義,MacOS 只需要一個。例如,抓取 icmp 協議的報文:Port 過濾器用來過濾通過某個端口的數據報文,關鍵字為 port。例如:截取數據只是第一步,第二步就是理解這些數據,下面就解釋一下 tcpdump 命令輸出各部分的意義。最基本也是最重要的信息就是數據報的源地址/端口和目的地址/端口,上面的例子第一條數據報中,源地址 ip 是 192.168.1.106,源端口是 56166,目的地址是 124.192.132.54,目的端口是 80。> 符號代表數據的方向。此外,上面的三條數據還是 tcp 協議的三次握手過程,第一條就是 SYN 報文,這個可以通過 Flags [S] 看出。下面是常見的 TCP 報文的 Flags:下面給出一些具體的例子,每個例子都可以使用多種方法來獲得相同的輸出,你使用的方法取決于所需的輸出和網絡上的流量。我們在排障時,通常只想獲取自己想要的內容,可以通過過濾器和 ASCII 輸出并結合管道與 grep、cut、awk 等工具來實現此目的。例如,在抓取 HTTP 請求和響應數據包時,可以通過刪除標志 SYN/ACK/FIN 來過濾噪聲,但還有更簡單的方法,那就是通過管道傳遞給 grep。在達到目的的同時,我們要選擇最簡單最高效的方法。下面來看例子。從 HTTP 請求頭中提取 HTTP 用戶代理:通過 egrep 可以同時提取用戶代理和主機名(或其他頭文件):抓取 HTTP GET 流量:也可以抓取 HTTP POST 請求流量:注意:該方法不能保證抓取到 HTTP POST 有效數據流量,因為一個 POST 請求會被分割為多個 TCP 數據包。上述兩個表達式中的十六進制將會與 GET 和 POST 請求的 ASCII 字符串匹配。例如,tcp[((tcp[12:1] & 0xf0) >> 2):4] 首先會確定我們感興趣的字節的位置[3](在 TCP header 之后),然后選擇我們希望匹配的 4 個字節。提取 HTTP 請求的主機名和路徑:從 HTTP POST 請求中提取密碼和主機名:提取 Set-Cookie(服務端的 Cookie)和 Cookie(客戶端的 Cookie):查看網絡上的所有 ICMP 數據包:通過排除 echo 和 reply 類型的數據包使抓取到的數據包不包括標準的 ping 包:可以提取電子郵件的正文和其他數據。例如,只提取電子郵件的收件人:抓取 NTP 服務的查詢和響應通過 SNMP 服務,滲透測試人員可以獲取大量的設備和系統信息。在這些信息中,系統信息最為關鍵,如操作系統版本、內核版本等。使用 SNMP 協議快速掃描程序 onesixtyone,可以看到目標系統的信息:當抓取大量數據并寫入文件時,可以自動切割為多個大小相同的文件。例如,下面的命令表示每 3600 秒創建一個新文件 capture-(hour).pcap,每個文件大小不超過 200*1000000 字節:這些文件的命名為 capture-{1-24}.pcap,24 小時之后,之前的文件就會被覆蓋??梢酝ㄟ^過濾器 ip6 來抓取 IPv6 流量,同時可以指定協議如 TCP:從之前保存的文件中讀取 IPv6 UDP 數據報文:在下面的例子中,你會發現抓取到的報文的源和目的一直不變,且帶有標志位 [S] 和 [R],它們與一系列看似隨機的目標端口進行匹配。當發送 SYN 之后,如果目標主機的端口沒有打開,就會返回一個 RESET。這是 Nmap 等端口掃描工具的標準做法。本例中 Nmap NSE 測試腳本 http-enum.nse 用來檢測 HTTP 服務的合法 URL。在執行腳本測試的主機上:在目標主機上:向 Google 公共 DNS 發起的出站 DNS 請求和 A 記錄響應可以通過 tcpdump 抓取到:抓取 80 端口的 HTTP 有效數據包,排除 TCP 連接建立過程的數據包(SYN / FIN / ACK):通常 Wireshark(或 tshark)比 tcpdump 更容易分析應用層協議。一般的做法是在遠程服務器上先使用 tcpdump 抓取數據并寫入文件,然后再將文件拷貝到本地工作站上用 Wireshark 分析。還有一種更高效的方法,可以通過 ssh 連接將抓取到的數據實時發送給 Wireshark 進行分析。以 MacOS 系統為例,可以通過 brew cask install wireshark 來安裝,然后通過下面的命令來分析:例如,如果想分析 DNS 協議,可以使用下面的命令:抓取到的數據:找出一段時間內發包最多的 IP,或者從一堆報文中找出發包最多的 IP,可以使用下面的命令:cut -f 1,2,3,4 -d '.': 以 . 為分隔符,打印出每行的前四列。即 IP 地址。sort | uniq -c : 排序并計數sort -nr: 按照數值大小逆向排序本例將重點放在標準純文本協議上,過濾出于用戶名和密碼相關的報文:最后一個例子,抓取 DHCP 服務的請求和響應報文,67 為 DHCP 端口,68 為客戶機端口。 本文主要介紹了 tcpdump 的基本語法和使用方法,并通過一些示例來展示它強大的過濾功能。將 tcpdump 與 wireshark 進行組合可以發揮更強大的功效,本文也展示了如何優雅順滑地結合 tcpdump 和 wireshark。如果你想了解更多的細節,可以查看 tcpdump 的 man 手冊。
            Tcpdump 看這一篇就夠了

            簡述TCP的三次握手過程。

            TCP握手協議 在TCP/IP協議中,TCP協議提供可靠的連接服務,采用三次握手建立一個連接.第一次握手:建立連接時,客戶端發送syn包(syn=j)到服務器,并進入SYN_SEND狀態,等待服務器確認;SYN:同步序列編號(Synchronize Sequence Numbers)第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手. 完成三次握手,客戶端與服務器開始傳送數據
            第一次握手:建立連接時,客戶端發送syn包(syn=j)到服務器,并進入SYN_SEND狀態,等待服務器確認。第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態。 第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手。完成三次握手,客戶端與服務器開始傳送數據。簡版:首先A向B發SYN(同步請求),然后B回復SYN+ACK(同步請求應答),最后A回復ACK確認,這樣TCP的一次連接(三次握手)的過程就建立了。三次握手我們先明確兩個定義:1,client為數據發送方2,server為數據接收方好,下面進行三次握手的總結:1,client想要向server發送數據,請求連接。這時client向服務器發送一個數據包,其中同步位(SYN)被置為1,表明client申請TCP連接,序號為j。2,當server接收到了來自client的數據包時,解析發現同步位為1,便知道client是想要簡歷TCP連接,于是將當前client的IP、端口之類的加入未連接隊列中,并向client回復接受連接請求,想client發送數據包,其中同步位為1,并附帶確認位ACK=j+1,表明server已經準備好分配資源了,并向client發起連接請求,請求client為建立TCP連接而分配資源。 3,client向server回復一個ACK,并分配資源建立連接。server收到這個確認時也分配資源進行連接的建立。
            A與B建立TCP連接時:首先A向B發SYN(同步請求),然后B回復SYN+ACK(同步請求應答),最后A回復ACK確認,這樣TCP的一次連接(三次握手)的過程就建立了!


            簡述TCP的三次握手過程。

            網絡三次握手協議==抓包和分析??纯礊槭裁蠢鲜沁B接不上

            [RST]是復位標志,用于復位相應的TCP連接。 此問題詳細請百度 “TCP標志位" 復位到重新發送同步請求應該是TCP/IP協議有時間間隔的規定吧,我也不清楚,請查TCP/IP詳解。
            網絡三次握手協議==抓包和分析??纯礊槭裁蠢鲜沁B接不上

            TCP協議詳解及實戰解析【精心整理收藏】

            TCP協議是在TCP/IP協議模型中的運輸層中很重要的一個協議、負責處理主機端口層面之間的數據傳輸。主要有以下特點:1.TCP是面向鏈接的協議,在數據傳輸之前需要通過三次握手建立TCP鏈接,當數據傳遞完成之后,需要通過四次揮手進行連接釋放。2.每一條TCP通信都是兩臺主機和主機之間的,是點對點傳輸的協議。3.TCP提供可靠的、無差錯、不丟失、不重復,按序到達的服務。4.TCP的通信雙方在連接建立的任何時候都可以發送數據。TCP連接的兩端都設有發送緩存和接收緩存,用來臨時存放雙向通信的數據。5.面向字節流。在數據傳輸的過程中如果報文比較長的話TCP會進行數據分段傳輸,每一條分段的TCP傳輸信息都帶有分段的序號,每一段都包含一部分字節流。接收方根據每段攜帶的的序號信息進行數據拼接,最終拼接出來初始的傳輸數據。但是在整個傳輸的過程中每一段TCP攜帶的都是被切割的字節流數據。所以說TCP是面向字節流的。a.TCP和UDP在發送報文時所采用的方式完全不同。TCP并不關心應用程序一次把多長的報文發送到TCP緩存中,而是根據對方給出的窗口值和當前網絡擁塞的程度來決定一個報文段應包含多少個字節(UDP發送的報文長度是應用程序給出的)。b.如果應用程序傳送到TCP緩存的數據塊太大,TCP就可以把它劃分短一些再傳。TCP也可以等待積累有足夠多的字節后再構建成報文段發送出去。各字段含義:源端口:發送端的端口號目的端口:接收端的端口號序號:TCP將發送報文分段傳輸的時候會給每一段加上序號,接收端也可以根據這個序號來判斷數據拼接的順序,主要用來解決網絡報亂序的問題確認號:確認號為接收端收到數據之后進行排序確認以及發送下一次期待接收到的序號,數值 = 接收到的發送號 + 1數據偏移:占4比特,表示數據開始的地方離TCP段的起始處有多遠。實際上就是TCP段首部的長度。由于首部長度不固定,因此數據偏移字段是必要的。數據偏移以32位為長度單位,因此TCP首部的最大長度是60(15*4)個字節??刂莆唬篣RG:此標志表示TCP包的緊急指針域有效,用來保證TCP連接不被中斷,并且督促 中間層設備要盡快處理這些數據;ACK:此標志表示應答域有效,就是說前面所說的TCP應答號將會包含在TCP數據包中;有兩個取值:0和1, 為1的時候表示應答域有效,反之為0;PSH:這個標志位表示Push操作。所謂Push操作就是指在數據包到達接收端以后,立即傳送給應用程序, 而不是在緩沖區中排隊;RST:這個標志表示連接復位請求。用來復位那些產生錯誤的連接,也被用來拒絕錯誤和非法的數據包;SYN:表示同步序號,用來建立連接。SYN標志位和ACK標志位搭配使用,當連接請求的時候,SYN=1, ACK=0;連接被響應的時候,SYN=1,ACK=1;這個標志的數據包經常被用來進行端口掃描。掃描者發送 一個只有SYN的數據包,如果對方主機響應了一個數據包回來 ,就表明這臺主機存在這個端口;但是由于這 種掃描方式只是進行TCP三次握手的第一次握手,因此這種掃描的成功表示被掃描的機器不很安全,一臺安全 的主機將會強制要求一個連接嚴格的進行TCP的三次握手;FIN: 表示發送端已經達到數據末尾,也就是說雙方的數據傳送完成,沒有數據可以傳送了,發送FIN標志 位的TCP數據包后,連接將被斷開。這個標志的數據包也經常被用于進行端口掃描。窗口:TCP里很重要的一個機制,占2字節,表示報文段發送方期望接收的字節數,可接收的序號范圍是從接收方的確認號開始到確認號加上窗口大小之間的數據。后面會有實例講解。校驗和:校驗和包含了偽首部、TCP首部和數據,校驗和是TCP強制要求的,由發送方計算,接收方驗證緊急指針:URG標志為1時,緊急指針有效,表示數據需要優先處理。緊急指針指出在TCP段中的緊急數據的最后一個字節的序號,使接收方可以知道緊急數據共有多長。選項:最常用的選項是最大段大?。∕aximum Segment Size,MSS),向對方通知本機可以接收的最大TCP段長度。MSS選項只在建立連接的請求中發送。放在以太網幀里看TCP的位置TCP 數據包在 IP 數據包的負載里面。它的頭信息最少也需要20字節,因此 TCP 數據包的最大負載是 1480 - 20 = 1460 字節。由于 IP 和 TCP 協議往往有額外的頭信息,所以 TCP 負載實際為1400字節左右。因此,一條1500字節的信息需要兩個 TCP 數據包。HTTP/2 協議的一大改進, 就是壓縮 HTTP 協議的頭信息,使得一個 HTTP 請求可以放在一個 TCP 數據包里面,而不是分成多個,這樣就提高了速度。以太網數據包的負載是1500字節,TCP 數據包的負載在1400字節左右一個包1400字節,那么一次性發送大量數據,就必須分成多個包。比如,一個 10MB 的文件,需要發送7100多個包。發送的時候,TCP 協議為每個包編號(sequence number,簡稱 SEQ),以便接收的一方按照順序還原。萬一發生丟包,也可以知道丟失的是哪一個包。第一個包的編號是一個隨機數。為了便于理解,這里就把它稱為1號包。假定這個包的負載長度是100字節,那么可以推算出下一個包的編號應該是101。這就是說,每個數據包都可以得到兩個編號:自身的編號,以及下一個包的編號。接收方由此知道,應該按照什么順序將它們還原成原始文件。收到 TCP 數據包以后,組裝還原是操作系統完成的。應用程序不會直接處理 TCP 數據包。對于應用程序來說,不用關心數據通信的細節。除非線路異常,否則收到的總是完整的數據。應用程序需要的數據放在 TCP 數據包里面,有自己的格式(比如 HTTP 協議)。TCP 并沒有提供任何機制,表示原始文件的大小,這由應用層的協議來規定。比如,HTTP 協議就有一個頭信息Content-Length,表示信息體的大小。對于操作系統來說,就是持續地接收 TCP 數據包,將它們按照順序組裝好,一個包都不少。操作系統不會去處理 TCP 數據包里面的數據。一旦組裝好 TCP 數據包,就把它們轉交給應用程序。TCP 數據包里面有一個端口(port)參數,就是用來指定轉交給監聽該端口的應用程序。應用程序收到組裝好的原始數據,以瀏覽器為例,就會根據 HTTP 協議的Content-Length字段正確讀出一段段的數據。這也意味著,一次 TCP 通信可以包括多個 HTTP 通信。服務器發送數據包,當然越快越好,最好一次性全發出去。但是,發得太快,就有可能丟包。帶寬小、路由器過熱、緩存溢出等許多因素都會導致丟包。線路不好的話,發得越快,丟得越多。最理想的狀態是,在線路允許的情況下,達到最高速率。但是我們怎么知道,對方線路的理想速率是多少呢?答案就是慢慢試。TCP 協議為了做到效率與可靠性的統一,設計了一個慢啟動(slow start)機制。開始的時候,發送得較慢,然后根據丟包的情況,調整速率:如果不丟包,就加快發送速度;如果丟包,就降低發送速度。Linux 內核里面 設定 了(常量TCP_INIT_CWND),剛開始通信的時候,發送方一次性發送10個數據包,即"發送窗口"的大小為10。然后停下來,等待接收方的確認,再繼續發送。默認情況下,接收方每收到 兩個TCP 數據包,就要 發送 一個確認消息。"確認"的英語是 acknowledgement,所以這個確認消息就簡稱 ACK。ACK 攜帶兩個信息。發送方有了這兩個信息,再加上自己已經發出的數據包的最新編號,就會推測出接收方大概的接收速度,從而降低或增加發送速率。這被稱為"發送窗口",這個窗口的大小是可變的。注意,由于 TCP 通信是雙向的,所以雙方都需要發送 ACK。兩方的窗口大小,很可能是不一樣的。而且 ACK 只是很簡單的幾個字段,通常與數據合并在一個數據包里面發送。即使對于帶寬很大、線路很好的連接,TCP 也總是從10個數據包開始慢慢試,過了一段時間以后,才達到最高的傳輸速率。這就是 TCP 的慢啟動。TCP 協議可以保證數據通信的完整性,這是怎么做到的?前面說過,每一個數據包都帶有下一個數據包的編號。如果下一個數據包沒有收到,那么 ACK 的編號就不會發生變化。舉例來說,現在收到了4號包,但是沒有收到5號包。ACK 就會記錄,期待收到5號包。過了一段時間,5號包收到了,那么下一輪 ACK 會更新編號。如果5號包還是沒收到,但是收到了6號包或7號包,那么 ACK 里面的編號不會變化,總是顯示5號包。這會導致大量重復內容的 ACK。如果發送方發現收到 三個 連續的重復 ACK,或者超時了還沒有收到任何 ACK,就會確認丟包,即5號包遺失了,從而再次發送這個包。通過這種機制,TCP 保證了不會有數據包丟失。TCP是一個滑動窗口協議,即一個TCP連接的發送端在某個時刻能發多少數據是由滑動窗口控制的,而滑動窗口的大小實際上是由兩個窗口共同決定的,一個是接收端的通告窗口,這個窗口值在TCP協議頭部信息中有,會隨著數據的ACK包發送給發送端,這個值表示的是在接收端的TCP協議緩存中還有多少剩余空間,發送端必須保證發送的數據不超過這個剩余空間以免造成緩沖區溢出,這個窗口是接收端用來進行流量限制的,在傳輸過程中,通告窗口大小與接收端的進程取出數據的快慢有關。另一個窗口是發送端的擁塞窗口(Congestion window),由發送端維護這個值,在協議頭部信息中沒有,滑動窗口的大小就是通告窗口和擁塞窗口的較小值,所以擁塞窗口也看做是發送端用來進行流量控制的窗口?;瑒哟翱诘淖筮呇叵蛴乙苿臃Q為窗口合攏,發生在發送的數據被確認時(此時,表明數據已被接收端收到,不會再被需要重傳,可以從發送端的發送緩存中清除了),滑動窗口的右邊沿向右移動稱為窗口張開,發生在接收進程從接收端協議緩存中取出數據時。隨著發送端不斷收到的被發送數據的ACK包,根據ACK包中的確認序號和通告窗口大小使滑動窗口得以不斷的合攏和張開,形成滑動窗口的向前滑動。如果接收進程一直不取數據,則會出現0窗口現象,即滑動窗口左邊沿與右邊沿重合,此時窗口大小為0,就無法再發送數據。在TCP里,接收端(B)會給發送端(A)報一個窗口的大小,叫Advertised window。1.在沒有收到B的確認情況下,A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據,在未收到確認之前都必須暫時保留,以便在超時重傳時使用。2.發送窗口里面的序號表示允許發送的序號。顯然,窗口越大,發送方就可以在收到對方確認之前連續發送更多數據,因而可能獲得更高的傳輸效率。但接收方必須來得及處理這些收到的數據。3.發送窗口后沿的后面部分表示已發送且已收到確認。這些數據顯然不需要再保留了。4.發送窗口前沿的前面部分表示不允許發送的,應為接收方都沒有為這部分數據保留臨時存放的緩存空間。5.發送窗口后沿的變化情況有兩種:不動(沒有收到新的確認)和前移(收到了新的確認)6.發送窗口前沿的變化情況有兩種:不斷向前移或可能不動(沒收到新的確認)TCP的發送方在規定時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念很簡單,但重傳時間的選擇確是TCP最復雜的問題之一。TCP采用了一種自適應算法,它記錄一個報文段發出的時間,以及收到響應的確認的時間這兩個時間之差就是報文段的往返時間RTT。TCP保留了RTT的一個加權平均往返時間。超時重傳時間RTO略大于加權平均往返時間RTT:即Round Trip Time,表示從發送端到接收端的一去一回需要的時間,tcp在數據傳輸過程中會對RTT進行采樣(即對發送的數據包及其ACK的時間差進行測量,并根據測量值更新RTT值,具體的算法TCPIP詳解里面有),TCP根據得到的RTT值更新RTO值,即Retransmission TimeOut,就是重傳間隔,發送端對每個發出的數據包進行計時,如果在RTO時間內沒有收到所發出的數據包的對應ACK,則任務數據包丟失,將重傳數據。一般RTO值都比采樣得到的RTT值要大。如果收到的報文段無差錯,只是未按序號,中間還缺少一些序號的數據,那么能否設法只傳送缺少的數據而不重傳已經正確到達接收方的數據?答案是可以的,選擇確認就是一種可行的處理方法。如果要使用選項確認SACK,那么在建立TCP連接時,就要在TCP首部的選項中加上“允許SACK”的選項,而雙方必須都事先商定好。如果使用選擇確認,那么原來首部中的“確認號字段”的用法仍然不變。SACK文檔并沒有明確發送方應當怎么響應SACK.因此大多數的實現還是重傳所有未被確認的數據塊。一般說來,我們總是希望數據傳輸的更快一些,但如果發送方把數據發送的過快,接收方就可能來不及接收,這會造成數據的丟失。所謂流量控制就是讓發送方的發送速率不要太快,要讓接收方來得及接收。在計算機網絡中的鏈路容量,交換節點中的緩存和處理機等,都是網絡的資源。在某段時間,若對網絡中某一資源的需求超過了該資源所能提供的可用部分,網絡的性能就要變壞。這種情況就叫做擁塞。擁塞控制方法:1.慢開始和擁塞避免2.快重傳和快恢復3.隨機早期檢測1.一開始,客戶端和服務端都處于CLOSED狀態2.先是服務端主動監聽某個端口,處于LISTEN狀態(比如服務端啟動,開始監聽)。3.客戶端主動發起連接SYN,之后處于SYN-SENT狀態(第一次握手,發送 SYN = 1 ACK = 0 seq = x ack = 0)。4.服務端收到發起的連接,返回SYN,并且ACK客戶端的SYN,之后處于SYN-RCVD狀態(第二次握手,發送 SYN = 1 ACK = 1 seq = y ack = x + 1)。5.客戶端收到服務端發送的SYN和ACK之后,發送ACK的ACK,之后處于ESTABLISHED狀態(第三次握手,發送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1)。6.服務端收到客戶端的ACK之后,處于ESTABLISHED狀態。(需要注意的是,有可能X和Y是相等的,可能都是0,因為他們代表了各自發送報文段的序號。)TCP連接釋放四次揮手1.當前A和B都處于ESTAB-LISHED狀態。2.A的應用進程先向其TCP發出連接釋放報文段,并停止再發送數據,主動關閉TCP連接。3.B收到連接釋放報文段后即發出確認,然后B進入CLOSE-WAIT(關閉等待)狀態。TCP服務器進程這時應通知高層應用進程,因而從A到B這個方向的連接就釋放了,這時TCP連接處于半關閉狀態,即A已經沒有數據發送了。從B到A這個方向的連接并未關閉,這個狀態可能會持續一些時間。4.A收到來自B的確認后,就進入FIN-WAIT-2(終止等待2)狀態,等待B發出的連接釋放報文端。5.若B已經沒有向A發送的數據,B發出連接釋放信號,這時B進入LAST-ACK(最后確認)狀態等待A的確認。6.A再收到B的連接釋放消息后,必須對此發出確認,然后進入TIME-WAIT(時間等待)狀態。請注意,現在TCP連接還沒有釋放掉,必須經過時間等待計時器(TIME-WAIT timer)設置的時間2MSL后,A才進入CLOSED狀態。7。B收到A發出的確認消息后,進入CLOSED狀態。以請求百度為例,看一下三次握手真實數據的TCP連接建立過程我們再來看四次揮手。TCP斷開連接時,會有四次揮手過程,標志位是FIN,我們在封包列表中找到對應位置,理論上應該找到4個數據包,但我試了好幾次,實際只抓到3個數據包。查了相關資料,說是因為服務器端在給客戶端傳回的過程中,將兩個連續發送的包進行了合并。因此下面會按照合并后的三次揮手解釋,若有錯誤之處請指出。第一步,當主機A的應用程序通知TCP數據已經發送完畢時,TCP向主機B發送一個帶有FIN附加標記的報文段(FIN表示英文finish)。第二步,主機B收到這個FIN報文段之后,并不立即用FIN報文段回復主機A,而是先向主機A發送一個確認序號ACK,同時通知自己相應的應用程序:對方要求關閉連接(先發送ACK的目的是為了防止在這段時間內,對方重傳FIN報文段)。第三步,主機B的應用程序告訴TCP:我要徹底的關閉連接,TCP向主機A送一個FIN報文段。第四步,主機A收到這個FIN報文段后,向主機B發送一個ACK表示連接徹底釋放。這是因為服務端在LISTEN狀態下,收到建立連接請求的SYN報文后,把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時,當收到對方的FIN報文時,僅僅表示對方不再發送數據了但是還能接收數據,己方也未必全部數據都發送給對方了,所以己方可以立即close,也可以發送一些數據給對方后,再發送FIN報文給對方來表示同意現在關閉連接,因此,己方ACK和FIN一般都會分開發送。原因有二:一、保證TCP協議的全雙工連接能夠可靠關閉二、保證這次連接的重復數據段從網絡中消失先說第一點,如果Client直接CLOSED了,那么由于IP協議的不可靠性或者是其它網絡原因,導致Server沒有收到Client最后回復的ACK。那么Server就會在超時之后繼續發送FIN,此時由于Client已經CLOSED了,就找不到與重發的FIN對應的連接,最后Server就會收到RST而不是ACK,Server就會以為是連接錯誤把問題報告給高層。這樣的情況雖然不會造成數據丟失,但是卻導致TCP協議不符合可靠連接的要求。所以,Client不是直接進入CLOSED,而是要保持TIME_WAIT,當再次收到FIN的時候,能夠保證對方收到ACK,最后正確的關閉連接。再說第二點,如果Client直接CLOSED,然后又再向Server發起一個新連接,我們不能保證這個新連接與剛關閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發生什么問題,但是還是有特殊情況出現:假設新連接和已經關閉的老連接端口號是一樣的,如果前一次連接的某些數據仍然滯留在網絡中,這些延遲數據在建立新連接之后才到達Server,由于新連接和老連接的端口號是一樣的,又因為TCP協議判斷不同連接的依據是socket pair,于是,TCP協議就認為那個延遲的數據是屬于新連接的,這樣就和真正的新連接的數據包發生混淆了。所以TCP連接還要在TIME_WAIT狀態等待2倍MSL,這樣可以保證本次連接的所有數據都從網絡中消失。硬件速度網絡和服務器的負載請求和響應報文的尺寸客戶端和服務器之間的距離TCP 協議的技術復雜性TCP 連接建立握手;TCP 慢啟動擁塞控制;數據聚集的 Nagle 算法;用于捎帶確認的 TCP 延遲確認算法;TIME_WAIT 時延和端口耗盡。介紹完畢,就這?是的,就這。補充:大部分內容為網絡整理,方便自己學習回顧,參考文章:TCP 協議簡介TCP協議圖文詳解什么是TCP協議?wireshark抓包分析——TCP/IP協議TCP協議的三次握手和四次揮手TCP協議詳解TCP帶寬和時延的研究(1)
            TCP協議詳解及實戰解析【精心整理收藏】

            本文由 在線網速測試 整理編輯,轉載請注明出處,原文鏈接:http://www.mestier.com/news/44748.html。

                熱門文章

                文章分類

            欧美熟妇A片在线A片视频

            <p id="p7rr7"><ruby id="p7rr7"><b id="p7rr7"></b></ruby></p><noframes id="p7rr7">

                <address id="p7rr7"></address>

                <track id="p7rr7"><strike id="p7rr7"><rp id="p7rr7"></rp></strike></track>
                <pre id="p7rr7"><strike id="p7rr7"><b id="p7rr7"></b></strike></pre>

                  <track id="p7rr7"><strike id="p7rr7"><span id="p7rr7"></span></strike></track><address id="p7rr7"><pre id="p7rr7"><span id="p7rr7"></span></pre></address>