当前位置： 首页 > news >正文

【音视频】HLS拉流抓包分析

news 2025/7/12 8:16:52

一、测试环境

1.1 服务器

在Ubuntu下启动SRS服务器

./objs/srs -c conf/srs.conf

在这里插入图片描述

1.2 推流

使用ffmpeg推流RTMP到SRS服务器

ffmpeg -re -i .\2.mp4 -codec:v h264 -codec:a aac -f flv rtmp://10.22.79.251/live/video

1.3 查看服务器ts列表

推流后，进入对应的推流文件夹下，可以查看到.m3u8文件，以及ts切片

cd objs/srs/nginx/html/live
ls

在这里插入图片描述

.m3u8文件是随着时间动态改变的，类似一个滑动窗口，每次最新的文件去顶替最旧的文件

cat video.m3u8

在这里插入图片描述

1.4 ffplay拉流

使用ffplay下载对应的.m3u8文件，ffplay内部会根据列表下载对应的ts文件

ffplay -i http://10.22.79.251:8081/live/video.m3u8

在这里插入图片描述

二、HLS抓包分析

这里简单分析抓包的内容，主要是分析HTTP的请求和响应报文

2.1 WireShark抓包

设置WireShark过滤条件

ip.addr==10.22.79.251 and http and tcp.port==8081

可以发现，抓取到了许多GET请求报文，主要是两类：

  1. 请求下载.m3u8文件
  2. 请求下载.ts文件

响应报文也对应上面：

  1. 响应下载.m3u8文件的请求
  2. 响应下载.ts文件的请求

在这里插入图片描述

2.2 请求下载.m3u8报文

在 HLS 工作流程中，客户端需要先获取m3u8 索引文件（也就是报文中请求的video.m3u8），通过解析索引文件里的切片列表（.ts视频片段地址）、码率信息等，才能依次拉取视频流播放。这个请求，就是客户端发起的 “获取 m3u8 索引” 的核心动作。

在这里插入图片描述

2.2.1 状态与协议

1. 请求行（Request Line）
GET /live/video.m3u8?hls_ctx=3j4yt616 HTTP/1.1
  • GET方法：HLS 中，客户端通过GET从服务端拉取静态 / 动态生成的 m3u8 索引文件，是最基础的资源获取方式。
  • /live/video.m3u8：HLS 索引文件路径，服务端需按此路径返回对应的 m3u8 内容（包含视频切片列表、码率切换规则等）。
  • hls_ctx=3j4yt616：自定义查询参数（非 HLS 标准字段），可能是：
    • 会话标识：服务端用它区分不同客户端会话、维护播放状态（如鉴权 token、流唯一标识）；
    • 防盗链 / 校验：通过随机串或加密参数，防止非法请求；
    • 多终端适配：传递设备信息（如分辨率、码率偏好），让服务端返回适配的 m3u8 内容。
  • HTTP/1.1：HLS 依赖 HTTP 协议传输，HTTP/1.1的长连接（keep-alive）特性，可让客户端在同一 TCP 连接里连续拉取 m3u8、ts 切片，减少连接开销。
