• <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ù)報(bào)文協(xié)議,是以數(shù)據(jù)包方式,所以每次可以接收100,
            200,在理想情況下,第一次是無論recvfrom多少都是接收到100。當(dāng)然,可能由于網(wǎng)絡(luò)原因,第二個(gè)包先到的話,有可能是200了。對(duì)可能會(huì)由于網(wǎng)絡(luò)原因亂序,所以可能先收到200,所以自定義的udp協(xié)議包頭里都要加上一個(gè)序列號(hào),標(biāo)識(shí)發(fā)送與收包對(duì)應(yīng)

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

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

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

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

            6.什么是TCP粘包

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

            評(píng)論

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

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

            <2014年3月>
            2324252627281
            2345678
            9101112131415
            16171819202122
            23242526272829
            303112345

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            留言簿(4)

            隨筆分類(378)

            隨筆檔案(329)

            鏈接

            最新隨筆

            搜索

            最新評(píng)論

            国产综合精品久久亚洲| 日本人妻丰满熟妇久久久久久| 亚洲国产另类久久久精品黑人 | 亚洲午夜久久久久久久久久| 精品乱码久久久久久夜夜嗨| 久久这里只有精品久久| 韩国免费A级毛片久久| 久久精品人人槡人妻人人玩AV| 伊人久久大香线蕉亚洲五月天| 一本久久综合亚洲鲁鲁五月天| 久久久久久久综合综合狠狠| 久久青青草原精品国产不卡| 久久91这里精品国产2020| 国产精品久久久久乳精品爆| 国产—久久香蕉国产线看观看| 国产成人精品综合久久久| 久久久91人妻无码精品蜜桃HD| 国产成人久久精品麻豆一区| 国产精品伦理久久久久久| 性高湖久久久久久久久AAAAA | 久久久久久亚洲精品成人| av无码久久久久不卡免费网站| 国产精品久久久久久福利漫画| 97久久精品人人做人人爽| 久久这里只有精品视频99| 久久久久久久波多野结衣高潮| 日韩精品久久无码中文字幕 | 久久精品国产亚洲一区二区| 久久久久久综合一区中文字幕| yellow中文字幕久久网| 亚洲日本久久久午夜精品| 国产精品久久久久久吹潮| 久久免费视频6| 久久午夜伦鲁片免费无码| 国产精品99久久久久久董美香| 色播久久人人爽人人爽人人片AV| 国产成人精品久久免费动漫| 久久青青国产| 99久久精品国产麻豆| 伊人久久五月天| 久久人人爽人人爽人人片AV麻豆|