• <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
            1
            、建立連接協(xié)議(三次握手)
            (1)客戶端發(fā)送一個帶SYN標(biāo)志的TCP報文到服務(wù)器。這是三次握手過程中的報文1。
            (2) 服務(wù)器端回應(yīng)客戶端的,這是三次握手中的第2個報文,這個報文同時帶ACK標(biāo)志和SYN標(biāo)志。因此它表示對剛才客戶端SYN報文的回應(yīng);同時又標(biāo)志SYN給客戶端,詢問客戶端是否準(zhǔn)備好進(jìn)行數(shù)據(jù)通訊。
            (3) 客戶必須再次回應(yīng)服務(wù)段一個ACK報文,這是報文段3。
            2
            、連接終止協(xié)議(四次揮手)
               由于TCP連接是全雙工的,因此每個方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數(shù)據(jù)流動,一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動關(guān)閉,而另一方執(zhí)行被動關(guān)閉。
             (1) TCP客戶端發(fā)送一個FIN,用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送(報文段4)。
             (2) 服務(wù)器收到這個FIN,它發(fā)回一個ACK,確認(rèn)序號為收到的序號加1(報文段5)。和SYN一樣,一個FIN將占用一個序號。
             (3) 服務(wù)器關(guān)閉客戶端的連接,發(fā)送一個FIN給客戶端(報文段6)。
             (4) 客戶段發(fā)回ACK報文確認(rèn),并將確認(rèn)序號設(shè)置為收到序號加1(報文段7)。
            CLOSED: 這個沒什么好說的了,表示初始狀態(tài)。
            LISTEN: 這個也是非常容易理解的一個狀態(tài),表示服務(wù)器端的某個SOCKET處于監(jiān)聽狀態(tài),可以接受連接了。
            SYN_RCVD: 這個狀態(tài)表示接受到了SYN報文,在正常情況下,這個狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態(tài),很短暫,基本 上用netstat你是很難看到這種狀態(tài)的,除非你特意寫了一個客戶端測試程序,故意將三次TCP握手過程中最后一個ACK報文不予發(fā)送。因此這種狀態(tài) 時,當(dāng)收到客戶端的ACK報文后,它會進(jìn)入到ESTABLISHED狀態(tài)。
            SYN_SENT: 這個狀態(tài)與SYN_RCVD遙想呼應(yīng),當(dāng)客戶端SOCKET執(zhí)行CONNECT連接時,它首先發(fā)送SYN報文,因此也隨即它會進(jìn)入到了SYN_SENT狀 態(tài),并等待服務(wù)端的發(fā)送三次握手中的第2個報文。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報文。
            ESTABLISHED:這個容易理解了,表示連接已經(jīng)建立了。
            FIN_WAIT_1: 這個狀態(tài)要好好解釋一下,其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別 是:FIN_WAIT_1狀態(tài)實際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時,它想主動關(guān)閉連接,向?qū)Ψ桨l(fā)送了FIN報文,此時該SOCKET即 進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對方回應(yīng)ACK報文后,則進(jìn)入到FIN_WAIT_2狀態(tài),當(dāng)然在實際的正常情況下,無論對方何種情況下,都應(yīng)該馬 上回應(yīng)ACK報文,所以FIN_WAIT_1狀態(tài)一般是比較難見到的,而FIN_WAIT_2狀態(tài)還有時常常可以用netstat看到。
            FIN_WAIT_2:上面已經(jīng)詳細(xì)解釋了這種狀態(tài),實際上FIN_WAIT_2狀態(tài)下的SOCKET,表示半連接,也即有一方要求close連接,但另外還告訴對方,我暫時還有點(diǎn)數(shù)據(jù)需要傳送給你,稍后再關(guān)閉連接。
            TIME_WAIT: 表示收到了對方的FIN報文,并發(fā)送出了ACK報文,就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下,收到了對方同時帶 FIN標(biāo)志和ACK標(biāo)志的報文時,可以直接進(jìn)入到TIME_WAIT狀態(tài),而無須經(jīng)過FIN_WAIT_2狀態(tài)。
            CLOSING: 這種狀態(tài)比較特殊,實際情況中應(yīng)該是很少見,屬于一種比較罕見的例外狀態(tài)。正常情況下,當(dāng)你發(fā)送FIN報文后,按理來說是應(yīng)該先收到(或同時收到)對方的 ACK報文,再收到對方的FIN報文。但是CLOSING狀態(tài)表示你發(fā)送FIN報文后,并沒有收到對方的ACK報文,反而卻也收到了對方的FIN報文。什 么情況下會出現(xiàn)此種情況呢?其實細(xì)想一下,也不難得出結(jié)論:那就是如果雙方幾乎在同時close一個SOCKET的話,那么就出現(xiàn)了雙方同時發(fā)送FIN報 文的情況,也即會出現(xiàn)CLOSING狀態(tài),表示雙方都正在關(guān)閉SOCKET連接。
            CLOSE_WAIT: 這種狀態(tài)的含義其實是表示在等待關(guān)閉。怎么理解呢?當(dāng)對方close一個SOCKET后發(fā)送FIN報文給自己,你系統(tǒng)毫無疑問地會回應(yīng)一個ACK報文給對 方,此時則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來呢,實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方,如果沒有的話,那么你也就可以 close這個SOCKET,發(fā)送FIN報文給對方,也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下,需要完成的事情是等待你去關(guān)閉連接。
            LAST_ACK: 這個狀態(tài)還是比較容易好理解的,它是被動關(guān)閉一方在發(fā)送FIN報文后,最后等待對方的ACK報文。當(dāng)收到ACK報文后,也即可以進(jìn)入到CLOSED可用狀態(tài)了。
            最后有2個問題的回答,我自己分析后的結(jié)論(不一定保證100%正確)
            1、 為什么建立連接協(xié)議是三次握手,而關(guān)閉連接卻是四次握手呢?
            這 是因為服務(wù)端的LISTEN狀態(tài)下的SOCKET當(dāng)收到SYN報文的建連請求后,它可以把ACK和SYN(ACK起應(yīng)答作用,而SYN起同步作用)放在一 個報文里來發(fā)送。但關(guān)閉連接時,當(dāng)收到對方的FIN報文通知時,它僅僅表示對方?jīng)]有數(shù)據(jù)發(fā)送給你了;但未必你所有的數(shù)據(jù)都全部發(fā)送給對方了,所以你可以未 必會馬上會關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對方之后,再發(fā)送FIN報文給對方來表示你同意現(xiàn)在可以關(guān)閉連接了,所以它這里的ACK報文 和FIN報文多數(shù)情況下都是分開發(fā)送的。
            2、 為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)?
            這是因為: 雖然雙方都同意關(guān)閉連接了,而且握手的4個報文也都協(xié)調(diào)和發(fā)送完畢,按理可以直接回到CLOSED狀態(tài)(就好比從SYN_SEND狀態(tài)到 ESTABLISH狀態(tài)那樣);但是因為我們必須要假想網(wǎng)絡(luò)是不可靠的,你無法保證你最后發(fā)送的ACK報文會一定被對方收到,因此對方處于 LAST_ACK狀態(tài)下的SOCKET可能會因為超時未收到ACK報文,而重發(fā)FIN報文,所以這個TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的 ACK報文。
            轉(zhuǎn)自:
            posted on 2009-10-20 21:15 chatler 閱讀(314) 評論(0)  編輯 收藏 引用 所屬分類: Network
            <2009年5月>
            262728293012
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(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

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            国产A三级久久精品| 狠狠精品干练久久久无码中文字幕| 久久久国产精品| 久久WWW免费人成一看片| 色综合久久久久久久久五月| 久久精品国产亚洲AV高清热 | 99久久精品国产一区二区蜜芽| 伊人久久精品线影院| 国产成人综合久久精品红| 久久久精品午夜免费不卡| 亚洲国产精品综合久久网络| 一级做a爰片久久毛片16| 国产偷久久久精品专区| 久久精品国产精品亚洲艾草网美妙 | 久久久久久久久久久久中文字幕 | 久久99中文字幕久久| 色综合久久88色综合天天 | 国产精品久久影院| 亚洲精品无码久久千人斩| 久久久久亚洲AV无码专区网站 | 无码人妻久久一区二区三区蜜桃| 国内精品久久国产大陆| 久久亚洲美女精品国产精品| 色婷婷久久综合中文久久一本| 88久久精品无码一区二区毛片| 日韩人妻无码一区二区三区久久| 热久久国产欧美一区二区精品| 色综合久久综精品| 欧美日韩中文字幕久久伊人| 午夜欧美精品久久久久久久| 91麻豆国产精品91久久久| 亚洲精品高清国产一线久久| 亚洲va中文字幕无码久久 | 久久午夜电影网| 7777久久亚洲中文字幕| 久久99精品国产麻豆| 久久夜色精品国产欧美乱| 国产美女亚洲精品久久久综合| 国产亚洲精品久久久久秋霞| 嫩草伊人久久精品少妇AV| 天天爽天天狠久久久综合麻豆|