<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三次握手抓包分析(tcp三次握手抓包實驗詳解)

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

            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協議詳解及實戰解析【精心整理收藏】

            TCP 連接詳解

            1、先提出一個問題, 可以不進行三次握手直接往服務端發送數據包嗎?是不可以的,也是可以的;1)不可以是因為現在的TCP連接標準和規范要求傳輸數據前先確認兩端的狀態,有一端狀態不OK的話,發數據包有什么用呢;2)說可以是站在網絡連接的角度,像 UDP 協議;2、TCP三次握手1)標志位、隨機序列號和確認序列號是在數據包的 TCP 首部里面;2)幾個狀態是指客戶端和服務端連接過程中 socket 狀態;3)第一次握手,客戶端向服務端發送數據包,該數據包中 SYN 標志位為 1,還有隨機生成的序列號c_seq,客戶端狀態改為 SYN-SENT;4)第二次握手,服務端接收到客戶端發過來的數據包中 SYN 標志位為 1,就知道客戶端想和自己建立連接,服務端會根據自身的情況決定是拒絕連接,或確定連接,還是丟棄該數據包;拒絕連接,會往客戶端發一個數據包,該數據包中 RST 標志位為 1,客戶端會報 Connection refused;丟棄客戶端的數據包,超過一定時間后客戶端會報 Connection timeout;確定連接時會往客戶端發一個數據包,該數據包中 ACK 標志位為 1,確認序列號 ack=c_seq+1,SYN 標志位為 1,隨機序列號 s_seq,狀態由 LISTEN 改為 SYN-RCVD;5)第三次握手,客戶端接收到數據包會做校驗,校驗ACK標志位和確認序列號 ack=c_seq+1,如果確定是服務端的確認數據包,改自己的狀態為 ESTABLISHED,并給服務端發確認數據包;6)服務端接到客戶端數據包,會校驗ACK標志位和確認序列號 ack=s_seq+1,改自己的狀態為 ESTABLISHED,之后就可以進行數據傳輸了;7)建立連接時的數據包是沒有實際內容的,沒有應用層的數據;8)建立連接之后發起的請求數據包,每個數據包都會封裝各層協議的頭部信息,標志位ACK為1,其他標志位變動;9)網絡進程間的通信,一臺服務器內部的進程間通信不用這樣;3、TCP 連接三次握手抓包1)Socket 在 linux 系統中是一種特殊的文件,因為 linux 系統的理念就是【一切皆文件】,是系統內核級的功能;2)以上定義比較具體,可以抽象來理解,是一個內核級的用于通信的功能層,包含一組接口函數,這些函數實際就是操作 socket 文件句柄文件描述符;一個 TCP 連接由四要素【源IP、源Port、目標IP、目標Port】唯一標識,也即 socket 由這四要素唯一確定;一個 TCP 連接的建立也就是客戶端、服務端創建了相對應的一對 socket,客戶端和服務端之間的通信也就是這對 socket 間的通信(物理層面是網卡在發送/接收比特流數據);3)一個服務與另一個服務建立連接,他們的端口是什么呢?客戶端發出請求端口號是隨機的,服務端是進程監聽的端口號;2、socket 主要函數介紹1、進程通信,一個進程只有一個監聽 socket,connect socket 是針對一個客戶的一個連接的,有很多個; 2、connect 函數內部在發起請求前會找系統隨機一個端口號; 3、連接建立后,客戶端發起請求傳輸數據,服務端會直接交給 connect socket 處理,不會交給監聽 socket 處理;4、監聽 socket 在處理客戶端請求時,如果此時其他客戶端發請求過來,監聽 socket 是沒法處理的,此時系統會維護請求隊列由 backlog 參數指定;全連接隊列(completed connection queue)半連接隊列(incomplete connection queue)Linux 內核 2.2 版本之前,backlog 的大小等于全連接隊列和半連接隊列之和;Linux 內核 2.2 版本之后,backlog 的大小之和全連接隊列有關系:半連接隊列大小由 /proc/sys/net/ipv4/tcp_max_syn_backlog 文件指定,可以開很大;全連接隊列大小由 /proc/sys/net/core/somaxconn 文件和 backlog 參數指定,取兩個中的最小值;tomcat acceptCount 就是配置全連接隊列大??;3、socket 函數在建立連接和數據傳輸的大概使用情況4、TCP首部結構1)2的16次方等于 65536,所以系統中端口號的限制個數為 65536,一般1024以下端口被系統占用;2)標志位這里是 6 個,還有其他標志位的,只是這 6 個標志位常用;3)seq 序列號,ack 確認序列號,序列號在數據傳輸時分包用到。三次握手時 seq 序列號是隨機的,沒有實際意義;4)TCP 包首部后面接著的是 IP 包首部,再緊接著的是以太網包首部,其實都是加 0101010101 二進制位;幾個常用標志位,首先一個標志位占一個 bit 位,只能是二進制中的 1 或 0;1)SYN,簡寫 S,請求標志位,用來建立連接。在TCP三次握手中收到帶有該標志位的數據包,表示對方想與己方建立連接;2)ACK,簡寫【.】,請求確認/應答標志位,用于對對方的請求進行應答,對方收到含該標志位的數據包,會知道己方存在且可用。也會用在連接建立之后,己方發送響應數據給對方的數據包中;3)FIN,簡寫 F,請求斷開標志位,用于斷開連接。對方收到己方的含該標志位的數據包,就知道己方想與它斷開連接,不再保持連接;4)RST,簡寫 R,請求復位標志位,因網絡或己方服務原因導致有數據包丟失,己方接收到的數據包序列號與上一個數據包的序列號不銜接,那己方會發送含該標志位的數據包告訴對方,對方接收到含該標志位的數據包就知道己方要求它重新三次握手建立連接并重新發送丟失的數據包,一般斷點續傳會用到該標志位;還有就是如果對方發過來的數據錯了,有問題,己方也會發送含該標志位的數據包;5)PSH,簡寫 P,推送標志位,表示收到數據包后要立即交給應用程序去處理,不應該放在緩存中,read()/write() 都有緩存區;6)URG,簡寫 U,緊急標志位,該標志位表示 tcp 包首部中的緊急指針域有效,督促中間層盡快處理;7)ECE,在保留位中;8)CWR,在保留位中;5、TCP 抓包1)服務端會根據自身情況,沒有要處理的數據時會把第二次和第三次揮手合并成一次揮手,此時標志位 FIN=1 / ACK=1;2)MSL 是 Maximum Segment Lifetime 縮寫,指數據包在網絡中最大生存時間,RFC 建議是 2分鐘;詳細描述:1)客戶端、服務端都可以主動發起斷開連接;2)第一次揮手,客戶端向服務端發送含 FIN=1 標志位的數據包,隨機序列號 seq=m,此時客戶端狀態由 ESTABLISHED 變為 FIN_WAIT_1;3)第二次揮手,服務端收到含 FIN=1 標志位的數據包,就知道客戶端要斷開連接,服務端會向客戶端發送含 ACK=1 標志位的應答數據包,確認序列號 ack=m+1,此時服務端狀態由 ESTABLISHED 變為 CLOSE_WAIT;4)客戶端收到含 ACK=1 標志位的應答數據包,知道服務端的可以斷開的意思,此時客戶端狀態由 FIN_WAIT_1 變為 FIN_WAIT_2;(第一、二次揮手也只是雙方交換一下意見而已)5)第三次揮手,服務端處理完剩下的數據后再次向客戶端發送含 FIN=1 標志位的數據包,隨機序列號 seq=n,告訴客戶端現在可以真正的斷開連接了,此時服務端狀態由 CLOSE_WAIT 變為 LAST_ACK;6)第四次揮手,客戶端收到服務端再次發送的含 FIN=1 標志位的數據包,就知道服務端處理好了可以斷開連接了,但是客戶端為了慎重起見,不會立馬關閉連接,而是改狀態,且向服務端發送含 ACK=1 標志位的應答數據包,確認序列號 ack=n+1,此時客戶端狀態由 FIN_WAIT_2 變為 TIME_WAIT;等待 2 個MSL時間還是未收到服務端發過來的數據,則表明服務端已經關閉連接了,客戶端也會關閉連接釋放資源,此時客戶端狀態由 TIME_WAIT 變為 CLOSED;也就是說 TIME_WAIT 狀態存在時長在 1~4分鐘;7)服務端收到含 ACK=1 標志位的應答數據包,知道客戶端確認可以斷開了,就立即關閉連接釋放資源,此時服務端狀態由 LAST_ACK 變為 CLOSED;SYN 洪水攻擊(SYN Flood)是一種 DoS攻擊(拒絕服務攻擊),大概原理是偽造大量的TCP請求,服務端收到大量的第一次握手的數據包,且都會發第二次握手數據包去回應,但是因為 IP 是偽造的,一直都不會有第三次握手數據包,導致服務端存在大量的半連接,即 SYN_RCVD 狀態的連接,導致半連接隊列被塞滿,且服務端默認會發 5 個第二次握手數據包,耗費大量 CPU 和內存資源,使得正常的連接請求進不來;
            TCP 連接詳解

            wireshark抓包三次握手怎么判斷有問題

            finack指的是數據已經傳完了,可以斷開連接,如果你仔細觀察的話,可以看到最后有兩個finack的。pshack都是tcp的頭部字段,psh指的是不用在等待其他包了,自己就可以單獨發送,所以帶有pshack的是數據發送的包,傳的應該就是你要的數據,當然到底是不是要看源和目的的ip對不對。
            第一次握手數據包 客戶端發送一個TCP,標志位為SYN,序列號為0, 代表客戶端請求建立連接。第二次握手的數據包服務器發回確認包, 標志位為 SYN,ACK. 將確認序號(Acknowledgement Number)設置為客戶的I S N加1以.即0+1=1。第三次握手的數據包 客戶端再次發送確認包(ACK) SYN標志位為0,ACK標志位為1.并且把服務器發來ACK的序號字段+1,放在確定字段中發送給對方.并且在數據段放寫ISN的+1。
            wireshark抓包三次握手怎么判斷有問題

            TCP三握手,是什么意思,為什么會有這個過程,如果沒這個過程會怎樣?

            在客戶機和服務器之間建立正常的TCP網絡連接時,客戶機首先發出一個SYN消息,服務器使用SYN-ACK應答表示接收到了這個消息,最后客戶機再以ACK(Acknowledgement[漢譯:確認字符 ,在數據通信傳輸中,接收站發給發送站的一種傳輸控制字符。它表示確認發來的數據已經接受無誤。 ])消息響應。這樣在客戶機和服務器之間才能建立起可靠的TCP連接,數據才可以在客戶機和服務器之間傳遞。 TCP連接的第一個包,非常小的一種數據包。SYN 攻擊包括大量此類的包,由于這些包看上去來自實際不存在的站點,因此無法有效進行處理。每個機器的欺騙包都要花幾秒鐘進行嘗試方可放棄提供正常響應。第二 、詳實的資料補充:TCP三次握手/四次揮手詳解1、建立連接協議(三次握手)(1)客戶端發送一個帶SYN標志的TCP報文到服務器。這是三次握手過程中的報文1。(2) 服務器端回應客戶端的,這是三次握手中的第2個報文,這個報文同時帶ACK標志和SYN標志。因此它表示對剛才客戶端SYN報文的回應;同時又標志SYN給客戶端,詢問客戶端是否準備好進行數據通訊。(3) 客戶必須再次回應服務段一個ACK報文,這是報文段3。2、連接終止協議(四次揮手)由于TCP連接是全雙工的,因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動,一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉,而另一方執行被動關閉。(1) TCP客戶端發送一個FIN,用來關閉客戶到服務器的數據傳送(報文段4)。(2) 服務器收到這個FIN,它發回一個ACK,確認序號為收到的序號加1(報文段5)。和SYN一樣,一個FIN將占用一個序號。(3) 服務器關閉客戶端的連接,發送一個FIN給客戶端(報文段6)。(4) 客戶段發回ACK報文確認,并將確認序號設置為收到序號加1(報文段7)。LISTEN: 這個也是非常容易理解的一個狀態,表示服務器端的某個SOCKET處于監聽狀態,可以接受連接了。SYN_RCVD: 這個狀態表示接受到了SYN報文,在正常情況下,這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態,很短暫,基本上用netstat你是很難看到這種狀態的,除非你特意寫了一個客戶端測試程序,故意將三次TCP握手過程中最后一個ACK報文不予發送。因此這種狀態時,當收到客戶端的ACK報文后,它會進入到ESTABLISHED狀態。SYN_SENT: 這個狀態與SYN_RCVD遙想呼應,當客戶端SOCKET執行CONNECT連接時,它首先發送SYN報文,因此也隨即它會進入到了SYN_SENT狀態,并等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。ESTABLISHED:這個容易理解了,表示連接已經建立了。FIN_WAIT_1: 這個狀態要好好解釋一下,其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是:FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時,它想主動關閉連接,向對方發送了FIN報文,此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文后,則進入到FIN_WAIT_2狀態,當然在實際的正常情況下,無論對方何種情況下,都應該馬上回應ACK報文,所以FIN_WAIT_1狀態一般是比較難見到的,而FIN_WAIT_2狀態還有時常??梢杂胣etstat看到。FIN_WAIT_2:上面已經詳細解釋了這種狀態,實際上FIN_WAIT_2狀態下的SOCKET,表示半連接,也即有一方要求close連接,但另外還告訴對方,我暫時還有點數據需要傳送給你,稍后再關閉連接。TIME_WAIT: 表示收到了對方的FIN報文,并發送出了ACK報文,就等2MSL后即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下,收到了對方同時帶FIN標志和ACK標志的報文時,可以直接進入到TIME_WAIT狀態,而無須經過FIN_WAIT_2狀態。CLOSING: 這種狀態比較特殊,實際情況中應該是很少見,屬于一種比較罕見的例外狀態。正常情況下,當你發送FIN報文后,按理來說是應該先收到(或同時收到)對方的ACK報文,再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文后,并沒有收到對方的ACK報文,反而卻也收到了對方的FIN報文。什么情況下會出現此種情況呢?其實細想一下,也不難得出結論:那就是如果雙方幾乎在同時close一個SOCKET的話,那么就出現了雙方同時發送FIN報文的情況,也即會出現CLOSING狀態,表示雙方都正在關閉SOCKET連接。CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎么理解呢?當對方close一個SOCKET后發送FIN報文給自己,你系統毫無疑問地會回應一個ACK報文給對方,此時則進入到CLOSE_WAIT狀態。接下來呢,實際上你真正需要考慮的事情是察看你是否還有數據發送給對方,如果沒有的話,那么你也就可以close這個SOCKET,發送FIN報文給對方,也即關閉連接。所以你在CLOSE_WAIT狀態下,需要完成的事情是等待你去關閉連接。LAST_ACK: 這個狀態還是比較容易好理解的,它是被動關閉一方在發送FIN報文后,最后等待對方的ACK報文。當收到ACK報文后,也即可以進入到CLOSED可用狀態了。最后有2個問題的回答,我自己分析后的結論(不一定保證100%正確) 這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后,它可以把ACK和SYN(ACK起應答作用,而SYN起同步作用)放在一個報文里來發送。但關閉連接時,當收到對方的FIN報文通知時,它僅僅表示對方沒有數據發送給你了;但未必你所有的數據都全部發送給對方了,所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后,再發送FIN報文給對方來表示你同意現在可以關閉連接了,所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。
            TCP三握手,是什么意思,為什么會有這個過程,如果沒這個過程會怎樣?

            TCP三次握手原理

            本文主要內容1、TCP數據包格式TCP數據包格式如下:注意到中間還有幾個標志位:數據包格式當中,最重要的是理解序號和確認序號。TCP為什么是穩定可靠的,與序號與確認序號這套機制緊密相關,這也是TCP的精髓。2、TCP的三次握手眾所周知,TCP協議是可靠的,而UDP協議是不可靠的。在一些場景中必須用TCP,比如說用戶登錄,必須給出明確答復是否登錄成功等。而有些場景中,用戶是否接收到數據則不那么關鍵,比如網絡游戲當中,玩家射出一顆子彈,另外的玩家是否看到,完全取決于當前網絡環境,如果網絡卡頓,就會有玩家已經被射殺,但界面仍然刷新不出來的情況。這種情形適合UDP。為了保證TCP協議可靠,在建立連接之時就要得到保證。最初兩端的TCP進程都處于CLOSED關閉狀態,A主動打開連接,而B被動打開連接。(A、B關閉狀態CLOSED——B收聽狀態LISTEN——A同步已發送狀態SYN-SENT——B同步收到狀態SYN-RCVD——A、B連接已建立狀態ESTABLISHED)B服務器進程就處于LISTEN(收聽)狀態,等待客戶的連接請求。若有,則作出響應。3、TCP的傳輸和確認TCP 傳輸的可靠性,可以用一句話歸結:每收到對方數據,就發送 ACK 進行確定,發送方發送后沒有收到 ACK 就隔一段時間重發。就是 A 向 B 發送消息(下面將 TCP 的報文直接看做是消息,消息一詞跟 TCP 報文混用),B 收到消息后需要向 A 發送 ACK。這個 ACK 相當于返回結果,沒有返回結果,A 就重新發送消息。歸納起來,A 有 3 種消息需要確認。另外 A 也可以發送 RST 消息,代表出錯了。出錯消息不需要確認。RST 也可以當成返回接口,替代正常的 ACK。返回 ACK,表示消息發送并處理成功,返回 RST 表示消息處理失敗。因為通過網絡傳輸,還有第三種結果,就是不確定成功失敗。這樣歸納起來。就有三種返回結果。這兩種具體情況,A 根本識別不了,都只能重發。4、TCP的序號和確認序號A 向 B 發送消息,假如同時發送 a、b、c、d 消息,因為通過網絡,這些消息的順序并非固定的。而 B 返回 ACK 結果,這樣就有一個問題,這個結果到底對應了哪個消息?另外當 A 超時重發后,原來的消息延時一段時候,又重新到達了 B,這樣 B 就收到兩條相同的消息,那么 B 怎么確定這兩條消息是相同的呢?為了解決這個對應問題,每一條消息都需要有一個編號,返回結果也應該有一個編號。TCP 的序號可以看成是發送消息的編號,確認序號可以看成是返回結果的編號。有了編號,重復的消息才可以忽略,返回結果(ACK)才可以跟消息對應起來。當建立連接的時候,TCP 選定一個初始序號,之后每發送一個數據包(消息),就將序號遞增,保證每發送不同的數據包,數據包的序號都是不同的。TCP 是這樣處理的:SYN、FIN 也需要遞增序號。不然 A 向 B 重發多個 SYN 或者 FIN, B 根本判斷不了 SYN 是否相同,這樣就不可以忽略重復的數據包了。當 TCP 發送 ACK 時,相當于返回結果,需要帶有確認序號,以便跟發送的消息對應起來。當發送包編號為 a,遞增長度為 len。其中 SYN 和 FIN 可以看成是遞增長度為 1。這條消息可以這樣表示為:現在來回顧三次握手過程。 A 發送序列號x給 B , B 回復 A 確認號 x+ 1,同時發送序列號 y, A 接收到 B 的回復后,再回復確認號 y+1,同時發送序列號 x+1。給對方的回復一定是接收到的序號加1(或者是數據長度),這樣對方才能知道我已經收到了,這樣才能保證TCP是可靠的。
            TCP三次握手原理

            本文由 在線網速測試 整理編輯,轉載請注明出處,原文鏈接:http://www.mestier.com/news/44746.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>