遇到一个关于视频业务很蛋疼的反向代理问题

[daimaosix]

遇到一个关于视频业务很蛋疼的问题，业务需要调整接口地址，分为地址 a 和地址 b

地址 a 为：a.com

地址 b 为：b.com

现在 b.com 没办法直接用，因为后端把地址 a.com 写死了卧槽！！！现在想的办法是通过 a.com 反向代理到 b.com ，但是 b.com 的服务器带宽比较充足，a.com 带宽就比较小。

如果通过 a.com 反向代理到 b.com ，那是不是就会受限于 a.com 的服务器带宽呢？

如果受限于 a.com 的带宽，不通过 a.com 反向代理，那么是不是可以用重定向的方式呢？

或者还有其他更友好的方式实现呢？谢谢各位 V 友。

[also24]

是否支持重定向，要在客户端上测试一下做确认（大部分情况下都可以）。

要注意使用 301 302 可能会导致 POST 请求变为 GET 请求，如果这里存在问题，可以测试一下 307 是否正常。


另：不能直接将 a.com 指到 b.com 去嘛？

[Tianao]

直接把 a.com 解析到 b.com ，b.com 的服务器监听对 a.com 的请求。

[also24]

少回答了一个问题，如果直接反代，那流量确实会受限于 a_com 的带宽。


另外，既然是视频业务，不清楚你们 a_com b_com 上具体放的是什么？
假如是 HLS 流的话，那么 a_com 先返回的是 m3u8 文件？
假如是这种情况，可以考虑篡改相应的文件，将文件內 ts 的地址都修改到 b_com，这样也是可以的。

[daimaosix]

@also24
@Tianao
做不了哥，因为 a.com 要用 https，直接 CNAME 不能这样做吧？ b.com 上做不了 a.com 的 https 配置

[daimaosix]

@also24 刚才确实是想到了，m3u8 的文件可以走 a 。com，ts 走 b 。com，因为文件量实在太大了，不知道能不能去实现修改，多谢老哥的建议。

[vanillaxxx]

@daimaosix b.com 用 http 然后 a.com CNAME 到 b.com 不知道了行不？

[daimaosix]

@parorisim 不行老哥，a,com 必须用 https，b,com 用啥无所谓，主要是 a,com

[also24]

@daimaosix #4
我们先来说直接 https 的方案，其实并不需要 b_com 上有 a_com 的证书。

你可以在 b_com 上配置 SNI 反代，具体可以参考这个模块的使用：
http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

这样实现之后的效果的：
只要 b_com 发现流量是要访问 a_com 的，就直接转发到 a_com （没有解密过程）。
如果 b_com 和 a_com 在同一个内网，这样操作还是有一点点意义的。

[vanillaxxx]

一楼说的重定向我们之前用 307 做过，完全没问题，这个应该是最简便快捷的了吧

[daimaosix]

@parorisim
@also24
@Tianao
哭了，307 太好用了！！！谢谢各位大佬

[vanillaxxx]

@daimaosix #10 恭喜恭喜恭喜你呀哈哈哈

[also24]

@daimaosix #5
然后我们说 m3u8 文件修改的方案。

首先，最简单的方法肯定是直接改文件本身，可以写个小程序去批量修改。

其次，就是直接使用 nginx 的 ngx_http_substitutions_filter_module 模块动态修改。
https://www.nginx.com/resources/wiki/modules/substitutions/
https://github.com/yaoweibin/ngx_http_substitutions_filter_module

这个模块的功能也很简单，就是查找替换，比起官方的 ngx_http_sub_module 多支持了正则。
需要注意的是，这是个第三方模块，且近期似乎没有太多维护，要做好测试。


不知道你们的请求分布情况是怎么样的，按道理来说，对于大量请求的文件，还是尽量直接修改掉会比较好。

[also24]

@daimaosix #10
hhh 307 能用就最好，有些客户端对 307 的支持不是很好。

[daimaosix]

@also24 我们主要是 APP，既然播放器 OK 的话，那其他问题应该就不大吧？

[daimaosix]

@also24 刚才试了一下，H5 的播放器不支持，不过我们也没有网页，基本都是通过 APP 用的，测试了一下 APP 没发现什么异常。

[also24]

@daimaosix #14
比较新一点的客户端应该都还不错，大部分情况下应该不用操心。
没找到请求库相关的，只找到一份浏览器的：
http://test.greenbytes.de/tech/tc/httpredirects/


如果很担心的话，可以在重定向的时候加一点标记，然后两边统计一下请求数量。

[also24]

这里举一个不支持 307 的例子：
https://github.com/square/okhttp/blob/master/CHANGELOG.md#version-460

相应的代码在这里：
https://github.com/square/okhttp/pull/5990

这个的问题，在 2014 年就被引入，2016 年就被提出，却直到今年才被修正：
https://github.com/square/okhttp/pull/944#issuecomment-248449263


这个库，就是大名鼎鼎的 okhttp，做 Android 开发的应该基本都用过它 ~

[also24]

修正一下措辞，okhttp 不是不支持 307，是对 307 的支持不标准。