4. Diameter协议基础：架构、路由、应用层与SS7互操作
各位好，我是老周。今天咱们聊聊Diameter协议。说实话，在核心网漫游这个领域，Diameter可以说是绕不开的坎儿。我最早接触它是在做LTE漫游测试的时候，那时候SS7还没完全退网，两套协议混着用，踩了不少坑。今天我把这些经验掰开揉碎，跟大家好好说说。
4.1 Diameter协议架构
Diameter不是凭空冒出来的。它脱胎于RADIUS，但比RADIUS强太多了。你想想看，RADIUS用UDP，可靠性靠应用层自己保证，而且没有端到端的安全机制。Diameter直接把这些短板都补上了。
Diameter的架构，说白了就是三个核心要素：节点、连接和会话。
- 节点：包括客户端、服务器和代理。代理又分中继代理、重定向代理、代理代理和转换代理。我在项目里用得最多的是中继代理，它负责把消息转发到正确的目的地，自己不做业务逻辑判断。
- 连接：Diameter使用TCP或SCTP。我个人习惯用SCTP，因为它支持多宿主和多流，可靠性更高。记得有一次现网故障，就是TCP连接被中间防火墙重置了，换成SCTP后问题再没出现过。
- 会话：一个会话对应一次业务交互，比如一次鉴权或一次计费。会话ID是全局唯一的，这个一定要保证，否则计费对账会出大问题。
核心要点：Diameter的架构设计，本质上是为了解决RADIUS在可靠性、安全性和扩展性上的不足。每个节点都支持能力协商，这在漫游场景下特别重要——不同厂商的设备能力不一样，协商失败就直接拒绝服务。
4.2 Diameter路由
路由是Diameter最让我头疼的部分，也是攻击者最喜欢下手的地方。为什么？因为路由决定了消息往哪儿走，一旦被篡改，整个漫游链路就乱了。
Diameter路由的核心机制是逐跳路由。每个节点根据消息中的Destination-Realm和Destination-Host来决定下一跳。这里有个关键点：Realm是域名级别的标识，Host是具体设备标识。
我画了一张图，帮大家理解路由的流转过程：
这张图展示了一个典型的漫游路由场景。客户端先发请求到中继代理，中继代理查重定向代理拿到目标地址，再转发给服务器。应答原路返回。嗯，这里要注意：路由环路是Diameter网络里最隐蔽的问题。我曾经遇到过一次，两个中继代理互相转发，消息永远到不了目的地，最后超时导致漫游用户无法注册。
避坑指南：我曾经在配置Diameter路由时，忘记设置Hop-by-Hop Identifier的唯一性检查。结果现网出现消息ID冲突，导致计费话单错乱。后来我强制要求所有节点必须做ID去重校验，问题才彻底解决。
4.3 Diameter应用层协议
Diameter的应用层协议，说白了就是定义了一堆AVP（属性值对），用来承载具体的业务数据。漫游场景下，最常用的几个应用是：
| 应用名称 | 应用ID | 主要用途 | 我在项目中遇到的坑 |
|---|---|---|---|
| Diameter基础协议 | 0 | 能力协商、连接维护 | 能力协商失败导致连接断开 |
| NASREQ | 1 | 网络接入鉴权 | AVP顺序不对被对端拒绝 |
| Credit-Control | 4 | 在线计费 | 余额不足时重试风暴 |
| Sh接口 | 15 | 用户数据查询 | 数据同步延迟导致用户状态不一致 |
每个应用都有自己的命令码和AVP集合。比如NASREQ的AA-Request（命令码265）用于鉴权，Credit-Control的CC-Request（命令码272）用于计费。你想想看，如果攻击者伪造一个CC-Request，把扣费金额改成负数，那运营商就得倒贴钱给用户了。这不是开玩笑，我在安全审计时真的发现过这种漏洞。
警告：应用层AVP的合法性校验绝对不能省。特别是那些数值类型的AVP，比如CC-Money（AVP码413），一定要做范围检查。我曾经见过一个案例，攻击者把CC-Money设成极大值，导致计费系统整数溢出，直接崩溃。
4.4 Diameter与SS7互操作
这是最让我感慨的部分。SS7是电信网的元老，Diameter是IP网的新贵。两者互操作，说白了就是新老交替时期的过渡方案。但问题是，这个过渡期比所有人预想的都要长。
互操作的核心是协议转换。SS7用TCAP、MAP这些协议，Diameter用AVP。转换网关要做的事情，就是把MAP操作码映射成Diameter命令码，把MAP参数映射成AVP。
举个例子，MAP的Send Authentication Info操作，对应到Diameter就是MAR（Multimedia-Auth-Request）。MAP里的IMSI参数，对应到Diameter的User-Name AVP。看起来简单，但实际做起来全是坑。
我列几个常见的互操作问题：
- 超时机制不同：SS7的超时是秒级的，Diameter是毫秒级的。转换网关如果处理不当，SS7那边还没响应，Diameter这边已经超时重发了。
- 错误码映射：SS7的Error Code和Diameter的Result-Code不是一一对应的。比如SS7的System Failure（47）映射到Diameter的DIAMETER_UNABLE_TO_COMPLY（3002），但有些厂商自己定义了扩展错误码，映射表得手工维护。
- 地址格式：SS7用GT（Global Title），Diameter用FQDN或IP。转换网关需要维护一个GT到FQDN的映射表。这个表如果不同步，漫游用户就找不到归属网络。
我的经验：在做SS7与Diameter互操作测试时，我建议重点关注超时和重传。我曾经遇到一个场景：SS7网络延迟大，Diameter网关连续重传了3次请求，SS7那边收到3个一模一样的请求，处理了3次，导致用户被重复扣费。后来我们在网关层做了去重处理，才解决这个问题。
还有一个容易被忽视的点：安全上下文。SS7网络默认是信任的，几乎没有安全机制。Diameter有TLS/DTLS和IPsec。互操作时，转换网关必须处理好安全边界的切换。我见过一个案例，SS7侧过来的请求没有做任何校验，直接透传到Diameter侧，结果被攻击者利用SS7的漏洞攻击了Diameter网络。
好了，关于Diameter协议基础，我就说这么多。这些内容看起来是基础，但每一个点背后都有血泪教训。做核心网安全，基础不牢，地动山摇。希望大家在实际工作中，能把今天讲的内容用起来。