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

            天下

            記錄修行的印記

            TCP與UDP的不同接包處理方式

            TCP與UDP的不同接包處理方式


            1.UDP發(fā)包的問題
            問:udp 發(fā)送兩次數(shù)據(jù),第一次 100字節(jié) ,第二次200字節(jié), 接包方一次recvfrom( 
            1000 ), 收到是 100,還是200,還是300?
            答:UDP是數(shù)據(jù)報文協(xié)議,是以數(shù)據(jù)包方式,所以每次可以接收100,
            200,在理想情況下,第一次是無論recvfrom多少都是接收到100。當(dāng)然,可能由于網(wǎng)絡(luò)原因,第二個包先到的話,有可能是200了。對可能會由于網(wǎng)絡(luò)原因亂序,所以可能先收到200,所以自定義的udp協(xié)議包頭里都要加上一個序列號,標(biāo)識發(fā)送與收包對應(yīng)

            2.TCP的發(fā)包問題
            問:同樣如果換成tcp, 第一次發(fā)送 100字節(jié) ,第二次發(fā)送200字節(jié),recv( 
            1000 )會接收到多少?
            答:tcp是流協(xié)議,所以recv( 
            1000 ),會收到300 tcp自己處理好了重傳,保證數(shù)據(jù)包的完整性

            3.有分片的情況下如下處理
            問:如果MTU是1500,使用UDP發(fā)送 
            2000,那么recvfrom(2000)是收到1500,還是2000?
            答: 還是接收2000,數(shù)據(jù)分片由ip層處理了,放到udp還是一個完整的包。接收到的包是由路由路徑上最少的MTU來分片,注意轉(zhuǎn)到UDP已經(jīng)在是組裝好的(組裝出錯的包會經(jīng)crc校驗(yàn)出錯而丟棄),是一個完整的數(shù)據(jù)包

            4.分片后的處理
            問:如果500那個片丟了怎么辦?udp又沒有重傳
            答:udp里有個crc檢驗(yàn),如果包不完整就會丟棄,也不會通知是否接收成功,所以UDP是不可靠的傳輸協(xié)議,而且TCP不存在這個問題,有自己的重傳機(jī)制。在內(nèi)網(wǎng)來說,UDP基本不會有丟包,可靠性還是有保障。當(dāng)然如果是要求有時序性和高可靠性,還是走TCP,不然就要自己提供重傳和亂序處理( UDP內(nèi)網(wǎng)發(fā)包處理量可以達(dá) 7w
            ~10w/s )

            5.不同連接到同一個端口的包處理
            問:TCP
            -> C 發(fā)100
            -> C 發(fā)200
            AB同時同一端口
            C recv(
            1000) ,會收到多少?
            答:A與C是一個tcp連接,B與C又是另一個tcp連接, 所以不同socket,所以分開處理。每個socket有自己的接收緩沖和發(fā)送緩沖

            6.什么是TCP粘包

            由于TCP是流協(xié)議,對于一個socket的包,如發(fā)送 10AAAAABBBBB兩次,由于網(wǎng)絡(luò)原因第一次又分成兩次發(fā)送, 10AAAAAB和BBBB,如果接包的時候先讀取10(包長度)再讀入后續(xù)數(shù)據(jù),當(dāng)接收得快,發(fā)送的慢時,就會出現(xiàn)先接收了 10AAAAAB,會解釋錯誤 ,再接到到BBBB10AAAAABBBBB,也解釋錯誤的情況。這就是TCP的粘包。
               解決的辦法TLV方式,先接收包頭,在包頭里指定包體長度來接收。設(shè)置包頭包尾的檢查位(如群空間0x2開頭,0x3結(jié)束來檢查一個包是否完整)。對于TCP來說:
            1)不存在丟包,錯包,所以不會出現(xiàn)數(shù)據(jù)出錯 2)如果包頭檢測錯誤,即為非法或者請求,直接重置即可
            7.

            For message-oriented sockets, data is extracted from the first enqueued message, up to the size of the buffer specified. If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recvfrom generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost.

            posted on 2012-01-06 17:03 天下 閱讀(1810) 評論(1)  編輯 收藏 引用 所屬分類: Socket

            評論

            # re: TCP與UDP的不同接包處理方式[未登錄] 2015-11-05 17:50 12

            粘包那瞎寫  回復(fù)  更多評論   

            <2012年6月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            1234567

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            留言簿(4)

            隨筆分類(378)

            隨筆檔案(329)

            鏈接

            最新隨筆

            搜索

            最新評論

            青青草原综合久久大伊人导航| 久久精品中文闷骚内射| 久久er国产精品免费观看8| 91精品国产91久久久久久| 青青热久久国产久精品 | 久久er国产精品免费观看2| 99久久精品国产一区二区三区| 亚洲AV伊人久久青青草原| 69国产成人综合久久精品| 久久夜色撩人精品国产| 国产成人精品久久免费动漫| 久久e热在这里只有国产中文精品99| 久久久无码精品亚洲日韩京东传媒 | 日日狠狠久久偷偷色综合免费| 久久精品国产2020| 久久精品国产精品亚洲艾草网美妙| 99久久国产精品免费一区二区| 久久久久国产一区二区三区| 久久精品国产亚洲麻豆| 国内高清久久久久久| 日韩电影久久久被窝网| 国产成人AV综合久久| 97久久精品国产精品青草| 久久精品中文騷妇女内射| 久久久久国产精品嫩草影院| 亚洲国产精品成人久久蜜臀 | 精品久久久久久久| 久久久久人妻一区精品色| 午夜精品久久久久久久久| 国产69精品久久久久9999APGF | 国产精品免费久久| 久久综合九色综合97_久久久| 精品综合久久久久久888蜜芽| 少妇久久久久久久久久| 亚洲va久久久噜噜噜久久天堂| 老男人久久青草av高清| 国内精品久久久久影院老司| 麻豆久久| 国内精品久久久久影院一蜜桃| 久久久久久九九99精品| 亚洲一区中文字幕久久|