• <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年5月>
            30123456
            78910111213
            14151617181920
            21222324252627
            28293031123
            45678910


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

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            相冊

            Awesome

            Blog

            Book

            GitHub

            Link

            搜索

            •  

            積分與排名

            • 積分 - 215465
            • 排名 - 118

            最新評論

            閱讀排行榜

            https://www.cnblogs.com/yuanyifei1/p/6846310.html

              kcp協議是傳輸層的一個具有可靠性的傳輸層ARQ協議。它的設計是為了解決在網絡擁堵情況下tcp協議的網絡速度慢的問題。kcp力求在保證可靠性的情況下提高傳輸速度。kcp協議的關注點主要在控制數據的可靠性和提高傳輸速度上面,因此kcp沒有規定下層傳輸協議,一般用udp作為下層傳輸協議,kcp層協議的數據包在udp數據報文的基礎上增加控制頭。當用戶數據很大,大于一個udp包能承擔的范圍時(大于mss),kcp會將用戶數據分片存儲在多個kcp包中。因此每個kcp包稱為一個分片。

              為了提供可靠性,kcp采用了重傳機制。為實現重傳機制,kcp為每個分片分配一個唯一標識,接收方收到一個包后告知發送方接到的包的序號,發送方接到確認后再繼續發送。而如果發送方在一定時間內(超時重傳時間)沒有接到確認,就說明數據包丟失了,發送方需要重傳丟失的數據包,所以發送方會把待確認的數據緩存起來,方便重傳。

              停等的重傳機制發送一個包后必須等待確認后再發下一個包,傳輸速度較慢,所以為了提高發送速度,發送方可以不必再每發送一個包后就進行等待確認,而是可以發送多個包出去,然后等待接收方一一確認。又由于接收方不可能同時處理無限多的數據,因此需要限制發送方往網絡中發送的數據數量。因此接收方限制發送方在未收到確認之前只能發送wnd大小的數據,這個機制叫做滑動窗口機制。kcp采用滑動窗口機制來提高發送速度。由于UDP在網絡中的傳輸是不可靠的,因此會出現丟包和包的亂序。kcp是可靠的保證數據有序的協議,所以為了糾正包的亂序。接收方維護一個接收窗口。接收窗口有一個起始序號rcv_nxt以及尾序號rcv_nxt+rcv_wnd。如果接收窗口收到序號為rcv_nxt的分片那么rcv_nxt就加一,形象一點的說法是滑動窗口右移,并把該數據放入接收隊列供應用層取用。如果收到的數據在窗口范圍內但不是rcv_nxt那么就把數據保存起來,等收到rcv_nxt序號的分片時再一并放入接收隊列供應用層取用。

              當網絡擁堵嚴重時,會發生丟包,丟包發生時kcp為了保證可靠性需要重傳數據。而發送方需要判斷什么時候發生了丟包,以及丟了哪些包。為了解決這個問題,發送方為緩存隊列中的每個包設置了包序號和超時重傳時間。當檢測到當前時間超過了分片的超時重傳時間,該分片還沒有得到確認時就會觸發該分片的超時重傳

              數據在網絡中的傳輸時間是不固定的,因此超時重傳時間比較長。而為了盡早地判斷出數據包的丟失,kcp引入了快速重傳機制。快速重傳機制工作原理是,當發送方發送了n,n+1,n+2...等等包出去后,接收方沒有接收到n,而接收到n+1,n+2..等等n號包之后的包,這時因為n號包之后的包都已經接收到了,而n號包還沒有接收到,所以可以認為n號包已經丟失了,告知發送方可以進行快速重傳。kcp為了支持快速重傳,接收方需要告訴發送方,哪些包已經成功收到了,哪些包沒有收到。因此接收方返回發送方的確認數據(ack)中包含以下信息:接收窗口左端的序號rcv_nxt,接收到的大于rcv_nxt的包序號sn。rcv_nxt的含義是接收方已經成功按順序接收了rcv_nxt序號之前的所有包,大于rcv_nxt的序號sn表示的是在接收窗口內的不連續的包。發送方接收到接收方發過來的數據時,首先解析rcv_nxt,把發送緩存中所有小于rcv_nxt序號的包全部移除掉(因為這些包全都都已經正確接收了)。然后再解析sn,遍歷發送緩存,找到所有序號小于sn的包,這些包就是可能在網絡中已經丟掉了的包,只是可能,因為有可能這些包只是擁堵在了網絡中,需要更長的時間到達,所以這里我們設置一個快速重傳的門限,對每個分片維護一個快速重傳的計數,每收到一個ack解析sn后找到了一個分片,就把該分片的快速重傳的計數加一,如果該計數達到了快速重傳門限,那么就認為該分片已經丟失,可以觸發快速重傳,該門限值在kcp中可以設置,tcp中是3。

              丟包發生時,由于滑動窗口的存在,假設第n個包丟失了,但是此時n+1,n+2號包卻已經傳輸成功了,此時最好只重傳丟失的n號包,而不重傳成功傳輸的n+1,n+2號包,這個機制叫做選擇重傳,選擇重傳的關鍵在于接收方要告知發送方哪些包已經收到了,哪些包沒有收到,為了最小化數據量,接收方可以告訴發送方哪些包已經按序收到了,哪些包是收到的但是不連續。所以返回的ack中包含rcv_nxt和sn。rcv_nxt代表收到的所有連續的包,sn代表哪些不連續的包收到了,那么根據這兩個參數可以計算出來沒有收到的包的序號。

              當網絡實在很擁堵的時候(一般由于網絡消息太多,堵車了),kcp會限制發送方發送的數據量,這叫做擁塞控制,擁塞控制就是告訴發送方,網絡太堵了,應該少發一些數據,因此在滑動窗口的機制上引入了擁塞窗口,也就是說發送發發送的數據不得超過擁塞窗口,擁塞窗口的大小會隨網絡情況而變快,網絡快擁塞窗口就大,反之同理。

              那么擁塞窗口應該等于多少呢?解決這一問題的原則是,讓網絡充分被利用,但是不能堵塞,這里引入了慢啟動機制,慢啟動也就是控制擁塞窗口從0開始增長,隨著數據不斷地成功傳輸,擁塞窗口逐漸增大,直至達到飽和,也就是網絡的收發平衡。為了快速達到網絡的收發平衡,擁塞窗口采用倍數增長。也就是每成功發送一個數據擁塞窗口加一,舉個例子,窗口大小為1時,發送一個數據,成功后窗口變成2,之后發送兩個數據出去,成功接收后窗口大小變為4。為了方便讓更多的用戶連入網絡時,網絡能有足夠的流量提供給用戶,還可以設置擁塞門限,擁塞門限值就是當用戶擁塞窗口快速增長到門限值后就減慢增加速度,緩慢增長,騰出流量給其它用戶。

              但是當網絡很擁堵的情況下,導致發送數據出現重傳時,這時說明網絡中消息太多了,用戶應該減少發送的數據,也就是擁塞窗口應該減小。怎么減小呢,在快速重傳的情況下,有包丟失了但是有后續的包收到了,說明網絡還是通的,這時采取擁塞窗口的退半避讓,擁塞窗口減半,擁塞門限減半。減小網絡流量,緩解擁堵。當出現超時重傳的時候,說明網絡很可能死掉了,因為超時重傳會出現,原因是有包丟失了,并且該包之后的包也沒有收到,這很有可能是網絡死了,這時候,擁塞窗口直接變為1,不再發送新的數據,直到丟失的包傳輸成功。

              在上述原理之下,kcp為了提高傳輸速度,還可以有許多選項供用戶選擇:

                kcp的擁塞控制可以取消

                ack回復可以設置成無延遲ack回復

                kcp的快速重傳門限可以控制

              總之,kcp采取一系列措施盡量提高網絡傳輸速率,在網絡實時性和可靠性要求比較高的場景下可以考慮kcp協議代替tcp協議。

            posted on 2017-12-09 14:00 思月行云 閱讀(1743) 評論(0)  編輯 收藏 引用 所屬分類: C\C++
            久久精品国产男包| 久久国产免费| 99精品久久精品一区二区| 99999久久久久久亚洲| 国产亚洲成人久久| 亚洲中文久久精品无码ww16 | 中文精品99久久国产| 日本欧美久久久久免费播放网 | 久久精品人人做人人爽电影| 久久996热精品xxxx| 久久国产色av免费看| 伊人色综合久久| 久久精品一本到99热免费| 久久国产成人| 青青青青久久精品国产h| 99久久99久久精品国产片果冻| 色综合久久久久| 久久婷婷国产综合精品| 久久午夜免费视频| 久久夜色撩人精品国产| 青青青青久久精品国产h| 久久精品aⅴ无码中文字字幕重口| 久久久不卡国产精品一区二区| 99久久99这里只有免费的精品| 久久精品国产久精国产一老狼| 婷婷久久综合九色综合九七| 久久福利片| 久久99精品久久久久久秒播| 久久综合九色综合欧美狠狠| 久久精品亚洲一区二区三区浴池 | Xx性欧美肥妇精品久久久久久| 久久精品午夜一区二区福利| 国产A三级久久精品| 久久久久亚洲精品日久生情| 性做久久久久久久久老女人| 欧美亚洲日本久久精品| 久久久久国产视频电影| 亚洲国产天堂久久综合| 7777精品久久久大香线蕉 | 无码人妻少妇久久中文字幕| 久久影视综合亚洲|