We usually play a lot of online games such as League of Legends / king of glory / PUBG, etc., you feel Caton often not because of your speed, but because of the delay caused by the network, such as LOL US service game server the United States, and you playing the United States serving LOL in central China China, then you may be a delay of about 300ms, because the network request from the US to China Central China need to go through a lot of routes, there will consume a lot of time, if happened packet loss, then delayed retransmission is needed will redouble grow, but more than 150ms delay often when they tend to affect your game experience.
The market there will be some game accelerator, they would place a server in a foreign country, to build a line to ensure that your request can be processed quickly, to reduce the delay of the game.
Now apply low-latency needs a lot of games and live broadcast are not normally re-use native TCP or UDP for transmission, but extended modified on the basis of both on, whichever is excellent, reliable transport such as TCP, UDP transmission speed.
Think about the time before learning TCP / UDP courses in computer networks, reliable transmission on the so-called TCP feeling very strange, really reliable to be too careful, and cautious when it comes to would have to mention this month of a new fan "this obviously super brave but too cautious."
Yesterday saw the first words, the blowout!
Coming back to TCP, it felt RTO retransmission timeout is doubled every time, if a package several time-outs, and that the next retransmission packet does not need a long time, this delay is not on the table? And all the package after its retransmission, he lost on a package needs to be retransmitted, excessive caution, although you can guarantee reliability, but it does not very friendly to us millisecond instant messaging applications and the like.
In this context, with many improvements based on TCP or UDP, and specifically for online games as well as audio and video call delay herein, this agreement say is KCP.
What is the protocol KCP
KCP is a fast and reliable protocol, TCP waste than can be 10% -20% of the cost of bandwidth in exchange for the average delay reduced by 30% -40%, and a maximum of three times to reduce delay transmission.
Pure algorithm, the transceiver is not responsible for the underlying protocols (e.g. UDP), the user himself needs to define the underlying transmission scheme of the packet data to be provided to the callback manner KCP.
Even require an external clock passed in, there will be no internal system call.
有一种叫KCPtun的实现，可以把我们的TCP请求转化成KCP+UDP在公网上传输。
KCP与TCP的比较
TCP是为流量设计的（每秒内可以传输多少KB的数据），讲究的是充分利用带宽。而 KCP是为流速设计的（单个数据包从一端发送到一端需要多少时间），以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。
TCP信道是一条流速很慢，但每秒流量很大的大运河，而KCP是水流湍急的小激流。
KCP有正常模式和快速模式两种，通过以下策略达到提高流速的结果：
- RTO翻倍vs不翻倍(RTO超时重传)：
TCP超时计算是RTOx2，这样连续丢三次包就变成RTOx8了，十分恐怖，而KCP启动快速模式后不x2，只是x1.5（实验证明1.5这个值相对比较好），提高了传输速度。
- 选择性重传 vs 全部重传：
TCP丢包时会全部重传从丢的那个包开始以后的数据，KCP是选择性重传，只重传真正丢失的数据包。
- 快速重传：
发送端发送了1,2,3,4,5几个包，然后收到远端的ACK: 1, 3, 4, 5，当收到ACK3时，KCP知道2被跳过1次，收到ACK4时，知道2被跳过了2次，此时可以认为2号丢失，不用等超时，直接重传2号包，大大改善了丢包时的传输速度。
- 延迟ACK vs 非延迟ACK：
TCP为了充分利用带宽，延迟发送ACK（NODELAY都没用），这样超时计算会算出较大 RTT时间，延长了丢包时的判断过程。KCP的ACK是否延迟发送可以调节。
- UNA vs ACK+UNA：
ARQ模型响应有两种，UNA（此编号前所有包已收到，如TCP）和ACK（该编号包已收到），光用UNA将导致全部重传，光用ACK则丢失成本太高，以往协议都是二选其一，而 KCP协议中，除去单独的 ACK包外，所有包都有UNA信息。
- 非退让流控：
KCP normal mode, like TCP use a fair compromise law that send window size is determined by: send buffer size, the receiver remaining receive buffer size, packet loss and slow start concede four elements of the decision. However, when transmitting high timeliness requirements of small data, to selectively control the transmission frequency by skipping the configuration steps, only the first two. At the expense of fairness and part of the cost of bandwidth utilization, in exchange for the effect of driving BT can smooth transmission.
If the network never card, that KCP / TCP performance is similar, but the network itself is unreliable, packet loss and jitter can not be avoided (or even doing a variety of reliable protocol). This intranet is almost ideal environment in direct comparison, almost everyone, but put the public Internet, into 3G / 4G network under the circumstances, or in the use of network packet loss simulation, the gap is quite clear. At the peak of the public have an average of close to 10% of the loss, wifi / 3g / 4g under worse, which will allow the transmission change card.
Maybe you play a lot of games, or use the accelerator, we are using the KCP to reduce latency.
how to use
Here is the address on GitHub of KCP, which only need to ikcp.c, ikcp.h two files into your protocol stack can be used.
https://github.com/skywind3000/kcp
KCP created objects:
// 初始化 kcp对象，conv为一个表示会话编号的整数，和tcp的 conv一样，通信双
// 方需保证 conv相同，相互的数据包才能够被认可，user是一个给回调函数的指针
ikcpcb *kcp = ikcp_create(conv, user);Sets the callback function:
// KCP的下层协议输出函数，KCP需要发送数据时会调用它
// buf/len 表示缓存和长度
// user指针为 kcp对象创建时传入的值，用于区别多个 KCP对象
int udp_output(const char *buf, int len, ikcpcb *kcp, void *user)
{
....
}
// 设置回调函数
kcp->output = udp_output;Cycle call update:
// 以一定频率调用 ikcp_update来更新 kcp状态，并且传入当前时钟（毫秒单位）
// 如 10ms调用一次，或用 ikcp_check确定下次调用 update的时间不必每次调用
ikcp_update(kcp, millisec);A lower input data packet:
// 收到一个下层数据包（比如UDP包）时需要调用：
ikcp_input(kcp, received_udp_packet, received_udp_size);After processing the lower layer protocol of the input / output protocol KCP can work normally, used to send data to the remote ikcp_send. And the other end in ikcp_recv (kcp, ptr, size) to receive data.