通信协议—自定义URL Protocol 协议、SSE、Http、UDP、TCP、MQ

        近日在推进项目开发的过程中，我接触并深入学习了一系列全新的通信协议，诸如 URL Protocol、 SSE（服务器推送事件）等。在实际项目应用里，这些协议各司其职，发挥着不可替代的关键作用。不过，由于当时项目进度紧迫，我未能静下心来深入探究这些协议背后的原理与内涵。如今项目暂告一段落，我便抽空对所学的这些通信协议进行了系统梳理与简要汇总，以下将逐一展开介绍。

自定义URL Protocol 协议

定义

        URLProtocol是一个用于自定义网络请求处理的类，可以让你拦截和处理URL请求。自定义URL Protocol（也称为自定义URL方案）允许开发者创建一个特定的URL格式，通过该格式，用户可以在浏览器中启动特定的应用程序或执行特定的操作。例如，常见的如迅雷的thunder://协议、电驴的ed2k://协议等，都是自定义URL Protocol的实例。

        当用户在浏览器中点击这类URL时，浏览器在解析到自定义URL Protocol之后，会寻找注册表，然后通过注册表启动相应的程序，然后启动改程序，传入参数。

实现方式

        1、协议注册   

HKEY_CLASSES_ROOT
   └── myapp          # 自定义协议名
       ├── URL Protocol  # 协议标识（声明当前注册项为URL协议处理器，决定系统是否为合法协议）
       └── shell      # 操作容器（核心项，若缺少shell层级，协议将无法触发应用程序）
           └── open   # 默认操作（可扩展其他操作类型（如print、edit等），浏览器默认调用open）
               └── command  # 执行命令（必须位于shell\open下	指定可执行文件路径及参数）

   假设你要注册 myapp:// 协议，并让它启动应用程序 C:\Program Files\MyApp\MyApp.exe，注册表结构应如下所示：

HKEY_CLASSES_ROOT
   └── myapp
       ├── (Default) = "My Application Protocol"
       ├── URL Protocol = ""
       └── shell
           └── open
               └── command
                   └── (Default) = "C:\Program Files\MyApp\MyApp.exe"  "%1"   //%1必须保留以接收完整URL

2. 验证协议是否工作

1. 打开浏览器或运行窗口（Win + R）。
2. 输入 myapp://somepath，并按下回车。
3. 如果配置正确，浏览器或系统会打开 MyApp.exe 并将 somepath 传递给应用程序。

3. 实现解析自定义协议的参数

        在你的应用程序中，你需要实现代码来解析通过自定义协议传递的参数。

using System;
using System.Diagnostics;
using System.Threading;
using System.Web;

class Program
{
    [STAThread]
    static void Main(string[] args)
    {
        try
        {
            // 解析参数
            if (args.Length > 0)
            {
                string url = args[0];
                Uri uri = new Uri(url);

                // 验证协议头
                if (!uri.Scheme.Equals("myapp", StringComparison.OrdinalIgnoreCase))
                    throw new UriFormatException("Invalid protocol scheme");

                // 解析操作指令
                string action = uri.Host; // 获取主机部分作为操作类型
                var parameters = HttpUtility.ParseQueryString(uri.Query);

                // 解码参数
                string param1 = HttpUtility.UrlDecode(parameters["param1"]);
                int param2 = int.Parse(parameters["param2"] ?? "0");

                // 执行操作
                ProcessCommand(action, param1, param2);
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Error processing command: {ex.Message}");
#if DEBUG
            Console.ReadKey();
#endif
        }
    }

    static void ProcessCommand(string action, string param1, int param2)
    {
        Console.WriteLine($"Received command:");
        Console.WriteLine($"Action: {action}");
        Console.WriteLine($"Param1: {param1}");
        Console.WriteLine($"Param2: {param2}");

        // 添加你的业务逻辑
        switch (action.ToLower())
        {
            case "open":
                Console.WriteLine("执行打开操作...");
                break;
            case "save":
                Console.WriteLine("执行保存操作...");
                break;
            default:
                throw new NotSupportedException($"未知操作: {action}");
        }
    }
}

SSE

定义

        SSE（Server-Sent Events）是一种基于 HTTP 协议的推送技术。服务端可以使用 SSE 来向客户端推送数据，但客户端不能通过SSE向服务端发送数据。相较于 WebSocket，SSE 更简单、更轻量级，但只能实现单向通信。

实现步骤

• 服务端实现: 使用支持 SSE 的服务器端技术（如Node.js的express框架），在 HTTP 头部添加特定的 Content-Type（text/event-stream）和其他 SSE 相关字段，定期向客户端发送数据。

res.writeHead(200, {
  'Content-Type': 'text/event-stream',
  'Cache-Control': 'no-cache',
  'Connection': 'keep-alive',
});

res.write('data: Hello\n\n'); // 发送数据给客户端

• 客户端实现: 使用 JavaScript 创建一个 EventSource 对象，监听从服务器发送的事件。

  var eventSource = new EventSource('/sse-endpoint');
  
