----------------------------------------
源碼地址：https://github.com/KumoKyaku/KCP
-----------------------------------------
- 問題來了：KCP接收端如何拼包，以確保可靠性傳輸？
- 轉換問題：KCP源碼中幾個關鍵的發送接收隊列與緩沖的作用是什么？
KCP Send ，對用戶的數據根據mss值進行分片，然后將分片后的數據放入snd_queue。
KCP Flush，每次被調用的時候遍歷出隊snd_queue（條件為snd_nxt < snd_una + cwnd_）。
對每個seg的sn與una編號，cmd = IKCP_CMD_PUSH，進行初始化后，放入snd_buf。
之后立即對current_, segment.resendts進行比較，決定每個元素是否重傳發送，
KCP Input，如果cmd為PUSH，則記錄每個包的sn進acklist隊列。
然后新建一個KcpSegment，將數據考入其中，再放入rcv_buf
緊接着，循環遍歷rcv_buf，看隊頭是不是我們恰恰想要的rcv_nxt，如果是則加入rcv_queue中。
KCP PeekSize，rcv_queue隊頭元素的frg記錄着發送方此次分包的數量，若rcv_queue次數的隊列元素個數等於它，則說明所有的分包都已收到。
KCP Recv，如若PeekSize返回大於0，則可以此函數取一個完整的UDP數據包，此函數內部會對rcv_queue內所有元素的數據進行解包merge，
最后清除掉rcv_queue。
---------------------------------------------
- 問題來了：他的超時重傳機制有何優勢？
TCP滑動窗口與KCP窗口機制的比較
1、TCP的滑動窗口，采用累積確認的方式，對按序到達的最后一個分組發送確認，如發送方發送了10個分組，第3個分組丟失了，則接收方只能
對前2個分組發送確認，而發送方必須把3~8個分組全部重傳。如果網絡情況不好，這可能會帶來不好的影響。
2、KCP的窗口，接收方會為發送方的每個分組都發送回復（sn），也會采用TCP模式對若干連續分組統一回復（una），這樣的混合模塊，增加了
帶寬負擔，但是在網絡情況不好的時候，可以減少發送方的重傳負擔。
-----------------------------------------
- 問題來了：怎么才能讓服務器發送一個帶ACK或UNA的包？
答案：接收方的 KCP acklist在每次收到對方的數據包時，會收集sn序列號，然后Flush的時候，封裝成ACK包回給對方。