背景：

最近有个朋友的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}

// 协议数据的具体内容