企业官网建设流程全解析

简介：面向通信网络工程师、协议研究人员及高校通信专业学生，这份压缩包提供了围绕七号信令（SS7）协议栈的完整学习资料。内容覆盖消息传递部分（MTP）、信令连接控制部分（SCCP）、事务处理应用部分（TCAP）等核心层次，并延伸到信令网架构、信令点与转接点职责、信令数据单元格式、SS7与IP网络融合、协议安全漏洞及防护等主题；资料中的大量JPG截图与HTM网页文档相互配合，可对照查看协议字段、信令流程和网络拓扑示意，适合作为自学入门、课程设计以及日常排障的参考手册。压缩包共607个文件，以465张JPG和138个HTM为主，辅以少量HTML说明与文本资料，整体大小约3.43MB，体积紧凑、便于离线查阅。已有368人浏览学习，适合需要快速建立SS7知识体系的技术人员下载使用。

1. 七号信令的前置认知：从 ss7.rar 里的那一堆 pcap 说起

打开一个名为 ss7.rar 的资源包，最先看到的往往不是程序，而是一堆 .pcap 和十六进制 dump——这正是七号信令（SS7，Signaling System No.7）协议分析最典型的开场。SS7 是电信网络控制面的统一协议族，呼叫建立、位置更新、短信投递、号码携带，全靠它在一台台交换机之间传递消息。

SS7 与普通 IT 协议最大的差异是“共路”。信令不再跟着每一条话路走，而是集中在独立的 64kbps 信令链路里批量转发，网络协议分析里那条看不见的控制面，就归 SS7 管辖。核心网运维、信令监测开发，甚至只是想从抓包回溯一次呼叫为什么失败，都得先看懂 MTP3 路由标签和 ISUP 的 IAM。

下面按协议栈分层把 SS7 拆开讲，然后用 Wireshark 过滤命令和一段 Python 手工解码，把一次呼叫还原到主被叫号码。新手能照步骤跑通，熟手直接看最后一章的 DPC 与 SLS 排错参数。

2. SS7 协议栈的分层逻辑：从 MTP 到 MAP 的消息封装

2.1 共路信令与随路信令：为什么 SS7 要单独建一张网络

早期电话网用的是随路信令，每个话路时隙里抽几个比特做振铃、摘机、占用，信令带宽被卡死在几十 bit/s 量级，能表达的状态也有限。七号信令把信令集中到专用的 64kbps 信令链路，一条链路能支撑上千条话路的控制消息，这在信令容量上是完全不同的设计。

也正是因为“信令有自己的一张网”，SS7 才需要完整的网络层：普通网络协议只需要节点，SS7 要区分信令点（SP）和信令转接点（STP），要让消息在信令点之间逐跳转发，还要在链路故障时倒换到备用链路。这套设计的最直接结果，就是下面的 MTP 三层，它是一切 SS7 分析的地基。

2.2 MTP1/MTP2/MTP3：信令链路、差错控制和路由选择的分工

MTP1 只负责物理层，常见载体是 E1/T1 里的一个 64kbps 时隙，抓包里它表现为一路裸时隙数据。MTP2 负责帧同步和差错控制：每一帧带前向序号和反向序号（FSN/BSN），收端用 BIB/SIB 两个标志位通知对端哪一帧要重传，这套机制保证了信令消息几乎不丢不错。

MTP3 才是分析时最常碰到的层。它用目的信令点编码（DPC）、源信令点编码（OPC）决定消息往哪走，用信令链路选择码（SLS）在各链路组之间做负荷分担。国内国标和 ANSI 用 24 位信令点编码，按 8+8+8 分成主信令区、分信令区和信令点号；ITU 的 14 位编码常见于国际关口局。抓包时用 24 位还是 14 位解析，直接决定路由标签能否读对，这点在最后一章排错时还会用到。

2.3 ISUP、SCCP、TCAP、MAP：上层协议按什么业务来选

MTP 之上按业务方向分成几大用户部分。传统语音走 ISUP，它用电路识别码（CIC）把信令消息对应到某一条中继电路；移动业务走 SCCP+TCAP+MAP 这条链，SCCP 在点编码之外引入了子系统号（SSN）和全局码（GT）寻址，TCAP 把一次查询封装成事务，MAP 才是真正执行“位置更新”“取路由”的操作原语。IP 化之后的信令网（SIGTRAN）里，MTP3 以上的内容原封不动，只是承载由 TDM 换成 SCTP 之上的 M2PA 或 M3UA，这也是现在抓包文件里最常见的形态。

