美咔(mekya) 协议前瞻 - 愿光芒散射于风雪 | Mekya Protocol Preview (English Translation Available)

[xiaokangwang]

距离上一个协议的推出也有一段时间了，在这段时间内，有不少人在畅想在更新暂停的期间在做些什么？现在即是答案接晓之时！Mekya 协议经过数月的断断续续的开发终于完成了基础调试即将发布，本文旨在与快速展示 mekya 协议的亮点以推广该协议，并将其与其他同类协议进行对比。那么，立刻上图！

图 1 - 在实验室模拟的恶劣网络环境下不同 h2 可反射协议传输速度的对比

如图 1 所示，在 HTTP 请求下载速度被限速 512 千字节每秒，且加入 100 毫秒的请求延迟的情况下，如 附件1 所描述的配置文件运行的不同协议在以 HTTP 协议下载 32 兆字节的随机文件时有不同的下载速度。其中 meek 的平均下载速度为 37 千字节每秒，SplitHTTP 的平均下载速度为 507 千字节每秒，mekya 的平均下载速度为 2220 千字节每秒。

之所以能够达成这样的下载速度是因为 mekya 协议通过并发连接提高下载速度，减少因为单个连接受到网络抖动或其他原因导致的不稳定影响负载连接的稳定性。在不同的网络环境下不同协议的连接速度会有差异，本图示中所表示的实验中的恶劣网络环境对 mekya 的影响相对较小。

协议设计

那么 mekya 的协议设计和其他协议有什么区别呢？

在 meek 协议中，流式负载连接被拆分为一个一个小的数据块，然后按顺序使用 HTTP 请求 发送至远程服务器，或者从服务器被发送回客户端。在这种协议设计下，每个请求都需要按照顺序进行发送和接受，在延迟较高时，会导致大量时间被用于等待服务器返回结果或客户端发起下一个请求，因此传送速度不高，适用于不需要很高传输速度的元数据的传输。

在 SplitHTTP 协议中，上传数据被拆分为数据块后通过序列号标注允许乱序传输，然后使用 HTTP 请求发送至服务器端。而下载数据则通过 HTTP 协议流式下载到客户端。在这种协议设计下，连接延迟问题被通过乱序传输和流水线式下载规避，然而，仍然受到单一连接网络状况的影响。同时因为依赖于 HTTP 流式下载只能利用一部分 HTTP 反射器（如 反向代理 或 CDN）。

而在 mekya 协议中，上传下载数据被使用 mkcp 协议直接全部切片并自动重传以在远端重组，然后使用 HTTP 协议乱序多线程上传下载。在某个连接出现阻塞或异常时，数据将全自动重传解决。由于数据全部被分块，mekya 支持在 HTTP 不支持流式下载时降级运转，因此可以最大程度适配不同的网络环境和 HTTP 反射器（如 反向代理 或 CDN）服务。

协议特性

各位客官大概看文字也看累了，咱们直接上表！表 1 中总结了 V2Ray v5.17 版本 和 XRay 1.8.23 版本中实现的不同协议的特性。

表 1 - 不同 h2 可反射协议的特性

	meek (V2Ray)	SplitHTTP	mekya (V2Ray)
传输速度	❌ 慢	取决于网络状况	取决于网络状况
多线程传输	❌ 不支持	❌ 仅上载	✅ 支持
依赖流式传输	✅ 不依赖	❌ 依赖	✅ 不依赖，但推荐
连接阻塞自主愈合	❌ 不支持	❌ 不支持	✅ 支持
网络抖动自主愈合	❌ 不支持	❌ 连接崩毁	✅ 支持
协议调参	✅ 支持，高级用法	❌ 可调参数较少	✅ 支持，高级用法
性能利用率	✅ 较低	✅ 较低	⚠ 高

嗯嗯，感觉需要一个小小的名词解释呢，什么是连接阻塞和网络抖动呢？

连接阻塞 就是说当某个特定的连接出现故障，速度突然降低或不再传输数据，但是连接没有被中断的情况。这种情况一般在某个服务器突然掉线，或者丢包率突然上升时产生。网络抖动指连接突然闪断，会话状态丢失的状况。Mekya 在这些环境下会通过持续发送HTTP请求及回复并积极重传来使连接自主愈合，减少用户可感知的异常。在 附件 2 中展示了相应的日志。

