• <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
            <2016年9月>
            28293031123
            45678910
            11121314151617
            18192021222324
            2526272829301
            2345678


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

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            相冊

            Awesome

            Blog

            Book

            GitHub

            Link

            搜索

            •  

            積分與排名

            • 積分 - 216730
            • 排名 - 118

            最新評論

            閱讀排行榜

            http://blog.csdn.net/skywind/article/details/8804912

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

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

            技術(shù)特性

            TCP是為流量設(shè)計的(每秒內(nèi)可以傳輸多少KB的數(shù)據(jù)),講究的是充分利用帶寬。而KCP是為流速設(shè)計的(單個數(shù)據(jù)包從一端發(fā)送到一端需要多少時間),以10%-20%帶寬浪費的代價換取了比 TCP快30%-40%的傳輸速度。TCP信道是一條流速很慢,但每秒流量很大的大運河,而KCP是水流湍急的小激流。KCP有正常模式和快速模式兩種,通過以下策略達到提高流速的結(jié)果:

            • RTO翻倍vs不翻倍:TCP超時計算是RTOx2,這樣連續(xù)丟三次包就變成RTOx8了,十分恐怖,而KCP啟動快速模式后不x2,只是x1.5(實驗證明1.5這個值相對比較好),提高了傳輸速度。
            • 選擇性重傳 vs 全部重傳:TCP丟包時會全部重傳從丟的那個包開始以后的數(shù)據(jù),KCP是選擇性重傳,只重傳真正丟失的數(shù)據(jù)包。
            • 快速重傳:發(fā)送端發(fā)送了1,2,3,4,5幾個包,然后收到遠端的ACK: 1, 3, 4, 5,當(dāng)收到ACK3時,KCP知道2被跳過1次,收到ACK4時,知道2被跳過了2次,此時可以認為2號丟失,不用等超時,直接重傳2號包,大大改善了丟包時的傳輸速度。
            • 延遲ACK vs 非延遲ACK :TCP為了充分利用帶寬,延遲發(fā)送ACK(NODELAY都沒用),這樣超時計算會算出較大RTT時間,延長了丟包時的判斷過程。KCP的ACK是否延遲發(fā)送可以調(diào)節(jié)。
            • UNA vs ACK+UNA :ARQ模型響應(yīng)有兩種,UNA(此編號前所有包已收到,如TCP)和ACK(該編號包已收到),KCP有單獨ACK,且數(shù)據(jù)包和ACK包都帶UNA信息,有效降低ACK丟失成本。
            • 非退讓流控:KCP正常模式同TCP一樣使用公平退讓法則,即發(fā)送窗口大小由:發(fā)送緩存大小、接收端剩余接收緩存大小、丟包退讓及慢啟動這四要素決定。但傳送及時性要求很高的小數(shù)據(jù)時,可選擇通過配置跳過后兩步,僅用前兩項來控制發(fā)送頻率。以犧牲部分公平性及帶寬利用率之代價,換取了開著BT都能流暢傳輸?shù)男Ч?/li>

            基本使用

            1. 創(chuàng)建 KCP對象:
              // 初始化 kcp對象,conv為一個表示會話編號的整數(shù),和tcp的 conv一樣,通信雙方需要 // 保證 conv相同,相互的數(shù)據(jù)包才能夠被認可,user是一個給回調(diào)函數(shù)的指針。 ikcpcb *kcp = ikcp_create(conv, user);
            2. 設(shè)置回調(diào)函數(shù):
              // KCP的下層協(xié)議輸出函數(shù),KCP需要發(fā)送數(shù)據(jù)時會調(diào)用它 // buf/len 表示緩存和長度 // user指針為 kcp對象創(chuàng)建時傳入的值,用于區(qū)別多個 KCP對象 int udp_output(const char *buf, int len, ikcpcb *kcp, void *user) { .... }  // 設(shè)置回調(diào)函數(shù) kcp->output = udp_output;
            3. 循環(huán)調(diào)用 update:
              // 以一定頻率調(diào)用 ikcp_update來更新 kcp狀態(tài),并且傳入當(dāng)前的時鐘(毫秒單位)。 // 比如 10ms調(diào)用一次,或用 ikcp_check確定下次調(diào)用 update的時間不必每次調(diào)用。 ikcp_update(kcp, millisec);
            4. 輸入一個下層數(shù)據(jù)包:
              // 收到一個下層數(shù)據(jù)包(比如UDP包)時需要調(diào)用: ikcp_input(kcp, received_udp_packet, received_udp_size);

            處理了下層協(xié)議的輸出/輸入后 KCP協(xié)議就可以正常工作了,使用 ikcp_send(kcp, ptr, size)來向遠端發(fā)送數(shù)據(jù)。而另一端使用ikcp_recv(kcp, ptr, size)來接收數(shù)據(jù)。

            協(xié)議配置

            協(xié)議默認模式是一個標準的 ARQ,需要通過配置打開各項加速開關(guān):

            • 工作模式

              int ikcp_nodelay(ikcpcb *kcp, int nodelay, int interval, int resend, int nc);
              • nodelay :是否啟用 nodelay模式,0不啟用;1啟用。
              • interval :協(xié)議內(nèi)部工作的 interval,單位毫秒,比如 10ms或者 20ms
              • resend :快速重傳模式,默認0關(guān)閉,可以設(shè)置2(2次ACK跨越將會直接重傳)
              • nc :是否關(guān)閉流控,默認是0代表不關(guān)閉,1代表關(guān)閉。
            普通模式:`ikcp_nodelay(kcp, 0, 40, 0, 0); 極速模式: ikcp_nodelay(kcp, 1, 10, 2, 1);
            • 最大窗口
              int ikcp_wndsize(ikcpcb *kcp, int sndwnd, int rcvwnd);
            該調(diào)用將會設(shè)置協(xié)議的最大發(fā)送窗口和最大接收窗口大小,默認為32.
            • 最大傳輸單元
            純算法協(xié)議并不負責(zé)探測 MTU,默認 mtu是1400字節(jié),可以使用ikcp_setmtu來設(shè)置該值。該值將會影響數(shù)據(jù)包歸并及分片時候的最大傳輸單元。
            • 最小RTO
            不管是 TCP還是 KCP計算 RTO時都有最小 RTO的限制,即便計算出來RTO為40ms,由于默認的 RTO是100ms,協(xié)議只有在100ms后才能檢測到丟包,快速模式下該值為30ms,可以手動更改該值:
            kcp->rx_minrto = 10;

            內(nèi)存分配器

            默認KCP協(xié)議使用 malloc/free進行內(nèi)存分配釋放,如果應(yīng)用層接管了內(nèi)存分配,可以用ikcp_allocator來設(shè)置新的內(nèi)存分配器,注意要在一開始設(shè)置:

            ikcp_allocator(my_new_malloc, my_new_free);

            前向糾錯

            為了進一步提高傳輸速度,下層協(xié)議也許會使用前向糾錯技術(shù)。需要注意,前向糾錯會根據(jù)冗余信息解出原始數(shù)據(jù)包。相同的原始數(shù)據(jù)包不要兩次input到KCP,否則將會導(dǎo)致kcp以為對方重發(fā)了,這樣會產(chǎn)生更多的ack占用額外帶寬。

            比如下層協(xié)議使用最簡單的冗余包:單個數(shù)據(jù)包除了自己外,還會重復(fù)存儲一次上一個數(shù)據(jù)包,以及上上一個數(shù)據(jù)包的內(nèi)容:

            Fn = (Pn, Pn-1, Pn-2)  P0 = (0, X, X) P1 = (1, 0, X) P2 = (2, 1, 0) P3 = (3, 2, 1)

            這樣幾個包發(fā)送出去,接收方對于單個原始包都可能被解出3次來(后面兩個包任然會重復(fù)該包內(nèi)容),那么這里需要記錄一下,一個下層數(shù)據(jù)包只會input給kcp一次,避免過多重復(fù)ack帶來的浪費。


            http://blog.csdn.net/kxg99/article/details/50696336

            如果不丟包那么 KCP()和 TCP性能差不多,KCP不會有任何優(yōu)勢,但是網(wǎng)絡(luò)會卡,造成卡的原因就是丟包和抖動,有同學(xué)在內(nèi)網(wǎng)這樣好的環(huán)境下沒有用任何丟包模擬直接跑,跑出來的數(shù)據(jù)是差不多的,但是放到公網(wǎng)上,放到3G/4G網(wǎng)絡(luò)情況下,差距就很明顯了,公網(wǎng)在高峰期有平均接近10%的丟包,wifi/3g/4g下更糟糕,這正是造成各種網(wǎng)絡(luò)卡頓的元兇。


            感謝asio-kcp的作者 zhangyuan 對 KCP 與 enet, udt做過的一次橫向評測,結(jié)論如下:

            • ASIO-KCP hasgood performace in wifi and phone network(3G, 4G).
            • Extra using 20% ~ 50% network flow for speed improvement.
            • 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 enetwhen 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.

            具體見:橫向比較這里。截取一段在網(wǎng)絡(luò)糟糕時,asio-kcp/enet的延遲數(shù)據(jù):

            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

            posted on 2017-12-08 16:22 思月行云 閱讀(1460) 評論(0)  編輯 收藏 引用 所屬分類: C\C++
            亚洲国产视频久久| 思思久久99热免费精品6| 久久se精品一区二区影院| 26uuu久久五月天| 久久人人爽人人澡人人高潮AV| 色播久久人人爽人人爽人人片AV| 亚洲熟妇无码另类久久久| 少妇久久久久久被弄高潮| 午夜不卡888久久| 久久久久久久久久免免费精品| 精品乱码久久久久久久| 精品久久久久久无码免费| 久久久久亚洲国产| 精品久久久久久久| 久久水蜜桃亚洲av无码精品麻豆 | 久久精品国产亚洲av麻豆图片| 久久亚洲私人国产精品| 国产高清国内精品福利99久久| 少妇高潮惨叫久久久久久| 成人精品一区二区久久久| 午夜精品久久久久久中宇| 久久久久人妻一区精品| 久久免费小视频| 久久99国内精品自在现线| 亚洲国产成人久久综合碰| 久久男人中文字幕资源站| 99久久婷婷国产综合亚洲| 久久久无码精品亚洲日韩蜜臀浪潮 | 久久人人爽人人爽人人片AV麻烦| 青青青国产成人久久111网站| 久久亚洲AV成人无码软件| 一级做a爰片久久毛片免费陪| 99热都是精品久久久久久| 99久久免费国产精品热| 精品精品国产自在久久高清 | 一本色综合网久久| 久久一区二区三区免费| 精品久久久久久无码人妻热| 激情五月综合综合久久69| 久久国产精品偷99| 亚洲国产香蕉人人爽成AV片久久 |