SS7 协议栈各层职责对照

下面这段 Python 展示 MTP3 路由标签的最小拆分，解析思路在第四章手工解码时要直接复用。它按 24 位编码展开，DPC、OPC 各占 3 字节，SLS 占 1 字节。

import struct def split_mtp3_user(msu: bytes): # msu 是 MTP2 去帧后的 MTP3 消息体 sio = msu[0] # 业务指示语字节 si = sio & 0x0F # 低4位: 5=ISUP, 3=SCCP dpc = int.from_bytes(msu[1:4], "big") # 目的信令点编码 opc = int.from_bytes(msu[4:7], "big") # 源信令点编码 sls = msu[7] # 信令链路选择码 return si, dpc, opc, sls, msu[8:] # 剩余部分交给 ISUP/SCCP

int.from_bytes(..., "big")把三个字节拼成一个整数，打印出的就是类似 512345 的信令点号；sls取到的是原始字节，不同标准里位宽有 4/5/8 位之分，Wireshark 的mtp3.sls字段会按协议版本自动换算，手动解析时不要拿它和抓包显示值直接做二进制比较。返回值里的最后一段msu[8:]才是 ISUP 或 SCCP 的起点。

3. 用 Wireshark 和 tshark 打开 SS7 抓包：链路类型判断与过滤字段

3.1 先判断抓包里的链路承载：TDM、M2PA 还是 M3UA

拿到一个 SS7 抓包，第一步不是过滤，而是看协议树根层是什么。SIGTRAN 抓包顶部一般是 SCTP，下面跟着 M3UA 或 SUA，再往下才是 MTP3，Wireshark 会自动逐层解开，直接展开mtp3节点就能看到 DPC/OPC/SLS。如果抓到的是 E1/T1 裸链路，顶部会是 MTP2 相关内容，需要进入Protocols → MTP2，或对帧执行右键Decode As，把链路层明确指到 MTP2/MTP3。用 tshark 时对应-d参数，具体取值先跑一下tshark -d help看你安装版本里的解码器名。

3.2 几组常用的 SS7 显示过滤器

注意点编码的过滤写法。Wireshark 界面里 DPC 显示成“区-分-点”这类带分隔的形式，但过滤条件里写的是整数值，mtp3.dpc == 2580是在拿解码后的整数做比对。拿不准某个字段名时，展开协议树，右键任意字段选Copy → Field Name，它给出的就是过滤表达式里的准确写法。

3.3 用 tshark 把信令字段导成表格做统计分析

一次呼叫的关键字段无外乎 OPC、DPC、SLS、CIC、消息类型和主被叫号码。下面命令一次把它们抽成 CSV，方便直接进 Excel 或 pandas：

tshark -r ss7.pcap -Y "mtp3.si == 5" \ -T fields -E header=y -E separator=, -E quote=d \ -e frame.time -e mtp3.opc -e mtp3.dpc -e mtp3.sls \ -e isup.cic -e isup.message_type \ -e isup.calling_party_number -e isup.called_party_number

-Y先做显示过滤，mtp3.si == 5表示只要 ISUP 消息，把 TUP、SCCP 全部挡在门外；-T fields进入字段输出模式，-e每写一次就多导出一列，-E控制表头、分隔符和引用符，quote=d用双引号包住号码字段，避免号码里的空格把 CSV 列撑破。对照导出结果，如果同一个isup.cic上出现多组 IAM/REL，说明这条电路被反复占用释放，配合-e frame.time就能拉出逐电路的时间线。

4. 手工解析一条 IAM 消息：从路由标签到被叫号码

4.1 IAM 在信令流程里的位置与消息类型对照

一次普通局间呼叫，最少四到六条 ISUP 消息就能闭环：发起端先发 IAM 占用电路，对端回 ACM 表示开始振铃，被叫接听后回 ANM，任一方挂机会发 REL，最后对端确认 RLC。排障时数消息数量就能判断卡在哪一步：久久不见 ACM，多半是被叫侧或承载侧出了问题；ACM 到了却没有 ANM，问题往往在被叫用户侧。

4.2 被叫号码的 BCD 解码：奇偶标志与 0xF 填充

ISUP 的字段分成固定参数和变长参数两类，被叫号码属于变长参数。号码本身用 BCD 半个字节表示一个数字，先传个位再传十位，位数是奇数时最后一个半字节填 0xF 做填充。下面是演示用的 IAM 载荷，CIC 为 1，消息类型为 0x01，被叫号码参数从偏移 3 开始：

