A brief introduction to KCP protocol

Part 01

What is KCP Protocol

KCP is an open source fast and reliable ARQ protocol. It can reduce the average delay by 30%-40% and the maximum delay by three times at the cost of wasting 10%-20% of the bandwidth compared to TCP. KCP is a pure algorithm implementation and is not responsible for the sending and receiving of the underlying protocol (such as UDP). Users define the sending method of the underlying data packet and provide it to KCP in the form of callback. There will not be any system calls inside, including the clock, which needs to be passed in from the outside.

The entire KCP protocol consists of only two source files, ikcp.h and ikcp.c, which can be easily integrated into the user's own protocol stack according to their needs.

So the KCP protocol can be regarded as an application layer protocol, and the underlying layer uses the UDP protocol. However, strictly speaking, KCP is not a network transmission protocol. It is a reliable transmission algorithm written for UDP. It transplants the main reliable transmission mechanism of TCP to UDP, making UDP more reliable.

Part 02

KCP Protocol Features   

TCP is designed for traffic (how many KB of data can be transmitted per second), and it emphasizes full utilization of bandwidth. KCP is designed for flow rate (how long it takes for a single data packet to be sent from one end to the other end), and it wastes 10%-20% of bandwidth in exchange for a transmission speed that is 30%-40% faster than TCP. If the TCP channel is likened to a large canal with a slow flow rate but a large flow per second, then KCP is a small rapids with turbulent water. KCP has two modes: normal mode and fast mode, and the following strategies are used to achieve the result of increasing the flow rate.

1. RTO does not double

RTO (Retransmission TimeOut) is the retransmission timeout. The TCP timeout calculation is RTOx2. So if the packet is lost three times in a row, it becomes RTO×8. After KCP starts the fast mode, it is not x2, but x1.5, which improves the transmission speed.

2. Select retransmission

When TCP loses packets, it will retransmit all data after the packet loss, while KCP is a selective retransmission, which only retransmits the data packets that are actually lost.

3. Fast retransmission

TCP retransmission mode timeout retransmission: retransmission occurs when the specified RTO is exceeded.

Fast retransmission: After receiving 3 redundant ACKs, retransmit directly without waiting for RTO. For example, after the sender sends 1, 2, 3, 4, 5... packets, and then receives ACKs from the remote end: 1, 3, 4, when receiving ACK3, KCP knows that 2 was skipped once, and when receiving ACK4, it knows that 2 was skipped twice, and when receiving Ack5, it can be considered that 2 has been lost, and retransmit 2 directly without waiting for RTO, which greatly improves the transmission speed when packets are lost.

4. Delayed ACK vs. Non-delayed ACK

In the continuous ARQ protocol, TCP does not respond to each data in a series once, but delays sending ACK in order to make full use of the bandwidth. This delay in sending ACK leads to a longer RTT time and prolongs the judgment process when the packet is lost. The delay in sending ACK in KCP can be adjusted.

5. UNA vs ACK+UNA

There are two types of ARQ model responses, UNA (all packets before this number have been received, such as TCP) and ACK (the packet with this number has been received). Using only UNA will result in all packets being retransmitted, while using only ACK will result in too high a loss cost. Previous protocols have always chosen one of the two. TCP uses the UNA mode, which has the problem of all packets being retransmitted if they are lost; KCP has a separate ACK, and both the data packet and the ACK packet carry UNA information, effectively reducing the ACK loss cost.

6. Non-yielding flow control

KCP normal mode uses the same fair concession rule as TCP, that is, the sending window size is determined by the sending buffer size, the remaining receiving buffer size at the receiving end, packet loss concession, and slow start. However, when transmitting small data with high timeliness requirements, you can choose to skip the last two steps through configuration and only use the first two steps to control the sending frequency. This sacrifices some fairness and bandwidth utilization in exchange for smooth transmission.

Part 03

KCP Application Cases  

Business case for KCP protocol:

• Tomorrow Never Dies: Game K17's Tomorrow Never Dies (Google Play) uses KCP to accelerate game messages, allowing players around the world to connect to the Internet smoothly.
• Fairy Wars: 4399's MOBA game, uses KCP to optimize game synchronization.
• CC: NetEase CC uses kcp to accelerate video streaming, effectively improving fluency.
• BOBO: NetEase BOBO uses kcp to accelerate the streaming of anchors.
• Yunfan Acceleration: Use KCP to accelerate file transfer and video streaming, and optimize the smoothness of Taiwan anchors' streaming.
• SpatialOS: A massively multiplayer distributed game server engine, the successor to BigWorld, using KCP to accelerate data transmission.

The advantage of KCP will only be shown in a network environment with a high packet loss rate. If there is no packet loss, the efficiency difference between TCP and KCP is not significant, and it may just be that the establishment/closing of connections is missing. Generally speaking, applications transmitted on the public network can use it, especially programs with high real-time requirements, such as games with frequent interactions between the client and the server.