结语

本文的目的是为了推广 mekya 协议，因此自然对 mekya 仍存在的不足之处没有过多提及，这包括其所需要利用的性能更高，mkcp 协议并不能有效理解 HTTP 传输的机制和特性，因此需要仔细的参数调整才能最大的利用网络来提升连接速度和相应速度。对于不同的用户来说适合自己的协议就是最好的，没有必要为了这个去互相攻击对方。尚未实现的协议包括 SplitHTTP 都为新协议 mekya 的设计提供了灵感和思路，未来如果有时间和机会的话也会进一步借鉴这些协议中优秀的设计。

目前 mekya 协议还在最后优化阶段目前还没有正式加入到 V2Ray 中，但是如果大家有想体验的愿望的话，已经可以在 v5.17 及之后的版本中使用工程模式调用了哦。配置示例参见： #3120

至于标题的后半句是 愿光芒散射于风雪呢？这就涉及了 mekya 协议的设计哲学了。mekya 协议在不牺牲其所能适配的 HTTP 请求反射器（或者说转发工具，反向代理，CDN）的情况下相比于 meek 大幅度提高了连接速度。每个 HTTP 请求如同光芒(Ray) 一样被各种各样的不同的多样的如雪花一样满天飞舞的转发服务散射，最终照澈大地点亮昭昭前路，愿 V2Ray 以此发散出更明亮的光辉，可以被风雪中的雪花散射的光辉！

快问快答环节

问：请问部署后的转发服务配额消耗情况是怎样的呢？

在观看直播并撰写本篇文档时每小时产生约 50万 个 HTTP 请求。流量消耗不小于 mKCP 所消耗的流量。

问：请问会对流量特征产生什么影响呢？

由于使用了 mKCP 基本上就是 KCP 的流量特征了，但是它又是在好几个 TCP 连接上发的，所以可以说是截稿时被针对比较少的特征。

问：... 大家都用等于都没用... 对别人不公平 ... CDN 滥用 …

正如你们所说，V2Ray 的用户已经没有那么多了，所以已经不再会对其他人产生任何影响了呢。

附件

附件 1

https://gist.github.com/xiaokangwang/1a99130a498f0eca0e61253d6c791596

附件 2

https://gist.github.com/xiaokangwang/161beccb35b7a6e05db4a1ad668cb325

Mekya Protocol Preview - May the Ray Scatter through the Wind and Snow

(Translated by ChatGPT from the original ZhongWen-HuaXia language version and fact checked by its original author.)

It has been some time since the last protocol was released, and during this period, many have wondered what has been happening while updates were on hold. Now is the time for answers! After months of intermittent development, the mekya protocol has finally completed its basic testing and is about to be released. This article aims to quickly showcase the highlights of the Meyka protocol to promote it and compare it with other similar protocols. So, let’s dive right in!

Figure 1 - Comparative Analysis of Transmission Speeds for Various HTTP/2 Reflect-able Protocols in a Simulated Adverse Network Environment

Figure 1 shows that when the HTTP request download speed is throttled to 512 KB/s and a 100 ms request delay is introduced, the various protocols configured as described in Appendix 1 exhibit different download speeds when retrieving a 32 MB random file via the HTTP protocol. The average download speed for Meek is 37 KB/s, for SplitHTTP is 507 KB/s, and for Mekya is 2220 KB/s.

The mekya protocol achieves these download speeds by utilizing concurrent connections to enhance performance and minimize instability caused by network interruption or other factors that could disrupt payload connection stability. While connection speeds may vary across different protocols under various network conditions, the adverse conditions in this experiment had a relatively minimal impact on mekya.

Protocol Design

How does the protocol design of mekya differ from that of other protocols?

In the meek protocol, the streaming payload connection is divided into smaller data blocks and transmitted sequentially through HTTP requests to the remote server or received from the server by the client. This design mandates that requests be sent and received in order. High latency can cause substantial delays due to the time spent awaiting server responses or client requests, resulting in reduced transfer speeds. This approach is suited for the transfer of metadata where high-speed transmission is not critical.