import struct def bcd_decode(buf: bytes) -> str: digits = [] for b in buf: lo, hi = b & 0x0F, (b >> 4) & 0x0F if lo != 0x0F: digits.append(str(lo)) if hi != 0x0F: digits.append(str(hi)) return "".join(digits) def parse_iam_for_demo(): upper = bytes.fromhex("0001 01 83 31 08 10 83 00 0F".replace(" ", "")) cic = struct.unpack(">H", upper[0:2])[0] & 0x0FFF # CIC 低12位有效 msg_type = upper[2] if msg_type != 0x01: return None oei = (upper[3] >> 7) & 0x01 # 1 表示奇数个地址信号 called = bcd_decode(upper[4:]) return cic, oei, called print(parse_iam_for_demo()) # (1, 1, '13800138000')

bcd_decode对每个字节先取低半字节再取高半字节，遇到 0xF 就跳过，奇偶两种填充方式都能兼容。upper[3]的第一个比特是奇偶标志，演示值 0x83 最高位为 1，表示 11 位奇数号码，与 BCD 解码得到的 13800138000 吻合。这里为了演示跳过了 IAM 的固定参数区，真实环境里被叫号码之前还有主叫用户类别、转发呼叫指示等字段，必须按 Q.763 的参数指针逐个跳到目标偏移，否则会把固定参数当成号码解出来；拿一条 tshark 导出的isup.called_party_number与实际字节对照，是最快的校验办法。

提示：把上面upper的开头拼上第二章split_mtp3_user需要的 MTP3 头，用 Wireshark 的Import Hex Dump导入，解码出的被叫号码应该和手工结果一致，这是验证解析器最直接的方式。

4.3 从 SCCP 的 SSN 判断消息发往哪类移动网元

移动业务里，SCCP 消息的目的地址由 DPC+SSN 组成，SSN 说明消息要交给交换机里的哪个功能实体。常用子系统号如下表，按sccp.ssn == 6过滤就能把发往 HLR 的请求单独拉出来。

实际组网里，MSC 往往不知道 HLR 的信令点编码，只会在 GT（全局码，通常是 MSISDN 或 IMSI）里写号码，由 STP 做 GT 翻译后把 DPC 填上再转发。pcap 里由此看到两类寻址：面向端局的 DPC 直呼，和面向用户的 GT 翻译。分析一次“取路由”查询时，先看sccp.called_party_address里的 GT 部分，再看 STP 翻译后写进 DPC 的编码，就能把完整信令路径补出来。

5. 信令链路排错：DPC 路由与 SLS 均衡的三个验证技巧

5.1 用 OPC/DPC 组合快速画信令路由

tshark -r ss7.pcap -Y mtp3 -T fields -e mtp3.opc -e mtp3.dpc -e mtp3.sls \ | sort | uniq -c | sort -rn | head -20

输出第一列是消息条数，后面是“源点编码→目的点编码→SLS”。把出现次数最多的几对点编码放到拓扑图上一对，立刻能看出核心路由的流量占比，也能发现异常旁路——某些本应直连的网元大量经过 STP 转发，往往是信令路由数据配置错误的迹象。

5.2 从 SLS 分布判断链路组是否均衡

tshark -r ss7.pcap -Y "mtp3.si == 5" -T fields -e mtp3.sls \ | sort | uniq -c | sort -rn

链路组里通常有多条链路，MTP3 按 SLS 取值把消息散到不同链路上。正常情况各 SLS 的计数接近均匀；如果某几个 SLS 值计数明显偏高或整段缺失，说明负荷分担没生效，常见诱因是其中一条链路被 MTP2 倒换掉了，或是链路激活参数里人为固定了 SLS 映射。同时留意 SLS 位宽，14 位编码环境里它只有 4bit，最大取值范围是 0-15，看到 SLS 只有 16 个取值时不要误判成异常。

5.3 解码失败和处理 Unknown 协议的两个方向

Wireshark 顶部显示 Unknown 时，多数不是协议不受支持，而是承载层指错了。TDM 抓包把链路层指成 M3UA，或者把 24 位编码当成 14 位解析，都会让 MTP3 把路由标签读错位置，上层自然解不出 ISUP。处理顺序是先回Decode As确认链路层类型，再进 MTP3 协议首选项核对信令点编码格式；最后用第二章的split_mtp3_user打印 DPC/OPC，与 Wireshark 显示的mtp3.dpc比对，两者一致才说明解析基准是对的——这也是每次手工解析前最值得先做的一步验证。

本文还有配套的精品资源，点击获取