kcp
kcp copied to clipboard
skywind3000
比 TCP浪费10%-20%的带宽
在局域网下你直接用UDP就好了，不需要用KCP。
Founder of http://slicelayer.com
On Sun, Jun 26, 2016 at 8:07 AM, happy365 [email protected] wrote:
请问下：在 局域网，下层用udp的话，传输的速度可以超过tcp呢？如何设置参数?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/skywind3000/kcp/issues/25#issuecomment-228576820, or mute the thread https://github.com/notifications/unsubscribe/AC9tC4lS0nM8d46DOzR8tTvinZRlsObCks5qPcK_gaJpZM4IrUB0 .
带宽，延迟，两个数值是天平的两端，不可能同时提高，取舍而已。tcp选择照顾带宽，kcp选择底延迟（面向游戏或者其他高速传输应用），如此而已。“带宽又大，延迟又低” 哪里有那么好的事情啊。
@skywind3000 1>每秒传输的数据越多，延迟就越小; 相反的，在上下行带宽允许的范围内，延迟小，那每秒传输的数据不是越多吗？ 2>我有测试kcp, 在公网上，用kcp+udp 传输确定比较好，局域网: ikcp_nodelay(kcp, 1, 10, 16, 1); //16是windows size/2 速度大概在1.5MBytes/s左右
你这根本就是观念错误啊，我readme就写的很清楚了，每秒传送多少字节，叫做“带宽”（bandwidth），数据从一端到另外一端叫做延迟（latency），给你举个例子， 运河：河面很宽，河水很深，但是水流很慢，扔一片叶子下去，你看他在水上飘着的速度和人走路差不多 激流：水流很窄，落差很大，每秒钟流过的水量（立方米）没有运河那么多，但是流速惊人，扔片叶子下去，转眼就飘走了。 你说的 MB/s 只是：流量（单位体积每秒），不是速度。
基本概念都没搞清楚啊。
是否可以参考
https://github.com/v2ray/manual/blob/master/zh_cn/chapter_03/kcp.md
https://www.v2ray.com/zh_cn/chapter_02/01_overview.html
思路进一步优化 KCP的能力呢？
就好像 传说中的FastTcp 一样。。。。
鱼和熊掌 尽可能地兼得。
扫了一眼，那几个 patch 修改提高有限，你可以自己测试，应该不会有明显的区别， 你当然可以按照你想的修改，只是修改要基于 benchmark，是否能在benchmark上反应出成绩 只是所谓得兼，这是个物理和逻辑问题，FastTcp 也只是类似 kcp 一样，把传输从gentle变的流氓一点。
谢谢 老大回复 但是 不正是 流氓了那么一点点 所以 KCP和 fasttcp 之类的才能脱颖而出....慢慢流行.... 当然啦 咱也不能抄别人的成果，何况对方也没主动贡献代码。 就当我没说吧 其实我还是够用就行了 加油吧 老大，希望KCP 越来越好!
更小的协议头
原生 KCP 协议使用了 24 字节的固定头部，而 mKCP 修改为数据包 18 字节，确认（ACK）包 12 字节。 更小的头部有助于躲避特征检查，并加快传输速度。 另外，原生 KCP 的单个确认包只能确认一个数据包已收到，也就是说当 KCP 需要确认 100 个数据已收 到时，它会发出 24 * 100 = 2400 字节的数据。其中包含了大量重复的头部数据，造成带宽的浪费。 mKCP 会对多个确认包进行压缩，100 个确认包只需要 12 + 2 + 100 * 8 = 814 字节，相当于原生的三分之一。
确认包重传 原生 KCP 协议的确认（ACK）包只发送一次，如果确认包丢失，则一定会导致数据重传，造成不必要的带宽浪费。而 mKCP 会以一定的频率重发确认包，直到发送方确认为止。单个确认包的大小为 22 字节，相比起数据包的 1000 字节以上，重传确认包的代价要小得多。
虽然 .... 但是我觉得 这文章中还是点出了KCP的一点点小缺陷的 再次谢谢老大回复 不管怎么说 老大还是很厉害的 发扬和广大了KCP 感觉造福了 不少人类 哈哈
关于头部尺寸之所以这么设计是考虑过的，把kcp头部从24字节缩小成18字节无外乎，去掉conv验证，缩小size比特位之类的东西，再我看来，意义不大，因为本身IP有20个字节包头，UDP有8字节包头，你自己的协议肯定也会在UDP头加入8个左右的字节。合起来加上kcp的24字节共计 60个字节，而现在删除conv验证，缩小size之类的事情，也只能带来6个字节的改变：60->54，我并没有见到本质性的提高，反而伤害了kcp逻辑的完整性，没有太大意义。
至于ack的确认包，其实在udt里就引入了，叫做ack2，无数次试验比较，udt的传输延迟在kcp面前并没有优势。所以 ack的二次确认是否真有延迟上的改善的余地，并没有明显的实验数据上的支撑，因为本身ack不过来，发送方也会持续不断的重发源数据。
直接IP发送没有意义，手机上做不到，台式机下要管理员权限。你也只节省了8字节的udp头，还有20字节的ip头等着你呢，况且你节省了8字节的udp头，checksum这个事情没法做了，还还得在你自己的协议里做一次checksum，又是四个字节，到头来你只能节省4个字节，从28变成24字节的包头，要付出如此的代价，还要增加运行环境的限制，把自己变残废，有意思么？