In the SplitHTTP protocol, upload data is segmented into blocks and tagged with sequence numbers to permit out-of-order transmission, then transmitted to the server via HTTP requests. Download data is streamed to the client using the HTTP protocol. This design mitigates connection latency issues through out-of-order transmission uploading and pipelined downloading; however, it is still impacted by single-connection network conditions. Furthermore, due to its reliance on HTTP streaming, it can leverage only a subset of HTTP Reflectors (like Reverse Proxy or CDN).

In the mekya protocol, both upload and download data are fully sliced and automatically retransmitted using the mkcp protocol for reassembly at the remote end. The HTTP protocol is then used for out-of-order, multi-threaded upload and download. In the event of a connection blockage or anomaly, data is automatically retransmitted to address the issue. Given that all data is chunked, mekya supports fallback operation in cases where HTTP streaming downloads are unsupported, thereby maximizing compatibility with diverse network environments and HTTP Reflectors (like Reverse Proxy or CDN) services.

Protocol Characteristics

Readers may find the text overwhelming, so let’s refer directly to the table. Table 1 summarizes the features of the various protocols implemented in V2Ray v5.17 and XRay 1.8.23.

Table 1 - Characteristics of Various HTTP/2 Reflect-able Protocols

	meek (V2Ray)	SplitHTTP	mekya (V2Ray)
Transfer Speed	❌ Slow	Dependent on network conditions	Dependent on network conditions
Multi-threaded Transmission	❌ Not supported	❌ Upload only	✅ Supported
Requires Streaming Download	✅ Not reliant	❌ Dependent	✅ Not reliant, though recommended
Self-healing for Stalled Connections	❌ Not supported	❌ Not supported	✅ Supported
Self-healing for Network Interruptions	❌ Not supported	❌ Connection failure	✅ Supported
Protocol Tuning	✅ Supported, advanced use case	❌ Limited tunable parameters	✅ Supported, advanced use case
Performance Utilization Rate	✅ Low	✅ Low	⚠ High

Yes, yes, it seems we need a brief explanation of what stalled connections and network interruptions are.

A stalled connection occurs when a specific connection encounters a fault, resulting in a sudden decrease in speed or a halt in data transmission, while the connection itself remains intact. This typically happens when a server unexpectedly goes offline or there is a sudden increase in packet loss. Network interruption refers to instances where the connection experiences sudden disconnections and session status is lost. Mekya addresses these conditions by persistently sending HTTP requests and responses and actively retransmitting to facilitate autonomous recovery of the connection, thereby minimizing perceptible anomalies for users. Relevant logs are provided in Appendix 2.

Conclusion

This article aims to promote the mekya protocol and does not extensively address its existing limitations. These limitations include the need for enhanced performance utilization and the fact that the mkcp protocol does not fully comprehend HTTP transmission mechanisms and characteristics. Therefore, meticulous parameter adjustments are required to optimize network performance and improve connection and response speeds. The most suitable protocol is the one that aligns best with the needs of individual users, and there is no need for mutual criticism over protocol choices. Unimplemented protocols, such as SplitHTTP, have offered valuable insights and inspiration for the design of the mekya protocol. In the future, should time and opportunities permit, further exploration of the outstanding features of these protocols may be pursued.

At present, the mekya protocol is in the final stages of optimization and has not yet been officially incorporated into V2Ray. Nevertheless, it is available for experimentation in engineering mode starting from version 5.17 and subsequent releases. Configuration examples are available at:#3120

The latter part of the title, 'May the ray scatter amidst the wind and snow,' reflects the design philosophy of the mekya protocol. Mekya greatly improves connection speeds over meek while preserving compatibility with HTTP Reflectors (such as forwarding tools, reverse proxies, and CDNs). Each HTTP request, akin to a ray, is scattered by a variety of forwarding services, much like snowflakes drifting through the sky, ultimately illuminating the path ahead. May V2Ray, through this protocol, emit a brighter light that can be scattered by snowflakes amidst the wind and snow!

