視訊交流是Vimbox平台上師生交流的主要方式。 我們很早之前就放棄了 Skype，嘗試了幾種第三方解決方案，最後選擇了 WebRTC - Janus-網關組合。 有一段時間，我們對一切都感到滿意，但有些負面方面仍然不斷出現。 結果，創建了一個單獨的視訊方向。
我請新方向負責人 Kirill Rogovoy 談談 Skyeng 視訊通訊的演變、發現的問題、解決方案以及我們最終使用的拐杖。 我們希望本文對那些透過網路應用程式自行創建影片的公司有所幫助。
歷史上的位
2017 年夏天，Skyeng 開發負責人 Sergey Safonov 在 Backend Conf 上發表演講，講述了我們如何「放棄 Skype 並實施 WebRTC」的故事。 有興趣的可以觀看演講錄音 （~45 分鐘），在這裡我將簡要概述其本質。
對天成學校來說，視訊交流一直是師生交流的優先方式。 起初，使用了 Skype，但由於多種原因，它絕對不能令人滿意，主要是由於缺乏日誌以及無法直接整合到 Web 應用程式中。 因此，我們進行了各種實驗。
其實我們對於視訊通訊的需求大概是這樣的：
- 穩定;
— 每堂課價格低廉；
——記錄課程；
— 追蹤誰說了多少話（對我們來說重要的是學生在課堂上說的比老師多）；
——線性縮放；
- 能夠同時使用 UDP 和 TCP。
第一個嘗試是在 2013 年實施 Tokbox。 一切都很好，但結果卻非常昂貴——每節課 113 盧布——並且吞噬了利潤。
然後在 2015 年，Voximplant 被整合。 這是我們需要追蹤誰說了多少話的功能，同時解決方案要便宜得多：如果只錄製音頻，每節課花費 20 盧布。 但是，它只能透過 UDP 工作，無法切換到 TCP。 然而，大約 40% 的學生最終使用了它。
一年後，我們開始遇到有特定要求的企業客戶。 例如，一切都應該透過瀏覽器進行；公司只開放http和https； 即沒有 Skype 或 UDP。 企業客戶=錢，於是他們又回到了Tokbox，但價格問題並沒有消失。
解決方案 - WebRTC 和 Janus
決定使用 。 它負責建立連接、編碼和解碼流、同步軌道和品質控制以及處理網路故障。 就我們而言，我們必須確保從攝影機和麥克風讀取串流、繪製視訊、管理連線、建立 WebRTC 連線並向其傳輸串流，以及在客戶端之間傳輸訊號訊息以建立連線（WebRTC 本身僅描述了資料格式，但不是其機制傳輸）。 如果用戶端位於 NAT 之後，WebRTC 將連接 STUN 伺服器；如果這沒有幫助，則連接 TURN 伺服器。
常規的 p2p 連結對我們來說還不夠，因為我們想記錄教訓，以便在出現投訴時進行進一步分析。 因此我們透過中繼發送WebRTC流 。 結果，客戶端不知道彼此的位址，只能看到 Janus 伺服器位址； 它還執行信號伺服器的功能。 Janus具有我們需要的許多功能：如果客戶端封鎖了UDP，則自動切換到TCP； 可以記錄UDP和TCP串流； 可擴展； 甚至還有一個用於迴聲測試的內建插件。 如有必要，Twilio 的 STUN 和 TURN 伺服器會自動連線。
2017年夏天，我們運行了兩台Janus伺服器，另外還有一台伺服器用於處理錄製的原始音訊和視訊文件，以免佔用主伺服器的處理器。 連接時，Janus 伺服器是按奇偶數（連接數）選擇的。 當時，這已經足夠了，根據我們的感覺，它提供了大約四倍的安全裕度，實施百分比約為80。同時，價格降至每節課約2盧布，再加上開發和支援。
回到視訊通訊的話題
我們不斷監控學生和教師的回饋，以便及時發現並糾正問題。 2018年夏季，通話品質穩居投訴首位。 一方面，這意味著我們已經成功克服了其他缺點。 另一方面，有必要緊急採取一些措施：如果課程被中斷，我們就有失去其價值的風險，有時還包括購買下一個課程的成本，如果入門課程被中斷，我們就有失去潛在客戶的風險共。
那時我們的視訊交流還處於MVP模式。 簡而言之，他們推出了它，它起作用了，他們擴展了一次，他們了解如何做到這一點 - 嗯，太棒了。 如果有效，請不要修復它。 沒有人刻意解決通信品質問題。 到了 XNUMX 月份，很明顯這種情況無法繼續下去，我們啟動了一個單獨的方向來找出 WebRTC 和 Janus 的問題。
在輸入時，該方向收到：MVP 解決方案，沒有指標，沒有目標，沒有改善流程，而 7% 的教師抱怨溝通品質（也沒有關於學生的數據）。
新的方向正在進行中
該命令看起來像這樣：
- 部門負責人，也是主要開發人員。
- QA 幫助測試變更，尋找新的方法來創造不穩定的通訊條件，並從第一線報告問題。
- 分析師不斷尋找技術數據中的各種相關性，改進對使用者回饋的分析，並檢查實驗結果。
- 產品經理幫助確定實驗的整體方向和資源分配。
- 第二個開發人員經常幫忙完成程式設計和相關任務。
首先，我們建立了一個相對可靠的指標來追蹤通訊品質評估的變化（幾天、幾週、幾個月的平均值）。 當時是老師的成績，後來又加上了學生的成績。 然後他們開始對哪裡出了問題提出假設，修正它，並觀察動態變化。 我們追求的是容易實現的目標：例如，我們用 vp8 取代了 vp9 編解碼器，效能得到了提升。 我們嘗試使用 Janus 設定並進行其他實驗 - 在大多數情況下它們沒有產生任何結果。
在第二階段，出現了一個假設：WebRTC是一種點對點解決方案，我們在中間使用伺服器。 也許問題就出在這裡？ 我們開始挖掘並發現了迄今為止最顯著的改進。
當時，使用一種相當愚蠢的演算法從池中選擇了一台伺服器：每個伺服器都有自己的“權重”，具體取決於通道和功率，我們試圖將用戶發送到“權重”最大的伺服器，而無需注意用戶所在的地理位置。 因此，來自聖彼得堡的老師可以透過莫斯科與來自西伯利亞的學生進行通信，而不是透過我們位於聖彼得堡的 Janus 伺服器。
演算法已重做：現在，當用戶打開我們的平台時，我們會使用 Ajax 收集他對所有伺服器的 ping。 建立連線時，我們選擇數量最少的一對 ping（教師伺服器和學生伺服器）。 ping 越少意味著到伺服器的網路距離越短； 距離越短，丟包機率越低； 丟包是視訊通訊中最大的負面因素。 三個月內負面情緒的比例下降了一半（公平地說，此時還進行了其他實驗，但幾乎可以肯定這個實驗的影響最大）。
我們最近發現了另一件不明顯但顯然很重要的事情：與其在厚通道上使用一台強大的 Janus 伺服器，不如使用兩台頻寬較薄的簡單伺服器。 當我們購買功能強大的機器並希望同時塞入盡可能多的房間（通訊會話）時，這一點變得很明顯。 伺服器有頻寬限制，我們可以準確地將其轉換為房間數量 - 我們知道可以打開多少個，例如以 300 Mbit/s 的速度。 一旦伺服器上打開的房間太多，我們就會停止選擇它進行新活動，直到負載減少。 我們的想法是，購買一台功能強大的機器後，我們會將通道載入到最大，這樣最終它將受到處理器和記憶體的限制，而不是頻寬的限制。 但事實證明，在打開一定數量的房間（420）之後，儘管處理器、記憶體和磁碟上的負載仍遠未達到極限，但負面情緒開始到達技術支撐。 顯然，Janus 內部的情況正在變得更糟，也許那裡也有一些限制。 我們開始試驗，將頻寬限制從 300 Mbit/s 降低到 200 Mbit/s，問題就消失了。 現在我們一次性購買了三台新伺服器，其限制和功能較低，我們認為這將導致通訊品質的穩定提高。 當然，我們並沒有試圖弄清楚那裡發生了什麼；我們的拐杖就是一切。 我們可以說，當時需要盡快解決緊迫的問題，而不是做得很漂亮； 另外，Janus 對我們來說是一個用 C 語言寫的黑盒子，修改它的成本非常高。
嗯，在這個過程中我們：
- 更新了伺服器和客戶端上所有可以更新的依賴項（這些也是實驗，我們監控了結果）；
- 修正了與特定情況相關的所有已識別錯誤，例如，當連線中斷且未自動恢復時；
- 我們與視訊通訊領域的公司舉行了許多會議，了解我們的問題：串流遊戲、組織網路研討會； 我們嘗試了一切對我們有用的東西；
- 對投訴最多的教師的硬體和溝通品質進行了技術審查。
這些實驗和隨後的改變使得教師之間對溝通的不滿情緒從7,1年2018月的2,5%降低到2019年XNUMX月的XNUMX%。
下一步是什麼
穩定我們的 Vimbox 平台是該公司 2019 年的主要項目之一。 我們寄予厚望，希望能夠保持這一勢頭，不再在投訴最多的地方看到視訊通訊。 我們知道這些投訴很大一部分與用戶電腦和互聯網的延遲有關，但我們必須確定這部分並解決其餘部分。 其他的都是技術問題，看來我們應該要能夠應付。
主要困難是我們不知道品質實際上可以提高到什麼水平。 找出這個上限是主要任務。 因此，計劃了兩個實驗：
- 將 Janus 的影片與戰鬥條件下的常規 p2p 進行比較。 這個實驗已經進行過，我們的解決方案和p2p之間沒有發現統計上的顯著差異；
- 讓我們提供專門透過視訊通訊解決方案賺錢的公司提供的（昂貴的）服務，並將它們與現有服務的負面影響進行比較。
這兩個實驗將使我們能夠確定一個可實現的目標並專注於它。
此外，還有許多可以例行解決的任務：
- 我們創造溝通品質的技術指標，而不是主觀評價；
- 我們製作更詳細的會話日誌，以便更準確地分析發生的故障，了解它們發生的具體時間和地點，以及當時發生了哪些看似無關的事件；
- 我們在課前準備了自動連接品質測試，同時也為客戶提供了手動測試連接的機會，以減少因硬體和通道造成的負面影響；
- 我們將開發並進行更多惡劣條件下的視訊通訊負載測試，包括可變丟包等；
- 我們在出現問題時更改伺服器的行為以提高容錯能力；
- 如果使用者的連線出現問題，我們會像 Skype 一樣向使用者發出警告，以便他明白問題出在他這邊。
自XNUMX月份以來，視訊通訊方向已成為Skyeng內部的一個成熟的獨立項目，處理自己的產品，而不僅僅是Vimbox的一部分。 這意味著我們開始尋找人 。 嗯，一如既往 .
當然，我們將繼續積極與從事視訊通訊的人員和公司進行溝通。 如果您想與我們交流經驗，我們將很高興！ 發表評論，聯絡我們—我們會回答每個人。
來源： www.habr.com