2. 请求头（Request Headers）

  • User-Agent: Lavf/62.0.102
    标识客户端类型，Lavf是 FFmpeg 的 “Libavformat” 库（常用于音视频处理、拉流工具 ），说明发起请求的可能是基于 FFmpeg 开发的播放器、推流 / 拉流程序。服务端可据此做兼容性适配（如返回不同格式的 m3u8 扩展信息）。

  • Accept: */*
    客户端声明 “接受任意类型响应”，因 HLS 中 m3u8 本质是文本文件（Content-Type: application/x-mpegURL或application/vnd.apple.mpegurl ），此配置足够覆盖，确保服务端返回的 m3u8 能被识别。

  • Range: bytes=0-
    请求 “从第 0 字节开始的全部内容”，HLS 里 m3u8 通常是小文本文件，直接完整拉取即可。若服务端支持，也可用于 “续传”（但 m3u8 动态更新频繁，一般用不到）。

  • Connection: keep-alive
    要求保持 TCP 连接，HLS 播放时需连续拉取 m3u8（定时刷新索引）和 ts 切片，长连接可复用连接，提升播放流畅度、降低延迟。

  • Host: 10.22.79.251:8081
    指定服务端 IP 和端口，HLS 服务端需绑定此地址提供 m3u8、ts 资源，客户端通过它精准定位服务。

  • Icy-Metadata: 1

2.2.2 HLS 流程里的后续交互

客户端发送此请求后，服务端需：

  1. 校验参数：检查hls_ctx合法性（如是否鉴权、是否对应有效流）；
  2. 返回 m3u8：找到/live/video.m3u8对应的文件（或动态生成，如按hls_ctx拼接 ts 切片地址 ），设置正确的Content-Type（application/x-mpegURL）返回；
  3. 客户端解析：拿到 m3u8 后，解析出#EXTINF（切片时长）、#EXT-X-STREAM-INF（多码率信息）、ts切片地址，然后按序发起GET请求拉取视频流，实现播放。

2.3 响应请求下载.m3u8文件报文

这是一条HTTP 1.1 响应报文，与 HLS（HTTP Live Streaming，基于 HTTP 的自适应码率流媒体传输协议 ）场景强相关，是服务端对客户端获取 m3u8 索引文件请求的回应

在这里插入图片描述

2.3.1 状态与协议

HTTP/1.1 200 OK
  • HTTP/1.1：服务端用 HTTP 1.1 协议响应，支持长连接（但此报文 Connection: Close 主动关闭，不过 HLS 可通过多次请求适配 ）。
  • 200 OK：状态码表示请求成功，服务端已找到并准备返回客户端请求的 m3u8 资源（HLS 播放流程的关键一步：拿到索引文件才能解析视频切片）。

2.3.2 响应头（Response Headers）与 HLS 关联

1. Connection: Close

服务端告知客户端：本次响应后关闭 TCP 连接。

  • HLS 中，客户端后续会频繁请求 m3u8（定时刷新索引）和 ts 切片，虽然当前连接关闭，但 HTTP 1.1 可通过新连接继续请求，或服务端也可能根据配置改用长连接（这里是明确主动关闭）。
2. Content-Type: application/vnd.apple.mpegurl

HLS 标准响应类型，标识返回的内容是 m3u8 索引文件（苹果定义的 MPEG - DASH 流媒体索引格式 ）。

  • 客户端（如播放器）看到此头，会按 HLS 协议解析内容（识别 #EXTINF 切片时长、#EXT-X-STREAM-INF 多码率信息等 ）。
3. Content-Length: 298

返回的 m3u8 文件大小为 298 字节，客户端可校验接收数据是否完整（防止网络丢包导致解析失败 ）。

4. Server: SRS/6.0.134(Hang)

暴露服务端软件：SRS（Simple - RTMP - Server，轻量级流媒体服务器 ），版本 6.0.134。

  • SRS 常被用于直播场景，支持 RTMP 推流转 HLS 拉流，这里作为 HLS 服务端提供 m3u8 索引。
5. 下载的.m3u8文件
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:9
#EXTINF:8.333, no desc
video-1.ts?hls_ctx=3j4yt616
#EXTINF:8.333, no desc
video-2.ts?hls_ctx=3j4yt616
#EXTINF:7.434, no desc
video-3.ts?hls_ctx=3j4yt616
#EXT-X-DISCONTINUITY
#EXTINF:8.334, no desc
video-4.ts?hls_ctx=3j4yt616

TS 切片详情

  1. #EXTINF:8.333, no desc + video-1.ts?hls_ctx=3j4yt616

    • 8.333：该 TS 切片的实际播放时长（秒）；
    • no desc：自定义描述（无实际意义，可填写切片标题、编码信息等）；
    • video-1.ts?hls_ctx=3j4yt616：切片的网络地址，hls_ctx=3j4yt616 是会话参数（用于服务端鉴权、关联播放会话，确保切片与请求匹配）。

  2. #EXTINF:8.333, no desc + video-2.ts?hls_ctx=3j4yt616

    • 与第一个切片时长相同（8.333 秒），按序列号 2 顺序播放。

  3. #EXTINF:7.434, no desc + video-3.ts?hls_ctx=3j4yt616

    • 时长略短（7.434 秒），仍符合 #EXT-X-TARGETDURATION:9 定义的最大时长，序列号为 3。

  4. #EXT-X-DISCONTINUITY

    • 特殊标签：标记流不连续（可能是编码格式、分辨率、时间戳突变，例如推流端中途切换编码器导致切片参数变化）。
    • 作用：播放器需重置解码器状态（如清空缓存、重新初始化解码参数），避免画面花屏或声音卡顿。

  5. #EXTINF:8.334, no desc + video-4.ts?hls_ctx=3j4yt616

    • 时长 8.334 秒，序列号为 4（因 #EXT-X-DISCONTINUITY 标记，该切片与前一个切片可能存在参数差异，播放器需适配）。

2.3.3 HLS 场景下的后续流程

客户端收到此响应后：

  1. 解析 m3u8 内容：读取 #EXTINF（切片时长）、#EXT-X-STREAM-INF（多码率列表）、ts 切片地址（如 live/video_1.ts ）；
  2. 拉取视频流：按 m3u8 索引，依次发起 GET 请求拉取 ts 切片，实现连续播放；
  3. 定时刷新：若 m3u8 含 #EXT-X-REFRESH 或客户端策略，会定时重新请求 m3u8（对应 Next request in frame ），确保获取最新切片列表（直播场景关键，保证流实时更新 ）。

2.4 请求下载.ts文件报文

这是一个HTTP GET 请求报文，用于在 HLS（HTTP Live Streaming，基于 HTTP 的自适应码率流媒体传输协议）场景中，拉取视频切片文件（video-4.ts）

在这里插入图片描述

2.4.1 状态与协议

GET /live/video-4.ts?hls_ctx=3j4yt616 HTTP/1.1
  • GET 方法：客户端通过 GET 从服务端拉取TS 视频切片（HLS 中，视频流被分割为多个 .ts 小文件，按序播放实现连续视频 ）。
  • /live/video-4.ts：请求的TS 切片路径，对应 m3u8 索引文件中 #EXTINF 条目里的切片地址（如之前解析的 video-4.ts?hls_ctx=3j4yt616 ）。
  • hls_ctx=3j4yt616：自定义查询参数（与 m3u8 索引关联），作用：
    • 会话标识：服务端用它关联播放会话（如鉴权、流唯一标识）；
    • 防盗链/校验：防止非法请求，确保切片与 m3u8 索引匹配。
  • HTTP/1.1：基于 HTTP 1.1 协议，支持长连接（Connection: keep-alive ），减少多次请求的连接开销。

2.4.2 请求头（Request Headers）与 HLS 关联

1. User-Agent: Lavf/62.0.102

标识客户端类型：Lavf 是 FFmpeg 的“Libavformat”库（常用于音视频处理、播放器 ），说明发起请求的是基于 FFmpeg 的播放工具（或直播拉流程序 ）。

  • 服务端可据此适配响应（如兼容旧版 HLS 特性）。
2. Accept: */*

