从口型不同步说起

上周运营同事紧急找我，说电商直播时观众抱怨主播说话和画面有2秒延迟，促销互动完全对不上节奏。用Wireshark抓包发现RTMP协议在跨国传输时，仅网络抖动就达到800ms，加上编解码缓冲直接突破秒级延迟——这恰好是实时互动场景的致命伤。

协议选型对比

先看关键数据对比（测试环境：1080p@30fps，10Mbps码流）：

| 协议类型 | 端到端延迟 | 抗丢包能力 | 协议头部开销 | |----------|------------|------------|--------------| | RTMP | 1.5-3s | 差（依赖TCP重传） | 12字节 | | WebRTC | 300-800ms | 中等（NACK机制） | 24字节 | | SRT | 200-500ms | 强（ARQ+FEC） | 16字节 |

SRT（Secure Reliable Transport）的前向纠错(FEC)和自动重传请求(ARQ)混合机制，使其在20%丢包下仍能保持流畅传输，这成为我们技术选型的决定性因素。

实战配置

1. Media MTX接入SRT流

# media-mtx.yml 关键配置
srt:
  enabled: true
  address: 0.0.0.0
  port: 6000
  encryption: false  # 测试环境关闭TLS
  readTimeout: 10s
  writeTimeout: 10s
  authMethods:
    - type: "plain"
      username: "ingest_user"
      password: "srt@2024"

推流命令示例（OBS参数）：

srt://server_ip:6000?streamid=#!::r=ingest_user,srt@2024,m=publish

2. SRT参数调优

通过Python脚本动态调整延迟和FEC参数：

# srt_tuning.py
import pysrt

def setup_srt_socket():
    sock = pysrt.srt_socket()
    # 关键参数配置
    sock.set_option(pysrt.SRTO_LATENCY, 500)  # 目标延迟500ms
    sock.set_option(pysrt.SRTO_OHEADBW, 25)   # FEC冗余25%
    sock.set_option(pysrt.SRTO_TSBPDMODE, True)  # 启用时间戳缓冲
    return sock

3. 监控体系搭建

Prometheus指标采集配置：

# prometheus.yml
scrape_configs:
  - job_name: 'srt'
    static_configs:
      - targets: ['media-mtx:9999/metrics']

关键Grafana监控项： - srt_retransmit_bytes_total - srt_rtt_ms - srt_lossrate

性能实测数据

在模拟弱网环境（使用tc工具制造抖动）下的表现：

| 网络条件 | P50延迟 | P95延迟 | P99延迟 | CPU负载 | |----------------|---------|---------|---------|---------| | 5%丢包+50ms抖动 | 320ms | 450ms | 520ms | 22% | | 20%丢包+100ms抖动| 380ms | 550ms | 680ms | 37% |

避坑指南

1. 握手失败排查：
2. 检查防火墙是否放行6000端口（UDP）

3. NAT环境下需要设置SRTO_TRANSTYPE=1（中继模式）

4. 集群部署拓扑：

   graph TD
       A[边缘节点] -->|SRT推流| B[中心Media MTX集群]
       B -->|HLS/DASH| C[CDN边缘]
       B -->|SRT中继| D[备份集群]

5. 安卓兼容方案：

6. 使用libsrt-android 1.4.4+版本
7. 禁用加密（SRTO_PBKEYLEN=0）降低CPU占用

开放性问题

FEC冗余包比例设置需要权衡： - 高冗余（如30%）能抵抗剧烈丢包，但会浪费35%带宽 - 低冗余（如10%）节省流量，但丢包超过15%时画质劣化明显

你们团队是如何确定这个黄金分割点的？欢迎在评论区分享实战经验。