Moonlight串流总是卡顿？从技术角度谈虚拟局域网下 Moonlight 串流优化

距离上次发布 Zerotier + Moonlight 教程已经过去了接近半年的时间，在此过程中也获得了很多播放量和访问量。由于之前一直是教育网公网 ip 直连的情况，几乎可以做到无感穿串流，因此没有过多关注相关技术细节和优化，也并没有使用 Zerotier 搭建虚拟局域网进行串流。

最近由于不在学校而失去了教育网环境，被控机处于西安的教育网环境，主控机则处于黑龙江移动宽带，可见不仅物理距离数千公里并且网络线路复杂度相当复杂，无法直接通过公网 ip 进行串流，于是通过官方推荐的 Zerotier 虚拟组网工具搭建虚拟局域网进行串流。但在串流过程中遇到了非常明显的卡顿现象，几乎无法正常使用，在仔细分析内在原因，搜索相关技术原理之后，通过测试和修改参数，使原本卡顿的串流大大改善，几乎可以实现公网串流的效果，并且在这几天通过串流玩完了对流畅度要求很高的视频游戏——【采石场惊魂】。

鉴于上述经历，加之好多看过视频的朋友私信我关于串流卡顿的问题，这篇文章想和大家分享一下相关知识和解决问题的过程，希望能够帮助大家，也希望帮助因为串流卡顿而放弃 Moonlight 方案的朋友体验到前所未有的远程串流体验，如果觉得对你有帮助欢迎点赞转发，原文在我的博客。

大家在通过 Monnlight 串流时，一定见过下面这样的画面。

不知道大家有没有好奇过 RTSP 到底是个什么东西，既然是通过这个东西进行串流，想必它一定就是解决卡顿的关键。下面关于 RTSP 的相关内容引用自维基百科。

实时流协议（Real Time Streaming Protocol，RTSP）是一种网络应用协议，专为娱乐和通信系统的使用，以控制流媒体服务器。虽然在某些方面与HTTP类似，RTSP定义了控制多媒体播放控制顺序。虽然HTTP是无状态的，但RTSP具有状态; 当需要跟踪并发会话时使用标识符。像HTTP一样，RTSP使用TCP来维护端到端连接，而大多数RTSP控制消息由客户端发送到服务器，一些命令沿着另一个方向（即从服务器到客户端）传播。

简而言之， RTSP 就是通过有状态的 TCP 协议实现对服务器的实时控制。一方面，被控主机通过该协议向主控机传输视频流，另一方面主控机把鼠标键盘等控制器的操作信息发送给被控端，进而实现对被控机的实时控制。

通过分析这个过程，很显然画面卡顿的瓶颈在于需要大量带宽的被控端视频流的传输。

在 Moonlight 的设置中，关于视频流的传输有三个参数分辨率、帧率、码率。

帧率：FPS（每秒钟要多少帧画面） 

码率：编码器每秒编出的数据大小，单位是 kbps ，比如 800kbps 代表编码器每秒产生 800kb（或 100KB ）的数据  

分辨率：单位英寸中所包含的像素点数

帧率影响了视频的流畅程度，分辨率影响了视频画面的长宽比和大小，码率影响了视频每秒输出的数据大小。说得直白一点，视频就是快速播放的图片，因为播放的足够快，由于人眼的错觉导致我们感觉画面看起来是流畅的，

你有没有这样的疑惑：既然视频是一系列图片，那视频的大小是不是应该等于这些图片的总大小，那为什么还要再设置一个叫码率的参数，码率不是应该等于【每秒的帧数(帧率) 】*【每一帧图片的大小(分辨率)】么？

我们不妨做一个简单的计算：对于最常见的 1920*1080 分辨率 30fps 帧率的视频，每秒的数据量是多少呢？

首先假设每个像素需要 3Byte（1Byte=8bit）的数据量

每秒数据量 = 1920*1080*3*8*30/1024/1024 = 1423Mbps = 1.39Gbps

面对这样的结果，你会不会很惊讶！我们平时看的视频每秒钟有超过 1Gb 的数据传输？！我们的网络传输真的有这么快吗？显然没有！如果是这样的话你的流量岂不是几秒钟就没了😂而实际上你的流量每秒钟只有几个 Mb 或者几百 Kb，为什么会出现这种现象呢？

答案是编码！视频标准的制定者当然也意识到了这个问题，为了让有限的带宽能够传输视频，就需要对原始数据进行压缩，具体技术标准有很多，比如 MPEG 系列和 H.26X 系列。通过这些编码方式，能够在尽可能少地损失画质的前提下大幅度压缩视频的体积。例如 H264 可以把视频压缩 250 倍，而 H265 可以把视频压缩 300-500 倍，当然，随着压缩比的提高，画质随时会更大。

对于串流来说，分辨率就是输出视频的大小，默认为主控机的分辨率，我们不应该改变，因为如果使用了错误的分辨率，会导致全屏显示时显示出现下面这样的黑边

帧率是画面的流畅度，网络质量差时不建议开 60fps ，因为丢包会导致卡顿掉帧，在高帧帧率下更加影响体验

最重要的是码率，根据前面所说，码率是视频编码后每秒输出的数据大小，而编码后输出的画面就是被传输到主控端的画面，因此如果码率超过了被控端向主控端传输数据的最大速率，必然会导致卡顿和掉帧，因此改善串流质量的关键是找到被控端向主控端传输数据的最大速率，并把码率调到这个数值一下并尽可能接近这个极限数值。

iperf3 是一款带宽测试工具，它支持调节各种参数，比如通信协议，数据包个数，发送持续时间，测试完会报告网络带宽，丢包率和其他参数。通过 iperf3 这款工具，我们可以测量出被控端传输向主控端传输的极限速度。下面简单介绍 macos 和 windows 下的 iperf3 使用方法。

只需要使用 homebrew 工具执行下面的代码

brew install iperf3

只需要在 iperf3 官网选择合适的版本下载压缩包，并解压到任意位置

macos 可以直接在终端使用 iperf3 命令

windows 需要在解压文件夹打开终端（注意，windows需要关闭 Windows Defender 网络防火墙）

iperf3 的原理是通过 client 向 server 发送数据从而测量带宽，因此为了测量从被控端向主控端传输数据的带宽（注意方向，带宽通常不对等），我们需要把主控端作为服务端，被控端作为客户端，注意，在测量带宽时建议尽量关闭其他联网应用，包括串流，以获得较接近真实的结果

macos

iperf3 -s

windows

iperf3.exe -s

macos

iperf3 -c [主控端ip] -i 1 -t 60

windows

iperf3.exe -c [主控端ip] -i 1 -t 60

通过结果可以看到，我的平均带宽是 4.5Mbps，也就是说，被控端向主控端传输数据最大速率就是 4.5Mbps ，如果我把码率设置为高于这个值，就像把大水桶接在小水管上面，水没法顺畅地流，因此需要把码率设置为小于等于 4.5Mbps。为了证明这个说法我分别用 6Mbps 和 4.5Mbps 进行串流测试。

6Mbps（有声音但是黑屏）

4.5Mbps（直播弹幕流畅）

感谢你看完这篇文章，希望你有所收获！