客户端声明“接受任意类型响应”，因 TS 切片是二进制视频流（Content-Type: video/MP2T ），此配置确保服务端返回的内容能被识别。

3. Range: bytes=0-

请求“从第 0 字节开始的全部内容”，TS 切片是完整的视频片段，直接拉取即可。若网络中断，可用于续传（但 HLS 切片小、动态更新，一般用不到 ）。

4. Connection: keep-alive

要求保持 TCP 连接，HLS 播放时需连续拉取多个 TS 切片（按 m3u8 索引顺序），长连接可复用连接，提升播放流畅度、降低延迟。

5. Host: 10.22.79.251:8081

指定服务端 IP 和端口，HLS 服务端需绑定此地址提供 TS 切片，客户端通过它精准定位服务。

6. Icy-Metadata: 1

源自 ICEcast 流媒体协议的扩展头，用于传递音频流元数据（如主播名、歌曲名 ）。若服务端支持，会在 TS 流里携带元数据；即使不支持，也不影响视频播放（可能是客户端通用配置 ）。

2.4.3 HLS 流程里的上下文

客户端发送此请求前，已完成：

  1. 获取 m3u8 索引：解析到 video-4.ts?hls_ctx=3j4yt616 切片地址（如之前的 m3u8 报文 ）；
  2. 按序拉取切片：前 3 个切片（video-1.ts、video-2.ts、video-3.ts ）已请求，此为第 4 个切片，保证播放连续性。

2.5 响应请求下载ts报文

这是一条HTTP 1.1 响应报文，是服务端对客户端拉取 HLS 视频切片（video-4.ts）请求的回应：

在这里插入图片描述

2.5.1 状态与协议

