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