2026-10-24 13:53:54 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

浅谈摄像头相关的一些网络协议

原创

尺物科技
尺物科技

尺物科技

2026年10月23日 16:34
四川

去阅读

合规前置声明

相关代码和技术内容请仅在自有设备或获得明确授权的测试环境中使用，请勿对未经授权的第三方设备、网络或互联网资产进行探测、扫描或测试。

0x00 摄像头常见的网络协议

由于网络摄像头通常没有显示屏，首次接入网络时，如何快速找到设备、配置 IP，并进一步获取视频流，是设备部署中最常见的问题之一。

为解决这些问题，安防行业形成了一套成熟的网络协议体系：

ONVIF提供网络视频设备之间的标准化互操作接口，WS-Discovery负责局域网设备发现，厂商私有协议提供设备配置与管理能力（VMS软件），而 RTSP 则负责实时视频流传输，GB/T 28181主要面向安防监控平台接入。

本文将从这些常见协议入手，简单梳理它们之间的关系，并通过一个简易的 ONVIF 实现，直观了解摄像头从发现设备到获取视频流的基本过程。

0x01 什么是ONVIF？

ONVIF（Open Network Video Interface Forum，开放网络视频接口论坛），2008 年由安讯士、博世、索尼等厂商发起，现在是安防视频领域最主流的开放标准化接口规范，目标实现不同品牌网络视频设备之间互通。

ONVIF 整体架构分层

1、发现层：WS‑Discovery（UDP 3702）

局域网发现设备，拿到设备的 WebService URL一般是

http://ip:port/onvif/device_service

这一步不做鉴权。

2、核心服务层：HTTP + SOAP‑XML（TCP）

设备所有配置、查询能力全部封装成 SOAP WebService，需要 HTTP 基础认证 / 摘要认证（用户名密码）调用。

3、媒体流层：RTSP/RTPONVIF Media Service 返回 RTSP URL，客户端通过 RTSP 拉取音视频流，视频编码常见H.264/H.265。ONVIF 接口只显示流地址，视频数据本身不走 ONVIF SOAP 接口。

0x02 什么是 WS‑Discovery

WS‑Discovery，全称 Web Services Dynamic Discovery，是 OASIS 发布的开放标准服务发现协议，用于局域网内自动发现网络设备提供的 Web Service 服务。

传输：UDP 组播
默认端口：3702
IPv4 组播地址：239.255.255.250
IPv6 组播地址：ff02::c
报文格式：SOAP‑XML 封装，基于 SOAP over UDP 传输组播报文。
它是一套通用底层标准，并非安防专用协议，打印机、扫描仪、MFP 一体机、投影仪、NAS、IPC 摄像头都会使用该协议做设备上线宣告与探测响应。

WS‑Discovery 核心消息类型

该协议的官方文档地址：

https://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdfWS-Discovery的XSD（XML Schema 结构定义文件）

http://schemas.xmlsoap.org/ws/2005/04/discovery/ws-discovery.xsdWS-Discovery的WSDL（Web 服务描述语言文件）

https://schemas.xmlsoap.org/ws/2005/04/discovery/ws-discovery.wsdl

1、Hello:

设备上电、网络就绪后，主动向外组播 Hello 报文，宣告自身上线；

设备离线也可发送 Bye 报文宣告下线。

2、Probe:

客户端在局域网发送组播 Probe 探测报文，查询符合指定类型的设备。可携带筛选条件，例如只查询 ONVIF 设备。

3、ProbeMatch:

收到 Probe 的目标设备，以单播方式回复 ProbeMatch，报文中携带关键字段：

EndpointReference：设备唯一 UUID；
Types：设备服务类型标识；
XAddrs:设备 WebService 访问地址列表（http/https URL）。