HTTP/1.1 200 OK
  • HTTP/1.1：服务端用 HTTP 1.1 协议响应，支持长连接（但此报文 Connection: Close 主动关闭，不过 HLS 可通过多次请求适配 ）。
  • 200 OK：状态码表示请求成功，服务端已找到并返回客户端请求的 TS 视频切片（HLS 播放流程的核心：拿到切片才能拼接播放 ）。

2.5.2 响应头

1. Connection: Close

服务端告知客户端：本次响应后关闭 TCP 连接。

  • HLS 中，客户端后续会频繁请求其他 TS 切片（按 m3u8 索引顺序），虽然当前连接关闭，但 HTTP 1.1 可通过新连接继续请求，或服务端也可能根据配置改用长连接（这里是明确主动关闭）。
2. Content-Length: 1456060

返回的 TS 切片 大小为 1,456,060 字节（约 1.39MB ），客户端可校验接收数据是否完整（防止网络丢包导致播放卡顿/花屏 ）。

3. Content-Type: video/MP2T

TS 切片的标准 MIME 类型（MPEG-2 Transport Stream ），标识返回的是视频流数据。

  • 客户端（如播放器）看到此头，会按 video/MP2T 解析内容（解码 TS 流，渲染视频画面 ）。
4. Server: SRS/6.0.134(Hang)

暴露服务端软件：SRS（Simple-RTMP-Server，轻量级流媒体服务器 ），版本 6.0.134。

  • SRS 常被用于直播场景，支持 RTMP 推流转 HLS 拉流，这里作为 HLS 服务端提供 TS 切片。

2.5.3 TS 切片内容解析

报文下方的 ISO/IEC 13818-1、MPEG2 Program Association Table 等，是 Wireshark 对 TS 切片 的解析：

  • ISO/IEC 13818-1：MPEG-2 传输流的标准协议，PID（Packet Identifier ）用于标识流中的不同内容（如视频、音频、节目信息 ）。
  • MPEG2 Program Association Table：节目关联表，描述 TS 流中包含的节目、音视频 PID 映射关系，是播放器解码的基础。
  • Packetized Elementary Stream：打包的基本流，包含实际的视频/音频数据，播放器需解包、解码后渲染。

2.5.4 HLS 场景下的后续流程

客户端收到此响应后：

  1. 解码播放：按 video/MP2T 解析 TS 切片，解包音视频数据，渲染画面、播放声音；
  2. 请求下一切片：根据 m3u8 索引，发起下一个 TS 切片 请求（如 video-5.ts ），保证播放连续性；
  3. 处理延迟：若 Time since request 过大，播放器可能因缓冲不足出现卡顿，需依赖服务端优化切片生成速度或客户端增加缓冲。

2.6 请求下载第二个ts报文

这是一个HTTP GET 请求报文，用于在 HLS（HTTP Live Streaming，基于 HTTP 的自适应码率流媒体传输协议）场景中，拉取视频切片文件（video-5.ts）

在这里插入图片描述

2.6.1 状态与协议

GET /live/video-5.ts?hls_ctx=3j4yt616 HTTP/1.1

  • GET 方法：客户端通过 GET 从服务端拉取TS 视频切片（HLS 中，视频流被分割为多个 .ts 小文件，按序播放实现连续视频 ）。

  • /live/video-5.ts：请求的TS 切片路径，对应 m3u8 索引文件中 #EXTINF 条目里的切片地址（如之前解析的 video-5.ts?hls_ctx=3j4yt616 ）。

  • hls_ctx=3j4yt616：自定义查询参数（与 m3u8 索引关联），作用：

    • 会话标识：服务端用它关联播放会话（如鉴权、流唯一标识）；
    • 防盗链/校验：防止非法请求，确保切片与 m3u8 索引匹配。

  • HTTP/1.1：基于 HTTP 1.1 协议，支持长连接（Connection: keep-alive ），减少多次请求的连接开销。

2.6.2 请求头

1. User-Agent: Lavf/62.0.102

标识客户端类型：Lavf 是 FFmpeg 的“Libavformat”库（常用于音视频处理、播放器 ），说明发起请求的是基于 FFmpeg 的播放工具（或直播拉流程序 ）。

  • 服务端可据此适配响应（如兼容旧版 HLS 特性）。
