推荐两个 K/V 库
https://github.com/xujiajun/nutsdb
https://github.com/prologic/bitcask
如果习惯写 sql 的话还是建议 sqlite，用 xgo 交叉编译就行了，参考： https://monkeywie.github.io/2019/10/10/go-cross-compile

支持支持，goproxy.cn 出来之后，就从 goproxy.io 转移过来了

@cmdOptionKana 哈哈，不要在意这些细节

@dodo2012 现在就是用接口实现的，总感觉怪怪的 🥶，可能还是太习惯 OOP 了吧，https://play.golang.org/p/fsAfWNNkFOI

BT 一直都是基于 TCP 协议啊，不过后来也有基于 UDP 的 uTP，当然如果是 tracker 协议的话基本上都是走 UDP 的。

为啥要停止删除 docker，一般在前面跑一个 nginx 负载均衡，两个容器做滚动升级就好了

@yulihao x-forwarded-for 不行啊，目标服务器基本都是直接拿的 remote_ip

@Raynard 有例子吗？

@jangit 客户端出网是外网 ip 呀，代理服务器和客户端不是一个局域网下的，代理服务器单独部署在外网。

@ThirdFlame 额，可能我没太说明白，我现在的角色是客户端和代理服务器，就是想让别人知道我的真实 ip，而不是代理服务器 ip

测试了一下，初步怀疑是 http1.0 协议的客户端直接被 pass，但是我用 curl 指定 http2.0 协议请求也是 403，但是验证肯定还是在 TLS 这层，不是 http 这层，估计 curl 和浏览器的 TLS 握手还是有区别的。

卧槽，看完这个帖子我去翻了翻我的邮箱，发现也有收到，是华为的，华为 2012 实验室-可信理论、计算与工程实验室-开源软件部，不知道真的假的啊

@BBCCBB 都一样的，read()底层也是调用的 ReadFrom()，这个 @rio 就是个睿智，说了半天就一直在那秀优越，前面说的也全是错的，真的是 talk is cheap

@BBCCBB r 就是一个*net.UDPConn

@BBCCBB udp 读估计每次都是一个完整的 udp 报文，不存在和 tcp 那样用 Read()一次性读不完，所以我现在只要用最大字节数的 buf 去 Read()一次就行了，不用 io.ReadFull 了，毕竟响应的报文不一定有这么长，这个方法肯定阻塞。

@ma6254 现在没有 ReadFull()了，可能是 TCP 写多了,之前以为 UDP 和 TCP 一样可以这样读。 🤓

@BBCCBB 我现在只能确定 udp 响应包的最大长度，但是真实的响应可能没这么长，我看了 ioutil.ReadAll 源码，是要遇到 io.EOF 或者其它异常(比如超时)才能返回，但是 udp 协议并不存在关闭连接也就不会有 io.EOF ，所以我这里调用的话应该是一直阻塞着直到超时

@BBCCBB 用 ioutil.ReadAll 也不对呀，不是读完这次就 EOF，后面还有呢

@ma6254 n 我打印出来过了，都是 20 😂，其实是因为有 err，io.ReadFull()里面把 err 忽略掉了。
```
func ReadAtLeast(r Reader, buf []byte, min int) (n int, err error) {
if len(buf) < min {
return 0, ErrShortBuffer
}
for n < min && err == nil {
var nn int
nn, err = r.Read(buf[n:])
// nn=20,err!=nil
n += nn
}
if n >= min {
//读到了指定的字节数就置空 err
err = nil
} else if n > 0 && err == EOF {
err = ErrUnexpectedEOF
}
return
}
```

@ma6254 谢谢老哥耐心解答，我找到原因了，原来一直有 err 返回，只是 io.ReadFull()在读取到指定字节会把 err 置空，

错误信息：`wsarecv: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.`

看样子 upd 接收的缓冲区一定要大于要接收的这次报文，所以你 8L 提供的那种方法也是行不通的，现在我是直接开辟一个大点的 buf 用 conn.Read()接收，只能这样做了