1. MCP的Transport到底在解决什么问题
先说结论：MCP的Transport层是整个协议的地基，它决定了你的MCP server怎么被找到、怎么被连接、怎么传数据、怎么处理断连。前面几篇笔记我分别梳理了MCP的协议模型、工具调用链路和资源体系，这篇专门把Transport单独拎出来写，是因为我在实际搭建和调试MCP服务器的过程中，踩过太多跟传输层相关的坑——有些问题表面上看是业务逻辑错误，查到最后发现根子全在Transport层。
MCP（Model Context Protocol）的定位是让AI应用能够标准化地调用外部工具和数据源。既然是"标准化"，那就必须把传输方式也规范下来，否则各个server用不同的协议、不同的端口、不同的数据格式，AI应用根本没法统一对接。Transport层的作用就是定义一套通用的传输规则，让client和server之间能够稳定地交换JSON-RPC消息。
我最初接触MCP的时候有个误解，以为Transport就是简单的HTTP调用。后来把协议文档和源码看了一遍才发现，MCP在传输层的设计考虑得比我想象中细致得多。它要同时兼顾本地进程通信和远程网络通信两种场景，还要考虑流式响应、双向通信、断线重连这些复杂需求。特别是AI场景下的工具调用往往不是一次简单的请求-响应，而是需要持续的上下文交换，这对传输层的要求比普通API高不少。
从实际用途来看，理解Transport层的价值有三个方面：第一，当你需要自己封装MCP client或server时，Transport层是必须手写的部分；第二，当你遇到连接不稳定、消息丢失、超时等问题时，知道传输层的工作机制能帮你快速定位问题；第三，当你在不同的运行环境（本地 CLI、远程服务器、容器等）之间部署MCP服务时，Transport层的选型直接决定了架构的可行性。
我见过不少人在网上问"需要自己实现MCP还是用现成的"，我的建议是：不管是自己实现还是用现成框架，Transport层的工作原理都值得搞清楚。就算你用的是SDK，SDK内部的传输逻辑出了问题，不懂原理你连日志都看不懂。
2. 两种核心传输方式：Stdio和HTTP的选型逻辑
MCP协议目前主流的Transport方式有两种：Stdio（标准输入输出）和HTTP（包括Streamable HTTP），另外还有实验性的HTTP+SSE方案。我在项目里分别试过这三种，说说我的实际感受和选型逻辑。
2.1 Stdio传输：本地进程通信的主力
Stdio传输的工作方式很简单粗暴：client通过子进程启动server，然后通过标准输入（stdin）往server发消息，从标准输出（stdout）读取server的响应。这种方式的本质是本地进程间通信，不走网络，所以延迟极低，也不存在端口冲突、防火墙拦截这些网络问题。
我在实际项目中用Stdio方式跑过本地MCP server，好处非常明显。首先是部署简单，不需要启动独立服务，client直接拉起子进程就行，对用户来说完全无感。其次是安全，因为通信只发生在本地进程之间，不需要暴露端口，恶意外部请求根本摸不到你的server。再就是调试方便，我可以在终端里手动输入JSON-RPC消息到stdin，直接观察server的响应，排查问题非常直观。
但Stdio也有它天然的局限。由于走的是标准输入输出，server的生命周期跟client绑死了——client退出，server的进程也就结束了。这就意味着它只适合本地场景，没法做远程调用。另外，如果server需要在多个client之间共享，Stdio也做不了，因为每个client都得启动自己的子进程。
我做一个MCP server原型的时候，统一用的都是Stdio方式。当时的考虑是先把业务逻辑跑通，避免网络层引入额外变量。事实证明这个决策是对的，很多人在刚开始写MCP server时就纠结HTTP和网络配置，结果业务逻辑还没调通，先被网络问题折磨得死去活来。我的建议是：初期原型一律用Stdio，跑通了再考虑网络化部署。
2.2 HTTP传输：远程调用的必备方案
当MCP server需要部署在远程服务器上，或者需要支持多个client并发访问时，就必须上HTTP传输了。MCP的HTTP传输走的是Streamable HTTP模式，严格来说它不是传统的REST API，而是基于JSON-RPC over HTTP的封装，支持请求-响应模式和流式模式两种。
我在把本地server迁移到远程时踩了不少坑。最典型的一个是：MCP的HTTP传输默认使用POST方法，但有些中间件、网关或者Serverless平台对POST的路径和body大小有默认限制，导致消息发送失败。另一个坑是CORS——如果client跑在浏览器环境（比如某些Web IDE），server必须正确配置CORS头，否则浏览器的跨域策略会直接拦掉所有请求。
HTTP传输在处理长耗时工具调用时优势尤其明显。比如我这个server里有一个工具需要调用外部API，完整的执行时间可能超过30秒。如果用普通的请求-响应模式，HTTP连接大概率超时。MCP的Streamable HTTP支持SSE（Server-Sent Events）流式返回，server可以先把"接受请求"的响应返回给client，然后通过SSE流把最终结果推给client，这样既避免了超时，又能实现实时进度推送。
2.3 三种方式的对比与适用场景
| 传输方式 | 通信模型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| Stdio | 本地进程间通信 | 本地CLI工具、单用户场景 | 部署简单、安全、低延迟 | 只限本地、无法共享、生命周期绑定 |
| Streamable HTTP | 远程网络通信、支持流式 | 远程服务、多client共享 | 跨网络、支持并发、流式响应 | 需要处理CORS、超时、网络安全 |
| HTTP+SSE（实验性） | 远程网络通信、单向流 | 服务端主动推送场景 | 适合事件通知 | 协议稳定性不如前两者 |
选型逻辑总结成一句话：能本地就本地，必须远程再上HTTP。不要一上来就追求网络化，先想清楚你的使用场景到底是什么。我见过有人把本地MCP server用HTTP方式部署，纯粹是为了"看着专业"，结果平白多了网络安全、端口管理、进程守护一堆事情，完全没有必要。
3. 一次完整的Transport排查实录：stream disconnected before completion
前面铺垫了这么多理论，现在分享一个我最近实际踩到的坑，这个问题在相关热搜词里反复出现："stream disconnected before completion: transport error: network error: error"。我当初看到这个报错时也是一头雾水，现在把完整的排查链路写出来，希望能帮读者省点时间。
3.1 报错出现的场景还原
当时我在做的是一个远程MCP server的联调，client通过HTTP方式连接server。文件上传功能涉及一个需要几秒钟才能完成的工具调用。第一次调用时，client很快就收到了报错，完整的报错信息是：
stream disconnected before completion: transport error: network error: error这个报错信息其实已经透露出关键信息了：连接在stream完整结束之前被断开了，原因是transport层的网络错误。但"network error"本身太笼统，根本没有指明是哪个环节出了问题。我当时的排查链路如下。
第一步：确认server端是否收到了请求。我直接看了server端的访问日志，发现日志里根本没有这次调用的记录。这说明请求压根没到server，或者是到了但没被正确解析。于是我怀疑是网络层的问题。
第二步：用curl直接测试HTTP接口。我在server所在的机器上直接用curl模拟POST请求，结果是正常的，server能正常返回响应。这就排除了server本身的问题，问题出在client到server之间的某个环节。
第三步：检查client端的代理设置。我的client跑在一台开发机上，这台机器配置了HTTP代理。MCP的HTTP传输用的是长连接+流式响应，代理服务器（尤其是公司内部的代理）在处理这种流式响应时，经常会在中间缓存或者提前断开连接。我把client的网络代理关掉，直连server，问题就消失了。
第四步：进一步验证是代理的问题。我把代理重新打开，然后换了一个不涉及流式响应的简单工具调用，发现能正常返回。这就进一步确认了问题出在代理对流式HTTP响应的处理上，而不是MCP协议本身的bug。
3.2 根因分析与处理方案
这个问题的根因是：HTTP代理服务器在处理SSE或chunked传输时，如果代理设置了一个较短的响应超时时间，或者代理缓存了部分响应数据，就会导致client端收到的数据流不完整，最终触发"stream disconnected before completion"。
针对这个情况，我给了两个处理方案：
一个是治标的：在client开发环境的网络配置里，把MCP server的域名加到"不走代理"的列表里。这样做的好处是见效快，缺点是如果用户分布在各种网络环境下，你不可能要求每个人都改代理配置。
另一个是治本的：在server端和client端之间不使用HTTP代理，通过HTTPS直接通信。如果网络环境确实需要代理，那就把MCP的流式响应改成非流式的请求-响应模式。MCP的Streamable HTTP同时支持这两种模式，如果你的场景不是特别需要实时进度推送，建议先走非流式模式，稳定优先。
3.3 超时参数：另一个容易被忽略的坑
排查完代理问题之后，我又顺手梳理了跟传输层相关的超时参数。MCP client连接server时，一般涉及三个超时时间：连接超时（connectTimeout）、读取超时（readTimeout）和整体请求超时（requestTimeout）。
连接超时指的是从client发起TCP连接到server接受连接的最大等待时间，一般设置5-10秒就够了，太短了在跨地域网络下容易误报，太长了用户等待体验会很差。读取超时是client发起请求到收到第一个响应字节的最大等待时间，这个要根据你的工具执行耗时来定，如果你的工具执行要30秒，读取超时至少得设到35秒以上。整体请求超时则是完整的一轮请求-响应所允许的最大时间。
如果server端有工具执行超过30秒，而client端只给了10秒的读取超时，那client就会主动断连，表现出的症状跟上面的stream disconnected几乎一样，但根因完全不同。我的建议是：排查断连问题时，一定要把server端的工具执行耗时和client端的超时配置对照着看，两边都要收敛。
4. 从零手写一个MCP Transport：JSON-RPC消息的封与拆
前面说的都是基于SDK的MCP开发，但我知道很多人想搞清楚Transport层的内部实现。这里我用手写的方式拆一下Transport的封装与解析过程，原理弄懂了，SDK的错误日志一眼就能看懂。
4.1 JSON-RPC消息格式与封装流程
MCP的传输层传送的是一系列JSON-RPC 2.0格式的消息。一个标准的MCP消息有两种：一种是请求消息，带id和method，另一种是通知消息，没有id。在Stdio传输里，每条消息通过换行符分隔；在HTTP传输里，消息体放在POST请求的body里，响应则通过SSE流输出。
我举个Stdio传输的例子。假设client要调用server上一个叫fetch_data的工具，发出去的消息长这样：
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"fetch_data","arguments":{"url":"https://example.com"}}}server收到这条消息后，解析method字段，发现是tools/call，然后根据params.name调用对应的工具函数，最后把执行结果包装成响应消息：
{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"{\"status\":\"ok\",\"data\":\"...\"}"}]}}Transport层要做的事情就是把这个过程标准化：发消息时把JSON对象序列化成字节流，加消息边界（换行符）；收消息时按边界拆出完整消息，反序列化成JSON对象，再按jsonrpc、id、method这些字段去分发。看起来简单，但实际要考虑的边界情况不少。
4.2 消息标识与错误处理
MCP的消息通过id字段来关联请求和响应，所以id的唯一性很重要。我见过有人用自增的数字做id，在多线程并发请求时经常出现id冲突，导致响应关联错乱。建议直接用UUID或者时间戳+随机数。
错误处理方面，JSON-RPC规定了标准的错误码：-32700是解析错误、-32600是无效请求、-32601是方法不存在、-32602是无效参数、-32603是内部错误。Transport层要做的就是正确地把这些错误码封装进响应里。比如client发来一个server没注册的method，Transport层至少要能识别出这是"方法不存在"还是"内部错误"，不能让所有错误都吞成一个笼统的异常。
我在手写Transport时的经验是：日志怎么详细都不为过。每收到一条消息就打印一条debug日志，标明消息id、method、方向（in/out），出问题的时候对照日志能省下大量排查时间。MCP server在生产环境的日志尤其要舍得打，因为AI场景下client往往不会重试，一次失败就直接换方案了。
4.3 流式响应的通信时序
当工具调用需要长时间执行时，MCP走的是流式响应模式。以HTTP传输为例，通信时序是这样的：client先发一个POST请求，server立刻返回HTTP 202表示"请求已接受"，同时通过SSE流持续往后推消息。这些消息可以是进度通知（notification），也可以是最终结果（result）。
下面是我手写的一个简化版SSE消息示例：
event: message data: {"jsonrpc":"2.0","method":"notifications/progress","params":{"progress":50,"total":100}}event: message data: {"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"done"}]}}client端收到这两条消息，先更新进度再拿到结果。这种设计的好处是，server不需要维持一个长期的HTTP连接，每次都是短连接+SSE流，配合负载均衡和自动扩缩容都很方便。
5. 环境差异对Transport的影响：本地、远程、受限环境
MCP server跑在什么环境里，直接决定了Transport策略。我分别说说本地环境、远程服务器和受限网络环境下的经验和坑。
5.1 本地环境：优先考虑进程生命周期管理
本地用Stdio方式启动MCP server，最大的坑是进程生命周期管理。如果client异常退出，server进程可能变成僵尸进程继续占用资源；反过来，如果server内部出现了未捕获的异常，进程悄悄退出，client侧的表现就是"连接被关闭"。
我现在的做法是在server的入口位置加一个极简的进程守护：捕获退出信号、处理未捕获异常、结束时把错误信息写到stderr。MCP client通常会读取server的stderr作为诊断信息，这一点很实用——server崩溃时，错误原因能直接显示在client日志里，而不会只显示"连接断开"。
5.2 远程服务器：端口、TLS、反向代理
远程部署MCP server，常见的有两种架构：直接用HTTP服务监听端口；或者用Nginx等反向代理转发到内部服务。我的建议是用反向代理，因为能在代理层统一处理TLS、限流、日志，而且是HTTP，IL。
反向代理配置MCP server时要注意一个点：MCP的SSE流式响应依赖chunked传输编码，Nginx默认是支持这种编码的，但如果有缓存模块开启了缓存，流式响应可能被截断。另外，如果代理层配置了缓冲（proxy_buffering），也可能导致SSE消息不实时。我一般会在MCP server对应的location里显式关闭代理缓冲：
location /mcp { proxy_pass http://127.0.0.1:8080; proxy_buffering off; proxy_cache off; proxy_set_header Connection ''; proxy_http_version 1.1; }这段配置里最关键的是proxy_buffering off，它确保SSE的每条消息都能及时转发给client，不会因为代理层的缓冲导致数据积压。proxy_http_version 1.1则是为了保证chunked transfer encoding正常工作。
5.3 受限网络环境和移动端
如果MCP server要跑在移动端或嵌入式设备上，网络环境就比较复杂了。移动端经常出现网络切换（WiFi切4G）、弱网、IP地址变化等情况，TCP长连接很容易断开。MCP协议本身没有内置重连机制，这部分逻辑需要client自己实现。
我在移动端的做法是：在Transport之上增加一层"心跳+自动重连"机制。心跳使用JSON-RPC的notifications/ping消息，每30秒发一次，如果连续3次没有收到pong响应，就主动断开重建连接。注意notifications/ping不是MCP协议的核心method，但它作为通用JSON-RPC方法，MCP SDK通常是支持的。
移动端的另一个坑是后台运行时的资源限制。操作系统可能随时挂起或杀掉后台进程，一旦进程被杀，TCP连接自然就断了。MCP场景下，client通常是AI应用，AI应用的进程在前台活动的时间比较长，后台挂起的概率相对低一些，但如果做的是后台任务型应用，就要额外考虑网络恢复后的数据同步问题。
5.4 容器环境下的Transport特例
最近容器环境跑MCP也比较常见了。容器环境下，MCP server的Transport层设计要考虑一个特殊情况：同一个MCP server可能要同时服务多个client，而每个client希望看到独立的会话状态。这时候Server端需要根据client的会话ID维护各自独立的上下文。
MCP协议在设计上其实是支持这种场景的，通过Streamable HTTP方式和SESSION-ID管理。容器调度起来果然方便，正因为如此，在容器里跑MCP server时要特别注意会话状态管理，不要在服务实例间共享可变状态，否则会话串了，AI的行为表现会很奇怪。
6. MCP Transport的未来方向与个人实践建议
最后聊聊趋势和我的几点体会。MCP的Transport层整体演进方向是：稳定、流式化、贴近AI场景。从最初的HTTP+SSE实验方案，到现在的Streamable HTTP标准化，明显能看出协议在设计时的取舍——它不想发明新传输协议，而是尽量复用现有的HTTP基础设施，降低各方的接入门槛。
另外，围绕Transport层的工具生态也在逐步成熟。像mcpCLI工具就提供了Transport的启动、连接、调试能力，可以在本地快速验证server能不能正常响应。我习惯用mcp dev来启动server做交互调试，用mcp inspector来检查server暴露的工具列表和能力，这样能把Transport层的连通性验证前置，不会等到client端联调才发现问题。
关于使用现成的SDK还是自己实现Transport，我的观点是：如果能用SDK，优先用SDK。尤其是官方维护的TypeScript和Python SDK，把很多容易踩坑的细节都处理好了，比如消息格式、流式处理、错误码。但你一定要了解SDK帮你做了什么，否则出了问题你连排查方向都没有。
我的实际工作流是这样的：先确认client和server的SDK版本兼容性，再确认Transport模式（Stdio还是HTTP），然后用mcp inspector快速验证连通性和工具可用性，最后再进入业务联调。这套流程帮我躲过了绝大部分transport层面的坑，也让我在遇到真正的问题时能快速定位。
在实际跑MCP项目的这几个月里，我最大的体会是：Transport层在整个MCP协议栈里虽然最"不值钱"（写业务逻辑的人往往先忽略它），但它恰恰是决定一个MCP server能不能真正用起来的关键。本地demo随便写写就能跑通，到了远程、到了多客户端并发、到了移动网络环境下，Transport层的设计功力就能见高下了。
