青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 297,  comments - 15,  trackbacks - 0

版權(quán)聲明:轉(zhuǎn)載時請以超鏈接形式標(biāo)明文章原始出處和作者信息及本聲明
http://xufish.blogbus.com/logs/40536553.html

TCP 的三次握手是怎么進行的了:發(fā)送端發(fā)送一個SYN=1,ACK=0標(biāo)志的數(shù)據(jù)包給接收端,請求進行連接,這是第一次握手;接收端收到請 求并且允許連接的話,就會發(fā)送一個SYN=1,ACK=1標(biāo)志的數(shù)據(jù)包給發(fā)送端,告訴它,可以通訊了,并且讓發(fā)送端發(fā)送一個確認(rèn)數(shù)據(jù)包,這是第二次握手; 最后,發(fā)送端發(fā)送一個SYN=0,ACK=1的數(shù)據(jù)包給接收端,告訴它連接已被確認(rèn),這就是第三次握手。之后,一個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é)的序列編號。

*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ù)。

*RST:復(fù)位標(biāo)志
復(fù)位標(biāo)志有效。用于復(fù)位相應(yīng)的TCP連接。

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

*PSH:推標(biāo)志
該 標(biāo)志置位時,接收端不將該數(shù)據(jù)進行隊列處理,而是盡可能快將數(shù)據(jù)轉(zhuǎn)由應(yīng)用處理。在處理 telnet 或 rlogin 等交互模式的連接時,該標(biāo)志總是置位的。

*FIN:結(jié)束標(biāo)志
帶有該標(biāo)志置位的數(shù)據(jù)包用來結(jié)束一個TCP回話,但對應(yīng)端口仍處于開放狀態(tài),準(zhǔn)備接收后續(xù)數(shù)據(jù)。

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

三次握手Three-way Handshake

一個虛擬連接的建立是通過三次握手來實現(xiàn)的

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

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

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

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

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

注意: SYN/ACK包是僅SYN 和 ACK 標(biāo)記為1的包.

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

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

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

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

四次握手Four-way Handshake

四次握手用來關(guān)閉已建 立的TCP連接

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

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

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

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

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

連接復(fù)位Resetting a connection

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

請注意RST包是可 以不要收到方確認(rèn)的?

無效的TCP標(biāo)記Invalid TCP Flags

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

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

由于現(xiàn)在大多數(shù)防火墻已知 SYN/FIN 包, 別的一些組合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明顯,當(dāng)網(wǎng)絡(luò)中出現(xiàn)這種包時,很你的網(wǎng)絡(luò)肯定受到攻擊了。

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

到目前為止,正常的網(wǎng) 絡(luò)活動下,TCP協(xié)議棧不可能產(chǎn)生帶有上面提到的任何一種標(biāo)記組合的TCP包。當(dāng)你發(fā)現(xiàn)這些不正常的包時,肯定有人對你的網(wǎng)絡(luò)不懷好意。

UDP (用戶數(shù)據(jù)包協(xié)議User Datagram Protocol)
TCP是面向連接 的,而UDP是非連接的協(xié)議。UDP沒有對接受進行確認(rèn)的標(biāo)記和確認(rèn)機制。對丟包的處理是在應(yīng)用層來完成的。(or accidental arrival).

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

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

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

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

ICMP (網(wǎng)間控制消息協(xié)議Internet Control Message Protocol)
如同名字一樣, ICMP用來在主機/路由器之間傳遞控制信息的協(xié)議。 ICMP包可以包含診斷信息(ping, traceroute - 注意目前unix系統(tǒng)中的traceroute用UDP包而不是ICMP),錯誤信息(網(wǎng)絡(luò)/主機/端口 不可達(dá) 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) 能用來轉(zhuǎn)發(fā)通訊。

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

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

包碎片注意A Note About Packet Fragmentation

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

因為分片的包的第一個 分片包含一個包頭,若沒有包分片的重組功能,包過濾器不可能檢測附加的包分片。典型的攻擊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發(fā)起 連接請求,以一個隨機數(shù)初始化A的seq,這里假設(shè)為10000,此時ACK=0

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

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


