简介本资源是一份详尽的非官方 AirPlay 协议技术解析文档面向嵌入式开发、iOS/macOS 底层通信研究者及音视频协议逆向分析工程师帮助理解苹果设备间媒体投屏与流传输的核心机制。文档系统梳理了 AirPlay 协议全栈架构涵盖服务发现Bonjour/mDNS、照片/视频/音频分项传输HTTP/RTSP/RTP、屏幕镜像AirPlay Mirroring实现细节、密码保护机制及历史演进脉络并附有 IETF RFCs 与苹果私有协议对照参考。资源为单个 Word 文档.doc大小 511KB结构清晰、章节完整适合作为协议学习主干资料或二次开发参考依据。目前已有 1415 人下载学习内容基于真实逆向工程实践整理虽未披露 RSA 密钥或 FairPlay DRM 实现但对 RAOPRemote Audio Output Protocol、AirTunes 演进、时间同步、元数据管理等关键技术点均有深入展开具备较强工程参考价值。1. AirPlay 协议不是“投屏开关”而是一套可拆解、可复现、可调试的七层协议栈它让 Apple TV 变成一台 HTTPRTSPRTPBonjour 的嵌入式媒体网关你点开 iOS 控制中心划出「屏幕镜像」——那个秒连 Apple TV 的瞬间背后不是黑匣子而是一整套被逆向工程锤实的协议组合HTTP 服务发现 RTSP 控制信令 RTP 实时流 Bonjour 多播 DNS NTP 时间同步 自定义 plist 事件总线。这份 Unofficial AirPlay Protocol Specification非官方协议规范不是理论文档它是 2012 年基于 Apple TV 5.0、iOS 5.1、iTunes 10.6 真机抓包逆向得出的实操手册覆盖照片缓存、幻灯片过渡、FairPlay SAPv2.5 认证边界、AirPort Express 音频加密握手等真实链路。它不提供密钥、不破解 DRM但把 RAOPRemote Audio Output Protocol和 AirPlay Service 的每个 TXT 字段、每个 HTTP Header、每个 RTP payload type、每个事件回调路径都摊开在你面前。适合三类人想用 Python 写个轻量 AirPlay 客户端的嵌入式开发者需要对接第三方 AirPlay 设备做音视频中控的系统集成工程师或是正在排查「为什么 iPad 能连 Apple TV 但 Mac 不能」这类跨平台兼容问题的现场运维。这不是 API 文档这是协议层的手术刀——切开就能看见血管走向。2. Service DiscoveryBonjour 不是魔法而是 mDNS 报文里的两个关键 TXT 记录解析AirPlay 设备上线即可见靠的不是配置而是设备主动广播的 mDNS 服务。Apple TV 同时注册两个服务_raop._tcp音频专用和_airplay._tcp视频/照片/镜像通用。它们不是并列关系而是功能分层——RAOP 负责纯音频流AirPlay Service 负责所有带 UI 和状态同步的媒体类型。抓包验证时你看到的不是“AirPlay”一个服务名而是两个独立的 SRV 记录各自携带不同端口和 TXT 参数。理解这点才能避免后续调试中把音频控制命令发到 7000 端口AirPlay或把视频元数据塞进 49152 端口RAOP这种低级翻车。2.1 RAOP 服务从 TXT 记录反推音频能力矩阵RAOP 服务的 TXT 记录是音频设备的“能力身份证”。以name: 5855CA1AE288Apple TV为例其 TXT 字段直接决定你能用什么编解码器、要不要加解密、是否支持远程控制txtvers1 ch2 cn0,1,2,3 datrue et0,3,5 md0,1,2 pwfalse svfalse sr44100 ss16 tpUDP vn65537 vs130.14 amAppleTV2,1 sf0x4关键字段逐条拆解cn0,1,2,3支持 PCM0、ALAC1、AAC2、AAC ELD3四种音频编码。注意ALAC 是 Apple Lossless非标准 AAC客户端必须自带解码器。et0,3,5加密类型支持列表。0无加密本地测试可用3FairPlay需硬件授权5FairPlay SAPv2.5iOS 6 屏幕镜像认证核心不可绕过。md0,1,2元数据支持。0文本标题/艺术家1封面图需额外/artwork接口2播放进度用于进度条拖拽。sr44100 ss16采样率 44.1kHz、16bit 深度——这是 ALAC 流的默认规格若强行推送 48kHz 流Apple TV 会静音或断连。tpUDP传输协议强制 UDPTCP 仅用于初始 RTSP 握手RTP 数据必须走 UDP且需开启IP_TOS0x60DSCP CS6保障实时性。提示sf0x4是设备特性标志位0x4表示支持「音频包冗余」Redundant Packet即同一帧音频发送两次降低丢包影响。实测中若网络抖动大开启此特性比调高缓冲更有效。2.2 AirPlay Servicefeatures 位域才是功能开关的物理地址AirPlay Service 的 TXT 记录更精炼但features0x39f7这个十六进制数藏着所有功能开关Bit名称含义Apple TV 5.0 实际值关键影响0Video视频播放支持1/video接口可用1Photo照片上传支持1/photoPUT 接口生效2VideoFairPlayFairPlay DRM 视频1需 SAPv2.5 认证否则 4033VideoVolumeControl视频音量控制0Apple TV 不支持调音量无效4VideoHTTPLiveStreamsHLS 直播流0仅支持 MP4/H.264 文件流5Slideshow幻灯片模式1/slideshows/1可用7ScreenMirroring屏幕镜像1/stream接口启用需 NTP 同步9Audio音频播放非 RAOP0此服务不处理音频交由 RAOP实操中features位域必须校验——比如你调用/stream做镜像但 bit70则返回404 Not Found你发/photo请求但 bit10则返回405 Method Not Allowed。这不是服务器 bug是协议层硬约束。2.3 服务发现实战用 avahi-browse 或 Python-zeroconf 快速定位别依赖「控制中心自动发现」——那只是苹果生态的糖衣。真要调试得自己抓服务# Linux 下用 avahi-browse 查看所有 AirPlay 设备 avahi-browse -t _raop._tcp _airplay._tcp --resolve --parsable输出示例;enp0s3;IPv4;5855CA1AE288Apple TV;_raop._tcp;local;192.168.1.100;49152;txtvers1,ch2,cn0,1,2,3,... ;enp0s3;IPv4;Apple TV;_airplay._tcp;local;192.168.1.100;7000;deviceid58:55:CA:1A:E2:88,features0x39f7,...Python 侧推荐zeroconf库比pybonjour更稳定from zeroconf import Zeroconf, ServiceBrowser import socket class AirPlayListener: def add_service(self, zc, type, name): info zc.get_service_info(type, name) if info and info.port: print(fFound {type}: {name} at {socket.inet_ntoa(info.addresses[0])}:{info.port}) print(fTXT: {info.properties}) zeroconf Zeroconf() listener AirPlayListener() browser ServiceBrowser(zeroconf, [_raop._tcp, _airplay._tcp], listener) # 运行 5 秒后停止 import time time.sleep(5) zeroconf.close()这段代码会打印出所有 RAOP 和 AirPlay 服务的 IP、端口、TXT 记录。注意info.properties是 bytes 字典需info.properties.decode(utf-8)解析否则看到的是乱码二进制。2.4 避坑Bonjour 服务发现失败的五个真实原因与修复现象 → 原因 → 解决avahi-browse无输出但 iOS 能连→ 原因Linux 主机防火墙阻断了 UDP 5353 端口mDNS 默认端口或 NetworkManager 启用了avahi-daemon冲突。→ 解决sudo ufw allow 5353/udp并检查systemctl status avahi-daemon是否运行若冲突停用sudo systemctl stop avahi-daemon改用systemd-resolved。Python zeroconf 找到服务但get_service_info()返回 None→ 原因服务广播的address是 IPv6 地址而你的网卡未启用 IPv6或info.addresses为空数组。→ 解决强制指定 IPv4info zc.get_service_info(type, name, timeout3000); if info.addresses: ip socket.inet_ntoa(info.addresses[0])。TXT 记录中pwtrue但实际未设密码→ 原因Apple TV 固件 Bug5.0.2 版本存在pw字段误置为 true但实际认证逻辑未启用。→ 解决忽略pw字段直接发起连接若 401 Unauthorized则再补X-Apple-PasscodeHeader。同一局域网多台 Apple TV服务名重复导致解析错误→ 原因Bonjour 服务名冲突如都叫Apple TVmDNS 返回随机一台的 IP。→ 解决在 Apple TV 设置中修改设备名称为唯一值如LivingRoom-ATV或通过deviceid字段过滤。RAOP 服务端口 49152 被占用Apple TV 改用其他端口但未更新 TXT 记录→ 原因端口冲突时 Apple TV 会动态分配新端口如 49153但 TXT 记录仍写 49152导致客户端连错。→ 解决抓包看SRV记录的实际 port 字段而非信任 TXT或重启 Apple TV 强制重广播。3. Photos 协议PUT /photo 不是文件上传而是带状态机的 JPEG 流式渲染引擎AirPlay 照片协议表面是 HTTP PUT实则是状态驱动的媒体管道。/photo接口不保存文件而是将 JPEG 数据帧实时解码、缩放、应用过渡效果后推送到 GPU 帧缓冲区。这意味着你不能像传普通文件一样发 multipart/form-data必须用 raw JPEG binary也不能指望服务器返回「上传成功」后再发下一张——每张图的X-Apple-AssetKey是全局唯一 UUID用于缓存索引和过渡动画绑定。搞错这个逻辑就会出现「图片闪一下就消失」或「幻灯片卡在第一张」的玄学问题。3.1 HTTP 请求四个核心接口与 header 组合拳AirPlay 照片协议围绕四个 HTTP 端点构建每个都有严格 header 要求接口方法关键 Header用途失败响应/slideshow-featuresGETAccept-Language: en-US获取过渡效果列表Reflections/Classic 等404若设备不支持幻灯片bit50/photoPUTX-Apple-AssetKey,X-Apple-Transition上传单张 JPEG立即显示400 Bad Request若 JPEG 格式非法非 baseline JPEG/slideshows/1PUTContent-Type: text/x-apple-plistxml启动/停止幻灯片设置时长与主题400若 plist XML 格式错误标签未闭合/stopPOST无强制终止当前照片/幻灯片会话200总是成功但需等待/event确认结束X-Apple-AssetKey是核心——它不仅是 ID更是缓存 key。同一张图用不同 key 上传两次会被视为两张图用相同 key 发送新 JPEG会原地刷新画面无过渡。X-Apple-Transition则控制入场动画Dissolve淡入、Push滑入、Reveal揭开值必须全小写且匹配/slideshow-features返回的key字段。3.2 Photo CachingcacheOnly/displayCached 不是优化而是解决「幻灯片卡顿」的唯一路径AirPlay 的「预加载缓存」机制Photo Caching不是可选项而是协议层强制要求的性能保障。当你启动幻灯片时Apple TV 期望客户端提前把下一张图用X-Apple-AssetAction: cacheOnly上传到内存等当前图显示完毕立刻用X-Apple-AssetAction: displayCached 相同X-Apple-AssetKey触发切换。整个过程无网络 IO延迟 50ms。import requests # Step 1: 缓存下一张图异步不阻塞当前显示 headers { X-Apple-AssetKey: B2F3E4A5-C6D7-8901-2345-678901234567, X-Apple-AssetAction: cacheOnly, User-Agent: MediaControl/1.0, X-Apple-Session-ID: session-123 } with open(next.jpg, rb) as f: requests.put(http://192.168.1.100:7000/photo, headersheaders, dataf.read()) # Step 2: 当前图显示完毕触发缓存图显示毫秒级 headers[X-Apple-AssetAction] displayCached requests.put(http://192.168.1.100:7000/photo, headersheaders, datab)注意displayCached的datab是必须的——空 body 表示「只触发缓存渲染不传新数据」。若省略 data服务器会返回400若传 JPEG 数据会覆盖缓存并重新解码失去预加载意义。3.3 SlideshowsXML plist 不是配置文件而是状态机指令集/slideshows/1的 PUT 请求体是 Apple Property Listplist格式但它不是静态配置而是实时状态指令?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keysettings/key dict keyslideDuration/key integer5/integer !-- 单张停留秒数 -- keytheme/key stringClassic/string !-- 必须来自 /slideshow-features -- /dict keystate/key stringplaying/string !-- playing/stopped -- /dict /plist关键约束slideDuration最小值为 1 秒设为 0 会返回400theme字符串必须精确匹配/slideshow-features返回的keykey/key值如Reflections大小写敏感stateplaying会立即开始幻灯片statestopped会清空所有缓存并退出。3.4 避坑照片协议里最隐蔽的三个坑现象 → 原因 → 解决JPEG 图片上传后显示为绿色/紫色色块→ 原因Apple TV 仅支持 baseline JPEG无渐进式、无 CMYK、无 ICC profile。Photoshop 默认导出含 ICCGIMP 默认渐进式。→ 解决用convert input.jpg -strip -interlace none -colorspace sRGB output.jpgImageMagick清洗或 Python PILimg.save(out.jpg, JPEG, optimizeTrue, progressiveFalse)。/slideshows/1返回 200 但幻灯片不启动→ 原因X-Apple-Session-ID在/photo和/slideshows/1中不一致导致状态机无法关联。→ 解决所有请求必须复用同一个X-Apple-Session-IDUUID建议用uuid.uuid4()生成一次全程传递。幻灯片播放中调用/stop但 Apple TV 仍显示最后一张图→ 原因/stop只是发送停止指令实际结束需等待/event回调statestopped。若客户端未监听 event 连接会误判为失败。→ 解决必须建立 reverse HTTP 连接见 4.2 节并解析POST /event的 plist确认categoryslideshow且statestopped后才认为结束。4. Audio 协议RTSP 是遥控器RTP 是水管ALAC 是唯一能喂饱 Apple TV 的音频饲料AirPlay 音频不是简单的 HTTP 流而是 RTSP/RTP 双协议协同的实时管道。RTSPReal Time Streaming Protocol只负责「遥控」播放、暂停、音量、跳转真正的音频数据走 RTPReal-time Transport ProtocolUDP 流封装 ALACApple Lossless帧。这意味着你不能用 FFmpeg 直接-i http://...拉流必须实现 RTSP OPTIONS/DESCRIBE/SETUP/PLAY 信令并解析 SDP 获取 RTP 端口再用自定义 UDP socket 接收 ALAC 包。漏掉任何一环声音就出不来。4.1 RTSP 请求四步握手缺一不可RAOP 服务端口 49152的 RTSP 控制流程严格遵循 RFC 2326OPTIONS探测服务器能力OPTIONS rtsp://192.168.1.100:49152/ RTSP/1.0 CSeq: 1 User-Agent: MediaControl/1.0响应含Public: OPTIONS, ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, GET_PARAMETER, SET_PARAMETER—— 注意ANNOUNCE用于元数据FLUSH用于清空缓冲。DESCRIBE获取媒体描述SDPDESCRIBE rtsp://192.168.1.100:49152/ RTSP/1.0 CSeq: 2 Accept: application/sdp响应 SDP 中关键行artpmap:96 AppleLossless/44100/2→ payload type 96ALAC44.1kHz双声道acontrol:rtsp://192.168.1.100:49152/trackID1→ RTP 流控制地址SETUP协商 RTP 传输参数SETUP rtsp://192.168.1.100:49152/trackID1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port6000-6001响应含Transport: RTP/AVP;unicast;server_port6002-6003—— 服务器分配的 RTP 接收端口。PLAY启动流PLAY rtsp://192.168.1.100:49152/ RTSP/1.0 CSeq: 4 Range: npt0.000-提示client_port6000-6001表示客户端用 6000 接收 RTP6001 接收 RTCP。Apple TV 会向6000发 ALAC 包向6001发 RTCP RR接收报告。4.2 RTP StreamsALAC 帧不是裸数据而是带 16 字节头的压缩块RTP 包结构固定12 字节 RTP header ALAC frame。但 ALAC frame 本身有 16 字节私有头必须剥离才能解码RTP Header (12B) [ALAC Header (16B)] [ALAC Compressed Data]ALAC Header 解析小端序Bytes 0-3frame_lengthALAC 数据长度不含此 headerBytes 4-7unknown恒为 0Bytes 8-11sample_count本帧样本数如 44100Hz 下 1024 样本 23msBytes 12-15unknown恒为 0Python 解包示例import socket import struct sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((, 6000)) while True: data, addr sock.recvfrom(65536) # 跳过 RTP header (12B) alac_data data[12:] # 解析 ALAC header frame_len struct.unpack(I, alac_data[0:4])[0] sample_count struct.unpack(I, alac_data[8:12])[0] # 真正的 ALAC 压缩数据从 offset 16 开始 alac_payload alac_data[16:16frame_len] # 交给 alac_decoder 解码...4.3 Volume Control音量不是百分比而是线性衰减系数RAOP 的音量控制走 RTSPSET_PARAMETER但值不是 0-100而是-30.0到0.0的 dB 值SET_PARAMETER rtsp://192.168.1.100:49152/ RTSP/1.0 CSeq: 5 Content-Type: text/parameters Content-Length: 20 volume: -6.0volume: 0.0 0dB最大音量volume: -30.0≈ 0.03 倍振幅极小声。实测-12.0是日常听感舒适点。注意此参数对 ALAC 有效对 AAC 流无效Apple TV 会忽略。4.4 避坑音频协议里最致命的三个坑现象 → 原因 → 解决RTSP SETUP 返回 461 Unsupported Transport→ 原因Transportheader 中client_port未指定范围如6000-6001或端口被占用。→ 解决必须用client_portA-B格式且 A/B 为连续偶数端口A 为 RTPB 为 RTCP启动前netstat -ulnp | grep :6000确保端口空闲。RTP 包接收正常但解码后全是噪音→ 原因ALAC 帧头未正确剥离或frame_length解析错误导致读取越界。→ 解决打印前 32 字节 hex dump确认alac_data[0:4]确实是小端 4 字节整数用len(alac_payload) frame_len校验。音量调节后无变化或调节延迟 2 秒→ 原因SET_PARAMETER未带CSeq或CSeq未递增导致服务器丢弃请求。→ 解决维护全局cseq_counter每次SET_PARAMETER时cseq_counter 1并在 header 中写CSeq: {cseq_counter}。5. Screen Mirroring不是视频流而是 H.264 Annex B 帧 NTP 时间戳的精密时钟同步系统AirPlay 屏幕镜像Screen Mirroring是协议中最复杂的模块。它不传输原始像素而是将 iOS/macOS 屏幕编码为 H.264 Annex B 格式NALU 分隔符00 00 00 01通过/streamHTTP 接口推送并强制要求 NTP 时间戳对齐。Apple TV 的 GPU 渲染管线会根据时间戳做帧率补偿——若你的时间戳漂移 50ms画面就会撕裂或卡顿。这不是「能连就行」的功能而是对时钟精度、网络抖动、编码延迟的三重考验。5.1 HTTP 请求/stream 是单向流式接口需保持长连接/stream接口本质是 HTTP chunked transfer客户端持续 POST H.264 Annex B 帧POST /stream HTTP/1.1 Host: 192.168.1.100:7000 Content-Type: video/h264 X-Apple-Session-ID: session-123 Transfer-Encoding: chunked每帧数据前需加 8 字节 headerBytes 0-3NALU length大端序不含 start codeBytes 4-7NTP timestamp大端序单位秒自 1900-01-01NTP timestamp 必须来自本地 NTP client非系统时间且与 Apple TV 的 NTP servertime.apple.com误差 10ms。Python 获取精准 NTP 时间import ntplib from datetime import datetime def get_ntp_time(): c ntplib.NTPClient() try: response c.request(time.apple.com, version3) # 转换为 NTP timestamp自 1900-01-01 的秒数 ntp_sec int(response.tx_time) 2208988800 # 1900-1970 偏移 return ntp_sec except: return int(datetime.now().timestamp()) 2208988800 # 构造帧 header ntp_ts get_ntp_time() header struct.pack(II, len(h264_frame), ntp_ts)5.2 Stream PacketsH.264 Annex B 帧必须纯净无 SPS/PPS 冗余Apple TV 要求每帧独立可解码因此首帧必须含 SPSPPS在第一个 chunk 中先发 SPSSequence Parameter Set和 PPSPicture Parameter Set再发 I 帧。后续帧只发 slice dataP/B 帧无需重复 SPS/PPS。NALU 分隔符必须为00 00 00 01不能是00 00 01旧标准否则 Apple TV 解码失败。SPS/PPS 提取FFmpeg 示例ffmpeg -i input.mp4 -vcodec copy -vbsf h264_mp4toannexb -f h264 - | head -c 1000 sps_pps.h264然后在 stream 中[8B header] [SPS] [8B header] [PPS] [8B header] [I-frame] ...5.3 Time SynchronizationNTP 不是可选而是协议层硬性依赖AirPlay 镜像的 NTP 同步不是「最好有」而是「没有就崩」。Apple TV 渲染逻辑收到帧后计算(当前 NTP 时间 - 帧 NTP 时间)得到网络延迟若延迟 10ms立即渲染若延迟 10-50ms插入 1 帧缓冲若延迟 50ms丢弃该帧。因此你的 NTP client 必须每 5 秒同步一次time.apple.com使用ntplib而非time.time()系统时间误差可达 100ms在构造帧 header 前 1ms 内获取时间戳。5.4 避坑屏幕镜像协议里最反直觉的三个坑现象 → 原因 → 解决镜像画面卡顿但网络 ping 延迟 10ms→ 原因NTP 时间戳未校准或使用了系统时间而非 NTP 时间。Apple TV 认为帧已过期而丢弃。→ 解决强制用ntplib同步且response.offset客户端-服务器偏移必须 5ms否则重试。首帧显示绿屏后续帧正常→ 原因SPS/PPS 未放在第一个 chunk或 SPS/PPS 数据损坏如被 gzip 压缩。→ 解决用 hexdump 检查首 chunk 前 100 字节确认00 00 00 01后紧跟67SPS和68PPS禁用所有中间件压缩。镜像启动后 30 秒自动断开→ 原因未发送 keep-alive。Apple TV 要求每 25 秒内至少一个 chunk哪怕空帧超时则断连。→ 解决即使无新帧也每 20 秒发一个 8B header 0-length payloadstruct.pack(II, 0, get_ntp_time())。6. 密码保护与安全边界pwtrue 不是拦路虎而是 FairPlay SAPv2.5 认证的启动开关AirPlay 的密码保护Password Protection常被误解为「输入密码就能连」实则是 FairPlay SAPv2.5 认证流程的触发器。当pwtrue出现在 AirPlay Service TXT 记录中意味着服务器要求客户端完成完整的公钥交换、挑战-响应、AES-GCM 加密握手。这不是 HTTP Basic Auth而是基于 RSA-2048 和 ECDSA 的硬件级认证。跳过它不可能。但理解它就能避开 90% 的「401 Unauthorized」报错。6.1 密码保护流程四步密钥交换缺一不可Client Hello客户端发GET /auth-setup携带X-Apple-Passcode用户输入密码的 SHA256Server Challenge服务器返回200 OKX-Apple-ResponseRSA 加密的随机 challengeClient Response客户端用设备私钥解密 challenge计算HMAC-SHA256(shared_secret, challenge)发POST /pair-setupSession Key Exchange服务器验证后返回 AES-GCM 加密密钥后续所有/stream/photo请求均需 AES 加密 body关键点X-Apple-Passcode不是明文密码而是SHA256(password)shared_secret来自设备证书链iOS/macOS 硬件 Secure Enclave 生成不可导出。6.2 FairPlay SAPv2.5认证不是选择而是协议层强制门禁SAPv2.5Secure Authentication Protocol v2.5是 AirPlay 镜像和 DRM 视频的认证核心。它的存在意味着任何/stream请求若未完成 SAPv2.5返回401 Unauthorized任何/video请求若视频受 FairPlay 保护返回403 ForbiddenRAOP 音频若et5FairPlay SAPv2.5同样需认证。认证失败的典型日志[ERROR] /stream 401: Missing or invalid X-Apple-Session-ID and authentication token这不是 header 漏了而是根本没走/auth-setup流程。6.3 避坑安全协议里最易被忽视的三个坑现象 → 原因 → 解决/auth-setup返回 404→ 原因Apple TV 固件版本 5.0或设备未启用「需要密码」Settings →本文还有配套的精品资源点击获取