2. Accept: */*

客户端声明“接受任意类型响应”，因 TS 切片是二进制视频流（Content-Type: video/MP2T ），此配置确保服务端返回的内容能被识别。

3. Range: bytes=0-

请求“从第 0 字节开始的全部内容”，TS 切片是完整的视频片段，直接拉取即可。若网络中断，可用于续传（但 HLS 切片小、动态更新，一般用不到 ）。

4. Connection: keep-alive

要求保持 TCP 连接，HLS 播放时需连续拉取多个 TS 切片（按 m3u8 索引顺序），长连接可复用连接，提升播放流畅度、降低延迟。

5. Host: 10.22.79.251:8081

指定服务端 IP 和端口，HLS 服务端需绑定此地址提供 TS 切片，客户端通过它精准定位服务。

6. Icy-Metadata: 1

源自 ICEcast 流媒体协议的扩展头，用于传递音频流元数据（如主播名、歌曲名 ）。若服务端支持，会在 TS 流里携带元数据；即使不支持，也不影响视频播放（可能是客户端通用配置 ）。

2.6.3 HLS 流程里的上下文

客户端发送此请求前，已完成：

  1. 获取 m3u8 索引：解析到 video-5.ts?hls_ctx=3j4yt616 切片地址（如之前的 m3u8 报文 ）；
  2. 按序拉取切片：前 4 个切片（video-1.ts、video-2.ts、video-3.ts、video-4.ts ）已请求，此为第 5 个切片，保证播放连续性。

2.7 响应第二个请求下载ts报文

这是一条HTTP 1.1 响应报文，是服务端对客户端拉取 HLS 视频切片（video-5.ts）请求的回应

在这里插入图片描述

2.7.1 状态与协议

HTTP/1.1 200 OK
  • HTTP/1.1：服务端通过 HTTP 1.1 协议响应，支持长连接（但此报文 Connection: Close 主动关闭，HLS 可通过多次请求适配 ）。
  • 200 OK：状态码表示请求成功，服务端已找到并返回客户端请求的 TS 视频切片（HLS 播放流程的核心：拿到切片才能拼接播放 ）。

2.7.2 响应头（Response Headers）与 HLS 关联

1. Connection: Close

服务端告知客户端：本次响应后关闭 TCP 连接。

  • HLS 中，客户端后续会频繁请求其他 TS 切片（按 m3u8 索引顺序），当前连接关闭后，HTTP 1.1 可通过新连接继续请求，或服务端也可能根据配置改用长连接（这里明确主动关闭）。
2. Content-Length: 2112556

返回的 TS 切片 大小为 2,112,556 字节（约 2.02MB ），客户端可校验接收数据是否完整（防止网络丢包导致播放卡顿/花屏 ）。

3. Content-Type: video/MP2T

TS 切片的标准 MIME 类型（MPEG-2 Transport Stream ），标识返回的是视频流数据。

  • 客户端（如播放器）看到此头，会按 video/MP2T 解析内容（解码 TS 流，渲染视频画面 ）。
4. Server: SRS/6.0.134(Hang)

暴露服务端软件：SRS（Simple-RTMP-Server，轻量级流媒体服务器 ），版本 6.0.134。

  • SRS 常用于直播场景，支持 RTMP 推流转 HLS 拉流，这里作为 HLS 服务端提供 TS 切片。

2.7.3 TS 切片内容解析

报文下方的十六进制数据，是 Wireshark 对 TS 切片 的原始解析：

  • video/MP2T 格式：TS 切片遵循 MPEG-2 传输流标准，包含 PAT（节目关联表）、PMT（节目映射表）、音视频数据等。
  • 解码依赖：客户端需解析这些二进制数据，提取 PAT/PMT 找到音视频流 PID，再解码播放。

2.7.4 HLS 场景下的后续流程

客户端收到此响应后：

  1. 解码播放：按 video/MP2T 解析 TS 切片，解包音视频数据，渲染画面、播放声音；
  2. 请求下一切片：根据 m3u8 索引，发起下一个 TS 切片 请求（如 video-6.ts ），保证播放连续性；
  3. 处理延迟：若 Time since request 过大，播放器可能因缓冲不足出现卡顿，需依赖服务端优化切片生成速度或客户端增加缓冲。

2.8 第二次下载m3u8文件

这是一个 HTTP GET 请求报文，用于在 HLS（HTTP Live Streaming，基于 HTTP 的自适应码率流媒体传输协议）场景中，拉取 HLS 索引文件（video.m3u8）

在这里插入图片描述

2.8.1 状态与协议

GET /live/video.m3u8?hls_ctx=3j4yt616 HTTP/1.1

  • GET 方法：客户端通过 GET 从服务端拉取 HLS 索引文件（.m3u8），这是 HLS 播放的第一步（客户端需先拿到 .m3u8，才能解析后续的 TS 视频切片地址 ）。

  • /live/video.m3u8：请求的 HLS 索引文件路径，服务端需按此路径返回 .m3u8 文件（包含 TS 切片列表、码率信息、播放参数等 ）。

  • hls_ctx=3j4yt616：自定义查询参数（非 HLS 标准字段），作用：

    • 会话标识：服务端用它区分不同客户端会话、维护播放状态（如鉴权 token、流唯一标识）；
    • 防盗链/校验：通过随机串或加密参数，防止非法请求；
    • 多终端适配：传递设备信息（如分辨率、码率偏好），让服务端返回适配的 .m3u8 内容。

  • HTTP/1.1：基于 HTTP 1.1 协议，支持长连接（Connection: keep-alive ），减少多次请求的连接开销（HLS 需频繁请求 .m3u8 和 TS 切片 ）。

2.8.2 请求头

1. User-Agent: Lavf/62.0.102

标识客户端类型：Lavf 是 FFmpeg 的“Libavformat”库（常用于音视频处理、播放器、拉流工具 ），说明发起请求的是 基于 FFmpeg 的应用程序（如直播拉流程序、自定义播放器 ）。

  • 服务端可据此适配响应（如返回更简洁的 HLS 扩展头，或兼容旧版 FFmpeg 的特性 ）。
2. Accept: */*