Quick Q&A session

Q: How is the quota consumption for the forwarding service after deployment?

While viewing the live stream and drafting this document, approximately 500,000 HTTP requests are generated per hour. The traffic consumption is at least equivalent to that consumed by mKCP.

Q: What effect will this have on traffic shape?

Since mKCP essentially mirrors the traffic characteristics of KCP but is transmitted over multiple TCP connections, it can be considered to have relatively less targeted traffic shape at the time of drafting.

Q: ... Everyone uses it, so it's all ineffective... It's unfair to others... CDN abuse…

(Fact Checker note: This question and answer is a satire in response to accusations from others, and has no meaning when translated to English. Shown here for equality purposes only, feel free to skip this.)
As you noted, the number of V2Ray users has diminished, and therefore it no longer affects others.

Appendix

Appendix 1

https://gist.github.com/xiaokangwang/1a99130a498f0eca0e61253d6c791596

Appendix 2

https://gist.github.com/xiaokangwang/161beccb35b7a6e05db4a1ad668cb325

Translator Note

This translation is facilitated by ChatGPT with the following prompt, inspired by prompt generator:

Please ignore all previous instructions. Please respond only in the English language. Do not explain what you are doing. Do not self reference. You are an expert translator that will be tasked with translating and improving the spelling/grammar/literary quality of a piece of text. You have a Professional tone of voice. You have a Technical writing style. Please rewrite the translated text in your tone of voice and writing style. Ensure that the meaning of the original text is not changed. You know term "光芒" should be translated to "ray", if possible. You know term "h2 可反射协议" should be translated to "HTTP/2 Reflect-able Protocol", if possible. You know term "附件" should be translated to "appendix", if possible. You know term "限速" should be translated to "throttle", if possible. You know term "网络抖动" should be translated to "network interruption", if possible. You know term "负载连接" should be translated to "payload connection", if possible. You know term "meek" should be translated to "meek" as is and in lower case, if possible. You know term "mkcp" should be translated to "mkcp" as is and in lower case, if possible. You know term "mekya" should be translated to "mekya" as is and in lower case unless it is positioned at the beginning of a sentence, if possible. You know term "HTTP 反射器（如 反向代理 或 CDN）" should always be translated to "HTTP Reflector (like Reverse Proxy or CDN)" as is. You know term "连接阻塞" should be translated to "stalled connection", if possible. You know term "性能利用率" should be translated to "performance utilization rate", if possible.  You know term "高级用法" should be translated to "advanced use case", if possible. You know term "散射" should always be translated to "scatter", if possible. You know term "流量特征" should always be translated to "traffic shape", if possible.  Present the results as follows: Simplified text translation and expert translation. Please execute the command for the following text:

[lengge86]

期待！！

[zzlinwq]

期待！！

[KGorham123]

期待！！
v2ray用户已经没有那么多，主要是v5的配置格式变化限制了初级使用者（似乎新的协议都 停止了对v4格式的支持）。而v5 config范例少之又少。亲身经历，做一测试在没借鉴情况下的确花了更多的时间。感恩[xiaokangwang]及v2ray成员的无私奉献！

[Fangliding]

对吗 哦对的对的对的

[iambabyninja]

Oh, it's good 👍

[zzlinwq]

SplitHTTP 已经推向市场了。mekya 协议啥时候出呀

[zzlinwq]

愿不鸣则已，一鸣冲天。

[xiaokangwang]

嗯嗯，其实细水长流也可以。。。

[KGorham123]

超大链接数与mkcp会否偏离meek初衷（适用于其他传输协议无法使用的情况），使其出现更容易捕捉的特征

[RPRX]

超大链接数与mkcp会否偏离meek初衷（适用于其他传输协议无法使用的情况），使其出现更容易捕捉的特征

其实据研究，meek 本身就有一些可捕捉的流量特征，SplitHTTP 则比较注重消除自身带来的流量特征，mekya 还需要深入分析

[zzlinwq]

愿不鸣则已一鸣惊人

[RPRX]

毕竟懂的人没多少，我相信大家都期待着我的仅技术性评价：mekya 相对于 meek 肯定更快，但相对于 SplitHTTP 不一定是更快还是更慢

