深入KCP源码：一个2000行C实现，凭什么比TCP快40%？逐行拆解ARQ算法精髓
面试官问我：“你们项目里为什么要用KCP？TCP不是已经很可靠了吗？”
我说因为我们游戏要求延迟100ms以内，TCP太慢了。他追问："TCP慢在哪？"我说TCP有三次握手、有拥塞控制、有慢启动……说了一堆教科书上的东西。
他皱了皱眉说：“这些我知道。我问的是：KCP靠什么比TCP快40%？你能从源码层面解释吗？”
那一刻我愣住了。
我用KCP用了一年多，只会调用ikcp_send和ikcp_recv这几个API，对它到底是怎么实现的、为什么比TCP快，说实话一知半解。后来我花了两周时间把KCP那2000多行C代码逐行读了一遍，才真正理解了它快的原因——不是什么黑科技，而是在ARQ（自动重传请求）协议的每个关键环节上都做了针对性优化，用10%-20%的带宽浪费换取了30%-40%的延迟降低和3倍的最大延迟改善。
今天我把这些心得整理成文，希望能帮你在面试中不再愣住。
一、先搞清楚：TCP到底"慢"在哪？
在讲KCP快在哪之前，我们得先搞清楚TCP慢在哪。这个问题看似简单，但很多人答得很表面。
TCP是一个可靠的传输协议，它的设计目标是保证数据能够完整、有序、无差错地从发送端到达接收端。为了实现这个目标，TCP做了很多事情：
- 三次握手建立连接：发送数据之前必须先建立连接，这就是三次握手的开销
- 四次挥手释放连接：传完数据还要优