![](https://mmbiz.qpic.cn/mmbiz_png/cbBa3Hu8iaBUcJupRtQiaMJRMrnphQcS9KS05jLFXZyRU19L2aJgadf4ibm78JibHzqjQaTibPfsbpRal77TPXQPVLd87zrfPrSWiaeiaibtPVe0NYI/640?wx_fmt=png&from=appmsg#imgIndex=4)

4、Resolve / ResolveMatch:

已知设备 UUID，但不知道设备网络地址时，发送 Resolve 组播查询，设备返回 ResolveMatch 给出访问地址。

WS-Discovery探测方式：

WS-Discovery 的设备探测并不复杂，最基本的实现只需要：

创建 UDP Socket；
加入/发送到 239.255.255.250:3702；
构造一个 SOAP-XML 格式的 Probe 报文；
通过 UDP 组播发送；
等待设备返回 ProbeMatch；
解析 XML 中的 EndpointReference、Types、XAddrs 等字段。
下面是一个简单的代码实现。

import socketimport uuidimport xml.etree.ElementTree as ETMULTICAST_ADDR = \"239.255.255.250\"PORT = 3702PROBE = \"\"\"<?xml version=\"1.0\" encoding=\"UTF-8\"?><SOAP-ENV:Envelope  xmlns:SOAP-ENV=\"http://www.w3.org/2003/05/soap-envelope\"  xmlns:SOAP-ENC=\"http://www.w3.org/2003/05/soap-encoding\"  xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"  xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"  xmlns:wsa=\"http://schemas.xmlsoap.org/ws/2004/08/addressing\"  xmlns:dn=\"http://www.onvif.org/ver10/network/wsdl\"  xmlns:d=\"http://schemas.xmlsoap.org/ws/2005/04/discovery\">  <SOAP-ENV:Header>    <wsa:MessageID>{message_id}</wsa:MessageID>    <wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To>    <wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action>  </SOAP-ENV:Header>  <SOAP-ENV:Body>    <d:Probe>      <d:Types>dn:NetworkVideoTransmitter</d:Types>      <d:Scopes></d:Scopes>    </d:Probe>  </SOAP-ENV:Body></SOAP-ENV:Envelope>\"\"\"def build_probe():    message_id = str(uuid.uuid4())    return PROBE.format(message_id=message_id).encode(\"utf-8\")def parse_probe_match(data, addr):    try:        root = ET.fromstring(data)        # 忽略XML Namespace，匹配标签后缀取值        def find_text(suffix):            for elem in root.iter():                if elem.tag.endswith(suffix):                    return (elem.text or \"\").strip()            return \"\"        endpoint = find_text(\"Address\")        types = find_text(\"Types\")        xaddrs = find_text(\"XAddrs\")        print(\"=\" * 70)        print(f\"Source   : {addr[0]}:{addr[1]}\")        print(f\"UUID     : {endpoint}\")        print(f\"Types    : {types}\")        print(f\"XAddrs   : {xaddrs}\")    except ET.ParseError:        passdef discover(timeout=5):    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM,socket.IPPROTO_UDP)    # 地址复用    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)    # 组播TTL    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 4)    sock.settimeout(timeout)    probe = build_probe()    print(f\"[+] Sending WS-Discovery Probe to {MULTICAST_ADDR}:{PORT}\")    sock.sendto(probe, (MULTICAST_ADDR, PORT))    print(\"[+] Waiting for ProbeMatch...\
\")    while True:        try:            data, addr = sock.recvfrom(65535)            print(f\"[+] Received {len(data)} bytes from {addr[0]}:{addr[1]}\")            parse_probe_match(data, addr)        except socket.timeout:            print(\"\
[-] Discovery finished.\")            break    sock.close()if __name__ == \"__main__\":    discover(timeout=5)

运行结果：

WS-Discovery的局限性

WS-Discovery 解决的是局域网设备发现和服务地址获取问题。在 ONVIF 场景中，客户端可以通过发送 Probe 探测设备，并从 ProbeMatch 中获取设备的 UUID、服务类型以及 Web Service 地址。

但设备发现只是摄像头部署过程中的一个环节。实际安装和维护过程中，还涉及 IP 配置、设备激活、初始化、状态查询等操作，这些并不属于 WS-Discovery 本身定义的能力，因此厂商通常还会提供额外的管理机制。

此外，WS-Discovery/ONVIF 并不是所有网络摄像头都必须支持的协议。对于未实现 ONVIF 或 WS-Discovery 的设备，客户端自然无法通过这种方式完成发现；即使设备支持，也可能受到网络隔离、组播限制或设备配置等因素影响。

因此，在实际安防网络中，通常会同时存在：

标准发现机制： WS-Discovery，主要用于发现支持相应服务的 ONVIF 设备；厂商私有机制：面向特定品牌和设备生态，通常进一步提供设备发现、网络配置、激活和维护等能力。

这也意味着：

支持 ONVIF 并不意味着设备一定能够通过 WS-Discovery 被发现；

同样，无法通过 WS-Discovery 发现设备，也不意味着设备一定不存在。

0x03 厂商私有协议

在实际安防设备中，这类协议常见于设备的首次部署和日常维护，除了发现设备外，还可能提供：

设备信息查询
IP 地址配置
设备激活与初始化
网络参数修改
设备状态查询
密码重置等管理功能

不同厂商的协议实现差异较大，通信方式也不尽相同，常见形式包括 UDP 广播、UDP 组播、单播探测，以及直接基于二层以太网报文进行设备发现。

因此，在实际网络中，一台摄像头可能同时运行 WS-Discovery/ONVIF 和一套厂商自己的发现协议。前者用于标准化的设备发现与交互，后者则更多服务于厂商自身的设备配置和运维体系。

常见的一些厂商私有协议会使用以下端口：

37020，37810，37820，37809，5050，8087，34569，3705

需要注意的是，这些端口并不是统一的行业标准，不同厂商、不同产品甚至不同固件版本的实现都可能存在差异。

完成设备发现和网络配置后，下一步就是解决一个更直接的问题：摄像头采集到的视频，究竟是如何传输到 NVR、播放器或其他平台的？

这就涉及网络摄像头中最常见的实时流媒体协议——RTSP/RTP/RTCP。

0x04 什么是RTSP协议?

在 RTSP 出现之前，网络视频更多采用 HTTP 进行文件传输。用户访问视频 URL 后，需要先下载数据，再进行播放。这种方式对早期较低的分辨率、较小的视频文件来说尚可接受，但随着视频分辨率、帧率不断提升，单纯依赖文件下载已经难以满足实时观看的需求。

随着网络带宽和视频采集技术的发展，用户对低延迟、边下载边播放的实时视频体验需求越来越强。传统 HTTP 文件传输逐渐难以满足这一场景，专门面向实时流媒体控制的 RTSP 由此得到广泛应用。

RTSP 在报文格式和交互方式上与 HTTP 有一定相似之处，但它并不负责传输实际的视频数据，而是主要负责流媒体会话的建立、控制与管理，实际音视频数据通常由 RTP 承载。

RTSP（Real Time Streaming Protocol）是一种应用层流媒体控制协议，主要负责媒体会话的建立、控制和管理。

常见方法包括 OPTIONS（查询服务器支持的方法）、DESCRIBE（获取媒体描述信息）、SETUP（协商媒体传输参数）、PLAY（开始播放）、PAUSE（暂停播放）、TEARDOWN（结束会话）和 ANNOUNCE（向服务器发送或更新媒体描述信息）等。

RTSP 本身通常不直接传输视频数据，而是与 RTP、RTCP 等协议协同工作，实现流媒体的传输与控制。

RTP（Real-time Transport Protocol） 负责实际的音视频数据传输。摄像头将 H.264、H.265、G.711 等编码数据封装为 RTP 报文，通过 UDP 等方式发送给播放器或 NVR。

RTCP（RTP Control Protocol） 是 RTP 的控制协议，主要负责传输统计、质量反馈和同步辅助。

简单来说：

RTSP 负责控制，RTP 负责传输，RTCP 负责反馈。

0x05 什么是国标 28181？

GB/T 28181，全称 《公共安全视频监控联网系统信息传输、交换、控制技术要求》，是我国公共安全视频监控领域广泛采用的国家标准，常见于平安城市、雪亮工程以及大型视频监控联网项目。

与 ONVIF 不同，GB/T 28181 的核心不是局域网设备发现，而是设备接入视频监控平台。其信令层采用 SIP，通常使用 UDP/TCP 5060 进行通信；视频等媒体数据则通过 RTP 传输。

设备如何接入？

GB/T 28181 采用的是“设备主动注册，平台统一管理”的模式。

在设备中预先配置：

SIP 平台地址
SIP 服务器端口
国标设备 ID
注册密码等参数

摄像头或 NVR 启动后，主动向 SIP 平台发送 REGISTER 请求。注册并完成鉴权后，平台即可获取设备及其通道信息。

28181协议的注册流程

设备首次注册时，通常先发送 REGISTER，平台返回 401 Unauthorized 携带认证参数，设备随后携带 Authorization 再次注册，认证通过后平台返回 200 OK，完成注册。

在实际工程中，这些协议往往是协同工作的：先通过 SADP、DHIP、WS-Discovery 等机制发现和配置设备，再通过 ONVIF、Web 管理接口等方式完成设备调试；如果需要接入安防平台，则进一步配置 GB/T 28181，由设备主动向平台注册。视频点播时，则通常通过 RTCP/RTP 完成媒体传输。

0x06 总结对比

网络摄像头看似只是一个提供视频画面的终端，实际上从设备发现、网络配置，到视频传输、平台接入，背后涉及多种协议的协同工作。

WS-Discovery 和厂商私有协议负责发现与配置，ONVIF 提供标准化的设备交互能力，RTSP/RTP/RTCP 负责实时媒体传输，GB/T 28181 则面向安防监控平台的设备接入与管理。

协议构成了物联网设备之间的连接，而协议实现则构成了设备的安全边界。

从发现、配置到媒体传输，在这条完整的通信链路中，任何一个环节出现脆弱点，都可能成为突破设备安全边界的入口，并进一步影响整个系统的安全性。

[PX4飞控安全深挖：RavenEye从二进制固件中发现十余个0-Day

2026-08-25

](https://mp.weixin.qq.com/s?__biz=Mzg3ODUyNzgyMg==&mid=2247485221&idx=1&sn=3cb29b50e2c7a40c981926b4e025ab1b&scene=21#wechat_redirect)[持续上榜：尺物科技再次入选《中国网络安全行业全景图（第十三版）》

2026-08-12

](https://mp.weixin.qq.com/s?__biz=Mzg3ODUyNzgyMg==&mid=2247485125&idx=1&sn=5ea29892b6565734f6f8e64d900d1bcd&scene=21#wechat_redirect)[一个无法解析的固件升级包，我们是如何一步步还原它的？