企业官网建设流程全解析

这个系列写到第4篇，我打算先聊聊OPTIONS。别看它名字平平无奇，却是几乎所有RTSP客户端第一条发出去的命令。DESCRIBE决定能不能拿到SDP，SETUP决定媒体通道能不能建立，PLAY决定画面能不能跑起来，而OPTIONS相当于你敲门前先问一句“屋里有人吗，都会哪些活儿”。就这么一句话的事，里面涉及的协议细节、解析坑和兼容性问题一点都不少。如果你正准备手写RTSP协议栈，或者在做播放器联调、摄像头接入，建议把这篇看完。后面几篇我们会逐步进入有状态的方法，但OPTIONS就像地基，地基不稳，后面全得返工。

1. 先搞清楚OPTIONS在整个RTSP体系里的位置

1.1 为什么第一个要写它

RTSP标准里列出的方法不少，日常接触最多的也就那么几个：OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN，再加上GET_PARAMETER和SET_PARAMETER。从状态机的角度来看，DESCRIBE BEGIN_SETUP、SETUP READY、PLAY PLAYING、TEARDOWN 这些都是有状态的过程，会话建立起来之后，服务器得一直维护Session ID和相应的资源状态。OPTIONS不一样，它是无状态的，不创建会话、不申请资源、不改动任何状态，只是单纯地“问”。

从协议设计者的角度看，客户端拿着一串rtsp://地址，除了知道目标IP和端口之外，对服务器一无所知。它不知道服务器是标准实现还是半吊子兼容层，不知道支不支持PLAY，也不知道有没有扩展方法。这种情况下，协议必须提供一种能力探测机制。这就是OPTIONS存在的原因。

还有一个很现实的原因：我在调试播放器和摄像头对接的时候，发现一个问题——很多设备对DESCRIBE的响应格式严格，但对OPTIONS的响应五花八门。要么不返回Public头，要么返回的小写方法名，要么压根就是私有格式。如果你一上来就直接DESCRIBE，遇到协议差异根本分不清是设备问题还是自己代码问题。先发OPTIONS，等于用一个最简单的请求把设备的协议喜好摸一遍，后续走什么流程心里有数。这个习惯救过我很多次。

1.2 OPTIONS在RTSP交互时间轴里的位置

典型的RTSP播放流程是这样的：

1. TCP三次握手连接服务器
2. 客户端发OPTIONS，服务器返回支持的方法列表
3. 客户端发DESCRIBE，服务器返回SDP描述
4. 客户端根据SDP准备接收参数，发SETUP建立媒体会话
5. 客户端发PLAY触发推流
6. 播放过程中可发送PAUSE、GET_PARAMETER等操作请求
7. 结束时发送TEARDOWN释放所有资源

从抓包角度看，OPTIONS基本是TCP握手之后的第一个应用层报文。有些客户端图省事，跳过OPTIONS直接DESCRIBE，大多数情况下服务器也能正常响应，毕竟RTSP不像HTTP那样强制要求每个请求前必须有一个能力协商过程。但做正规客户端和协议栈，这一步不能省。原因很简单：DESCRIBE得到的SDP只能告诉你媒体描述，告诉不了你服务器支持哪些控制方法。如果服务器不支持PLAY而支持RECORD，那你就得换个交互方式，而不是想当然地按播放逻辑写下去。

还有一个容易被忽略的细节：OPTIONS的请求URI可以带也可以不带具体的媒体路径。例如OPTIONS rtsp://192.168.1.100:554/live和OPTIONS rtsp://192.168.1.100:554/理论上都是合法请求。不同服务器对URI路径的处理逻辑不一样，有的会忽略路径直接返回全局能力，有的会针对具体媒体资源返回该资源可用的能力。习惯上客户端会填完整的播放URL，因为这样兼容性最好。

2. 报文拆解：OPTIONS请求和响应到底长什么样

2.1 请求报文：一个空格都不能错

RTSP是文本协议，报文长得和HTTP很像，但细节上有自己的规矩。一个标准的OPTIONS请求长这样：

OPTIONS rtsp://192.168.1.100:554/live RTSP/1.0 CSeq: 1 User-Agent: hand-rtsp/0.1

第一行是请求行，格式严格为：方法名 + 空格 + 请求URI + 空格 + RTSP版本号 + CRLF。这里有几个新手必踩的坑。

