主 题：【TQ】VMISS-US.LA.TRI.Basic 和 Lightlayer-US.SJC TCP调参前后对比，附5.6 Sol测评
发 布 者：KawaTU
标签分类： 测评
时 间：2026-07-30 02:00:02
内容预览：之前发过一篇Lightlayer的TQ测试帖，被 @金山云 大佬告知可以通过调整TCP参数进行优化。我把大佬的说法发给AI，让AI根据两台机器的实际系统参数分别给出调优方案。调整完成后，我又重新跑了一遍TQ，效果非常明显：Lightlayer终于发挥出G口性能，标称200Mbps的VMISS甚至跑到了500Mbps。这里附上两台机器调参前后的完整TQ报告，以及AI对参数和测试结果的总结。@金山云 大佬的说法：单线程理论极值 = 最大窗口 ÷ 平均延迟 × 8，其中最大窗口取本地最大窗口与测速点最大窗口中的较小值，测速点最大窗口为16MB。以美西为例，160ms延迟加4MB发送缓存，理论单线程约为200Mbps。这个理论值不考虑商家限速和线路拥堵。肯定可以调，200Mbps回国大概率使用的还是默认参数。Lightlayer US.SJC调参前IPv4回程IPv4大包回程教育网回程国际互联三网单线程速度报告链接：https://tcpquality.ibsgss.uk/r/fydt7vgDjk调参后IPv4回程IPv4大包回程教育网回程国际互联三网单线程速度报告链接：https://tcpquality.ibsgss.uk/r/MAdwAaThYJAI评价：Lightlayer参数调整Lightlayer原本已经启用BBR + fq，主要问题是TCP收发缓冲区偏小：调参前拥塞控制：BBR队列算法：fqTCP发送：4K / 16K / 4MTCP接收：4K / 128K / 6M美西回国平均延迟约160ms，4MB发送窗口对应的理论单线程上限约为200Mbps，因此G口无法得到充分发挥。本次主要调整为：调参后拥塞控制：BBR队列算法：fqTCP发送：4K / 64K / 32MTCP接收：4K / 256K / 32MSocket收发上限：64MTCP窗口缩放：开启MTU自动探测
直达链接： https://www.nodeseek.com/post-847872-1
发 布 者：KawaTU
标签分类： 测评
时 间：2026-07-30 02:00:02
内容预览：之前发过一篇Lightlayer的TQ测试帖，被 @金山云 大佬告知可以通过调整TCP参数进行优化。我把大佬的说法发给AI，让AI根据两台机器的实际系统参数分别给出调优方案。调整完成后，我又重新跑了一遍TQ，效果非常明显：Lightlayer终于发挥出G口性能，标称200Mbps的VMISS甚至跑到了500Mbps。这里附上两台机器调参前后的完整TQ报告，以及AI对参数和测试结果的总结。@金山云 大佬的说法：单线程理论极值 = 最大窗口 ÷ 平均延迟 × 8，其中最大窗口取本地最大窗口与测速点最大窗口中的较小值，测速点最大窗口为16MB。以美西为例，160ms延迟加4MB发送缓存，理论单线程约为200Mbps。这个理论值不考虑商家限速和线路拥堵。肯定可以调，200Mbps回国大概率使用的还是默认参数。Lightlayer US.SJC调参前IPv4回程IPv4大包回程教育网回程国际互联三网单线程速度报告链接：https://tcpquality.ibsgss.uk/r/fydt7vgDjk调参后IPv4回程IPv4大包回程教育网回程国际互联三网单线程速度报告链接：https://tcpquality.ibsgss.uk/r/MAdwAaThYJAI评价：Lightlayer参数调整Lightlayer原本已经启用BBR + fq，主要问题是TCP收发缓冲区偏小：调参前拥塞控制：BBR队列算法：fqTCP发送：4K / 16K / 4MTCP接收：4K / 128K / 6M美西回国平均延迟约160ms，4MB发送窗口对应的理论单线程上限约为200Mbps，因此G口无法得到充分发挥。本次主要调整为：调参后拥塞控制：BBR队列算法：fqTCP发送：4K / 64K / 32MTCP接收：4K / 256K / 32MSocket收发上限：64MTCP窗口缩放：开启MTU自动探测
直达链接： https://www.nodeseek.com/post-847872-1
