Yu Hao Dong

@ZezhongWang 根據我的測試，正確實現BBR式的bottleneck bandwidth estimation，通過它來設定cwnd和pacing，是可以達到很好的效果的。我這裏能搭建的最垃圾網絡（香港->塞爾維亞->美國東海岸）可以在丟包率

https://github.com/geph-official/geph2/blob/master/libs/kcp-go/kcp.go 和原版KCP有点出入，不能直接pull。（主要在于我正在试图完全去掉每x毫秒的polling，不然在手机上简直是费电大王）。值得注意的地方： - 两个congestion control方法，一个是CUBIC的原型BIC，是比较传统的丢包就减慢速度的算法，但是比原版的tahoe效率高太多了，可以和内核的默认tcp媲美。另外一个是LOL，算是一个缺胳膊短腿的BBR吧，可以基本填满带宽而不丢太多的包，使用LOL时tx.go会用pacing。追求低丢包，与现代TCP公平用BIC，追求带宽用LOL。没有什么情况需要关掉congestion control，关掉反而会因为大量丢包重发降低throughput。 - 原版KCP定min_rto时非常严格，网络稍微有一点jitter就疯狂地重发，虽然再等几毫秒ACK就到了。我让rto乘以1.5，**大大**地减少重发。我debug了太长时间才发现这是在坏网络情况下疯狂重发的病根，根本不是真的丢包率有多高。rto太长不会真的多影响性能，因为有fast retransmit机制。 - pacing不是特别重要，可以在好网络上把丢包率从10降到3之类的。坏网络上没什么区别，怎么着都20多 第二点非常重要。我不太清楚原版定rto为什么如此不好。

@xtaci 我的第二点还真不知道技术上是为什么，可能不是min定的不好。但是不管是为什么，原版经常重发没有丢的包，手动调高RTO就会避免。特别是长延迟，高带宽，低丢包的连接（如世界两端的两个服务器之间）。原版指kcp-go 我的fork里其实没有改数据结构，只是在所有queue都是空的时候会暂停每X毫秒的polling，一旦有新的packet则重新开始。这样解决了idle时费电的问题。不知道有没有什么弊端，是不是只要queue都是空的就可以安全的从updater的heap里删除。

@xtaci 确实改善了一点点，但是调高RTO还是降低重发。会不会是时钟稍微有点不准导致的？ 另外我的Idle机制是连续几秒queue都是空的，并且flush没有改动任何变量时，暂停polling。目前使用着似乎没有问题。

@xtaci 在安卓系统上，屏幕关了，进入到deep sleep确实就是好多秒才中断一次CPU的频率。手机上的省电机制非常依赖极低的interrupt，而且不断的polling其实也会被系统suspend。实测上如果不去掉polling又费电又有时卡顿。 我会测一侧改动的

```go // kcp update, returns interval for next calling func (s *UDPSession) update() (interval time.Duration) { s.mu.Lock() waitsnd := s.kcp.WaitSnd() interval = time.Duration(s.kcp.flush(false)) * time.Millisecond if s.kcp.WaitSnd() < waitsnd {...

Commenting to note that this behavior is actually desirable in my use case, as it prevents massive thundering-herds of timers suddenly expiring when Doze ends, something I've seen in Go....

目前仍然还没有完全稳定适合发布

> testing with another vpn such as proton vpn does not leak the private address and somehow disables webrtc transport. could geph be able to prevent such protocols that leak...

Right now, that is fairly difficult, because it requires that the entire infrastructure, including bridges used for censorship circumvention, support IPv6. Unfortunately, we often use "weird" connections, like home internet...