客户端声明“接受任意类型响应”，因 .m3u8 本质是文本文件（Content-Type: application/x-mpegURL 或 application/vnd.apple.mpegurl ），此配置确保服务端返回的内容能被识别。

3. Range: bytes=0-

请求“从第 0 字节开始的全部内容”，.m3u8 通常是小文本文件，直接完整拉取即可。若服务端支持，也可用于“续传”（但 .m3u8 动态更新频繁，一般用不到 ）。

4. Connection: keep-alive

要求保持 TCP 连接，HLS 播放时需频繁请求 .m3u8（定时刷新索引）和 TS 切片，长连接可 复用连接，提升播放流畅度、降低延迟。

5. Host: 10.22.79.251:8081

指定服务端 IP 和端口，HLS 服务端需绑定此地址提供 .m3u8 和 TS 切片，客户端通过它精准定位服务。

6. Icy-Metadata: 1

源自 ICEcast 流媒体协议的扩展头，用于传递音频流元数据（如主播名、歌曲名 ）。若服务端支持，会在 .m3u8 或 TS 流里携带元数据；即使不支持，也不影响 HLS 视频播放（可能是客户端通用配置带的冗余头 ）。

2.8.3 HLS 流程里的上下文

客户端发送此请求后，期望服务端：

  1. 校验参数：检查 hls_ctx 的合法性（如是否鉴权、是否对应有效流 ）；
  2. 返回 .m3u8：找到 /live/video.m3u8 对应的文件（或动态生成，如按 hls_ctx 拼接 TS 切片地址 ），设置正确的 Content-Type（application/x-mpegURL 或 application/vnd.apple.mpegurl ）返回；
  3. 客户端解析：拿到 .m3u8 后，解析出 #EXTINF（切片时长）、#EXT-X-STREAM-INF（多码率信息）、TS 切片地址（如 video-1.ts ），然后按序发起 GET 请求拉取视频流，实现播放。

2.9 响应请求下载第二个m3u8报文

这是一条HTTP 1.1 响应报文，用于向客户端返回 HLS 流媒体的 m3u8 索引文件

在这里插入图片描述

2.9.1 状态与协议

HTTP/1.1 200 OK
  • HTTP/1.1：服务端通过 HTTP 1.1 协议响应，支持长连接（但此报文 Connection: Close 主动关闭，HLS 可通过多次请求适配 ）。
  • 200 OK：状态码表示请求成功，服务端已找到并返回客户端请求的 m3u8 索引文件（HLS 播放流程的起点：客户端需先拿到 m3u8 才能解析 TS 切片 ）。

2.9.2 响应头

1. Connection: Close

服务端告知客户端：本次响应后关闭 TCP 连接。

  • HLS 中，客户端后续会频繁请求 m3u8（定时刷新索引）和 TS 切片，当前连接关闭后，HTTP 1.1 可通过新连接继续请求，或服务端也可能根据配置改用长连接（这里明确主动关闭）。
