• <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>
            Fork me on GitHub
            隨筆 - 215  文章 - 13  trackbacks - 0
            <2017年12月>
            262728293012
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456


            專注即時(shí)通訊及網(wǎng)游服務(wù)端編程
            ------------------------------------
            Openresty 官方模塊
            Openresty 標(biāo)準(zhǔn)模塊(Opm)
            Openresty 三方模塊
            ------------------------------------
            本博收藏大部分文章為轉(zhuǎn)載,并在文章開(kāi)頭給出了原文出處,如有再轉(zhuǎn),敬請(qǐng)保留相關(guān)信息,這是大家對(duì)原創(chuàng)作者勞動(dòng)成果的自覺(jué)尊重!!如為您帶來(lái)不便,請(qǐng)于本博下留言,謝謝配合。

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            相冊(cè)

            Awesome

            Blog

            Book

            GitHub

            Link

            搜索

            •  

            積分與排名

            • 積分 - 215335
            • 排名 - 118

            最新評(píng)論

            閱讀排行榜

            http://blog.csdn.net/u014630768/article/details/34895367

            UDT庫(kù) https://sourceforge.net/projects/udt/?source=directory

                C#包裝:https://github.com/dump247/udt-net

                

            • UDT協(xié)議是什么?是一種基于UDP的數(shù)據(jù)傳輸協(xié)議(UDP-based Data Transfer Protocol,簡(jiǎn)稱UDT)。

            • UDT協(xié)議的主要作用是什么?UDT的主要目的是支持高速?gòu)V域網(wǎng)上的海量數(shù)據(jù)傳輸,而互聯(lián)網(wǎng)上的標(biāo)準(zhǔn)數(shù)據(jù)傳輸協(xié)議TCP在高帶寬長(zhǎng)距離網(wǎng)絡(luò)上性能很差。

            • 那么UDT與UDP的區(qū)別又是什么?UDT建于UDP之上,并引入新的擁塞控制和數(shù)據(jù)可靠性控制機(jī)制。UDT是面向連接的雙向的應(yīng)用層協(xié)議。它同時(shí)支持可靠的數(shù)據(jù)流傳輸和部分可靠的數(shù)據(jù)報(bào)傳輸。

            • UDT的使用場(chǎng)景是什么?由于UDT完全在UDP上實(shí)現(xiàn),它也可以應(yīng)用在除了高速數(shù)據(jù)傳輸之外的其它應(yīng)用領(lǐng)域,例如點(diǎn)到點(diǎn)技術(shù)(P2P),防火墻穿透,多媒體數(shù)據(jù)傳輸?shù)鹊取?/span>

              (以上問(wèn)題的答案均摘自wikipedia)當(dāng)然我今天也不是來(lái)當(dāng)知識(shí)搬運(yùn)工的,而是結(jié)合以上UDT協(xié)議的基本定義來(lái)深入到UDT協(xié)議內(nèi)部去解析它。


              UDT協(xié)議的主要特性有哪些?

            • 基于UDP的應(yīng)用層協(xié)議: 有基本網(wǎng)絡(luò)知識(shí)的朋友都知道TCP和UDP的區(qū)別和使用場(chǎng)景,但是有沒(méi)有一種協(xié)議能同時(shí)兼顧TCP協(xié)議的安全可靠和UDP協(xié)議的高效,那么UDT就是一種。

            • 面向連接的協(xié)議:面向連接意味著兩個(gè)使用協(xié)議的應(yīng)用在彼此交換數(shù)據(jù)之前必須先建立一個(gè)連接,當(dāng)然UDT是邏輯上存在的連接通道。這種連接的維護(hù)是基于握手、Keep-alive(保活)以及關(guān)閉連接。

            • 可靠的協(xié)議:依靠包序號(hào)機(jī)制、接收者的ACK響應(yīng)和丟包報(bào)告、ACK序號(hào)機(jī)制、重傳機(jī)制(基于丟包報(bào)告和超時(shí)處理)來(lái)實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)目煽啃浴?/span>

            • 雙工的協(xié)議:每個(gè)UDT實(shí)例包含發(fā)送端和接收端的信息。

            • 單播的數(shù)據(jù)流。

            • 新的擁塞算法,并且具有可擴(kuò)展的擁塞控制框架:新的擁塞控制算法不同于基于窗口的TCP擁塞控制算法(慢啟動(dòng)和擁塞避免),是混合的基于窗口的、基于速率的擁塞控制算法。可擴(kuò)展的擁塞控制框架開(kāi)源的代碼和擁塞控制的C++類架構(gòu),可支持開(kāi)發(fā)者派生專用的擁塞控制算法。

            • 帶寬估計(jì):UDT使用對(duì)包(PP -- Packet pair)的機(jī)制來(lái)估計(jì)帶寬值。即每16個(gè)包為一組,最后一個(gè)是對(duì)包,即發(fā)送方不用等到下一個(gè)發(fā)送周期內(nèi)再發(fā)送。接收方接收到對(duì)包后對(duì)其到達(dá)時(shí)間進(jìn)行記錄,可結(jié)合上次記錄的值計(jì)算出鏈路的帶寬(計(jì)算的方法稱為中值過(guò)濾法), 并在下次ACK中進(jìn)行反饋。


            ★★★ENET庫(kù)(photon的可靠udp) https://github.com/lsalzman/enet

            c#包裝1:https://github.com/RainsSoft/enetcs

            c#包裝2:https://github.com/RainsSoft/ENetSharp

            大家都知道UDP這個(gè)東西太不可靠了,存在著亂序,丟包,包重復(fù)等缺點(diǎn),但它的速度快,包有界等優(yōu)點(diǎn),但在實(shí)際編程中要自己處理亂序啊之類的問(wèn)題會(huì)發(fā)瘋 的。也許大家說(shuō)用TCP就得了,第一點(diǎn)TCP的速度比較慢,第二個(gè)TCP是一個(gè)數(shù)據(jù)流一樣的東西,我們要傳數(shù)據(jù)的話還得處理數(shù)據(jù)的分界問(wèn)題,也挺麻煩的。

            針對(duì)這個(gè)問(wèn)題,ENET這個(gè)庫(kù)實(shí)現(xiàn)了一個(gè)性能介于TCP與UDP之間,完成可靠(不丟包,按序),保持?jǐn)?shù)據(jù)的分界的優(yōu)點(diǎn)。編程起來(lái)也挺方便的。

            下載地址:http://enet.bespin.org/SourceDistro.html


            RakNet庫(kù)  https://github.com/OculusVR/RakNet

            c#包裝:https://github.com/RainsSoft/RakNet-C-Sharp-binding-project

            RakNet是一個(gè)基于UDP網(wǎng)絡(luò)傳輸協(xié)議的C++網(wǎng)絡(luò)庫(kù),允許程序員在他們自己的程序中實(shí)現(xiàn)高效的網(wǎng)絡(luò)傳輸服務(wù)。通常情況下用于游戲,但也可以用于其它項(xiàng)目。

            RakNet有以下特點(diǎn):

            l 高性能 在同一臺(tái)計(jì)算機(jī)上,RakNet可以實(shí)現(xiàn)在兩個(gè)程序之間每秒傳輸25,000條信息;

            l 容易使用 RakNet有在線用戶手冊(cè),視頻教程。每一個(gè)函數(shù)和類都有詳細(xì)的講解,每一個(gè)功能都有自己的例程;

            l 跨平臺(tái),當(dāng)前RakNet支持Windows, Linux, Macs,可以建立在Visual Studio, GCC, Code,Blocks, DevCPP 和其它平臺(tái)上。

            l 在線技術(shù)支持 RakNet有一個(gè)活躍的論壇,郵件列表,你只要給他們發(fā)信,他們可以在幾小時(shí)之內(nèi)回復(fù)你。

            l 安全的傳輸 RakNet在你的代碼中自動(dòng)使用SHA1, AES128, SYN,用RSA避免傳輸受到攻擊

            l 音頻傳輸 用Speex編碼解碼,8位的音頻只需要每秒500字節(jié)傳輸。

            l 遠(yuǎn)程終端 用RakNet,你能遠(yuǎn)程管理你的程序,包括程序的設(shè)置,密碼的管理和日志的管理。

            l 目錄服務(wù)器 目錄服務(wù)器允許服務(wù)器列舉他們自己需要的客戶端,并與他們連接。

            l Autopatcher Autopatcher系統(tǒng)將限制客戶端傳輸?shù)椒?wù)端的文件,這樣是為了避免一些不合法的用戶將一些不合法的文件傳輸?shù)椒?wù)端。

            l 對(duì)象重載系統(tǒng)

            l 網(wǎng)絡(luò)數(shù)據(jù)壓縮 BitStream類允許壓縮矢量,矩陣,四元數(shù)和在-1到1之間的實(shí)數(shù)。

            l 遠(yuǎn)程功能調(diào)用

            l 強(qiáng)健的通信層 可以保障信息按照不同的信道傳輸


            UDT基于一種基于帶寬速率控制的擁塞控制算法進(jìn)行設(shè)計(jì),主要用在小數(shù)量的bulk源共享富裕帶寬的情況下,最典型的例子就是建立在光纖廣域網(wǎng)上的網(wǎng)格計(jì)算,而在ISP提供帶寬有限的情況下運(yùn)行卻顯得消耗資源并性能不足。甚至可能被防火墻,或ISP服務(wù)商判斷為惡意帶寬使用攻擊。

            RakNet是為游戲應(yīng)用而設(shè)計(jì),對(duì)于實(shí)時(shí)性等游戲相關(guān)的網(wǎng)絡(luò)需求有很好的支持,對(duì)于大批量數(shù)據(jù)傳輸卻有點(diǎn)力所不及。raknet的缺點(diǎn)是不支持組播


            ★★★★ KCP - A Fast and Reliable ARQ Protocol

            源碼: https://github.com/skywind3000/kcp

            c#包裝:https://github.com/RainsSoft/kcp-csharp

            KCP是一個(gè)快速可靠協(xié)議,能以比 TCP浪費(fèi)10%-20%的帶寬的代價(jià),換取平均延遲降低 30%-40%,且最大延遲降低三倍的傳輸效果。純算法實(shí)現(xiàn),并不負(fù)責(zé)底層協(xié)議(如UDP)的收發(fā),需要使用者自己定義下層數(shù)據(jù)包的發(fā)送方式,以 callback的方式提供給 KCP。 連時(shí)鐘都需要外部傳遞進(jìn)來(lái),內(nèi)部不會(huì)有任何一次系統(tǒng)調(diào)用。

            整個(gè)協(xié)議只有 ikcp.h, ikcp.c兩個(gè)源文件,可以方便的集成到用戶自己的協(xié)議棧中。也許你實(shí)現(xiàn)了一個(gè)P2P,或者某個(gè)基于 UDP的協(xié)議,而缺乏一套完善的ARQ可靠協(xié)議實(shí)現(xiàn),那么簡(jiǎn)單的拷貝這兩個(gè)文件到現(xiàn)有項(xiàng)目中,稍微編寫(xiě)兩行代碼,即可使用。

            KCP協(xié)議比較

            如果網(wǎng)絡(luò)從來(lái)不丟包,那么你直接用 TCP就行了,甚至直接裸UDP都沒(méi)關(guān)系,但是網(wǎng)絡(luò)因?yàn)閬G包造成卡頓,特別是高峰時(shí)期丟包會(huì)上到10%的情況,移動(dòng)設(shè)備上這個(gè)情況更糟糕。

            我自己評(píng)測(cè)過(guò)很多,asio_kcp 的作者做過(guò)比較詳細(xì)的評(píng)測(cè),在網(wǎng)絡(luò)變?cè)愀獾那闆r下,KCP的延遲比 libenet低三倍以上:

            worst network lag happen: asio: 10:51.21 291  295   269   268   231   195   249   230   225   204  enet: 10:51.21 1563   1520    1470    1482    1438    1454    1412    1637    1588    1540

            更詳細(xì)的評(píng)測(cè)可以看這里:benchmark,感謝 asio_kcp 的作者 zhangyuan 詳細(xì)對(duì)比了 UDT, libenet和 kcp,并給出結(jié)論如下:

            • ASIO-KCP has good performace in wifi and phone network(3G, 4G).
            • The kcp is the first choice for realtime pvp game.
            • The lag is less than 1 second when network lag happen. 3 times better than enet when lag happen.
            • The enet is a good choice if your game allow 2 second lag.
            • UDT is a bad idea. It always sink into badly situation of more than serval seconds lag. And the recovery is not expected.

            其他可以左右你選擇的情況:

            • enet has the problem of lack of doc. And it has lots of functions that you may intrest.
            • kcp's doc is chinese.
            • Good thing is the function detail which is writen in code is english. And you can use asio_kcp which is a good wrap.
            • The kcp is a simple thing. You will write more code if you want more feature.
            • UDT has a perfect doc. UDT may has more bug than others as I feeling.

            我當(dāng)年主要測(cè)試了 KCP和 TCP/UDT的比較,掃了一眼 libenet覺(jué)得協(xié)議實(shí)現(xiàn)中規(guī)中矩,缺乏很多現(xiàn)代傳輸協(xié)議的技術(shù),所以并沒(méi)有詳細(xì)測(cè)試。而 asio-kcp的作者同時(shí)給出了KCP/enet/udt三者的詳細(xì)比較,為猶豫選擇的人提供了更多指引。

            The bench mark is for realtime pvp game. For example, the multiplayer first person shooting game.
            The requirement of realtime pvp game is packet is small and frequently. 
            It wants a minimal delay. And the worst delay should be not so worse. 
            The test client send 500 bytes in every 50 milliseconds. And the server send it back after receiving immediately.

            Three frameworks were tested,

            • UDT - UDP-based Data Transfer Protocol
            • kcp - A Fast and Reliable ARQ Protocol
            • enet - Reliable UDP networking library


            lidgren-network-gen3 

            https://github.com/RainsSoft/lidgren-network-gen3

            純C#實(shí)現(xiàn)的UDP開(kāi)源庫(kù),可用于游戲,支持NAT,內(nèi)部使用的可靠ARQ協(xié)議算法沒(méi)仔細(xì)去研究,不知道WIFI以及3G/4G下的表現(xiàn)怎么樣,暫時(shí)沒(méi)有測(cè)試數(shù)據(jù)

            UDT協(xié)議詳解:
            http://blog.csdn.net/bytxl/article/details/44979669

            RakNet:http://blog.csdn.net/ww506772362/article/details/51076890
            ENET庫(kù)(可靠UDP):
            http://blog.csdn.net/yuanchunsi/article/details/70244338


            posted on 2017-12-08 14:32 思月行云 閱讀(7285) 評(píng)論(3)  編輯 收藏 引用 所屬分類: C\C++

            FeedBack:
            # re: 幾種UDP網(wǎng)絡(luò)庫(kù)的整理Raknet,UDT,ENet,lidgren-network-gen3 2017-12-08 16:02 思月行云
            # re: 幾種UDP網(wǎng)絡(luò)庫(kù)的整理Raknet,UDT,ENet,lidgren-network-gen3 2017-12-08 16:04 思月行云
            KCP —— 快速可靠的網(wǎng)絡(luò)傳輸協(xié)議
            https://www.oschina.net/p/kcp  回復(fù)  更多評(píng)論
              
            # re: 幾種UDP網(wǎng)絡(luò)庫(kù)的整理Raknet,UDT,ENet,lidgren-network-gen3 2017-12-08 16:17 思月行云
            久久久久久狠狠丁香| 精品久久久久久中文字幕人妻最新| 五月丁香综合激情六月久久| 青青久久精品国产免费看| 综合久久给合久久狠狠狠97色 | 91性高湖久久久久| 国产激情久久久久影院老熟女| 狠狠精品干练久久久无码中文字幕 | 久久无码精品一区二区三区| 亚洲AV伊人久久青青草原| 国产A三级久久精品| 69久久精品无码一区二区| 久久久久国产视频电影| 久久久久久综合网天天| 久久精品国产91久久综合麻豆自制| 久久久久国产一区二区三区| 久久久久久国产精品无码下载| 精品亚洲综合久久中文字幕| 色综合久久天天综线观看| 久久久久无码精品国产不卡| 日韩va亚洲va欧美va久久| 久久久久亚洲av无码专区导航| 国内精品欧美久久精品| 亚洲乱码中文字幕久久孕妇黑人 | 久久综合狠狠色综合伊人| 天天影视色香欲综合久久| 丰满少妇高潮惨叫久久久| 久久伊人影视| 久久99热精品| 亚洲欧美日韩中文久久| 欧美午夜精品久久久久久浪潮| 无码国产69精品久久久久网站| 久久天天躁狠狠躁夜夜av浪潮| 国内精品人妻无码久久久影院 | 久久婷婷五月综合成人D啪| 国产精品无码久久久久久| 亚洲午夜福利精品久久| 精品欧美一区二区三区久久久 | 亚洲?V乱码久久精品蜜桃| 色综合久久久久网| 999久久久免费精品国产|