  eventSource.onmessage = function(event) {
    console.log('Received event: ', event.data);
    // 处理接收到的数据
  };
  

  为什么大模型使用SSE而不是websocket

        1、实现成本

时间

WebSocket成本 = TCP握手(1次RTT) + TLS1.2握手(2次RTT) + Upgrade: websocket 请求(1次RTT) ，共计4次RTT。（如果是TLS1.3，可以做到0~1次RTT）

SSE成本 = HTTP长连接(1次RTT) + TLS ，会减少一次协议升级的RTT

Client                                        Server
   | -------------- SYN --------------------> |   ← 第一次握手
   | <----------- SYN + ACK ---------------- |   ← 第二次握手
   | -------------- ACK --------------------> |   ← 第三次握手

内存

        WebSocket需维护全双工长连接，每个连接占用独立线程或内存资源，而SSE通过HTTP长连接实现推送，服务器资源消耗更低，适合高并发场景

兼容性

        SSE基于HTTP协议，无需额外协议升级（如WebSocket的ws:///wss://），可直接复用现有HTTP端口（80/443），减少防火墙或代理配置问题。现代浏览器原生支持EventSource API，兼容性优于WebSocket的部分限制

格式

        SSE支持纯文本或JSON流式传输，与大模型输出的结构化数据（如Token序列、置信度）天然契合。WebSocket虽支持二进制数据，但需额外编码解析

2.单向数据流需求

        大模型的核心场景是流式文本生成，用户输入请求后，服务器需持续推送生成的文本片段。这种场景下，通信方向是单向的（服务器→客户端），而WebSocket的全双工通信能力（双向交互）反而冗余。

        当用户输入问题后，模型逐词生成回答，客户端无需中途向服务器发送额外数据。

3.流式信息的不均衡性

        大模型的输出Token量通常远大于输入（如输入10字问题，生成500字回答）。SSE的单向推送机制能高效处理这种**“稀疏请求，密集响应”**模式，避免WebSocket双向通道的资源浪费

4.断线重连天然支持

        SSE内置自动重连机制（默认3秒重试），支持通过Last-Event-ID头部恢复断连后的数据流，适合大模型长文本生成场景的网络波动容错。而WebSocket需手动实现心跳检测与重连逻辑

        SSE的核心优势在于将协议复杂度降至最低，精准匹配大模型的单向流式需求，同时通过HTTP生态的成熟性保障稳定性和兼容性。而WebSocket更适用于实时双向交互场景（如在线协作、聊天室）。技术选型时需遵循“用对的，而非用贵的”原则

其它通信协议：Http、UDP、TCP、MQ

以下是HTTP、UDP、TCP和MQ四种通信协议的简要说明：

1. HTTP（超文本传输协议）

• 协议类型：基于TCP的应用层协议。
• 特点：
  • 请求/响应模型：客户端发起请求，服务器返回响应，通信结束后连接通常关闭（HTTP/1.1支持持久连接）。
  • 无状态：服务器不保存客户端状态，每次请求独立处理。
  • 简单快速：适用于网页浏览、API通信等场景。
• 适用场景：网页浏览、RESTful API、文件传输等。

2. UDP（用户数据报协议）

• 协议类型：传输层协议。
• 特点：
  • 无连接：发送数据前无需建立连接，传输速度快但不可靠。
  • 不可靠传输：不保证数据包顺序、不重传丢失包，适合实时性要求高的场景。
  • 面向数据报：以独立的数据报为单位传输，首部开销小。
• 适用场景：视频流、音频流（如VoIP）、在线游戏、DNS查询等。

3. TCP（传输控制协议）

• 协议类型：面向连接的传输层协议。
• 特点：
  • 可靠传输：通过序号、确认号、重传机制等保证数据按序、不丢失、不重复。
  • 流量控制与拥塞控制：通过滑动窗口和拥塞窗口机制避免网络拥塞。
  • 全双工通信：支持双向数据传输。
• 适用场景：文件传输、网页加载、电子邮件、FTP等需要高可靠性的场景。

4. MQ（消息队列协议，如AMQP、MQTT）

• 协议类型：应用层协议，用于消息队列中间件。
• 特点：
  • 异步通信：发送者与接收者解耦，消息暂存于队列中，支持异步处理。
  • 发布/订阅模型：支持一对多、多对多的消息分发。
  • 可靠性：支持消息持久化、确认机制、事务等功能。
• 常见协议：
  • AMQP：高级消息队列协议，支持多种交换器类型和灵活的绑定规则。
  • MQTT：轻量级发布/订阅协议，适用于物联网设备通信。
• 适用场景：异步任务处理、系统解耦、流量削峰、物联网设备通信等。

协议	类型	可靠性	通信模型	适用场景
HTTP	应用层（基于TCP）	可靠	请求/响应	网页浏览、API通信
UDP	传输层	不可靠	无连接	视频流、在线游戏、DNS查询
TCP	传输层	可靠	面向连接	文件传输、网页加载、电子邮件
MQ（如AMQP、MQTT）	应用层	可配置	发布/订阅	异步任务处理、系统解耦、物联网设备通信