2. Content-Type: application/vnd.apple.mpegurl

HLS 标准响应类型，标识返回的内容是 m3u8 索引文件（苹果定义的 MPEG-DASH 流媒体索引格式 ）。

  • 客户端（如播放器）看到此头，会按 HLS 协议解析内容（识别 #EXTINF 切片时长、#EXT-X-STREAM-INF 多码率信息等 ）。
3. Content-Length: 298

返回的 m3u8 文件大小为 298 字节，客户端可校验接收数据是否完整（防止网络丢包导致解析失败 ）。

4. Server: SRS/6.0.134(Hang)

暴露服务端软件：SRS（Simple-RTMP-Server，轻量级流媒体服务器 ），版本 6.0.134。

  • SRS 常用于直播场景，支持 RTMP 推流转 HLS 拉流，这里作为 HLS 服务端提供 m3u8 索引。

2.9.3 m3u8 内容解析

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:3
#EXT-X-TARGETDURATION:9
#EXTINF:7.434, no desc
video-3.ts?hls_ctx=3j4yt616
#EXT-X-DISCONTINUITY
#EXTINF:8.334, no desc
video-4.ts?hls_ctx=3j4yt616
#EXTINF:8.333, no desc
video-5.ts?hls_ctx=3j4yt616
#EXTINF:8.333, no desc
video-6.ts?hls_ctx=3j4yt616
  • 关键字段作用：
    • #EXT-X-MEDIA-SEQUENCE:3：切片起始序列号为 3，后续切片按序播放；
    • #EXT-X-TARGETDURATION:9：单个切片最大时长 9 秒，指导客户端缓冲；
    • #EXT-X-DISCONTINUITY：标记流不连续（如编码变更），需客户端重置播放状态。

2.9.4 HLS 场景下的后续流程

客户端收到此响应后：

  1. 解析 m3u8：读取 TS 切片 地址（如 video-3.ts）、时长、不连续标记；
  2. 拉取 TS 切片：按 m3u8 索引，依次请求 TS 切片（如 video-3.ts、video-4.ts ），实现连续播放；
  3. 定时刷新：若 m3u8 含 #EXT-X-REFRESH 或客户端策略，会定时重新请求 m3u8（对应 Next request in frame ），确保获取最新切片列表（直播场景关键 ）。

更多资料：https://github.com/0voice

http://www.lryc.cn/news/585093.html

相关文章：

  • 物联网与互联网融合生态
  • C#事件：从原理到实践的深度剖析
  • 小架构step系列11：单元测试引入
  • 基于规则匹配的文档标题召回
  • 【天坑记录】cursor jsx文件保存时错误格式化了
  • PHY模式，slave master怎么区分
  • [Dify] -基础入门4-快速创建你的第一个 Chat 应用
  • 三坐标微米级测量精度，高精度检测液压支架导向套的几何公差尺寸
  • 基于vscode的go环境安装简介
  • 冒泡、选择、插入排序：三大基础排序算法深度解析（C语言实现）
  • 排序算法(一)：冒泡排序
  • 没有Mac如何完成iOS 上架：iOS App 上架App Store流程
  • python的社区残障人士服务系统
  • PC网站和uniapp安卓APP、H5接入支付宝支付
  • 通过命名空间引用了 Application 类，php不会自动包含路径文件吗？
  • Android原生TabLayout使用技巧
  • 没有管理员权限，在服务器安装使用 Jupyter + R 内核
  • springboot生成pdf方案之dot/html/图片转pdf三种方式
  • 深度学习入门教程（三）- 线性代数教程
  • SQL：数据库查询语言的核心技术
  • 语音对话秒译 + 视频悬浮字 + 相机即拍即译：ViiTor 如何破局跨语言场景？
  • FPGA实现SDI转LVDS视频发送，基于GTP+OSERDES2原语架构，提供工程源码和技术支持
  • 每日一SQL 【游戏玩法分析 IV】
  • 物联网应用开发技术趋势与实践指南
  • 华为数据通信网络基础
  • 《Java EE与中间件》实验三 基于Spring Boot框架的购物车
  • 搭建渗透测试环境
  • 每天一个前端小知识 Day 28 - Web Workers / 多线程模型在前端中的应用实践
  • Java Stream流介绍及使用指南
  • 冒泡排序和快速排序