• <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>

            A Za, A Za, Fighting...

            堅信:勤能補拙

            2011知識點-TCP 區分消息邊界[zz]

             在socket網絡程序中,TCP和UDP分別是面向連接和非面向連接的。因此TCP的socket編程,收發兩端(客戶端和服務器端)都要有一一成對的socket,因此,發送端為了將多個發往接收端的包,更有效的發到對方,使用了優化方法(Nagle算法),將多次間隔較小且數據量小的數據,合并成一個大的數據塊,然后進行封包。這樣,接收端,就難于分辨出來了,必須提供科學的拆包機制。
                   對于UDP,不會使用塊的合并優化算法,這樣,實際上目前認為,是由于UDP支持的是一對多的模式,所以接收端的skbuff(套接字緩沖區)采用了鏈式結構來記錄每一個到達的UDP包,在每個UDP包中就有了消息頭(消息來源地址,端口等信息),這樣,對于接收端來說,就容易進行區分處理了

            保護消息邊界和流

            那么什么是保護消息邊界和流呢?

                   保護消息邊界,就是指傳輸協議把數據當作一條獨立的消息在網上 
            傳輸,接收端只能接收獨立的消息.也就是說存在保護消息邊界,接收 
            端一次只能接收發送端發出的一個數據包. 
                   而面向流則是指無保護消息保護邊界的,如果發送端連續發送數據, 
            接收端有可能在一次接收動作中,會接收兩個或者更多的數據包.

                   我們舉個例子來說,例如,我們連續發送三個數據包,大小分別是2k, 
            4k , 8k,這三個數據包,都已經到達了接收端的網絡堆棧中,如果使 
            UDP協議,不管我們使用多大的接收緩沖區去接收數據,我們必須有 
            三次接收動作,才能夠把所有的數據包接收完.而使用TCP協議,我們 
            只要把接收的緩沖區大小設置在14k以上,我們就能夠一次把所有的 
            數據包接收下來.只需要有一次接收動作.

                   這就是因為UDP協議的保護消息邊界使得每一個消息都是獨立的.而 
            流傳輸,卻把數據當作一串數據流,他不認為數據是一個一個的消息.

                  所以有很多人在使用tcp協議通訊的時候,并不清楚tcp是基于流的 
            傳輸,當連續發送數據的時候,他們時常會認識tcp會丟包.其實不然, 
            因為當他們使用的緩沖區足夠大時,他們有可能會一次接收到兩個甚 
            至更多的數據包,而很多人往往會忽視這一點,只解析檢查了第一個 
            數據包,而已經接收的其他數據包卻被忽略了.所以大家如果要作這 
            類的網絡編程的時候,必須要注意這一點.

            結論:
                 根據以上所說,可以這樣理解,TCP為了保證可靠傳輸,盡量減少額外
            開銷(每次發包都要驗證),因此采用了流式傳輸,面向流的傳輸,
            相對于面向消息的傳輸,可以減少發送包的數量。從而減少了額外開
            銷。但是,對于數據傳輸頻繁的程序來講,使用TCP可能會容易粘包。
            當然,對接收端的程序來講,如果機器負荷很重,也會在接收緩沖里
            粘包。這樣,就需要接收端額外拆包,增加了工作量。因此,這個特
            別適合的是數據要求可靠傳輸,但是不需要太頻繁傳輸的場合(
            兩次操作間隔100ms,具體是由TCP等待發送間隔決定的,取決于內核
            中的socket的寫法)

            而UDP,由于面向的是消息傳輸,它把所有接收到的消息都掛接到緩沖
            區的接受隊列中,因此,它對于數據的提取分離就更加方便,但是,
            它沒有粘包機制,因此,當發送數據量較小的時候,就會發生數據包
            有效載荷較小的情況,也會增加多次發送的系統發送開銷(系統調用,
            寫硬件等)和接收開銷。因此,應該最好設置一個比較合適的數據包
            的包長,來進行UDP數據的發送。(UDP最大載荷為1472,因此最好能
            每次傳輸接近這個數的數據量,這特別適合于視頻,音頻等大塊數據
            的發送,同時,通過減少握手來保證流媒體的實時性)

            來自: http://hi.baidu.com/chongerfeia/blog/item/b1e572f631dd7e28bd310965.html

            TCP無保護消息邊界的解決
             針對這個問題,一般有3種解決方案:

                  (1)發送固定長度的消息

                  (2)把消息的尺寸與消息一塊發送

                  (3)使用特殊標記來區分消息間隔

                 

            下面我們主要分析下前兩種方法:

            1、發送固定長度的消息 
            這種方法的好處是他非常容易,而且只要指定好消息的長度,沒有遺漏未未發的數據,我們重寫了一個SendMessage方法。代碼如下:

              private static int SendMessage(Socket s, byte[] msg)

                    { 
                        int offset = 0; 
                        int size = msg.Length; 
                        int dataleft = size;

                        while (dataleft > 0) 
                        {

                            int sent = s.Send(msg, offset, SocketFlags.None); 
                            offset += sent; 
                            dataleft -= sent;

                        }

                        return offset; 
                    }

            簡要分析一下這個函數:形參s是進行通信的套接字,msg即待發送的字節數組。該方法使用while循環檢查是否還有數據未發送,尤其當發送一個很龐大的數據包,在不能一次性發完的情況下作用比較明顯。特別的,用sent來記錄實際發送的數據量,和recv是異曲同工的作用,最后返回發送的實際數據總數。

               有sentMessage函數后,還要根據指定的消息長度來設計一個新的Recive方法。代碼如下:

              private byte[] ReciveMessage(Socket s, int size) 
                    {

                        int offset = 0; 
                        int recv; 
                        int dataleft = size; 
                        byte[] msg = new byte[size];


                        while (dataleft > 0)

                        {

                            //接收消息 
                            recv = s.Receive(msg, offset, dataleft, 0); 
                            if (recv == 0)

                            {

                                break;

                            } 
                            offset += recv; 
                            dataleft -= recv;

                        }

                        return msg;

                    }

            以上這種做法比較適合于消息長度不是很長的情況。

            2、消息長度與消息一同發送

            我們可以這樣做:通過使用消息的整形數值來表示消息的實際大小,所以要把整形數轉換為字節類型。下面是發送變長消息的SendMessage方法。具體代碼如下:

              private static int SendMessage(Socket s, byte[] msg) 
                    {

                        int offset = 0; 
                        int sent; 
                        int size = msg.Length; 
                        int dataleft = size; 
                        byte[] msgsize = new byte[2];

                        //將消息尺寸從整形轉換成可以發送的字節型 
                        msgsize = BitConverter.GetBytes(size);


                        //發送消息的長度信息 
                        sent = s.Send(size);

                        while (dataleft > 0)

                        {

                            sent = s.Send(msg, offset, dataleft, SocketFlags.None);

                            //設置偏移量

                            offset += sent; 
                            dataleft -= sent;

                        }

                        return offset;

                    }


            下面是接收變長消息的ReciveVarMessage方法。代碼如下:

            private byte[] ReciveVarMessage(Socket s) 
                    {


                        int offset = 0; 
                        int recv; 
                        byte[] msgsize = new byte[2];


                        //將字節數組的消息長度信息轉換為整形 
                        int size = BitConverter.ToInt16(msgsize); 
                        int dataleft = size; 
                        byte[] msg = new byte[size];


                        //接收2個字節大小的長度信息 
                        recv = s.Receive(msgsize, 0, 2, 0); 
                        while (dataleft > 0) 
                        {

                            //接收數據 
                            recv = s.Receive(msg, offset, dataleft, 0); 
                            if (recv == 0) 
                            { 
                                break; 
                            } 
                            offset += recv; 
                            dataleft -= recv;

                        }

                        return msg;

                    }

            posted on 2011-09-01 18:36 simplyzhao 閱讀(643) 評論(0)  編輯 收藏 引用 所屬分類: R_找工復習2011

            導航

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            統計

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            97久久精品人妻人人搡人人玩| 中文字幕久久亚洲一区| 午夜欧美精品久久久久久久| 久久亚洲国产成人精品无码区| 久久久久久狠狠丁香| 久久精品成人国产午夜| 久久精品国产精品国产精品污| 欧美喷潮久久久XXXXx| 久久99国产精品久久99果冻传媒| 久久天天躁狠狠躁夜夜96流白浆 | 久久久久久亚洲AV无码专区| 伊人久久综合精品无码AV专区| 亚洲va中文字幕无码久久| 久久99精品久久久大学生| 久久亚洲精精品中文字幕| 精品久久久久香蕉网| 久久精品亚洲福利| 久久亚洲熟女cc98cm| 久久妇女高潮几次MBA| 97久久超碰成人精品网站| 国内精品九九久久久精品| 久久高清一级毛片| 久久精品国产2020| 亚洲欧美精品伊人久久| 国内精品久久久久影院薰衣草 | 亚洲国产二区三区久久| 一本色综合久久| 久久www免费人成看国产片| 亚洲欧美成人综合久久久| 欧美一级久久久久久久大| 乱亲女H秽乱长久久久| 久久精品99久久香蕉国产色戒 | 丁香五月网久久综合| 一级女性全黄久久生活片免费 | 欧美久久久久久精选9999| 天天爽天天爽天天片a久久网| 久久无码人妻一区二区三区| 亚洲国产精品成人AV无码久久综合影院| 久久免费高清视频| 久久综合久久综合久久| 国产成人久久精品区一区二区|