一是方法名必须是全大写，写成OPTIONS，不能是Options、options。有些服务器实现的解析器容错能力弱，方法名大小写不对直接返回400。二是请求行里有两处空格，少了任何一个都违反协议，服务器大概率直接丢连接。三是每行必须以\r\n结尾，不是\n，也不是\r。报文的最后必须有一个空行来表达“头部结束”，也就是请求行 + 三个头行之后，再补一个\r\n，前面一共三个\r\n，加上最后的空行，总共四个\r\n。如果不补最后的空行，服务器会一直等你的头结束，直到超时。

CSeq是每个RTSP请求必须带的头部，全称是Sequence Number，表示当前请求的序列号。它解决的是一对多请求时，客户端怎么把响应和请求对应起来的问题。OPTIONS这种串行请求，你从1开始递增就行。但要注意，如果你在同一个连接上连续发多个OPTIONS，CSeq不能重复，每个都要比上一个增加。有些老设备的实现是拿CSeq做索引表，重复的CSeq会让它直接乱掉。

User-Agent头是可选的，但强烈建议加上。对接不同厂商设备时，服务器日志里能看到你的客户端标识，排查问题的时候双方能对得上号。这里有个小技巧：你甚至可以故意在User-Agent里写一个常见的播放器名称，有些设备会据此切换兼容模式。不过自研协议栈建议写自己的标识，免得被设备针对性处理。

2.2 响应报文：Public头才是核心

服务器收到OPTIONS后，正常会返回类似这样的响应：

RTSP/1.0 200 OK CSeq: 1 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

第一行是状态行，格式为：RTSP版本号 + 空格 + 状态码 + 空格 + 状态短语 + CRLF。状态码的含义和HTTP高度重叠，200表示成功，400表示请求格式错误，401表示需要认证，404表示资源不存在，505表示版本不支持。RTSP自己也有一些专属状态码，比如454 Session Not Found、551 Option not supported，这些后面会提到。

CSeq头必须和请求里的CSeq完全一致。这是客户端校验响应的一个重要依据：如果发出去的是CSeq: 1，结果响应里回的是CSeq: 2，说明服务器实现有问题，或者你收到的是上一次请求的响应，也就是发生了报文错序。

响应里最关键的字段是Public。它的值是一个逗号分隔的方法列表，告诉客户端这台服务器支持哪些方法。上面这个例子说明它支持OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER、SET_PARAMETER，也就是一套完整的点播控制能力。解析的时候要注意几个细节，一是方法名按规范是大写，但实际产品里有不少返回小写的，建议统一转大写再比较。二是逗号后面可能带空格，也可能不带，split(",")之后要做strip。三是有的服务器会把未公开认证的能力也写进Public，有的会故意藏掉，所以说Public是“建议性”的，最终能不能用某种方法，还是得实际请求一次才知道。

另外，响应里可能出现Server头，值是服务器的软件标识。这个头对调试很有用，可以快速看出对端是某种常见开源服务还是私有实现。有些服务器还会返回Date头、Session头。因为OPTIONS无状态，正常情况下响应里不该有Session头，如果你收到了，只能说明服务器实现不规范，但并不致命。

2.3 与HTTP OPTIONS的区别别搞混

HTTP里也有OPTIONS方法，用途也是探测能力，但两者有几个关键区别。第一，HTTP响应里支持的方法列表放在Allow头，RTSP放在Public头。很多从HTTP转过来的人第一次写RTSP解析器，下意识去读Allow，结果永远读不到，就是这个原因。

第二，HTTP的OPTIONS在CORS跨域请求里承担了“预检”的角色，会携带Access-Control-Request-Method等头部。RTSP没有这套东西，它的OPTIONS就是纯粹的能力查询，不做跨域协商。

第三，HTTP基于请求-响应模型，客户端角色的区分比较清晰。RTSP虽然大多数时候也是客户端发请求、服务器回响应，但协议本身允许服务器向客户端发OPTIONS请求，这个方向反转的语义普通人接触得少，下文会专门讲。

3. 三个实际场景：查询能力、反向推送和保活心跳

3.1 客户端发起的能力查询

这是最经典的用法，也是OPTIONS出现的意义所在。客户端拿到一个RTSP地址后，先向服务器发送OPTIONS，根据响应中的Public字段决定后续流程。比如一个播放器拿到某个摄像头地址，OPTIONS发现Public里没有RECORD，那就说明这个设备只能播不能录；如果DESCRIBE返回的SDP里有H264，就可以按照H264的解码方案准备播放管线。