數(shù)據(jù)傳輸階段:
序號  方向      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發(fā)來的seq=40000,ack=70000,size=1514的數(shù)據(jù)包
24: 于是B向A也發(fā)一個數(shù)據(jù)包,告訴B,你的上個包我收到了。B的seq就以它收到的數(shù)據(jù)包的ACK填充,ACK是它收到的數(shù)據(jù)包的SEQ加上數(shù)據(jù)包的大小 (不包括以太網(wǎng)協(xié)議頭,IP頭,TCP頭),以證實B發(fā)過來的數(shù)據(jù)全收到了。
25:A 在收到B發(fā)過來的ack為41460的數(shù)據(jù)包時,一看到41460,正好是它的上個數(shù)據(jù)包的seq加上包的大小,就明白,上次發(fā)送的數(shù)據(jù)包已安全到達(dá)。于 是它再發(fā)一個數(shù)據(jù)包給B。這個正在發(fā)送的數(shù)據(jù)包的seq也以它收到的數(shù)據(jù)包的ACK填充,ACK就以它收到的數(shù)據(jù)包的seq(70000)加上包的 size(54)填充,即ack=70000+54-54(全是頭長,沒數(shù)據(jù)項)。

其實在握手和結(jié)束時確認(rèn)號應(yīng)該是對方序列號加1,傳輸數(shù)據(jù)時則是對方序列號加上對方攜帶應(yīng) 用層數(shù)據(jù)的長度.如果從以太網(wǎng)包返回來計算所加的長度,就嫌走彎路了.
另外,如果對 方?jīng)]有數(shù)據(jù)過來,則自己的確認(rèn)號不變,序列號為上次的序列號加上本次應(yīng)用層數(shù)據(jù)發(fā)送長度
posted on 2010-07-16 14:14 chatler 閱讀(884) 評論(0)  編輯 收藏 引用 所屬分類: NetworkSocket
<2010年11月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

常用鏈接

留言簿(10)

隨筆分類(307)

隨筆檔案(297)

algorithm

Books_Free_Online

C++

database

Linux

Linux shell

linux socket

misce

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

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

