不借助第三方應(yīng)用，快速且安全地在瀏覽器中傳輸視頻——這有可能實(shí)現(xiàn)嗎？根據(jù)你的需求，有不止一種方式能夠?qū)ebRTC添加到你的站點(diǎn)之中。
WebRTC（Web實(shí)時(shí)通信，Web Real-Time Communication）是一項(xiàng)開(kāi)源技術(shù)，用來(lái)在Web瀏覽器中實(shí)現(xiàn)實(shí)時(shí)直接的多媒體通信功能。它能夠在兩個(gè)或更多的人之間建立端到端的連接，這對(duì)于傳輸媒體（音頻和視頻流）來(lái)說(shuō)是非常合適的。這項(xiàng)技術(shù)已經(jīng)在如下的瀏覽器中得到了支持：Google Chrome、Mozilla Firefox和Opera。對(duì)于這些瀏覽器，我們不需要額外的插件。只需要打開(kāi)一個(gè)Web瀏覽器頁(yè)面并開(kāi)啟一個(gè)會(huì)話(huà)就可以了。對(duì)于使用Safari和IE的用戶(hù)來(lái)說(shuō)，沒(méi)有原生的支持，但是我們可以添加特定的插件。
理念是非常簡(jiǎn)單的。首先，瀏覽器發(fā)送一個(gè)信號(hào)到WebRTC服務(wù)器，這個(gè)服務(wù)器是用戶(hù)希望初始化調(diào)用的。在獲取到服務(wù)器的連接之后，用戶(hù)將其發(fā)送給他的同伴。瀏覽器彈出的窗口會(huì)提示用戶(hù)訪問(wèn)Web攝像頭和麥克風(fēng)的權(quán)限。如果用戶(hù)使用HTTPS協(xié)議的話(huà)，瀏覽器能夠記住你所選擇的選項(xiàng)（是否授予權(quán)限）。如果你使用HTTP協(xié)議的話(huà)，在每次嘗試連接的時(shí)候，瀏覽器都會(huì)向你申請(qǐng)權(quán)限。
如果你是用戶(hù)的話(huà)，這聽(tīng)起來(lái)非常簡(jiǎn)單。但是，作為開(kāi)發(fā)人員，又該如何呢？在Web站點(diǎn)上如何實(shí)現(xiàn)它呢？如果你所需要的不僅僅是視頻聊天，還要使用Web攝像頭進(jìn)行記錄，并將錄制的結(jié)果發(fā)送到Amazon S3存儲(chǔ)中，這樣第三方就有可能瀏覽這個(gè)錄制結(jié)果，那又該怎樣實(shí)現(xiàn)呢？對(duì)于一些場(chǎng)景來(lái)說(shuō)，這種方式是非常棒的，比如收集某些商品和服務(wù)的視頻回訪，當(dāng)某位討論成員不在場(chǎng)的時(shí)候，為其記錄視頻信息，為工作的求職者進(jìn)行面試，Web支持等等。
我們都知道，視頻格式有很多種。它們中的大多數(shù)在某些方面都具有一定的優(yōu)勢(shì)。例如，我可以選擇Flash格式（FLV、F4V）來(lái)記錄視頻，但是這項(xiàng)技術(shù)在Web中正在逐漸失勢(shì)。多個(gè)瀏覽器都已經(jīng)宣布將來(lái)不再支持Flash，這也是我選擇使用WebRTC的另外一個(gè)原因。Flash使用H。264視頻編碼解碼器，而WebRTC使用VP8.WebRTC標(biāo)準(zhǔn)中規(guī)定要支持H。264，但是它還沒(méi)有得到廣泛地應(yīng)用。VP8是免費(fèi)的（H。264并非如此），視頻文件的質(zhì)量和大小幾乎是相同的。
我開(kāi)始選擇使用的是免費(fèi)的Java Script庫(kù)，名為Media Stream Recorder，它用于跨瀏覽器的音頻/視頻記錄。這個(gè)庫(kù)通常會(huì)與WebRTC實(shí)現(xiàn)相關(guān)。不過(guò)令人遺憾的是，在這個(gè)過(guò)程中，我遇到了很多技術(shù)難題。例如，每次記錄完成時(shí)，瀏覽器會(huì)停止響應(yīng)，并且會(huì)很多的延遲（lag）。
然后，我嘗試使用WebRTC Experiments庫(kù)。它使用了相同的技術(shù)，但是實(shí)現(xiàn)不同。記錄完成時(shí)，它的延遲時(shí)間和瀏覽器行為都是正常的。
使用這個(gè)庫(kù)的結(jié)論如下所示：
優(yōu)點(diǎn)：
- 不需要運(yùn)行服務(wù)器，所有的負(fù)載都會(huì)落到瀏覽器端。
- 錄制過(guò)程的控制非常容易：只需點(diǎn)擊pause鍵，就能開(kāi)始新的錄制和停止錄制。
- 沒(méi)有延遲，因?yàn)樗械氖虑槎际窃贙urento中完成的（我稍后將會(huì)對(duì)其進(jìn)行介紹）。
不足：
- Google Chrome會(huì)分別記錄視頻和音頻，這樣最終會(huì)有兩個(gè)不同的文件：音頻文件以及沒(méi)有音頻的視頻文件。
- 如果錄制時(shí)間超過(guò)五分鐘的話(huà)，瀏覽器會(huì)停止響應(yīng)，用戶(hù)的命令會(huì)被忽略掉。
- 在錄制停止時(shí)，將會(huì)耗費(fèi)幾秒鐘的時(shí)間來(lái)解碼視頻和接收數(shù)據(jù)。
- 它將會(huì)耗費(fèi)一些時(shí)間將視頻發(fā)送到倉(cāng)庫(kù)中。如果在文件傳輸?shù)倪^(guò)程中，用戶(hù)關(guān)閉了瀏覽器的tab標(biāo)簽，數(shù)據(jù)將會(huì)出現(xiàn)丟失。
我需要一個(gè)服務(wù)器來(lái)接收來(lái)自客戶(hù)端的視頻流并對(duì)其進(jìn)行記錄。對(duì)我來(lái)講，一個(gè)較為合適的方案是使用Kurento Media Server，我在Amazon EC2上使用STUN/TURN服務(wù)器進(jìn)行了搭建。我使用Kurento庫(kù)實(shí)現(xiàn)了前端（不需要使用中間服務(wù)器）。Kurento（英語(yǔ)中“stream”這個(gè)詞的世界語(yǔ)名稱(chēng)）是一個(gè)開(kāi)源的框架，它提供了一個(gè)媒體服務(wù)器，這個(gè)服務(wù)器基于標(biāo)準(zhǔn)提供了任意媒體的處理功能。
最終，對(duì)于我來(lái)講，無(wú)法接受這樣的結(jié)果，但是如果上述的不足對(duì)你來(lái)講不那么重要的話(huà)，那你可以使用這種方法。因?yàn)槲业南敕ㄊ潜M可能實(shí)現(xiàn)最優(yōu)的結(jié)果，因此我又開(kāi)始尋找其他的解決方案。
有時(shí)候，我們所需要的記錄文件并不僅僅只有一個(gè)。如果我們基于某些原因，需要將流劃分為多個(gè)部分，例如應(yīng)用只能接收三分鐘或五分鐘的視頻記錄（以避免出現(xiàn)過(guò)載的情況），那該怎么做呢？我思考過(guò)如何將一個(gè)小時(shí)的記錄劃分為12個(gè)五分鐘的記錄，每一個(gè)都保存為一個(gè)單獨(dú)的文件。我嘗試的做法是每次都停止錄制，斷開(kāi)與服務(wù)器的連接并重新開(kāi)始錄制（再次連接到服務(wù)器）。使用Kurento無(wú)法正常運(yùn)行，這是因?yàn)槲颐看沃匦逻B接服務(wù)器的時(shí)候，會(huì)丟掉幾秒鐘的記錄（連接不是瞬時(shí)完成的）。
于是，我決定采用一個(gè)連接，使用Web攝像頭進(jìn)行無(wú)停止的錄制。稍后，我要將記錄進(jìn)行分割并將其發(fā)送到Amazon S3上，這個(gè)過(guò)程中，我決定使用node-fluent-ffmpeg庫(kù)。為了完成該功能，我搭建了一個(gè)新的服務(wù)器，但是這里還有一個(gè)難題。Kurento會(huì)將文件保存為webm格式，在Google Chrome上無(wú)法正確地播放（Mozilla Firefox不會(huì)有這個(gè)問(wèn)題）：視頻流播放地比音頻流更快。修正這個(gè)問(wèn)題的最佳方式是講文件重編碼為mp4，這樣就能解決這個(gè)問(wèn)題了。
最終，所有的事情都能正常運(yùn)行了。我使用WebRTC技術(shù)構(gòu)建了完整的流程，在當(dāng)前的任務(wù)下解決了所有的問(wèn)題。當(dāng)然，實(shí)現(xiàn)并不是100%完美的，我們同時(shí)可以看到它的優(yōu)勢(shì)和不足：
優(yōu)點(diǎn)：
- 視頻和音頻位于同一個(gè)文件中，沒(méi)有將其分為兩個(gè)單獨(dú)的文件。
- 視頻是以實(shí)時(shí)的模式錄制的，不會(huì)丟失視頻文件。如果在客戶(hù)端一側(cè)實(shí)現(xiàn)錄制的話(huà)，用戶(hù)在退出我們的服務(wù)之前，必須要等待文件上傳到倉(cāng)庫(kù)之中。
不足：
- 連接到Kurento Media Server需要耗費(fèi)一些時(shí)間。
- 網(wǎng)絡(luò)傳輸�？蛻�(hù)端的帶寬要足夠快。
- 實(shí)現(xiàn)起來(lái)比較困難，這不僅涉及到資源還涉及到時(shí)間。我必須要搭建Kurento Media Server、coturn以及Node.js，其中Node.js會(huì)用來(lái)將視頻轉(zhuǎn)換為另外一種格式，將其拆分為多個(gè)部分，并將其發(fā)送到S3中。
WebRTC技術(shù)是很新的，所以在安全性上會(huì)有一些問(wèn)題。它所使用的加密構(gòu)建在TLS協(xié)議之上。我們會(huì)發(fā)現(xiàn)安全漏洞，但是這可能并不是WebRTC技術(shù)的問(wèn)題，而是信號(hào)傳輸所使用的瀏覽器本身的問(wèn)題。WebRTC的主要問(wèn)題在于它很容易和快速地暴露真實(shí)的用戶(hù)IP地址，它并沒(méi)有使用代理、VPN、Tor或流行的插件如Ghostery進(jìn)行保護(hù)。為了使用WebRTC組織視頻或音頻會(huì)話(huà)，兩臺(tái)電腦必須發(fā)送IP地址給對(duì)方（不僅包括公網(wǎng)IP，還包括私有IP）。我們可以在Java Script中使用簡(jiǎn)單的腳本來(lái)請(qǐng)求地址，在個(gè)人數(shù)據(jù)保護(hù)方面，這是一個(gè)巨大的問(wèn)題，這個(gè)問(wèn)題只能通過(guò)禁用WebRTC來(lái)解決。
這里有很大的提升空間，首先就是瀏覽器的良好支持。
你也可以看到，這里并沒(méi)有完美的答案。這項(xiàng)技術(shù)有好處也有壞處，有優(yōu)勢(shì)也有不足，但是WebRTC正在迅速地流行起來(lái)。使用WebRTC的統(tǒng)計(jì)數(shù)據(jù)是令人興奮的。有47%的商業(yè)組織計(jì)劃在未來(lái)的12個(gè)月中使用該技術(shù)，或者已經(jīng)使用了該技術(shù)。90%的受訪者相信WebRTC有潛力提升客服中心的服務(wù)水平。超過(guò)720家公司正在以某種實(shí)行使用WebRTC。
我們可以預(yù)期WebRTC將會(huì)影響通信市場(chǎng)，有多種方式來(lái)使用該項(xiàng)技術(shù)。例如，假設(shè)在線商店會(huì)有一個(gè)“客戶(hù)支持”的鏈接，我們可以點(diǎn)擊這個(gè)鏈接并與客服進(jìn)行視頻聊天、詢(xún)問(wèn)問(wèn)題并得到建議。這都是在瀏覽器中實(shí)現(xiàn)的，不需要額外的應(yīng)用或插件。這能夠在很大程度上提升客戶(hù)服務(wù)的質(zhì)量，因而有利于增加利潤(rùn)。這意味著致力于成為市場(chǎng)領(lǐng)導(dǎo)者的公司會(huì)迅速使用這項(xiàng)技術(shù)，其余的公司將會(huì)隨之跟進(jìn)。
現(xiàn)實(shí)中使用傳統(tǒng)電話(huà)呼叫的很多領(lǐng)域正在被快速的鏈接點(diǎn)擊或Web通信器的消息所取代。相對(duì)于打電話(huà)，通過(guò)在站點(diǎn)上點(diǎn)擊鏈接，會(huì)更加容易地打出租車(chē)、訂餐等等。這是可以使用WebRTC技術(shù)的一個(gè)領(lǐng)域。它起初與通用的視頻聊天（如Skype）和電話(huà)呼叫進(jìn)行競(jìng)爭(zhēng)。誰(shuí)知道呢，也許在未來(lái)的幾年內(nèi)，WebRTC將會(huì)改變我們的日常習(xí)慣。
關(guān)于作者
Nikolai Bezruk是Qualium Systems的Java Script開(kāi)發(fā)人員，這家公司致力于為創(chuàng)業(yè)公司和數(shù)字代理公司創(chuàng)建Web和移動(dòng)應(yīng)用。Nikolai擔(dān)任團(tuán)隊(duì)領(lǐng)導(dǎo)和軟件架構(gòu)師，進(jìn)行全棧的Web編程。他同時(shí)還負(fù)責(zé)培訓(xùn)新員工。