写这套逻辑的时候要注意一个问题：不要把Public当成100%可信的契约。有些服务器在OPTIONS里列了一堆方法，但实际执行SETUP或者PLAY的时候才开始报错；反过来也有服务器Public里漏了PAUSE，但你发PAUSE它确实能响应。我倾向于把OPTIONS的响应当成“设备的自我介绍”，可以信赖但不能迷信。真要确定某个方法能否使用，最终还是得在实际请求之后看状态码。

还有一个工程细节。一次OPTIONS响应里Public可能有好几行，也可能一行里方法非常多。解析器最好支持Public头重复出现的情况，把多行里的方法合并到一起，而不是只取最后一个。这种防御性写法在处理那些日志格式不规范的设备时很管用。

3.2 服务器主动推送OPTIONS的场景

很多人不知道RTSP协议里服务器也可以向客户端发OPTIONS请求。这在RFC文档里是明确允许的，语义是服务器主动把自己的能力变化通知给客户端。什么情况下会出现？比如某台服务器在运行过程中动态加载了一个新的媒体处理方法，或者管理员把某个功能开启/关闭了，服务器可以发一个OPTIONS请求给已连接的客户端，相当于广播“我的能力集变了”。

客户端收到这种反向请求时，正确做法是照常回一个200 OK，同时更新自己维护的服务器能力表。具体报文长这样：

服务器发：

OPTIONS rtsp://192.168.1.100:554/live RTSP/1.0 CSeq: 190

客户端回：

RTSP/1.0 200 OK CSeq: 190

别看这个场景小众，如果你写的是服务端程序，忽略了对客户端反向OPTIONS请求的处理，某些严格客户端可能直接认为服务器协议异常而断开连接。反向OPTIONS里同样要带CSeq，客户端回复的时候也必须要带相同的CSeq。本质上它就是一次普通的RTSP请求，只不过方向反了。

3.3 用OPTIONS做保活心跳：低成本和隐藏的坑

RTSP连接建立后，如果长时间没有数据往来，网络中间设备可能会回收空闲连接。摄像头和服务器的NAT映射也会因为长时间无流量而失效。为了避免这种情况，客户端需要周期性发送心跳包。

心跳包的选择很讲究。TEARDOWN和SETUP肯定不行，会破坏会话状态。PLAY重复发可能会导致服务器重新播一遍，也不合适。GET_PARAMETER和SET_PARAMETER可以用，但很多设备没有实现。相比之下，OPTIONS是最安全的：无状态、不创建会话、不改变资源、几乎所有服务器都支持。所以很多成熟播放器在播放过程中会用OPTIONS作为心跳。

但这里有个实战经验必须提醒。有些服务器对OPTIONS的响应处理是带日志的，如果你每30秒发一次，服务器日志会被刷屏。更稳妥的做法是先用GET_PARAMETER做心跳，被拒绝或超时再降级到OPTIONS。优化的时候可以动态调整心跳间隔：前面几次心跳用30秒，稳定后再拉长到60秒，减少无谓的报文交互。心跳只代表连接活着，不代表播放状态正常，所以心跳超时后不要急着断连，可以先重发一次，连续失败两次再触发重连逻辑，避免单次网络抖动就把整条流打断。

4. 手写一个OPTIONS客户端：从socket到解析

4.1 一个能跑的最小实现

看再多协议文档，都不如自己亲手发一次报文来得实在。下面这段Python脚本就是最精简的RTSP OPTIONS客户端，用标准socket库，不依赖任何第三方模块，拷贝就能运行。

import socket HOST = "192.168.1.100" PORT = 554 URL = "rtsp://192.168.1.100:554/live" CSEQ = 1 def build_options_request(url, cseq): req = ( "OPTIONS " + url + " RTSP/1.0\r\n" "CSeq: " + str(cseq) + "\r\n" "User-Agent: hand-rtsp/0.1\r\n" "\r\n" ) return req.encode("utf-8") def read_response(sock): data = b"" while True: try: chunk = sock.recv(4096) if not chunk: break data += chunk if b"\r\n\r\n" in data: break except socket.timeout: break return data.decode("utf-8", errors="replace") sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(3) sock.connect((HOST, PORT)) sock.sendall(build_options_request(URL, CSEQ)) response = read_response(sock) sock.close() print(response)

这段代码的逻辑很简单：建立TCP连接，拼装文本请求，发送，接收响应直到空行，打印。你替换成自己的服务器IP、端口和URL，运行后就能在终端看到服务器返回的原始报文。这是理解RTSP最直观的方式——你亲手构造了一个真正的协议请求，并且看到了对端的真实回复。

