-
Notifications
You must be signed in to change notification settings - Fork 2.5k
EN_KCP Feature
The design of TCP focus on transport bandwidth, to transmit as more data as possible. While KCP is designed for low latency, to transmit as fast as possible, for some special use scenario, for example, realtime communication, low latency message system. KCP transmit faster than TCP(30%-40%), use ARQ which cost 10%-20% bandwidth. KCP support normal and fast mode, use bellow algorithms to decrease the latency:
When retransmission, TCP use exponential backoff(Karn/Partridge Algorithm) for congestion avoidance, which means the RTOx2, so the timeout will be very large when network is heavy, for example, the RTO will change to RTOx8 for just drop 3 segments. KCP use different algorithm, use RTOx1.5(not RTOx2), it's better in practice.
For retransmission in TCP, all the data after the lost segment will be retransmitted in practice(for example, ACK lost without SACK, or maybe only retransmit one packet but network is so heavy that more packets are retransmitted), while KCP only retransmit the really dropped part of segment(KCP use more ACK, so the lost of ACK is less than TCP).
For example, the sender has sent segments 1,2,3,4,5, then got the ACK message from peer 1,3,4,5. When got ACK 1,3, KCP notice the segment 2 maybe dropped; when got ACK 1,3,4, the segment 2 almost dropped and KCP will directly retransmit segment 2 without wait util timeout. This algorithm can improve the transport speed when network is heavy and segment loss occurs.
TCP will try to reply ACK as late as possible(even TCP_NODELAY), which will cause large RTT and RTO, it need more time to find out whether segments are lost. Certainly it causes larger latency, especially for heavy network. KCP allows to config to send ACK immediately without any delay.
There are two kinds of ARQ(Automatic Repeat reQuest) model responses: UNA (All segments before this number received, such as TCP) and ACK (The segment with this number received). For example, sender send 1,2,3,4,5 while receiver got 1,2,4,5. All segments will be retransmit for UNA, that is, receiver will reply UNA 3 two times when got 4,5, and sender will retransmit 3,4,5. It cost too much when only use ACK, receiver will reply ACK 1,2,4,5 for each received segment. KCP use better model of UNA and ACK, each segment use UNA but there is ACK segment when segment loss occurs.
In normal mode, KCP follows the congestion control algorithm as TCP, that is, the cwnd depends on: the size of send buffer, the size of peer receive buffer, congestion window backoff and slow startup. However, when transmitting small or realtime segments, KCP can ignore the last two factors, which means we won't use window backoff, but try to send more segments even though the network is heavy. It's impressive to fast transmit in heavy netowrk when segment loss occurs.