RTSP/RTMP/HTTP/ QUIC/UDT/SRT

一、RTSP、RTMP、HTTP协议

这三个协议都属于互联网 TCP/IP 五层体系结构中应用层的协议。理论上这三种都可以用来做视频直播或点播。但通常来说，直播一般用 RTSP、RTMP。而点播用 HTTP。下面分别介绍下三者的特点。

1、RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议。

RTSP是TCP/IP协议体系中的一个应用层协议，广泛使用的直播/点播流媒体协议，是一个基于文本的多媒体播放控制协议，属于应用层。RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定，对应的协议是RFC2326。

https://blog.csdn.net/deliapu/article/details/79199023

http://www.cnblogs.com/haibindev/p/3434922.html

（1）RTSP是流媒体协议。

（2）RTSP协议是共有协议，并有专门机构做维护。.

（3）RTSP协议一般传输的是 ts、mp4 格式的流。

（4）RTSP传输一般需要 2-3 个通道，命令和数据通道分离。

 （5）RTSP协议直播源:

           珠海过澳门大厅摄像头监控：rtsp://218.204.223.237:554/live/1/66251FC11353191F/e7ooqwcfbqjoo80j.sdp
           大熊兔（点播）：rtsp://184.72.239.149/vod/mp4://BigBuckBunny_175k.mov
 

2、RTMP协议(实时消息传输协议)

最初是由Macromedia为通过互联网在Flash播放器与一个服务器之间传输流媒体音频、视频和数据而开发的协议。随着视频直播领域的兴起，也成为业内广泛使用的协议。

RTMP是基于TCP的协议，存在着累积延迟和加密方面的问题。而伴随着互联网视频低延时，高质量的要求逐渐提升，相对而言，以UDP为核心的流媒体视频方式成为新的选择，包括SRT，QUIC等。

TCP和UDP是用于通过Internet发送数据位（称为数据包）的协议，但它们以不同的方式工作。 

TCP（传输控制协议）常用于日常互联网应用，以保证通过发送方和接收方之间的握手机制来传送分组。如果未收到数据包，则重新发送它们。虽然保证了数据包的真实传输，但速度非常慢，并且不会在波动的网络上进行优化。RTMP和其他基于HTTP流的协议（包括MPEG-DASH和HLS）依靠TCP / IP进行握手并替换传输中丢失的数据包。这意味着潜在的延迟问题对高性能视频流无效。

另一方面，UDP没有握手机制。它基本上发送数据包并希望最好。但就延迟而言，大大减少，实际上成为视频流的理想解决方案。

（1）RTMP是流媒体协议。

（2）RTMP协议是 Adobe 的私有协议，未完全公开。

（3）RTMP协议一般传输的是 flv，f4v 格式流。

（4）RTMP一般在 TCP 1个通道上传输命令和数据。

（5）RTMP协议直播源:

          香港卫视：rtmp://live.hkstv.hk.lxdns.com/live/hks

 

3、HTTP协议，HTTP(HyperText Transfer Protocol)即超文本传输协议。

现在基本上所有web项目都遵从HTTP协议(协议就是一种人为的规范)。

https://blog.csdn.net/tklwj/article/details/85342195

https://blog.csdn.net/tklwj/article/details/85340862

（1）HTTP不是是流媒体协议。

（2）HTTP协议是共有协议，并有专门机构做维护。 

（3）HTTP协议没有特定的传输流。 

（4）HTTP传输一般需要 2-3 个通道，命令和数据通道分离。

（5）HTTP协议直播源：

          香港卫视：http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8
          CCTV1高清：http://ivi.bupt.edu.cn/hls/cctv1hd.m3u8
          CCTV3高清：http://ivi.bupt.edu.cn/hls/cctv3hd.m3u8
          CCTV5高清：http://ivi.bupt.edu.cn/hls/cctv5hd.m3u8
          CCTV5+高清：http://ivi.bupt.edu.cn/hls/cctv5phd.m3u8
          CCTV6高清：http://ivi.bupt.edu.cn/hls/cctv6hd.m3u8
          苹果提供的测试源（点播）：http://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/gear2/prog_index.m3u8

（播放软件推荐：VLC）

二、谷歌推的 QUIC 方案(用于替代HTTP2.0)

QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。QUIC融合了包括TCP，TLS，HTTP/2等协议的特性，但基于UDP传输。

QUIC的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC只需要1RTT（Round-Trip Time）的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。

因为QUIC基于UDP，运行在用户域而不是系统内核，使得QUIC协议可以快速的更新和部署，从而很好地解决了TCP协议部署及更新的困难。

QUIC公共包头结构如下:
1字节公共Flags
8字节连接ID
4字节QUIC版本号
32字节多样化随机数(Nonce)
1至6字节可变长度的Packet编号(Packet Number)
     0        1        2        3        4            8
+--------+--------+--------+--------+--------+---    ---+
| Public |    Connection ID (64)    ...                 | ->
|Flags(8)|      (optional)                              |
+--------+--------+--------+--------+--------+---    ---+
 
     9       10       11        12   
+--------+--------+--------+--------+
|      QUIC Version (32)            | ->
|         (optional)                |                           
+--------+--------+--------+--------+
 
    13       14       15        16      17       18       19       20
+--------+--------+--------+--------+--------+--------+--------+--------+
|                        Diversification Nonce                          | ->
|                              (optional)                               |
+--------+--------+--------+--------+--------+--------+--------+--------+
 
    21       22       23        24      25       26       27       28
