寫在前面
在過于的兩個月時間艘策，我成功的完成了人生中的第一次實習 （在徑衛(wèi)視覺）就職與公司平臺研發(fā)部下屬的數(shù)據(jù)智能事業(yè)部前端組浮庐，不得不說我很感謝這家公司給了我這次給了我很多收獲的機會，到現(xiàn)在我仍然認為這家公司在5G技術(shù)逐漸成熟的未來將具有非常大的發(fā)展?jié)摿砘溃俅胃兄x审残。
這家公司主要的業(yè)務(wù)是幫助車輛運輸公司管理各個在路上跑的車輛，那么將業(yè)務(wù)剝離到我們部門就是為那些運輸公司定制toB的Web平臺（ps:本來這段寫了很多內(nèi)容斑举，但是突然想到這些可能是涉及到公司利益搅轿，最終還是去繁就簡吧）。
問題與解決
一富玷、關(guān)于HTTP請求的并發(fā)
問題起源
在項目中遇到過一個很吊詭的問題璧坟，在制作多路視頻時有個需求是需要在播放容器組件中可以同時播放1、4赎懦、6雀鹃、9、10励两、16個flv格式的直播流視頻（播放個數(shù)可以用戶自己選擇這六個選項中的其中一個）黎茎。這個直播流內(nèi)容是車載設(shè)備上采集的實時視頻。
這個需求本身并不難当悔，無非先在項目里封裝個用flv.js處理過的播放器組件傅瞻，然后再放到播放容器組件里踢代，并且為播放容器組件寫個不同播放個數(shù)的對應(yīng)樣式，最后處理下樣式和邏輯細節(jié)嗅骄。Bingo~ 需求解決!胳挎，我內(nèi)心想著：“就這簡單需求還想耽誤老子搬磚？”
一臉狂妄的打開瀏覽器開始逐個調(diào)試溺森。同時播放1慕爬、4、6個直播流視頻都順利通過了屏积，內(nèi)心狂喜医窿。
接下來繼續(xù)測試同時播放9個...個，我傻眼了肾请，居然只有前六個播放器可以正常工作留搔，后三個播放器等了很長時間一直是loading，參看network控制臺發(fā)現(xiàn)后三個請求一直是pedding铛铁。
問題究竟出在哪里隔显？
問題定位
在反復(fù)測試后，確認后三個直播流是沒有任何問題的饵逐，問題出在只要同時有超過6個視頻拉流請求括眠，六個后面的視頻拉流請求都將會被掛起。向后端的同時請求幫助倍权，服務(wù)端也沒有對并發(fā)請求數(shù)量做限制相關(guān)的操作掷豺。
那只能把視線轉(zhuǎn)移回前端了，在觀察network控制臺薄声，突然想到會不會是瀏覽器會對并發(fā)請求做出限制挺据，順著個這個思路搁拙，在搜索引擎中找到了答案。
對于Chrome來說，默認的瀏覽器對“同源”HTTP并發(fā)請求數(shù)限制最大為六個悔据，而多路視頻中的視頻流URL都是“同源” 的正好符合了被限制的條件窿凤。
一些主流瀏覽器對HTTP 1.1和HTTP 1.0的最大并發(fā)連接數(shù)目千贯，參考如下表格：
瀏覽器 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
思路考量
既然知道了是瀏覽器造成的并發(fā)限制造成的問題了孕似，那么如何突破這個限制呢？
第一種辦法是通過修改Chrome配置參數(shù)表谊，然而這不符合我們的需求（總不能要求所有用戶都重新配置自己的瀏覽器??）钞护，只能接著想其他的辦法。
再次回到問題上來爆办，瀏覽器的確會對”同源“的HTTP請求進行限制难咕，但是對于非”同源“的HTTP請求瀏覽器似乎就沒有并發(fā)個數(shù)限制。
解決方案
利用瀏覽器不會對非”同源“的HTTP請求進行并發(fā)限制的條件，而將同源轉(zhuǎn)為非同源（修改端口號）似乎是比較合適的步藕。（原有的直播流請求的端口號為 60010）
前端部分需要將直播流請求URL的 端口號需要進行處理惦界，默認情況下的視頻請求地址 使用的端口為原來的60010挑格，一旦超過6個咙冗，超過的部分使用 60011；而一旦超過12個漂彤，則超過部分端口使用60012雾消，依次類推。
并且需要增加一個Nginx服務(wù)挫望，將請求端口號為 60010：60020（根據(jù)實際情況來定）都映射到 服務(wù)端的60010端口立润。
二、關(guān)于Node.js的Stream
問題起源
前端項目中有個一需求媳板，項目中有一個Flash實現(xiàn)的RTMP語音推流的模塊桑腮，而現(xiàn)在Flash是已經(jīng)快被放棄了，那么有沒有其他的解決方案蛉幸。實現(xiàn)這個需求破讨。
未完待續(xù)
