大家好，又见面了，我是你们的朋友全栈君。
背景：
最近有个朋友的APP需要在国外搭建一个直播服务器，因为他们的主播在韩国(主播主要是记者)，而观众主要在国内，叫我帮忙给他们开发一个直播服务器。
目前开源的直播服务程序有：SRS，Nginx-rtmp；如果是做开发的同学应该有所了解，SRS是基于C 写的，Nginx-rtmp模块是Ngxin的第三方C模块。一开始我是直接部署SRS/Ngxin-rtmp 到我的韩国的服务器，结果直播rtmp或者hls都不理想，经常卡顿，究其原因，还是因为这些协议都是基于TCP,一旦遇到丢包啥的，效果就非常差。
这里，我主要介绍下外海直播常用的场景，以及基于KCP协议的国外直播服务器。
一、海外直播服务器的常用场景：
1)、主播和观众都在国内
适用于客户和观众都在国内，但需要把直播服务器架在海外的客户。直播服务器需要支持传统协议：RTMP、HLS、HTTP-FLV；应用场景如下图所示：
2)、主播在国外、观众在国内
适用主播在国外，观众在国内，但需要把直播服务器架在海外的客户。
三、基于KCP协议的海外直播服务器
为了给朋友搭建一个效果较好的海外直播服务器，我特意学习了一遍KCP协议，帮忙写了APP端的SDK。最终效果还是很棒。我介绍下我开发的流媒体服务的功能：
采用KCP协议作为传输层，具有超强的弱网传输能力和超低的延迟
支持NMS服务之间通过kmp协议进行中继转发
支持推流与播放
SDK版Andorid、IOS全系支持
空一点我拍个视频出来给大家看下效果。大家如果想要讨论技术底层的话可以加WX：stefan1240。貌似只有KCP协议才能达到一个比较好的效果，别的都不太行。
附录：KCP协议
type segment struct {
conv uint32
// 发送端与接收端通信时的匹配数字，发送端发送的数据包中此值与接收端的conv值匹配一致时，接收端才会接受此包
cmd uint8
// 改数据包的协议号，协议号有以下枚举：
// IKCP_CMD_PUSH = 81 // cmd: push data，数据包
// IKCP_CMD_ACK = 82 // cmd: ack，确认包，告诉对方收到数据包
// IKCP_CMD_WASK = 83 // cmd: window probe (ask)，询问远端滑动窗口的大小
// IKCP_CMD_WINS = 84 // cmd: window size (tell)，告知远端滑动窗口的大小
frg uint8
// 分帧号，由于udp传输有数据包大小的限制，因此，应用层一个数据包可能被分为多个udp包
制自己接下来发送数据的大小wnd uint16
// 滑动窗口的大小
// 当Segment做为发送数据时，此wnd为本机滑动窗口大小，用于告诉远端自己窗口剩余多少
// 当Segment做为接收到数据时，此wnd为远端滑动窗口大小，本机知道了远端窗口剩余多少后，可以控
ts uint32
// timestamp , 当前Segment发送时的时间戳
sn uint32
// Sequence Number,Segment数据包的编号
una uint32
// una即unacknowledged,未确认数据包的编号，表示此编号前的所有包都已收到了。
rto uint32
// rto即Retransmission TimeOut，即超时重传时间，在发送出去时根据之前的网络情况进行设置
xmit uint32
// 基本类似于Segment发送的次数，每发送一次会自加一。用于统计该Segment被重传了几次，用于参考，进行调节
resendts uint32
// 即resend timestamp , 指定重发的时间戳，当当前时间超过这个时间时，则再重发一次这个包。
fastack uint32
// 用于以数据驱动的快速重传机制；
// len uint32 c 版本有数据包的数据长度，go版本无此字段
data []byte}
// 协议数据的具体内容
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/144848.html原文链接：https://javaforall.cn