+--------+--------+--------+--------+--------+--------+--------+--------+
|                   Diversification Nonce Continued                     | ->
|                              (optional)                               |
+--------+--------+--------+--------+--------+--------+--------+--------+
 
    29       30       31        32      33       34       35       36
+--------+--------+--------+--------+--------+--------+--------+--------+
|                   Diversification Nonce Continued                     | ->
|                              (optional)                               |
+--------+--------+--------+--------+--------+--------+--------+--------+
 
    37       38       39        40      41       42       43       44
+--------+--------+--------+--------+--------+--------+--------+--------+
|                   Diversification Nonce Continued                     | ->
|                              (optional)                               |
+--------+--------+--------+--------+--------+--------+--------+--------+
 
    45      46       47        48       49       50
+--------+--------+--------+--------+--------+--------+
|           Packet Number (8, 16, 32, or 48)          |
|                  (variable length)                  |
+--------+--------+--------+--------+--------+--------+
 
参考资料https://www.chromium.org/quic
原始表格来自谷歌文档
https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit
 (需要科学上网)
中文译者：hanpfei
中文链接：https://www.jianshu.com/p/b73912342ab8

QUIC (Quick UDP Internet Connections)
维基百科词条 https://en.wikipedia.org/wiki/QUIC

参考hanpfei的博客, 博客链接如下
https://www.wolfcstech.com/tags/QUIC/
https://hanpfei.github.io/tags/QUIC/

学术解决方案 UDT 和商业解决方案 SRT

三、UDT(UDP-based Data Transfer)是一款开源工具包, 基于 UDP 协议实现可靠数据传输的 API 中间件.

https://en.wikipedia.org/wiki/UDP-based_Data_Transfer_Protocol
http://udt.sourceforge.net
UDT是什么？

参考WolfcsTech的博客1 https://www.jianshu.com/p/974d6c5590f6
https://www.wolfcstech.com/categories/网络协议/page/4/

参考CSDN开发者博客 http://blog.csdn.net/asdfghjkl1993/article/details/57417074

UDT是基于UDP的数据传输协议。UDT是开源软件，主要目的是针对“TCP在高带宽长距离网络上的传输性能差”的问题，尽可能全面支持UDP网络上的海量数据传输。
UDT是基于UDP的一种应用层协议。

四、SRT (Secure Reliable Transport)是一款商业级别的开源工具包, 由 Haivision Systems 公司开源发布. 它在 UDT 的基础上进行了一些扩展和定制, 具备网络传输丢包检测/延迟控制/视频加密功能, 可用于商业化的 P2P 视频流传输.

SRT使用UDP协议，旨在利用有损网络来确保可靠性。它通过使用“高性能”发送器和接收器模块来实现这一点 - 该模块不会通过握手确认来阻塞网络。这允许它扩展并最大化可用带宽。SRT保证发送的分组节奏（压缩视频信号）与解码器接收的分组节奏相同。

SRT增加了专为高效安全的视频流而设计的其他功能：

128/256 AES加密，通过公共网络在链路级提供安全性

内容不可知，并在单个SRT流中汇集多个视频，音频和数据（元数据）流，使其能够轻松支持高度复杂的工作流程 

支持发送和接收模式（与仅支持单一模式的RTMP和HTTP相反），对于传递防火墙非常有用

在发送器/接收器模块内，可以检测网络性能，并使用一种自适应比特率和纠正延迟，丢包和抖动

可支持当前和下一代压缩技术，即H264（AVC），H265（HEVC），AV1，VP9

SRT是开源的，免版税的，可在Github平台上使用

https://www.srtalliance.org/
https://github.com/Haivision/srt
https://github.com/Haivision/srt/blob/master/docs/why-srt-was-created.md

Demo

服务器端样例程序
https://github.com/chadnickbok/srt/blob/966a4dfc8cae29703b040e9a3ff66dc374593587/apps/testcserver.c
客户端样例程序
https://github.com/Haivision/srt/blob/master/apps/testcapi.c
#include <stdio.h>
#include <stdlib.h>
#include <arpa/inet.h>
#include <netinet/in.h> // #define INADDR_LOOPBACK 0x7F000001
 
#include <haisrt/srt.h>
 
int main( int argc, char** argv )
{
    int ss, st;
    struct sockaddr_in sa;
    int yes = 1;
    const char message [] = "This message should be sent to the other side";
 
    sa.sin_port = htons(20000); // 对方端口号
    sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK); // 对方IP地址
 
    srt_startup();
 
    ss = srt_socket(AF_INET, SOCK_DGRAM, 0);
    if(!ss)
    {
        goto CLEANUP;
    }
    srt_setsockflag(ss, SRTO_SENDER, &yes, sizeof yes);
    st = srt_connect(ss, (struct sockaddr*)&sa, sizeof sa);
    st = srt_sendmsg2(ss, message, sizeof message, NULL);
    st = srt_close(ss);
 
CLEANUP:
    srt_cleanup();
EXIT:
    return 0;
}
https://github.com/Haivision/srt/blob/master/srtcore/srt_c_api.cpp

 

来源：https://blog.csdn.net/sunxiaopengsun/article/details/62889726

来源：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/84801374

来源：https://blog.csdn.net/liuqun69/article/details/82457704