• <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>
            隨筆 - 96  文章 - 255  trackbacks - 0
            <2008年4月>
            303112345
            6789101112
            13141516171819
            20212223242526
            27282930123
            45678910

            E-mail:zbln426@163.com QQ:85132383 長期尋找對戰略游戲感興趣的合作伙伴。

            常用鏈接

            留言簿(21)

            隨筆分類

            隨筆檔案

            SDL相關網站

            我的個人網頁

            我的小游戲

            資源下載

            搜索

            •  

            積分與排名

            • 積分 - 494277
            • 排名 - 39

            最新評論

            閱讀排行榜

            評論排行榜

            前面3個小節介紹了socket機制對TCP協議三次握手的實現,需要強調的是,與協議獨立于實現類似,TCP的三次握手是獨立于socket體系的理論。在TCP協議中,三次握手是通過3個TCP格式的IP數據報來實現的。TCP格式的IP數據報中包含著TCP首部,TCP首部信息中包含著對每一個數據報具體內容的描述。我們這里需要介紹的首部位(bit)標志只有3個:
            SYN:同步序號用來發起一個連接。因為TCP協議要求數據傳送是可靠的,他的實現方式就是對傳輸的數據的每一個字節(byte)按順序編號。但是初始序列號(ISN:Initial Sequence Number)并非從0開始,而是一個隨時間周而復始變化的32位無符號整數。當一方發起連接的時候,SYN就會被設置成1,同時,在發送的數據部分用一個字節來表明這是一個新連接的開始。因此,假設發起連接的一方的ISN為n,因為SYN會在數據部分添加一個字節表示這是一個新連接的開始,所以這時候的字節序號就成了n+1。
            ACK:確認序號有效。TCP協議要求自動檢驗數據的可靠性,實現方式就是檢驗字節序號是否正確的銜接。假如接收數據的一方序號已經是m,那么其返回給發送方確認有效的序號就是m+1。一旦連接,ACK始終設置為1,即表示序號有效,并且在所有數據包中總是存在。但是數據是否真的被TCP采用要看序號是否能對應。如果發送方傳來的字節序號沒有從m+1開始,那么這個IP數據包就不會被采用,返回ACK信息序號依然是m+1;如果發送方傳來的字節序號盡管是從m+1開始的,但是在效驗時發生了錯誤,這個數據報依然不會被采用,返回的ACK信息序號依然是m+1。直到接收了通過TCP檢驗的數據,序號才會繼續增加,例如,傳來的數據字節序號從m+1開始到m+k結束,并且通過了TCP效驗,那么再次傳回的ACK信息,序號就成為了m+k+1。
            FIN:發送端完成發送。與SYN類似,FIN也會在數據部分占用一個字節,表示這是一個結束符號。
            TCP的三次握手過程如下:
            1、第一個SYN連接請求由客戶端發起,這個數據報將SYN設置為1表示是一個連接請求,并且包含著這次連接的ISN,我們假設其值為n。
            2、服務器端收到第一次握手請求的數據報后開始構建反饋的數據報。反饋數據報包括兩個部分:第一部分是將連接請求的序號反饋回去,因為SYN本身占了一個字節,所以反饋回去的序號就是n+1;第二部分是自己也向客戶端發起SYN連接請求,也將SYN設置為1,并包含這個新連接的ISN,我們設其值為m。
            3、客戶端回應服務器端的SYN連接請求,將服務器端到客戶端連接的序號反饋回去,因為SYN占了一個字節,所以反饋給服務器端的序號是m+1。
            由此,我們可以看到,TCP中,客戶端到服務器端,服務器端到客戶端的連接是分別建立的,具有不同的ISN(n和m),我們在后面可以看到,這也就意味著這兩個連接在正常情況下需要分別的斷開。
            posted on 2010-06-07 13:16 lf426 閱讀(3038) 評論(0)  編輯 收藏 引用 所屬分類: SDL入門教程socket 編程入門教程
            久久久久久亚洲精品不卡| 97久久精品国产精品青草| 亚洲精品乱码久久久久久蜜桃图片 | 久久香综合精品久久伊人| 男女久久久国产一区二区三区| 国产精品久久国产精品99盘| 欧美久久久久久午夜精品| 久久夜色精品国产噜噜噜亚洲AV| 99热热久久这里只有精品68| 亚洲国产另类久久久精品 | 久久天天躁狠狠躁夜夜躁2O2O | 色婷婷久久综合中文久久蜜桃av | 亚洲中文字幕无码久久2020| 国产精品亚洲综合专区片高清久久久| 无码精品久久久天天影视| 综合久久久久久中文字幕亚洲国产国产综合一区首 | 蜜桃麻豆WWW久久囤产精品| 一级做a爰片久久毛片16| 少妇内射兰兰久久| 欧美伊人久久大香线蕉综合| 狠狠色丁香婷婷综合久久来来去| 成人妇女免费播放久久久| 久久亚洲AV成人无码国产| 久久精品国产99国产精品导航| 人妻无码久久精品| 久久精品无码一区二区三区日韩| 亚洲欧美精品伊人久久| 91久久九九无码成人网站| 一级做a爰片久久毛片16| 99精品伊人久久久大香线蕉| 高清免费久久午夜精品| 久久久亚洲欧洲日产国码二区 | 亚洲国产精品人久久| 久久精品一区二区国产| 久久精品国产免费一区| 国产呻吟久久久久久久92| 久久亚洲电影| 久久久亚洲裙底偷窥综合 | 日韩欧美亚洲综合久久影院Ds| 综合久久一区二区三区 | 亚洲国产精品无码久久青草|