Mekya协议经过数月的断断续续的开发终于完成了基础调试即将发布，本文旨在与快速展示 mekya协议的亮点以推广该协议，并将其与其他同类协议进行对比。
距离上一个协议的推出也有一段时间了，在这段时间内，有不少人在畅想在更新暂停的期间在做些什么？现在即是答案接晓之时！Meyka 协议经过数月的断断续续的开发终于完成了基础调试即将发布，本文旨在与快速展示 meyka 协议的亮点以推广该协议，并将其与其他同类协议进行对比。那么，立刻上图！
图 1 – 在实验室模拟的恶劣网络环境下不同 h2 可反射协议传输速度的对比
如图 1 所示，在 HTTP 请求下载速度被限速 512 千字节每秒，且加入 100 毫秒的请求延迟的情况下，如 附件1 所描述的配置文件运行的不同协议在以 HTTP 协议下载 32 兆字节的随机文件时有不同的下载速度。其中 meek 的平均下载速度为 37 千字节每秒，SplitHTTP 的平均下载速度为 507 千字节每秒，mekya 的平均下载速度为 2220 千字节每秒。
之所以能够达成这样的下载速度是因为 mekya 协议通过并发连接提高下载速度，减少因为单个连接受到网络抖动或其他原因导致的不稳定影响负载连接的稳定性。在不同的网络环境下不同协议的连接速度会有差异，本图示中所表示的实验中的恶劣网络环境对 mekya 的影响相对较小。
协议设计
那么 meyka 的协议设计和其他协议有什么区别呢？
在 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) | |
|---|---|---|---|
| 传输速度 | ❌ 慢 | 取决于网络状况 | 取决于网络状况 |
| 多线程传输 | ❌ 不支持 | ❌ 仅上载 | ✅ 支持 |
| 依赖流式传输 | ✅ 不依赖 | ❌ 依赖 | ✅ 不依赖，但推荐 |
| 连接阻塞自主愈合 | ❌ 不支持 | ❌ 不支持 | ✅ 支持 |
| 网络抖动自主愈合 | ❌ 不支持 | ❌ 连接崩毁 | ✅ 支持 |
| 协议调参 | ✅ 支持，高级用法 | ❌ 可调参数较少 | ✅ 支持，高级用法 |
| 性能利用率 | ✅ 较低 | ✅ 较低 | ⚠ 高 |
嗯嗯，感觉需要一个小小的名词解释呢，什么是连接阻塞和网络抖动呢？
连接阻塞 就是说当某个特定的连接出现故障，速度突然降低或不再传输数据，但是连接没有被中断的情况。这种情况一般在某个服务器突然掉线，或者丢包率突然上升时产生。网络抖动指连接突然闪断，会话状态丢失的状况。Meyka 在这些环境下会通过持续发送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 的用户已经没有那么多了，所以已经不再会对其他人产生任何影响了呢。