当前mKCP协议在访问网页时的问题

[wwqgtxx]

提交 Issue 之前请先阅读 Issue 指引，然后回答下面的问题，谢谢。
Please answer the following questions before submitting your issue. Thank you.

1. 你正在使用哪个版本的 V2Ray？（如果服务器和客户端使用了不同版本，请注明）

2. What version of V2Ray are you using?
   2.3.3/2.2.1都有测试

3. 你的使用场景是什么？比如使用 Chrome 通过 Socks/VMess 代理观看 YouTube 视频。

4. What your scenario of using V2Ray? E.g., Watching YouTube videos in Chrome via Socks/VMess proxy.
   打开一个比较大型的网页（即含有大量CSS/JS/图片的网页），比如推特，微博

5. 你看到的不正常的现象是什么？

6. What did you see?
   经常导致网页无法加载，卡在那里
   即当加载一个域名下的多个资源的时候，容易导致第一个加载的资源被阻塞，表现为网页无限加载中，图片显示不出来

7. 你期待看到的正确表现是怎样的？

8. What do you expected to see instead?
   应该都可以正常加载

9. 请附上你的配置文件。

10. Please attach your configuration file.

"streamSettings": {
      "network": "kcp"
    }

"transport": {
    "kcpSettings": {
      "uplinkCapacity": 1,
      "downlinkCapacity": 100,
      "congestion": true
    }
  }

[ktcunreal]

2.1/2.3.3版本 同样出现楼主2)、3)所描述的情况。
（跑speedtest,fast.com之类的测试，下载文件时速度很快。 但打开某一部分网页时会经常卡死）
架设在同一VPS上的SS等代理则表现正常

[wwqgtxx]

测试在2.7版本中有了明显的改善，但是从commit记录又看不出来是哪里修复了，希望不是因为今天的网络环境比较正常才没有导致的问题

[v2ray]

2.7 中有一些优化，主要的改进是减小了内存使用，对速度的影响未知。如果你发现速度有稳定的改善请留言。

[wwqgtxx]

仔细看了一下commit记录，可能是减少了timeout所带来的提高，之前的拥塞应该是因为有一部分包丢失了，而v2ray重试的时候又不断的增加timeout值，导致了长时间的等待。

而且经过实际测试，旧版本（2.4.2）的拥塞情况不只是针对HTTP，实际上是所有大规模的对同一个IP和端口发起TCP连接都会出现拥塞情况，具体表现为，当其中的一个tcp链接因为某些原因阻塞了，就会导致其他同一ip:端口的TCP连接全部阻塞，进而导致整个连接接近于中断，需要重启v2ray客户端才能恢复正常
这种问题在原版的KCPTUN中则不会表现出来，在v2ray2.7版本中也尚未复现

测试方法如下：

1.先开启一个KCP协议的v2ray使用dokodemo-door协议映射服务器的v2ray tcp端口
2.再开启一个tcp协议的v2ray连接由本地v2ray经过kcp->tcp转接的vmess协议（这样做是因为普通的tcp版本的vmess协议并不会出现这个问题，所以将问题锁定在mkcp协议层）
3.使用浏览器大规模的访问各种网页（主要是图片多的网站，比如twitter,weibo），查看会否出现无法正在加载后续图片（大概一百张图片之后）

写这么多也是为了作者或者其他有相同问题的同志们能自行测试（比如楼上的 @ktcunreal ）
另外也是希望作者能找出真正修正这个问题的commit所在，这样以后才容易对症下药，进行更好的优化。同时也不会在之后的某个版本又复现该问题，导致用户体验的严重下降

[v2ray]

请测试 2.8 版本，大量并发的问题已经修复。

[wwqgtxx]

现在大量并发的问题基本解决了，现在是每次发起连接的握手过程延时太大了，打开一个网页的初始时间过长，一旦建立了http(s)连接之后的下载速度倒是非常可观，希望可以优化一下
测试版本2.10.1（服务端linux x64，客户端linux arm）

[v2ray]

kcp 在测速上还有一些问题，目前的计划是使用基于 BBR 的算法来精确估算传输速度。

[wwqgtxx]

感觉不一定是测速的问题，可能需要在握手阶段使用更激进的重传政策，毕竟UDP的丢包本来就比TCP严重，这点在KCPTUN中的性能就比较好。但KCPTUN的问题在于过渡依赖保持单一UDP连接，一旦单一UDP连接因为各种原因被断开，就会导致整个上层连接无法进行，只能重启整个KCPTUN，这点V2RAY的mKCP协议在较为恶劣的网络情况下稳定性还是大大超过KCPTUN的，不过也可能是因为这样拖慢了每次握手包的发送

[sinfere]

@wwqgtxx 有道理，mKCP开多个连接，每个连接之间rtt、rto等信息不共享，所以新连接达到稳定状态需要一定的时间，但实际上客户端和服务端的通路是唯一的确定的