1. 前言
市面上的开源RTSP服务器太过于复杂，我们今天使用GO语言，开发一款史上最简单的RTSP直播服务器，不依赖任何第三方GO语言框架，使用原生GO语言撸。
说起视频直播协议，最开始，笔者使用的是ffmpeg + nginx（RTMP）方案，但是nginx的RTMP模块有个问题，至少要六七秒才能够出画面，不知道是RTMP协议问题还是nginx的rtmp模块问题。过一段时间，我再用go语言撸一个RTMP服务器。
由于ffmpeg + nginx的上述缺点，所以我又转向了EasyDarwin的RTSP服务器方案，也就是ffmpeg + EasyDarwin（RTSP）方案，相比之下RTSP可以在两秒之内出现画面，超乎我的意料。
过了一段时间之后，发现EasyDarwin也有一些缺点，由于我需要鉴权、推流回调、播放回调，而且好像EasyDarwin在github上并没有注明是否可以商用，因此使用EasyDarwin也有一定的风险。
综上所述，我决定开发一款自己的RTSP服务器，首选语言当然是GO语言了，而且我决定不引用任何第三方框架，纯用原生GO撸。
其实我觉得，flash已经被抛弃了，相应的RTMP协议也应该被抛弃，RTMP播放延迟高，而且打开速度慢，相比之下RTSP协议延迟在1秒以内，打开速度超快。
2. RTSP
说到RTSP，不得不说到RTP（实时传输协议），RTP是用来传输视频帧数据。但是，在很多场景下，我们要和服务器进行一些其他交互，比如控制RTP传输，然后RTSP协议就诞生了，RTSP类似于HTTP协议，在传输RTP视频帧之前，双方先进行RTSP协议 交互，RTSP协议交互完成后，然后推流端不断发送RTP视频帧给RTSP服务器，拉流端则等待RTSP服务器发送RTP视频帧。
说到底，RTSP协议 = RTSP（字符串协议，类似HTTP）数据+ RTP（二进制协议）数据，其中，RTP数据原样转发就行，推流端推过来的RTP数据，服务器原样转发给播放段就行。不同的是，推流端和播放端，首先要采用RTSP协议，和服务器进行几个回合的交互，交互完成后，就轮到RTP二进制数据了。
我们这里不考虑RTSP走UDP协议，我在其它文章中测试过，UDP非常容易丢帧，而且容易花屏，受限制太多，因此我们这里只考虑基于TCP的RTSP协议。
RTSP官方给的命令太多，我们这里不考虑点播，只考虑直播。
对于一个完整的RTSP直播系统来说，有推流端（Pusher）、服务器端（Server）、播放端（Player）
3. 推流端
推流端的工作流程如下：
3.1 OPTIONS
推流端发送：
OPTIONS rtsp://192.168.1.201:5545/2_1 RTSP/1.0\nCSeq: 1\nUser-Agent: Lavf58.37.100\n\n需要注意的是，\n是回车符，这是我特意标注出来的,在下面我就不把回车符显示出来了，凡是换行，必有回车符
RTSP回应：
RTSP/1.0 200 OK
CSeq: 1
Session: ZTnZLWlGg
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD
在回应消息中，Session是在此时RTSP服务器生成的，在推流端整个连接周期内，都使用这个Session
3.2 ANNOUNCE
推流端发送：
ANNOUNCE rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: Lavf58.37.100
Session: ZTnZLWlGg
Content-Length: 296
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.1.201
t=0 0
a=tool:libavformat 58.37.100
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z00AKp2oHgCJ+WbgICAoAAADAAgAAAMBlCA=,aO48gA==; profile-level-id=4D002A
a=control:streamid=0RTSP服务器收到这个消息之后，需要把从"v=0"一直到最后，这段文字，保存起来，因为这是这个RTSP通道的sdp消息，播放端请求数据的时候，需要这个。
RTSP服务器发送：
RTSP/1.0 200 OK
CSeq: 2
Session: ZTnZlWLGg
3.3 SETUP
推流端发送：
SETUP rtsp://192.168.1.201:5545/2_1/streamid=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
CSeq: 3
User-Agent: Lavf58.37.100
Session: ZTnZLWlGg
RTSP服务器回应：
RTSP/1.0 200 OK
CSeq: 3
Session: ZTnZLWlGg
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
3.4 RECORD
推流端发送：
RECORD rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf58.37.100
Session: ZTnZLWlGg
RTSP服务器回应：
RTSP/1.0 200 OK
CSeq: 4
Session: ZTnZLWlGg
3.5 RTP消息
到这里，推流端就开始源源不断的发送RTP消息，RTSP服务器只需要把RTP消息转发给播放端即可，无需回应推流端消息
4. 播放端
播放端的流程：
4.1 OPTIONS
播放端发送：
OPTIONS rtsp://192.168.1.201:5545/2_1 RTSP/1.0
CSeq: 1
User-Agent: Lavf58.37.100
RTSP服务器回应：播放端的Session，此时由RTSP服务器生成，在播放端连接周期内，保持不变
RTSP/1.0 200 OK
CSeq: 1
Session: YXN_wZ_GR
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD
4.2 DESCRIBE
播放端发送：
DESCRIBE rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf58.12.100
Session: YXN_wZ_GR
还记得3.2中，让保存起来的sdp消息吗，就在此时，发送给播放端。
RTSP服务器回应：
RTSP/1.0 200 OK
Session: YXN_wZ_GR
Content-Length: 296
CSeq: 2
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.1.201
t=0 0
a=tool:libavformat 58.37.100
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z00AKp2oHgCJ+WbgICAoAAADAAgAAAMBlCA=,aO48gA==; profile-level-id=4D002A
a=control:streamid=04.3 SETUP
播放端发送：
SETUP rtsp://192.168.1.201:5545/2_1/streamid=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
CSeq: 3
User-Agent: Lavf58.37.100
Session: YXN_wZ_GR
RTSP服务器回应：
RTSP/1.0 200 OK
CSeq: 3
Session: YXN_wZ_GR
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
4.4 PLAY
播放端发送：
PLAY rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf58.12.100
Session: YXN_wZ_GR
RTSP服务器回应：
RTSP/1.0 200 OK
Session: YXN_wZ_GR
Range: npt=0.000-
CSeq: 4
4.5 RTP消息
接下来，RTSP服务器只需要把3.5中接受到的RTP消息，原封不动原发给播放端即可。
5. 效果图
5.1 服务器
5.2 ffmpeg推流端
5.3 播放端
6. 代码