Release Powered MIT licensed Build Status Go Report Card Downloads Docker

kcptun

Disclaimer: kcptun maintains a single website — github.com/xtaci/kcptun. Any websites other than github.com/xtaci/kcptun are not endorsed by xtaci.

• Requirements
• QuickStart
• Building from source
• Performance
• Basic Tuning Guide
  • To Improve Throughput
  • To Improve Latency
  • Head-of-Line Blocking (HOLB)
  • Slow Devices
• Expert Tuning Guide
  • Overview
  • Multiport Dialer
  • Rate Limit and Pacing
  • Forward Error Correction
  • DSCP
  • Cryptoanalysis
  • Quantum Resistance
  • Memory Control
  • Compression
  • SNMP
• FAQ
• References

NOTE: If you are using KVM, ensure that the guest OS supports AES instructions cpuinfo

Download:

curl -L https://raw.githubusercontent.com/xtaci/kcptun/master/download.sh | sh

Increase the number of open files on your server, as:

ulimit -n 65535, or write it in ~/.bashrc.

Suggested sysctl.conf parameters for Linux to improve UDP packet handling:

net.core.rmem_max=26214400 // BDP - Bandwidth Delay Product
net.core.rmem_default=26214400
net.core.wmem_max=26214400
net.core.wmem_default=26214400
net.core.netdev_max_backlog=2048 // Proportional to -rcvwnd

FreeBSD-related sysctl settings can be found here: https://github.com/xtaci/kcptun/blob/master/dist/freebsd/sysctl_freebsd

You can also increase the per-socket buffer by adding the parameter (default 4MB):

-sockbuf 16777217

For slow processors, increasing this buffer is CRITICAL for proper packet reception.

Download the appropriate binary from the precompiled Releases.

KCP Client: ./client_darwin_amd64 -r "KCP_SERVER_IP:4000" -l ":8388" -mode fast3 -nocomp -autoexpire 900 -sockbuf 16777217 -dscp 46
KCP Server: ./server_linux_amd64 -t "TARGET_IP:8388" -l ":4000" -mode fast3 -nocomp -sockbuf 16777217 -dscp 46

The above commands will establish a port forwarding channel for port 8388/tcp as follows:

Application -> KCP Client(8388/tcp) -> KCP Server(4000/udp) -> Target Server(8388/tcp)

which tunnels the original connection:

Application -> Target Server(8388/tcp)

OR START WITH THESE COMPLETE CONFIGURATION FILES: client --> server

$ git clone https://github.com/xtaci/kcptun.git
$ cd kcptun
$ ./build-release.sh
$ cd build

All precompiled releases are generated using the build-release.sh script.

fast.com

bandwidth

flame

Practical bandwidth graph with parameters: -mode fast3 -ds 10 -ps 3

Q: I have a high-speed network link. How can I maximize bandwidth?

A: Increase -rcvwnd on the KCP Client and -sndwnd on the KCP Server simultaneously and gradually. The minimum of these values determines the maximum transfer rate of the link using the formula wnd * mtu / rtt. Then test your connection by downloading content to verify it meets your requirements. (The MTU can be adjusted using the -mtu parameter.)

Q: I'm using kcptun for gaming and want to minimize latency.

A: Latency spikes often indicate packet loss. You can reduce lag by adjusting the -mode parameter.

For example: -mode fast3

Retransmission aggressiveness/responsiveness for embedded modes:

fast3 > fast2 > fast > normal > default

When all streams are multiplexed over a single physical channel, Head-of-Line Blocking (HOLB) can occur. You can mitigate this by tuning the following parameters:

• -smuxbuf: Sets the total buffer size for the multiplexer (default: 4MB). Increasing this value (e.g., -smuxbuf 8388608 for 8MB) can reduce the chance of HOLB, but will increase memory usage.

For versions >= v20190924, it is recommended to use smux v2:

• -smuxver 2: Enables smux v2 (must be set identically on both client and server).
• -streambuf: Limits the maximum buffer size per stream, in bytes (e.g., -streambuf 2097152 for 2MB per stream).

Recommended usage:

1. If you experience HOLB, first try increasing -smuxbuf to 8MB or higher.
2. For finer memory control, enable smux v2 and use -streambuf to limit per-stream memory usage.
3. The -smuxver parameter must be identical on both client and server, otherwise the connection will fail.
4. Limiting -streambuf on the receiver side applies back-pressure to the sender, preventing buffer overflow along the link.

Example:

./client_linux_amd64 -r "server_ip:4000" -l ":8388" -smuxver 2 -smuxbuf 8388608 -streambuf 2097152

This command sets the total smux buffer to 8MB and limits each stream to 2MB.

kcptun uses Reed-Solomon Codes for packet recovery, which requires substantial computational resources. Low-end ARM devices may experience performance issues with kcptun. For optimal performance, a multi-core x86 server CPU such as AMD Opteron is recommended. If you must use ARM routers, it's advisable to disable FEC and use salsa20 for encryption.

How to optimize for slow devices:

• Disable FEC: Set both --datashard 0 --parityshard 0 on client and server to turn off Forward Error Correction.
• Enable salsa20 encryption: Use --crypt salsa20 on both client and server for a lightweight cipher.

Example:

./client_linux_amd64 ... --datashard 0 --parityshard 0 --crypt salsa20
./server_linux_amd64 ... --datashard 0 --parityshard 0 --crypt salsa20

These settings can significantly reduce CPU usage and improve performance on ARM routers and other low-end hardware.

params

$ ./client_freebsd_amd64 -h
NAME:
 kcptun - client(with SMUX)
USAGE:
 client_freebsd_amd64 [global options] command [command options] [arguments...]
VERSION:
 20251124
COMMANDS:
 help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
 --localaddr value, -l value local listen address (default: ":12948")
 --remoteaddr value, -r value kcp server address, eg: "IP:29900" a for single port, "IP:minport-maxport" for port range (default: "vps:29900")
 --key value pre-shared secret between client and server (default: "it's a secrect") [$KCPTUN_KEY]
 --crypt value aes, aes-128, aes-128-gcm, aes-192, salsa20, blowfish, twofish, cast5, 3des, tea, xtea, xor, sm4, none, null (default: "aes")
 --mode value profiles: fast3, fast2, fast, normal, manual (default: "fast")
 --QPP enable Quantum Permutation Pads(QPP)
 --QPPCount value the prime number of pads to use for QPP: The more pads you use, the more secure the encryption. Each pad requires 256 bytes. (default: 61)
 --conn value set num of UDP connections to server (default: 1)
 --autoexpire value set auto expiration time(in seconds) for a single UDP connection, 0 to disable (default: 0)
 --scavengettl value set how long an expired connection can live (in seconds) (default: 600)
 --mtu value set maximum transmission unit for UDP packets (default: 1350)
 --ratelimit value set maximum outgoing speed (in bytes per second) for a single KCP connection, 0 to disable. Also known as packet pacing. (default: 0)
 --sndwnd value set send window size(num of packets) (default: 128)
 --rcvwnd value set receive window size(num of packets) (default: 512)
 --datashard value, --ds value set reed-solomon erasure coding - datashard (default: 10)
 --parityshard value, --ps value set reed-solomon erasure coding - parityshard (default: 3)
 --dscp value set DSCP(6bit) (default: 0)
 --nocomp disable compression
 --sockbuf value per-socket buffer in bytes (default: 4194304)
 --smuxver value specify smux version, available 1,2 (default: 2)
 --smuxbuf value the overall de-mux buffer in bytes (default: 4194304)
 --framesize value smux max frame size (default: 8192)
 --streambuf value per stream receive buffer in bytes, smux v2+ (default: 2097152)
 --keepalive value seconds between heartbeats (default: 10)
 --closewait value the seconds to wait before tearing down a connection (default: 0)
 --snmplog value collect snmp to file, aware of timeformat in golang, like: ./snmp-20060102.log
 --snmpperiod value snmp collect period, in seconds (default: 60)
 --log value specify a log file to output, default goes to stderr
 --quiet to suppress the 'stream open/close' messages
 --tcp to emulate a TCP connection(linux)
 -c value config from json file, which will override the command from shell
 --pprof start profiling server on :6060
 --help, -h show help
 --version, -v print the version
$ ./server_freebsd_amd64 -h
NAME:
 kcptun - server(with SMUX)
USAGE:
 server_freebsd_amd64 [global options] command [command options] [arguments...]
VERSION:
 20251124