4.2 代码里的几个关键细节

sendall和send的区别值得说。TCP是流式传输，一次send不一定能把缓冲区的所有数据发出去，尤其当你构造的请求很大时。sendall会循环调用send直到全部发送成功，所以用它比send安全得多。如果你用C语言写，对应的是send函数配合循环发送，或者直接用write，确认字节数完整。

接收响应时，我用了循环recv，并判断缓冲区里是否出现了\r\n\r\n。这里有个隐含假设：OPTIONS响应通常没有body，头部结束就是整个响应结束。这个假设对这个方法基本成立。但如果推广到DESCRIBE，响应是带有SDP body的，你还需要解析Content-Length并根据长度继续读取，否则会截断响应。所以这段代码只适合演示OPTIONS，写工程代码时要做完整的响应解码。

超时设置很有讲究。settimeout(3)的意思是最长等待3秒。我见过不少新手要么不设超时，导致程序卡死在recv上，要么把超时设成毫秒级，结果慢速服务器还没回包就先超时了。局域网内测试3秒很宽裕，公网环境可以放宽到5到8秒。

最后，连接异常要主动处理。connect失败会抛异常，主机不可达和端口不通的报错信息不一样，调试时注意区分。比如Connection refused说明TCP层到了对端但端口没服务，timed out说明包根本到不了，通常是防火墙拦截或者地址填错。

4.3 扩充成可用的解析代码

上面只是打印原始响应，实际开发中需要解析成结构化数据。扩展后的代码会这样处理：

def parse_options_response(text): lines = text.split("\r\n") status_line = lines[0] headers = {} for line in lines[1:]: if ":" in line: key, value = line.split(":", 1) headers[key.strip().lower()] = value.strip() public = headers.get("public", "") methods = [m.strip().upper() for m in public.split(",") if m.strip()] return status_line, methods status, methods = parse_options_response(response) print("status:", status) print("methods:", methods)

这里藏着几个容易被忽视的细节。一是按\r\n分割而不是\n，因为RTSP行分隔符严格是CRLF。二是line.split(":", 1)只切第一个冒号，如果你用split(":")，遇到Server: TestServer/1.0这种value里带冒号的情况会把后面的冒号一起切掉。三是对方法做strip().upper()，防御那些返回小写方法名的设备。

如果响应头里出现连续两行都叫Public，上述代码的后写入会覆盖前面的。要处理这种情况，可以把解析逻辑改成遇到public时做累加，用逗号连接后去重。这个不常见，但并不可笑，因为我在实际设备上是真遇到过的。

5. 抓包看OPTIONS：请求和响应的原始字节

5.1 怎么搭一个抓包环境

要深入理解RTSP，不能只看抽象描述，你一定要亲眼看看它在网络上长什么样。这里我用的方案很简单：在一台电脑上跑一个测试用RTSP服务器，监听554端口，另一台电脑上用我们的Python脚本发OPTIONS，同时在服务端网卡上抓包。

Wireshark默认会识别554端口上的RTSP协议，抓包后能看到很清晰的协议解析树。如果目标服务器跑在非标准端口，比如8554或者8080，Wireshark可能只显示为TCP payload，不会自动解析成RTSP。这时候右键点击对应的TCP包，选择“Decode As”，把当前端口强制指定为RTSP协议，解析树就出来了。这个操作用在排查“服务器端口明明是通的，为什么Wireshark看不到RTSP请求”的场景下，非常管用。

5.2 请求方向的字节流

在Wireshark里点开客户端到服务器的第一个TCP包，显示的内容大致是：

OPTIONS rtsp://192.168.1.100:554/live RTSP/1.0 CSeq: 1 User-Agent: hand-rtsp/0.1

换到十六进制视图，你能直观地看到文本的编码方式：

4f 50 54 49 4f 4e 53 20 72 74 73 70 3a 2f 2f ...

开头的几个字节是OPTIONS的ASCII码，注意方法名后面那个20就是空格，对应0x20。跟着的是rtsp://。每一行结束的地方能看到0d 0a，这是\r和\n的十六进制表示。报文最后连续两个0d 0a，这就对应了我们前面反复强调的空行。

看十六进制最直观的一点，是你能确认自己发的报文里到底有没有多余的字符。比如你手写请求时多加了一个空格，报文就变成了OPTIONS rtsp://...，在十六进制视图里就是两个连续的20 20，服务器返回400一点都不冤。

5.3 响应方向的字节流

服务器返回的包，文本视图长这样：

