1、问题分析
我们以一个实际现网的case来引入该问题，3月9日，巴西地区的主播，流id：stream-2990700835946365032
在20:50-21:50这段时间整体的推流帧率非常低，丢帧非常严重，但用户量非常大，有5w 人在线，下行近100G播放带宽
从cdn播放质量维度来看，对应时间段，卡顿率非常高，观看质量非常差。
紧急情况中，采取了断流迫使推流端重新推流，快速恢复了推流的稳定。
如上图所示，在21点47分左右，重新推流后，推流帧率稳定在30帧，卡顿率也恢复到正常水平。
经分析，该主播是在巴西，上行接流也在巴西，服务端存在大量的慢速日志：
其实这种由于单个tcp连接慢速问题，在海外复杂的推流环境中经常发生。海外的链路比较复杂，而且链路非常长，有时刚开始推流质量非常稳定，时间长了，网络出现抖动后，就会出现上述网络变差的情况，导致数据传输不稳定。
欧美等发达国家网络质量好，带宽比较充足，都能满足正常的直播推流。在一些发展中国家，比如中东，东南亚，电信基础设置比较差，网络带宽不足，本地运营商存在各种带宽限制。很容易出现推流一段时间后，出现网络不稳定的情况，断流重推后就能恢复正常。为了避免调度到同一个节点上，通常通过配置host的方式，指定接入节点，来避免调度到同一个节点，来恢复正常推流。
上述的异常情况，一般通过断流重推或切换推流节点的方式，往往能解决大部分的问题。服务器端主动断主播连接风险很高，如果推流端处理不好，还会出现主播推流异常，导致推流失败，很容易引起投诉，因此通常需要人工进行处理。人工处理的缺点很明显，成本高，问题处理不及时，处理问题时间长等。
为了解决上述问题，利用rtmp302特性，制定了一个改进方案。服务器端如果检测到推流有慢速，通过amf控制消息的方式，将新的推流接地址，发送给推流端，推流端结合本地网络情况，来进行综合决策是否要进行断流重推。
本方案的亮点是服务端只提供建议，不做决策，客户端可以结合终端和后台提供的信息，进行综合评估，对比单方面决策，可以大幅提升决策的准确性。
2、RTMP 302重定向具体方案
为了解决推流过程中，网络异常问题，采用了RTMP 302 重定向的方案，具体实现逻辑如下图所示：
步骤一，推流过程中，rtmp server端支持持续弱网检测，支持域名 发布点维度的配置化的弱网检测。
步骤二，检测到该情况发生后，需要向调度系统，根据客户端IP，请求一个合法、高质量的推流接入节点IP，拼接完整的重定向推流地址，通过amf data给到推流客户端。
步骤三，推流客户端识别对应的amf data，
推流终端拿到redirect中的重定向地址后，综合本地信息，判断是否需要断流重推，如果需要，进行使用服务器端提供的地址重新推流，解决慢速问题。
详情请查看具体的RFC文档：
1.https://tools.ietf.org/html/rfc7016#section-3.5.1.6
2、http://www.adobe.com/cn/products/adobe-media-server-professional/features._sl_id-contentfilter_sl_featuredisplaytypes_sl_all.html
AMS说是内置支持：
Server redirection
Automatically provide video players with new or alternate locations if content is missing using built-in redirection in RTMP similar to HTTP 302 redirection.
上述解决方案，在推流过程中，通过RTMP 302的方式获取到服务器慢速信息，根据客户端以及服务器端慢速信息，来进行断流重推，快速恢复直播，提高推流成功率。
对上述方案进行扩展，在开始推流时，利用302进行服务端的负载均衡。服务器端在刚收到客户端数据时，给客户端发送RTMP 302信息，来进行高负载302调度，提高推流的成功率。也可以通过302快速提出异常的推流接入点。
3、结论
综上所述：
1、在推流过程中，给客户端发送RTMP 302控制消息，客户端使用服务器提供的重定向地址，进行断流重推，可以快速恢复推流异常，提升上行推流质量；
2、在推流开始时，服务器端可以综合后台机器负载以及带宽资源情况，进行推流的负载均衡调度，给客户端提供优质的接入点，提升推流质量，改善平台接入的可用性。
3、兼容性好，能兼容新老客户端，是否检测RTMP 302 amf信息，完全由客户端控制。客户端可以根据自身情况，进行选择性使用。
4、决策成功率更高，相比传统的客户端断流重推策略，本方案可以综合客户端和服务端的信息，来制定更优的断流重试策略。