COMMANDS:
 help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
 --listen value, -l value kcp server listen address, eg: "IP:29900" for a single port, "IP:minport-maxport" for port range (default: ":29900")
 --target value, -t value target server address, or path/to/unix_socket (default: "127.0.0.1:12948")
 --key value pre-shared secret between client and server (default: "it's a secrect") [$KCPTUN_KEY]
 --crypt value aes, aes-128, aes-128-gcm, aes-192, salsa20, blowfish, twofish, cast5, 3des, tea, xtea, xor, sm4, none, null (default: "aes")
 --QPP enable Quantum Permutation Pads(QPP)
 --QPPCount value the prime number of pads to use for QPP: The more pads you use, the more secure the encryption. Each pad requires 256 bytes. (default: 61)
 --mode value profiles: fast3, fast2, fast, normal, manual (default: "fast")
 --mtu value set maximum transmission unit for UDP packets (default: 1350)
 --ratelimit value set maximum outgoing speed (in bytes per second) for a single KCP connection, 0 to disable. Also known as packet pacing. (default: 0)
 --sndwnd value set send window size(num of packets) (default: 1024)
 --rcvwnd value set receive window size(num of packets) (default: 1024)
 --datashard value, --ds value set reed-solomon erasure coding - datashard (default: 10)
 --parityshard value, --ps value set reed-solomon erasure coding - parityshard (default: 3)
 --dscp value set DSCP(6bit) (default: 0)
 --nocomp disable compression
 --sockbuf value per-socket buffer in bytes (default: 4194304)
 --smuxver value specify smux version, available 1,2 (default: 2)
 --smuxbuf value the overall de-mux buffer in bytes (default: 4194304)
 --framesize value smux max frame size (default: 8192)
 --streambuf value per stream receive buffer in bytes, smux v2+ (default: 2097152)
 --keepalive value seconds between heartbeats (default: 10)
 --closewait value the seconds to wait before tearing down a connection (default: 30)
 --snmplog value collect snmp to file, aware of timeformat in golang, like: ./snmp-20060102.log
 --snmpperiod value snmp collect period, in seconds (default: 60)
 --pprof start profiling server on :6060
 --log value specify a log file to output, default goes to stderr
 --quiet to suppress the 'stream open/close' messages
 --tcp to emulate a TCP connection(linux)
 -c value config from json file, which will override the command from shell
 --help, -h show help
 --version, -v print the version

kcptun can dial across a port range to avoid ISP QoS throttling or port-based interference.

How it works:

• Address format: IP:min-max (e.g., 1.2.3.4:3000-4000).
• On each new connection, the client randomly picks one port in the given range and connects to it.
• The server must listen on the same port range so it can accept connections on any port within that range.

Under the hood, addresses are parsed and validated as [host, minPort, maxPort] (see std/multiport.go), and the client selects a random port in [minPort, maxPort] for each session (see client/dial.go).

Usage:

1. Server — listen on a range:

   ./server_linux_amd64 -l ":3000-4000" ...

   Note: open the UDP ports 3000–4000 in your firewall.

2. Client — dial to a range:

   ./client_linux_amd64 -r "SERVER_IP:3000-4000" ...

Each new kcptun UDP/KCP session uses one randomly selected port from the range; sessions do not hop ports mid-connection.

Notes:

• Valid ranges are 1–65535 with min <= max.
• Single-port usage still works: IP:29900 (no hyphen).
• Works with --tcp mode as well; the remote port is still chosen from the range before initializing the connection.

kcptun supports userspace packet pacing to smooth out data transmission.

Why use it?

Without pacing, KCP may send data in large bursts (micro-bursts). These sudden spikes can overflow the network interface card (NIC) buffers or the OS kernel's UDP buffer, causing local packet drops before the data even leaves your server. This is especially common on high-speed links or restricted environments.

How to use:

Use --ratelimit <value> to set the maximum outgoing speed (in bytes per second) for a single KCP connection.

• Example: --ratelimit 1048576 limits the speed to 1MB/s.
• Default: 0 (unlimited).

Benefits:

1. Prevents Kernel Drops: Reduces the risk of ENOBUFS errors and kernel-level packet drops.
2. Smoother Traffic: Creates a more consistent flow of packets, which is friendlier to intermediate routers and reduces jitter.
3. Bandwidth Control: Useful for limiting upload speed on asymmetric networks (e.g., ADSL/Cable).

kcptun uses Reed-Solomon Codes to recover lost packets, which significantly improves data throughput on lossy networks.

You can configure the FEC parameters using the following flags:

• --datashard, -ds: Number of data shards (default: 10).
• --parityshard, -ps: Number of parity shards (default: 3).

How it works:

For every datashard packets sent, parityshard redundant packets are generated and sent. This allows the receiver to recover the original data even if up to parityshard packets are lost within the group of datashard + parityshard packets.

Overhead:

The bandwidth overhead can be calculated as: parityshard / datashard. For the default setting (10 data, 3 parity), the overhead is 30%.

Configuration Guide:

1. AutoTune: The receiver automatically detects and adapts to the sender's FEC parameters (DataShard/ParityShard), so you can adjust them on one side without restarting the other.
2. Tuning:
   • Increase -parityshard to improve reliability on highly lossy networks, at the cost of higher bandwidth usage.
   • Decrease -parityshard to reduce bandwidth overhead if the network quality is good.
3. Disable FEC: Set --parityshard 0 to disable Forward Error Correction. This saves CPU and bandwidth but reduces reliability on unstable networks.

Long-Distance Communication:

In long-distance communication (e.g., cross-continent), the Round-Trip Time (RTT) is high. If a packet is lost, waiting for retransmission (RTO) incurs a significant latency penalty. FEC allows the receiver to reconstruct lost packets immediately without waiting for retransmission, making it highly effective for reducing latency in high-RTT environments.

FEC

Differentiated Services (DiffServ) is a computer networking architecture that specifies a simple, scalable, and coarse-grained mechanism for classifying and managing network traffic and providing Quality of Service (QoS) on modern IP networks. DiffServ can, for example, be used to provide low-latency service to critical network traffic such as voice or streaming media while providing simple best-effort service to non-critical traffic such as web browsing or file transfers.

DiffServ uses a 6-bit differentiated services code point (DSCP) in the 8-bit differentiated services field (DS field) in the IP header for packet classification purposes. The DS field and ECN field replace the outdated IPv4 TOS field.

Set each side with -dscp value. Here are some commonly used DSCP values.

kcptun includes built-in packet encryption powered by various block encryption algorithms operating in Cipher Feedback Mode or AEAD. For each packet to be sent, the encryption process begins by encrypting a nonce from the system entropy, ensuring that encrypting identical plaintexts never produces identical ciphertexts.

Packet contents are fully encrypted, including headers (FEC, KCP), checksums, and data. Note that regardless of which encryption method you use in your upper layer, if you disable kcptun encryption by specifying -crypt none, the transmission will be insecure because the header remains PLAINTEXT, making it susceptible to tampering attacks such as manipulation of the sliding window size, round-trip time, FEC properties, and checksums. aes-128 is recommended for minimal encryption since modern CPUs include AES-NI instructions and perform even better than salsa20 (see the table below).

AEAD Support: Starting from v20251212, kcptun supports aes-128-gcm, which is an Authenticated Encryption with Associated Data (AEAD) algorithm. It provides both confidentiality and data integrity, effectively preventing ciphertext tampering.

Other possible attacks against kcptun include:

• Traffic analysis - data flow patterns from specific websites may be identifiable during data exchange. This type of eavesdropping has been mitigated by adapting smux to mix data streams and introduce noise. A perfect solution has not yet emerged; theoretically, shuffling/mixing messages across a larger-scale network may further mitigate this problem.

• Replay attack - since asymmetric encryption has not been integrated into kcptun, capturing and replaying packets on a different machine is possible. (Note: hijacking sessions and decrypting contents remains impossible). Therefore, upper layers must implement an asymmetric cryptosystem or a derived MAC to guarantee authenticity and prevent replay attacks (ensuring each message is processed exactly once). This vulnerability can only be eliminated by signing requests with private keys or employing an HMAC-based mechanism following initial authentication.

Important:

1. -crypt and -key must be identical on both the KCP Client and KCP Server.
2. -crypt xor is insecure and vulnerable to known-plaintext attacks. Do not use this unless you fully understand the implications. (Cryptanalysis note: any type of counter mode is insecure for packet encryption due to shortened counter periods that lead to IV/nonce collisions.)

Benchmarks for crypto algorithms supported by kcptun:

BenchmarkSM4-4 	 50000	 32087 ns/op	 93.49 MB/s	 0 B/op	 0 allocs/op
BenchmarkAES128-4 	 500000	 3274 ns/op	 916.15 MB/s	 0 B/op	 0 allocs/op
BenchmarkAES192-4 	 500000	 3587 ns/op	 836.34 MB/s	 0 B/op	 0 allocs/op
BenchmarkAES256-4 	 300000	 3828 ns/op	 783.60 MB/s	 0 B/op	 0 allocs/op
BenchmarkTEA-4 	 100000	 15359 ns/op	 195.32 MB/s	 0 B/op	 0 allocs/op
BenchmarkXOR-4 	20000000	 90.2 ns/op	33249.02 MB/s	 0 B/op	 0 allocs/op
BenchmarkBlowfish-4 	 50000	 26885 ns/op	 111.58 MB/s	 0 B/op	 0 allocs/op
BenchmarkNone-4 	30000000	 45.8 ns/op	65557.11 MB/s	 0 B/op	 0 allocs/op
BenchmarkCast5-4 	 50000	 34370 ns/op	 87.29 MB/s	 0 B/op	 0 allocs/op
Benchmark3DES-4 	 10000	 117893 ns/op	 25.45 MB/s	 0 B/op	 0 allocs/op
BenchmarkTwofish-4 	 50000	 33477 ns/op	 89.61 MB/s	 0 B/op	 0 allocs/op
BenchmarkXTEA-4 	 30000	 45825 ns/op	 65.47 MB/s	 0 B/op	 0 allocs/op
BenchmarkSalsa20-4 	 500000	 3282 ns/op	 913.90 MB/s	 0 B/op	 0 allocs/op

Benchmark result from openssl

$ openssl speed -evp aes-128-cfb
Doing aes-128-cfb for 3s on 16 size blocks: 157794127 aes-128-cfb's in 2.98s
Doing aes-128-cfb for 3s on 64 size blocks: 39614018 aes-128-cfb's in 2.98s
Doing aes-128-cfb for 3s on 256 size blocks: 9971090 aes-128-cfb's in 2.99s
Doing aes-128-cfb for 3s on 1024 size blocks: 2510877 aes-128-cfb's in 2.99s
Doing aes-128-cfb for 3s on 8192 size blocks: 310865 aes-128-cfb's in 2.98s
OpenSSL 1.0.2p 14 Aug 2018
built on: reproducible build, date unspecified
options:bn(64,64) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cfb 847216.79k 850770.86k 853712.05k 859912.39k 854565.80k

The encryption performance in kcptun is as fast as in openssl library(if not faster).

Quantum Resistance, also known as quantum-secure, post-quantum, or quantum-safe cryptography, refers to cryptographic algorithms that can withstand potential code-breaking attempts by quantum computers. Starting with version v20240701, kcptun adopts QPP based on Kuang's Quantum Permutation Pad for quantum-resistant communication.

da824f7919f70dd1dfa3be9d2302e4e0

To enable QPP in kcptun, set the following parameters:

 --QPP Enable Quantum Permutation Pads (QPP)
 --QPPCount value The prime number of pads to use for QPP. More pads provide greater encryption security. Each pad requires 256 bytes. (default: 61)

You can also specify

 "qpp":true,
 "qpp-count":61,

in your client and server-side JSON configuration files. These two parameters must be identical on both sides.

1. To achieve effective quantum resistance, specify at least 211 bytes in the -key parameter and ensure -QPPCount is at least 7.
2. Ensure that -QPPCount is COPRIME (互素) to 8 (or simply set it to a PRIME number) such as: 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199...

Routers and mobile devices are susceptible to memory constraints. Setting the GOGC environment variable (e.g., GOGC=20) will cause the garbage collector to recycle memory more aggressively. Reference: https://blog.golang.org/go15gc

Primary memory allocation is performed using a global buffer pool xmit.Buf in kcp-go. When bytes need to be allocated, they are obtained from this pool, and a fixed-capacity 1500-byte buffer (mtuLimit) is returned. The rx queue, tx queue, and fec queue all receive bytes from this pool and return them after use to prevent unnecessary zeroing of bytes. The pool mechanism maintains a high watermark for slice objects. These in-flight objects from the pool survive periodic garbage collection, while the pool retains the ability to return memory to the runtime when idle. The parameters -sndwnd, -rcvwnd, -ds, and -ps affect this high watermark; larger values result in greater memory consumption.

The -smuxbuf parameter also affects maximum memory consumption and maintains a delicate balance between concurrency and resource usage. You can increase this value (default 4MB) to boost concurrency if you have many clients to serve and a powerful server. Conversely, you can decrease this value to serve only 1-2 clients if you're running the program on an embedded SoC system with limited memory. (Note that the -smuxbuf value is not directly proportional to concurrency; testing is required.)

kcptun has builtin snappy algorithms for compressing streams:

Snappy is a compression/decompression library. It does not aim for maximum compression, or compatibility with any other compression library; instead, it aims for very high speeds and reasonable compression. For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger.

Reference: http://google.github.io/snappy/