RTSP/1.0 200 OK CSeq: 1 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Server: TestStreamServer/1.0

这里能看到的细节是，响应状态行的RTSP/1.0和请求行的版本号完全一致。如果客户端发的是RTSP/1.0，服务器回的是RTSP/2.0，这说明对端强制启用了新版协议，而你的客户端如果只实现了1.0，后面的流程基本走不通。

从时序上你会发现，TCP三次握手的前三个包都是纯TCP报文，没有载荷。第四个TCP包带着的是客户端的OPTIONS请求，紧接着服务器回一个带200 OK的包。这个顺序是定位RTSP交互问题的关键：如果你发现TCP握完手之后服务器迟迟不回OPTIONS，说明问题在应用层；如果握手阶段就失败，说明问题在网络层或者端口监听上，再怎么调OPTIONS也没用。

6. 调试RTSP时最容易踩的几个OPTIONS坑

6.1 常见错误参考表

我把这几年调RTSP设备时遇到过的OPTIONS相关问题整理成了一张表，遇到问题先对照自查：

前三项是新手最容易犯的，后几项更多是设备兼容性问题。

6.2 一个典型的兼容性排查过程

说一个印象很深的案例。当时在调试一款网络摄像头，端口是554，telnet能通，TCP握手正常，但我的客户端发OPTIONS之后，服务器直接回了RST断开连接。多次重试都一样，确认不是偶发现象。

我的排查过程是先用Wireshark抓包，确认报文文本格式完全正确，方法名大写、CRLF结尾、空行存在。既然报文没问题，问题只能在服务器侧。后来我换了VLC试着连这个摄像头，发现VLC能收到视频流。VLC也有RTSP实现，我抓它发出的OPTIONS报文，和我自己的报文逐一对比，发现唯一的区别是它没有发OPTIONS，而是直接发了DESCRIBE。

这个设备虽然监听554端口，但它的协议栈实现里压根没有做OPTIONS方法，收到不认识的请求，直接砸了连接。我调整客户端逻辑，探测阶段把OPTIONS失败不作为致命错误，超时或连接重置后自动降级到DESCRIBE，问题就解决了。这个案例给我最大的启发是：RTSP设备虽然遵循同一个协议标准，但私有实现和过时固件到处都是，协议栈写代码必须做好失败降级，而不是把单次请求失败当成全局错误。

6.3 OPTIONS与认证流程的关系

关于OPTIONS和认证，有个细节值得单独拎出来讲。标准RTSP流程里，认证发生在DESCRIBE阶段，正常的情况下OPTIONS是不需要鉴权的。但有些设备出于安全考虑，所有请求都要过认证。所以你发OPTIONS，可能得到的是401响应，而不是200。

这种情况下，你可以利用401响应里的认证头去做摘要认证的预握手。简单说，服务器返回401时会在响应头里带上WWW-Authenticate字段，里面包含realm和nonce等信息。客户端拿到这些信息后，可以构造一个带Authorization头的重发请求，认证通过后再收到200。这里要注意摘要算法里的nonce是有时效的，如果你隔了很久才用同一个nonce重发，会拿到401的再次返回。重试逻辑要把“重新取nonce再组合Authorization”做成一个完整循环，而不是只重发一次。

7. 写在最后的个人经验

写RTSP代码这一年多，给我最大的感觉是，能折腾人的往往不是协议里那些复杂的机制，而是像OPTIONS这类不起眼的小方法。它简单到几行代码就能发完，但在设备接入和联调中发挥的作用，远大于它在协议文档里的篇幅。每当我接手一个陌生设备的对接工作，第一件做的一定是抓包看它回OPTIONS的Public列表，这一步基本能判断出设备协议栈的规范程度和实现风格，后面所有兼容层的设计都从这里开始。

如果你在写服务端程序，有一个容易被忽略的点：OPTIONS响应里的Public列表，不要为了显得能力强就随便多填，能真正实现的方法才填上去，做不到的不要写。否则客户端看到Public里有PLAY，结果PLAY指令发过来你返回405，这种体验比一开始就不支持更糟糕。这份列表就是服务器给客户端的自我介绍，既然是自我介绍，就要真实、完整、经得起推敲。

最后补一个建议：大把时间花在读RFC正文上，不如把OPTIONS请求发出去，然后打开Wireshark盯着十六进制看一遍。协议这东西，亲手拆一次，比道听途说一百篇经验都管用。下一篇我们准备进入DESCRIBE，也就是真正开始和媒体描述打交道的地方，那一节的信息量会更大，到时候接着聊。