You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Dockerfile
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,10 @@ FROM golang:alpine as builder
2
2
MAINTAINER xtaci <daniel820313@gmail.com>
3
3
RUN apk update && \
4
4
apk upgrade && \
5
-
apk add git
5
+
apk add git gcc libc-dev linux-headers
6
6
RUN go get -ldflags "-X main.VERSION=$(date -u +%Y%m%d) -s -w" github.com/xtaci/kcptun/client && go get -ldflags "-X main.VERSION=$(date -u +%Y%m%d) -s -w" github.com/xtaci/kcptun/server
@@ -92,7 +100,15 @@ All precompiled releases are genereated from `build-release.sh` script.
92
100
93
101
> *fast3 > fast2 > fast > normal > default*
94
102
103
+
#### HOLB
104
+
105
+
Since streams are multiplexed into a single physical channel, head of line blocking may appear under certain circumstances, by
106
+
increasing `-smuxbuf` to a larger value (default 4MB) may mitigate this problem, obviously this will costs more memory.
95
107
108
+
#### Slow Devices
109
+
110
+
kcptun made use of **ReedSolomon-Codes** to recover lost packets, which requires massive amount of computation, a low-end ARM device cannot satisfy kcptun well. To unleash the full potential of kcptun, a multi-core x86 homeserver CPU like AMD Opteron is recommended.
111
+
If you insist on running under some ARM routers, you'd better turn off `FEC` and use `salsa20` as the encryption method.
96
112
97
113
### Expert Tuning Guide
98
114
@@ -103,15 +119,15 @@ All precompiled releases are genereated from `build-release.sh` script.
The encrytion performance in kcptun is as fast as in openssl library(if not faster).
250
268
251
269
252
-
#### Memory Usage Control
270
+
#### Memory Control
253
271
254
272
Routers, mobile devices are susceptible to memory consumption; by setting GOGC environment(eg: GOGC=20) will make the garbage collector to recycle faster.
255
273
Reference: https://blog.golang.org/go15gc
256
274
275
+
Primary memory allocation are done from a global buffer pool *xmit.Buf*, in kcp-go, when we need to allocate some bytes, we can get from that pool, and a *fixed-capacity* 1500 bytes(mtuLimit) will be returned, the *rx queue*, *tx queue* and *fec queue* all receive bytes from there, and they will return the bytes to the pool after using to prevent *unnecessary zer0ing* of bytes.
276
+
The pool mechanism maintained a *high watermark* for slice objects, these *in-flight* objects from the pool will survive from the perodical garbage collection, meanwhile the pool kept the ability to return the memory to runtime if in idle, `-sndwnd`,`-rcvwnd`,`-ds`, `-ps`, these parameters affect this *high watermark*, the larger the value, the bigger the memory consumption will be.
277
+
278
+
`-smuxbuf` also affects the maximum memory consumption, this parameter maintains a subtle balance between *concurrency* and *resource*, you can increase this value(default 4MB) to boost concurrency if you have many clients to serve and you get a powerful server at the same time, and also you can decrease this value to serve only 1 or 2 clients and hope this program can run under some embeded SoC system with limited memory and only you can access. (Notice that the `-smuxbuf` value is not proprotional to concurrency, you need to test.)
279
+
280
+
257
281
#### Compression
258
282
259
283
kcptun has builtin snappy algorithms for compressing streams:
@@ -274,29 +298,30 @@ Compression is enabled by default, you can disable it by setting ```-nocomp``` o
274
298
#### SNMP
275
299
276
300
```go
277
-
// Snmp defines network statistics indicator
278
301
typeSnmpstruct {
279
-
BytesSentuint64//raw bytes sent
280
-
BytesReceiveduint64
281
-
MaxConnuint64
282
-
ActiveOpensuint64
283
-
PassiveOpensuint64
284
-
CurrEstabuint64//count of connections for now
285
-
InErrsuint64//udp read errors
302
+
BytesSentuint64// bytes sent from upper level
303
+
BytesReceiveduint64// bytes received to upper level
304
+
MaxConnuint64// max number of connections ever reached
305
+
ActiveOpensuint64// accumulated active open connections
306
+
PassiveOpensuint64// accumulated passive open connections
307
+
CurrEstabuint64//current number of established connections
308
+
InErrsuint64//UDP read errors reported from net.PacketConn
286
309
InCsumErrorsuint64// checksum errors from CRC32
287
-
KCPInErrorsuint64// packet iput errors from kcp
288
-
InSegsuint64
289
-
OutSegsuint64
290
-
InBytesuint64// udp bytes received
291
-
OutBytesuint64// udp bytes sent
292
-
RetransSegsuint64
293
-
FastRetransSegsuint64
294
-
EarlyRetransSegsuint64
310
+
KCPInErrorsuint64// packet iput errors reported from KCP
0 commit comments