写在前面
在过于的两个月时间，我成功的完成了人生中的第一次实习 （在径卫视觉）就职与公司平台研发部下属的数据智能事业部前端组，不得不说我很感谢这家公司给了我这次给了我很多收获的机会，到现在我仍然认为这家公司在5G技术逐渐成熟的未来将具有非常大的发展潜力，再次感谢。
这家公司主要的业务是帮助车辆运输公司管理各个在路上跑的车辆，那么将业务剥离到我们部门就是为那些运输公司定制toB的Web平台（ps:本来这段写了很多内容，但是突然想到这些可能是涉及到公司利益，最终还是去繁就简吧）。
问题与解决
一、关于HTTP请求的并发
问题起源
在项目中遇到过一个很吊诡的问题，在制作多路视频时有个需求是需要在播放容器组件中可以同时播放1、4、6、9、10、16个flv格式的直播流视频（播放个数可以用户自己选择这六个选项中的其中一个）。这个直播流内容是车载设备上采集的实时视频。
这个需求本身并不难，无非先在项目里封装个用flv.js处理过的播放器组件，然后再放到播放容器组件里，并且为播放容器组件写个不同播放个数的对应样式，最后处理下样式和逻辑细节。Bingo~ 需求解决!，我内心想着：“就这简单需求还想耽误老子搬砖？”
一脸狂妄的打开浏览器开始逐个调试。同时播放1、4、6个直播流视频都顺利通过了，内心狂喜。
接下来继续测试同时播放9个...个，我傻眼了，居然只有前六个播放器可以正常工作，后三个播放器等了很长时间一直是loading，参看network控制台发现后三个请求一直是pedding。
问题究竟出在哪里？
问题定位
在反复测试后，确认后三个直播流是没有任何问题的，问题出在只要同时有超过6个视频拉流请求，六个后面的视频拉流请求都将会被挂起。向后端的同时请求帮助，服务端也没有对并发请求数量做限制相关的操作。
那只能把视线转移回前端了，在观察network控制台，突然想到会不会是浏览器会对并发请求做出限制，顺着个这个思路，在搜索引擎中找到了答案。
对于Chrome来说，默认的浏览器对“同源”HTTP并发请求数限制最大为六个，而多路视频中的视频流URL都是“同源” 的正好符合了被限制的条件。
一些主流浏览器对HTTP 1.1和HTTP 1.0的最大并发连接数目，参考如下表格：
浏览器 HTTP / 1.1 HTTP / 1.0 IE 11 6 6 IE 10 6 6 IE 9 10 10 IE 8 6 6 火狐 6 6 Safari 3,4 4 4 Chrome 4+ 6 6
思路考量
既然知道了是浏览器造成的并发限制造成的问题了，那么如何突破这个限制呢？
第一种办法是通过修改Chrome配置参数，然而这不符合我们的需求（总不能要求所有用户都重新配置自己的浏览器😂），只能接着想其他的办法。
再次回到问题上来，浏览器的确会对”同源“的HTTP请求进行限制，但是对于非”同源“的HTTP请求浏览器似乎就没有并发个数限制。
解决方案
利用浏览器不会对非”同源“的HTTP请求进行并发限制的条件，而将同源转为非同源（修改端口号）似乎是比较合适的。（原有的直播流请求的端口号为 60010）
前端部分需要将直播流请求URL的 端口号需要进行处理，默认情况下的视频请求地址 使用的端口为原来的60010，一旦超过6个，超过的部分使用 60011；而一旦超过12个，则超过部分端口使用60012，依次类推。
并且需要增加一个Nginx服务，将请求端口号为 60010：60020（根据实际情况来定）都映射到 服务端的60010端口。
二、关于Node.js的Stream
问题起源
前端项目中有个一需求，项目中有一个Flash实现的RTMP语音推流的模块，而现在Flash是已经快被放弃了，那么有没有其他的解决方案。实现这个需求。
未完待续