这主要取决于你的网络环境 对单条 HTTP/TCP/QUIC 连接是否有明显限速，与总带宽对比，for example，总带宽的二分之一以下

比如本文的“实验室环境”给你限到 512kB/s，而总带宽至少是它的五倍，仅次于百度网盘，那这种情况下多线程下载肯定能提高速度

那么实际环境是否有单连接限速呢？是有的但没那么夸张，比如 这里 提到的“单条 UDP 限速”就是 Project X 群友用 SplitHTTP H3 over Cloudflare 进行多线程测速时，发现新版本（复用 QUIC）比之前 buggy 版本（不复用 QUIC）的速度慢一点点，好像是五分之四的样子

不过我不确定当前版本的 mekya 是不是复用一条 H2，有没有支持 H3 以及会不会复用 QUIC，据本文描述我觉得应该是开了多条 TCP

其实到五分之四这个比例，虽然意义不大但如果非要极限操作的话也不是不能把带宽拉满，但 mekya 用的是 mkcp 协议，它是一个暴力发包协议，传输相同的内容它本身就是会消耗更多的带宽，它还会确保可靠传输，即会有 TCP over TCP 的反效果，不知道好不好调参解决

所以如果没有明显的单连接限速，mekya 应该是会有反效果的，会比 SplitHTTP 慢一些，而在有夸张的单连接限速时它会比 SplitHTTP 快

[RPRX]

忘记说明，以上分析针对的是单条被代理请求，而现实情况是同时有多条被代理请求，或者被代理的应用程序像 speedtest.net 一样本身就有多线程下载，下个版本的 SplitHTTP 可以用 multiplex controller 把它们分到不同的 TCP/QUIC 连接上，那么跑满本地与 Cloudflare 间的带宽上限是很轻松的（现在有点好奇这里一般是国际出口总限速还是单目标 IP 限速，如果是后者的话分散到多个 IP 上会更快），但这种情况下 mekya 由于多了一层额外的 mkcp，理论上会有降速及延迟不稳定的反效果。不过如果网络丢包率较高且被代理数据量不大，mekya 应该会有更稳定的表现，类似于 PLUX，区别是 PLUX 只针对 UDP 所以不会考虑缓存、重传等，简洁很多。

[rhjdvsgsgks]

xray 有计划加入 mekya 支持吗，就算可能并没有 splithttp 快，作为“v2ray 的超集”保持兼容上游新加的功能还是有必要的吧

[Heicnend3998]

忘记说明，以上分析针对的是单条被代理请求，而现实情况是同时有多条被代理请求，或者被代理的应用程序像 speedtest.net 一样本身就有多线程下载，下个版本的 SplitHTTP 可以用 multiplex controller 把它们分到不同的 TCP/QUIC 连接上，那么跑满本地与 Cloudflare 间的带宽上限是很轻松的（现在有点好奇这里一般是国际出口总限速还是单目标 IP 限速，如果是后者的话分散到多个 IP 上会更快），但这种情况下 mekya 由于多了一层额外的 mkcp，理论上会有降速及延迟不稳定的反效果。不过如果网络丢包率较高且被代理数据量不大，mekya 应该会有更稳定的表现，类似于 PLUX，区别是 PLUX 只针对 UDP 所以不会考虑缓存、重传等，简洁很多。

老王卖瓜，自卖自夸。

[RPRX]

xray 有计划加入 mekya 支持吗，就算可能并没有 splithttp 快，作为“v2ray 的超集”保持兼容上游新加的功能还是有必要的吧

没有

老王卖瓜，自卖自夸。

我只是很客观地讲技术而已，如果我讲的不对早就有人从技术层面反驳了，当然像你这样的 end user 是没有能力听懂的

如果这都叫自卖自夸，那这篇文章该叫什么

[finch71]

求考虑支持“保活”上层 TCP 、反向代理

XTLS/Xray-core#4113 (comment)

[RPRX]

如果我没理解错的话，mekya 这个协议本来就有“保活”上层 TCP 的能力吧，只是 mKCP over HTTP 大概不妥