Compression can save bandwidth for PLAINTEXT data and is particularly useful for specific scenarios such as cross-datacenter replication. Compressing redologs in database management systems or Kafka-like message queues before transferring data streams across continents can significantly improve speed.

Compression is enabled by default. You can disable it by setting -nocomp on BOTH the KCP Client and KCP Server (the setting MUST be IDENTICAL on both sides).

type Snmp struct {
 BytesSent uint64 // bytes sent from upper level
 BytesReceived uint64 // bytes received to upper level
 MaxConn uint64 // max number of connections ever reached
 ActiveOpens uint64 // accumulated active open connections
 PassiveOpens uint64 // accumulated passive open connections
 CurrEstab uint64 // current number of established connections
 InErrs uint64 // UDP read errors reported from net.PacketConn
 InCsumErrors uint64 // checksum errors from CRC32
 KCPInErrors uint64 // packet input errors reported from KCP
 InPkts uint64 // incoming packets count
 OutPkts uint64 // outgoing packets count
 InSegs uint64 // incoming KCP segments
 OutSegs uint64 // outgoing KCP segments
 InBytes uint64 // UDP bytes received
 OutBytes uint64 // UDP bytes sent
 RetransSegs uint64 // accumulated retransmitted segments
 FastRetransSegs uint64 // accumulated fast retransmitted segments
 EarlyRetransSegs uint64 // accumulated early retransmitted segments
 LostSegs uint64 // number of segs inferred as lost
 RepeatSegs uint64 // number of segs duplicated
 FECRecovered uint64 // correct packets recovered from FEC
 FECErrs uint64 // incorrect packets recovered from FEC
 FECParityShards uint64 // FEC segments received
 FECShortShards uint64 // number of data shards that's not enough for recovery
}

Sending a SIGUSR1 signal to the KCP Client or KCP Server will dump SNMP information to the console, similar to /proc/net/snmp. You can use this information for fine-grained tuning.

A: The following parameters MUST be exactly the same on both client and server, otherwise the connection will fail:

• --key and --crypt
• --QPP and --QPPCount
• --nocomp
• --smuxver

A: You can use -mode manual along with -nodelay, -interval, -resend, and -nc for advanced tuning. For example:

-mode manual -nodelay 1 -interval 20 -resend 2 -nc 1

Manual mode allows you to customize low-level KCP behavior. Make sure you fully understand each parameter before changing them, as improper settings may degrade performance or stability. See the KCP protocol configuration documentation for details.

A: Yes, official example configuration files are provided for quick setup:

• Client example
• Server example

A: Both options disable encryption, but they differ in protocol behavior:

• crypt=none: No encryption is applied, but a protocol header is still present. The packet format remains compatible with encrypted modes, but the content is plaintext. This helps with protocol compatibility.
• crypt=null: No encryption and no protocol header—data is transmitted in raw form without any cryptographic framing. This offers the highest performance but is the least secure and most easily identified.

In summary: none keeps the protocol header (plaintext payload), while null sends completely raw data (no header, no encryption).

1. https://github.com/skywind3000/kcp -- KCP - A Fast and Reliable ARQ Protocol.
2. https://github.com/xtaci/kcp-go/ -- A Production-Grade Reliable-UDP Library for golang
3. https://github.com/klauspost/reedsolomon -- Reed-Solomon Erasure Coding in Go.
4. https://en.wikipedia.org/wiki/Differentiated_services -- DSCP.
5. http://google.github.io/snappy/ -- A fast compressor/decompressor.
6. https://www.backblaze.com/blog/reed-solomon/ -- Reed-Solomon Explained.
7. http://www.qualcomm.cn/products/raptorq -- RaptorQ Forward Error Correction Scheme for Object Delivery.
8. https://en.wikipedia.org/wiki/PBKDF2 -- Key stretching.
9. http://blog.appcanary.com/2016/encrypt-or-compress.html -- Should you encrypt or compress first?
10. https://github.com/hashicorp/yamux -- Connection multiplexing library.
11. https://tools.ietf.org/html/rfc6937 -- Proportional Rate Reduction for TCP.
12. https://tools.ietf.org/html/rfc5827 -- Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP).
13. http://http2.github.io/ -- What is HTTP/2?
14. http://www.lartc.org/ -- Linux Advanced Routing & Traffic Control
15. https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem -- Noisy channel coding theorem
16. https://zhuanlan.zhihu.com/p/53849089 -- kcptun开发小记

Click here to donate.

(注意:kcptun没有任何社交网站的账号,请小心骗子。)