搜索

  •  

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美成年人网站| 亚洲精品美女免费| 久久精品一区二区三区不卡牛牛| 亚洲欧美日韩国产| 欧美亚洲日本国产| 欧美在线视频一区二区| 欧美一区二区在线免费观看| 欧美在线播放视频| 久久免费视频在线| 欧美第一黄网免费网站| 亚洲国产精品123| 最新国产の精品合集bt伙计| 日韩一级免费观看| 亚洲欧美电影院| 久久精品99无色码中文字幕| 久久免费午夜影院| 欧美第一黄色网| 欧美日韩国产在线一区| 国产精品日韩在线观看| 黑人中文字幕一区二区三区| 最新亚洲激情| 中文国产成人精品久久一| 午夜精品成人在线| 久久嫩草精品久久久精品一| 欧美肥婆在线| 一区二区日韩精品| 欧美一级大片在线免费观看| 久久一区二区三区四区| 欧美人与禽猛交乱配| 国产精品入口麻豆原神| 在线不卡欧美| 一区二区三区不卡视频在线观看| 欧美一级成年大片在线观看| 另类亚洲自拍| 日韩写真视频在线观看| 欧美一级在线亚洲天堂| 欧美成人国产一区二区| 国产精品视频免费| 亚洲国产精品v| 亚洲欧美日韩一区| 欧美风情在线| 亚洲综合精品一区二区| 欧美凹凸一区二区三区视频| 国产精品久久久久三级| 亚洲国内精品在线| 先锋资源久久| 亚洲激情av在线| 久久国产欧美精品| 欧美日韩大片| 在线播放豆国产99亚洲| 亚洲欧美欧美一区二区三区| 男女精品网站| 亚洲欧美bt| 欧美日韩不卡在线| 伊人久久婷婷色综合98网| 亚洲午夜精品网| 欧美成人一区在线| 午夜精品免费| 欧美日韩一区三区四区| 亚洲国产99精品国自产| 欧美在线啊v一区| 亚洲精品小视频| 久久嫩草精品久久久精品| 国产精品网站在线播放| 一本久久综合亚洲鲁鲁| 你懂的一区二区| 欧美一区二区高清在线观看| 欧美午夜在线视频| 亚洲另类自拍| 免费不卡视频| 久久精品国产77777蜜臀| 欧美亚州韩日在线看免费版国语版| 亚洲国产日韩欧美在线图片| 久久久久久亚洲精品不卡4k岛国| 一区二区三区高清视频在线观看| 免费视频一区二区三区在线观看| 国内精品免费午夜毛片| 午夜天堂精品久久久久| 一区二区三区产品免费精品久久75 | 小辣椒精品导航| 欧美视频在线视频| 一本久久a久久精品亚洲| 亚洲第一黄网| 久久综合亚州| 一区二区三区在线免费视频 | 久久综合网hezyo| 国产一区二区三区久久久久久久久| 亚洲午夜久久久久久久久电影网| 91久久久在线| 欧美国产专区| 亚洲看片免费| 亚洲人成网站精品片在线观看| 欧美.com| 亚洲乱码久久| 亚洲理伦在线| 欧美日韩精品是欧美日韩精品| 亚洲乱码日产精品bd| 最新亚洲视频| 欧美日韩精品久久久| 夜夜狂射影院欧美极品| 日韩午夜电影在线观看| 欧美日韩直播| 午夜精品久久久久久久99樱桃| 亚洲欧美日韩精品一区二区| 国产欧美日本一区视频| 久久国产加勒比精品无码| 欧美一区二区三区四区在线观看| 国产一区二区高清不卡| 久久久伊人欧美| 久久综合九色| 亚洲久久成人| 99热这里只有精品8| 国产精品第2页| 欧美专区在线观看| 久久久999国产| 亚洲人成网站999久久久综合| 亚洲激情第一区| 欧美三级精品| 久久精品99国产精品| 久久九九热免费视频| 亚洲丰满在线| 亚洲乱亚洲高清| 国产精品亚洲片夜色在线| 久久精品日韩| 男人天堂欧美日韩| 亚洲永久免费| 久久av一区二区三区漫画| 最新中文字幕一区二区三区| 亚洲乱码国产乱码精品精| 国产精品丝袜91| 久久夜色精品亚洲噜噜国产mv| 奶水喷射视频一区| 亚洲永久免费av| 久久精品免视看| 99精品欧美| 欧美一区二区三区啪啪| 亚洲人成久久| 亚洲自拍偷拍色片视频| 在线成人欧美| 一区二区激情| 影音先锋久久资源网| 亚洲精品婷婷| 红桃视频成人| 日韩亚洲精品在线| 红桃视频成人| 一区二区三区.www| 亚洲电影第三页| 亚洲午夜国产成人av电影男同| 尤物网精品视频| 中文在线不卡视频| 亚洲电影免费观看高清完整版| 在线亚洲伦理| 亚洲精品视频二区| 欧美亚洲综合网| 中国女人久久久| 久久福利精品| 亚洲欧美制服中文字幕| 免费日韩成人| 久久夜色精品国产欧美乱极品 | 久久天天躁狠狠躁夜夜爽蜜月| 亚洲视频一区二区在线观看| 久久精品国产2020观看福利| 亚洲手机视频| 美女成人午夜| 久久久久一本一区二区青青蜜月| 欧美日韩精品一区二区在线播放| 噜噜噜久久亚洲精品国产品小说| 国产精品白丝jk黑袜喷水| 欧美国产亚洲视频| 国产亚洲欧美日韩美女| 一级成人国产| 日韩午夜黄色| 美女精品网站| 久久综合伊人| 国产日产高清欧美一区二区三区| 夜夜嗨av一区二区三区中文字幕| 91久久久久久国产精品| 久久精品综合| 久久精品人人做人人综合| 欧美日韩妖精视频| 亚洲国产高清在线观看视频| 国产一区二区三区直播精品电影 | 亚洲国产视频a| 伊人精品久久久久7777| 欧美一级片一区| 亚洲综合不卡| 国产精品igao视频网网址不卡日韩| 亚洲国产日韩欧美在线动漫| 1024日韩| 久久人人爽爽爽人久久久| 久久精品在线播放| 国产欧美三级| 亚洲女人天堂成人av在线| 亚洲男人av电影| 国产精品激情电影| 一区二区三区蜜桃网| 亚洲素人在线| 欧美无砖砖区免费| 亚洲视频在线视频| 午夜激情综合网|