Readv 严重问题，拖累速度、造成闪退

[e1732a364fed]

之前写readv代码时只是简单试试好不好使，从来没经过 流量巨大的 测速测试

这次测速揭露出巨大问题

tls+vless

开启readv
1771 3488
1694 3103


关闭readv
3835 3536
3475  3604


ws+tls+vless

开启readv
2906 2435
2777 2424
2782 2436


关闭readv
2823 2447
2918 2445

readv本应加速，结果现在确实减速状态；

而测试ws+vless，中间不加tls层时，服务端则是直接闪退了

2022/03/26 17:26:44 direct 127.0.0.1:49281  want to dial  tcp+direct ://54.244.7.161:443
panic: runtime error: slice bounds out of range [:1500] with capacity 935
	panic: runtime error: slice bounds out of range [:1500] with capacity 935

/v2ray_simple/utils.RecoverBuffers(...)
v2ray_simple/utils/buffers.go:116

/v2ray_simple/netLayer.put_readvMem(0x14000064d18?)
	v2ray_simple/netLayer/readv.go:53 +0xf8

总之代码我还要改改！现在大家先用 -readv=false 参数 或者

[app]
noreadv = true 

关闭readv功能

[e1732a364fed]

我在最新commit中已经修复了闪退问题。

关于拖慢速度问题，我经过测试调节，发现是readv单个buf 大小的问题

经过排查，果然是buf大小问题，数据如下：

ws+vless，单机内网 使用自建speedtest工具自己连自己测速


关闭readv
2925 2524
3028 2512
2911 2558

开readv，buf 1500，16个

2405 2479
2373 2468
2534 2489

开readv但不用 multiwriter

1698 1957
1717 2021

buf 为 4096的情况, 数量为16

2755 2435

buf 为 10240的情况

3001 2538
2865 2513
2942 2544
2962 2511


buf 为 4096，数量为 32
2763 2513
2730 2540
2868 2543
2803 2534

buf 为 4096，数量为 320
2690 2514
2919 2484
2781 2537
2776 2485

总之，我的想法就是，在本地内网测速这种超快的极限的情况下，使用readv因为buf太小，会导致反效果而减速

如果是远程测速，反效果应该会减弱，甚至有正效果。这个我之前的benchmark也揭示过

所以实际上真不好说readv是好还是坏，看你的网络情况

个人推测，因为远程测速总是会经过多个网关，所以readv应该是有正效果的。同时，我也会进一步测试 readv最优化的参数。

[e1732a364fed]

关于该减速问题的思考，可以阅读
https://github.com/e1732a364fed/v2ray_simple/wiki/关于readv

在该页面里，我对这种现象进行了具体的解释。