• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 297,  comments - 15,  trackbacks - 0

            版權聲明:轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
            http://xufish.blogbus.com/logs/40536553.html

            TCP 的三次握手是怎么進行的了:發送端發送一個SYN=1,ACK=0標志的數據包給接收端,請求進行連接,這是第一次握手;接收端收到請 求并且允許連接的話,就會發送一個SYN=1,ACK=1標志的數據包給發送端,告訴它,可以通訊了,并且讓發送端發送一個確認數據包,這是第二次握手; 最后,發送端發送一個SYN=0,ACK=1的數據包給接收端,告訴它連接已被確認,這就是第三次握手。之后,一個TCP連接建立,開始通訊。

            *SYN:同步標志
            同步序列編號(Synchronize Sequence Numbers)欄有效。該標志僅在三次握手建立TCP連接時有效。它提示TCP連接的服務端檢查序列編號,該序列編號為TCP連接初始端(一般是客戶 端)的初始序列編號。在這里,可以把TCP序列編號看作是一個范圍從0到4,294,967,295的32位計數器。通過TCP連接交換的數據中每一個字 節都經過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個字節的序列編號。

            *ACK:確認標志
            確認編號(Acknowledgement Number)欄有效。大多數情況下該標志位是置位的。TCP報頭內的確認編號欄內包含的確認編號(w+1,Figure-1)為下一個預期的序列編號, 同時提示遠端系統已經成功接收所有數據。

            *RST:復位標志
            復位標志有效。用于復位相應的TCP連接。

            *URG:緊急標志
            緊急(The urgent pointer) 標志有效。緊急標志置位,

            *PSH:推標志
            該 標志置位時,接收端不將該數據進行隊列處理,而是盡可能快將數據轉由應用處理。在處理 telnet 或 rlogin 等交互模式的連接時,該標志總是置位的。

            *FIN:結束標志
            帶有該標志置位的數據包用來結束一個TCP回話,但對應端口仍處于開放狀態,準備接收后續數據。

            =============================================================

            三次握手Three-way Handshake

            一個虛擬連接的建立是通過三次握手來實現的

            1. (B) --> [SYN] --> (A)

            假如服 務器A和客戶機B通訊. 當A要和B通信時,B首先向A發一個SYN (Synchronize) 標記的包,告訴A請求建立連接.

            注意: 一個 SYN包就是僅SYN標記設為1的TCP包(參見TCP包頭Resources). 認識到這點很重要,只有當A受到B發來的SYN包,才可建立連接,除此之外別無他法。因此,如果你的防火墻丟棄所有的發往外網接口的SYN包,那么你將不 能讓外部任何主機主動建立連接。

            2. (B) <-- [SYN/ACK] <--(A)

            接著,A收到后會發一個對SYN包的確認包(SYN/ACK)回 去,表示對第一個SYN包的確認,并繼續握手操作.

            注意: SYN/ACK包是僅SYN 和 ACK 標記為1的包.

            3. (B) --> [ACK] --> (A)

            B收到SYN/ACK 包,B發一個確認包(ACK),通知A連接已建立。至此,三次握手完成,一個TCP連接完成

            Note: ACK包就是僅ACK 標記設為1的TCP包. 需要注意的是當三此握手完成、連接建立以后,TCP連接的每個包都會設置ACK位

            這就是為何連接跟蹤很重要的原因了. 沒有連接跟蹤,防火墻將無法判斷收到的ACK包是否屬于一個已經建立的連接.一般的包過濾(Ipchains)收到ACK包時,會讓它通過(這絕對不是個 好主意). 而當狀態型防火墻收到此種包時,它會先在連接表中查找是否屬于哪個已建連接,否則丟棄該包

            四次握手Four-way Handshake

            四次握手用來關閉已建 立的TCP連接

            1. (B) --> ACK/FIN --> (A)

            2. (B) <-- ACK <-- (A)

            3. (B) <-- ACK/FIN <-- (A)

            4. (B) --> ACK --> (A)

            注意: 由于TCP連接是雙向連接, 因此關閉連接需要在兩個方向上做。ACK/FIN 包(ACK 和FIN 標記設為1)通常被認為是FIN(終結)包.然而, 由于連接還沒有關閉, FIN包總是打上ACK標記. 沒有ACK標記而僅有FIN標記的包不是合法的包,并且通常被認為是惡意的

            連接復位Resetting a connection

            四次握手不是關閉 TCP連接的唯一方法. 有時,如果主機需要盡快關閉連接(或連接超時,端口或主機不可達),RST (Reset)包將被發送. 注意在,由于RST包不是TCP連接中的必須部分, 可以只發送RST包(即不帶ACK標記). 但在正常的TCP連接中RST包可以帶ACK確認標記

            請注意RST包是可 以不要收到方確認的?

            無效的TCP標記Invalid TCP Flags

            到目前為止,你已經看到了 SYN, ACK, FIN, 和RST 標記. 另外,還有PSH (Push) 和URG (Urgent)標記.

            最常見的非法組合是SYN/FIN 包. 注意:由于 SYN包是用來初始化連接的, 它不可能和 FIN和RST標記一起出現. 這也是一個惡意攻擊.

            由于現在大多數防火墻已知 SYN/FIN 包, 別的一些組合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明顯,當網絡中出現這種包時,很你的網絡肯定受到攻擊了。

            別的已知的非法包有FIN (無ACK標記)和"NULL"包。如同早先討論的,由于ACK/FIN包的出現是為了關閉一個TCP連接,那么正常的FIN包總是帶有 ACK 標記。"NULL"包就是沒有任何TCP標記的包(URG,ACK,PSH,RST,SYN,FIN都為0)。

            到目前為止,正常的網 絡活動下,TCP協議棧不可能產生帶有上面提到的任何一種標記組合的TCP包。當你發現這些不正常的包時,肯定有人對你的網絡不懷好意。

            UDP (用戶數據包協議User Datagram Protocol)
            TCP是面向連接 的,而UDP是非連接的協議。UDP沒有對接受進行確認的標記和確認機制。對丟包的處理是在應用層來完成的。(or accidental arrival).

            此處需要重點注意的事情是:在正常情況下,當UDP包到達一個關閉的端口時,會返回一個UDP復位包。由于UDP是非面向連接的, 因此沒有任何確認信息來確認包是否正確到達目的地。因此如果你的防火墻丟棄UDP包,它會開放所有的UDP端口(?)。

            由于Internet 上正常情況下一些包將被丟棄,甚至某些發往已關閉端口(非防火墻的)的UDP包將不會到達目的,它們將返回一個復位UDP包。

            因為這個原因,UDP 端口掃描總是不精確、不可靠的。

            看起來大UDP包的碎片是常見的DOS (Denial of Service)攻擊的常見形式 (這里有個DOS攻擊的例子,http://grc.com/dos/grcdos.htm ).

            ICMP (網間控制消息協議Internet Control Message Protocol)
            如同名字一樣, ICMP用來在主機/路由器之間傳遞控制信息的協議。 ICMP包可以包含診斷信息(ping, traceroute - 注意目前unix系統中的traceroute用UDP包而不是ICMP),錯誤信息(網絡/主機/端口 不可達 network/host/port unreachable), 信息(時間戳timestamp, 地址掩碼address mask request, etc.),或控制信息 (source quench, redirect, etc.) 。

            你可以在http://www.iana.org/assignments/icmp-parameters中 找到ICMP包的類型。

            盡管ICMP通常是無害的,還是有些類型的ICMP信息需要丟棄。

            Redirect (5), Alternate Host Address (6), Router Advertisement (9) 能用來轉發通訊。

            Echo (8), Timestamp (13) and Address Mask Request (17) 能用來分別判斷主機是否起來,本地時間和地址掩碼。注意它們是和返回的信息類別有關的。它們自己本身是不能被利用的,但它們泄露出的信息對攻擊者是有用 的。

            ICMP 消息有時也被用來作為DOS攻擊的一部分(例如:洪水ping flood ping,死 ping ?呵呵,有趣 ping of death)?/p>

            包碎片注意A Note About Packet Fragmentation

            如果一個包的大小超過了TCP的最大段長度MSS (Maximum Segment Size) 或MTU (Maximum Transmission Unit),能夠把此包發往目的的唯一方法是把此包分片。由于包分片是正常的,它可以被利用來做惡意的攻擊。

            因為分片的包的第一個 分片包含一個包頭,若沒有包分片的重組功能,包過濾器不可能檢測附加的包分片。典型的攻擊Typical attacks involve in overlapping the packet data in which packet header is 典型的攻擊Typical attacks involve in overlapping the packet data in which packet header isnormal until is it overwritten with different destination IP (or port) thereby bypassing firewall rules。包分片能作為 DOS 攻擊的一部分,它可以crash older IP stacks 或漲死CPU連接能力。

            Netfilter/Iptables中的連接跟蹤代碼能自動做分片重組。它仍有弱點,可能 受到飽和連接攻擊,可以把CPU資源耗光。

            握手階段:
            序號 方向 seq ack
            1  A->B 10000 0
            2 B->A 20000 10000+1=10001
            3 A->B 10001 20000+1=20001
            解釋:
            1:A向B發起 連接請求,以一個隨機數初始化A的seq,這里假設為10000,此時ACK=0

            2:B收到A的連接請求后,也以一個隨機數初始化B的seq,這里假設為20000,意思 是:你的請求我已收到,我這方的數據流就從這個數開始。B的ACK是A的seq加1,即10000+1=10001

            3:A收到B的回復 后,它的seq是它的上個請求的seq加1,即10000+1=10001,意思也是:你的回復我收到了,我這方的數據流就從這個數開始。A此時的ACK 是B的seq加1,即20000+1=20001


            數據傳輸階段:
            序號  方向      seq ack size
            23 A->B 40000 70000 1514
            24 B->A 70000 40000+1514-54=41460 54
            25 A->B 41460 70000+54-54=70000 1514
            26 B->A 70000 41460+1514-54=42920 54
            解釋:
            23:B接收到 A發來的seq=40000,ack=70000,size=1514的數據包
            24: 于是B向A也發一個數據包,告訴B,你的上個包我收到了。B的seq就以它收到的數據包的ACK填充,ACK是它收到的數據包的SEQ加上數據包的大小 (不包括以太網協議頭,IP頭,TCP頭),以證實B發過來的數據全收到了。
            25:A 在收到B發過來的ack為41460的數據包時,一看到41460,正好是它的上個數據包的seq加上包的大小,就明白,上次發送的數據包已安全到達。于 是它再發一個數據包給B。這個正在發送的數據包的seq也以它收到的數據包的ACK填充,ACK就以它收到的數據包的seq(70000)加上包的 size(54)填充,即ack=70000+54-54(全是頭長,沒數據項)。

            其實在握手和結束時確認號應該是對方序列號加1,傳輸數據時則是對方序列號加上對方攜帶應 用層數據的長度.如果從以太網包返回來計算所加的長度,就嫌走彎路了.
            另外,如果對 方沒有數據過來,則自己的確認號不變,序列號為上次的序列號加上本次應用層數據發送長度
            posted on 2010-07-16 14:14 chatler 閱讀(852) 評論(0)  編輯 收藏 引用 所屬分類: NetworkSocket
            <2010年8月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            常用鏈接

            留言簿(10)

            隨筆分類(307)

            隨筆檔案(297)

            algorithm

            Books_Free_Online

            C++

            database

            Linux

            Linux shell

            linux socket

            misce

            • cloudward
            • 感覺這個博客還是不錯,雖然做的東西和我不大相關,覺得看看還是有好處的

            network

            OSS

            • Google Android
            • Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
            • os161 file list

            overall

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品99久久香蕉国产色戒 | 久久午夜福利电影| 国产女人aaa级久久久级| 久久久久亚洲?V成人无码| 亚洲欧洲精品成人久久奇米网| 久久久久无码精品| 久久精品国产亚洲77777| 国产无套内射久久久国产| 久久这里只有精品首页| 中文字幕一区二区三区久久网站| 777久久精品一区二区三区无码| 色综合久久夜色精品国产| 91精品国产高清91久久久久久| 久久久久国产精品三级网| 久久精品人人做人人爽97| 亚洲国产成人久久综合一区77| 大伊人青草狠狠久久| 久久婷婷色综合一区二区| 99久久精品免费看国产一区二区三区 | 久久久精品2019免费观看| 精品久久久久久无码中文字幕 | 亚洲国产精品无码久久久久久曰| 天天爽天天狠久久久综合麻豆| 精品久久人人爽天天玩人人妻| 久久天天躁狠狠躁夜夜avapp| 久久久WWW免费人成精品| 国产精品久久久久影院色| 亚洲AV乱码久久精品蜜桃| 伊人久久成人成综合网222| 亚洲狠狠综合久久| 精品精品国产自在久久高清 | 伊人色综合久久天天人守人婷| 国产亚洲美女精品久久久久狼| 日韩精品久久无码中文字幕| 久久精品国产亚洲AV久| 18禁黄久久久AAA片| 狠狠色婷婷久久综合频道日韩 | 无码人妻少妇久久中文字幕蜜桃| 亚洲国产综合久久天堂| 亚洲人成无码网站久久99热国产| 久久男人AV资源网站|