即時通訊、線上教學、視訊會議——伺服器頻寬計算說明與網路品質測試
對一個實時的網路語音視訊系統而言,網路的品質對該系統的使用者的體驗具有決定性的作用,所以,在正式部署系統之前,進行較全面的網路測試和網路調優工作是非常必要的。這將是一個複雜的系統工程,如果有專業的團隊來做這件事情是最好的。然而,一般的公司都是由開發人員或實施人員來做這些事情。比如需要進行如下分析:目標使用者主要分佈在哪些城市?在哪個地方或哪些地方(分散式方案)部署伺服器對整體目標使用者而言綜合效果最為理想?如何部署?頻寬需要多大?是否需要支援雙線或多線(電信、聯通、移動、鐵通等)?等等。
本文不打算全面系統地介紹這些內容,而是隻把其中最重要的部分拿出來,沒有專業網路調優團隊的中小公司可以按照下面給出的資訊,進行一些必要的測試和分析。在做完這些後,對網路的基本情況就大致心中有數了。
一. 頻寬佔用大小
在語音視訊聊天系統或視訊會議系統中,語音、視訊、電子白板、遠端桌面等功能對網路頻寬的要求分別如何了?
我們先假設一種常見的場景:假設N個線上使用者同時進行1對1的多媒體溝通(即分為N/2組),在不考慮P2P通道的情況下,頻寬的大致佔用如下表所示(以OMCS語音視訊框架為例,與QQ流量要求接近):
對於視訊和遠端桌面而言 --
幀 頻: 8~10 fps 。
普通質量:對應EncodeQuality取值為 8 左右。
高 質 量:對應EncodeQuality取值為 3 左右。
說明:
1.流量對稱
對伺服器而言,上行、下行的流量是對稱的;對客戶端而言,進、出的流量幾乎也是對稱的。上表中列出的只是單向的流量。
2.正比推算
以視訊為例,如果視訊的尺寸不是320x240,那麼可以按比例推算頻寬的佔用。假設視訊大小為640x480,那麼,頻寬的佔用將增加4倍((640x480)/(320x240))。
3.考慮P2P
如果啟用了P2P通道,那麼,服務端頻寬佔用會減小,但客戶端頻寬佔用保持不變。假設P2P的成功率為70%,則服務端的頻寬佔用將減少至原來的30%。
4.視訊會議
上面的資料是基於1對1的多媒體溝通,如果是類似視訊會議的場景,則溝通就是多對多的,這時,頻寬的佔用就會增加,伺服器的上下行的流量也不再對稱。
比如,有M個使用者在一個視訊會議室聊天,每個使用者的視訊都要廣播給其它的(M-1)個使用者,而且,每個使用者都要接收其它(M-1)個使用者的視訊資料,所以頻寬的佔用就會增加很多。
二.伺服器共享頻寬與獨享頻寬
語音視訊資料都是實時採集、實時播放的資料,除了對伺服器頻寬的速度有要求外,更要求伺服器頻寬通訊質量的穩定性,即網路延時小、網路抖動小。很容易理解,如果網路抖動較大,聽到的聲音就是斷斷續續的(OMCS內建了抖動緩衝區JitterBuffer,但也只能在一定程度內減輕這個問題)。
所以,伺服器的頻寬要求必須是獨享頻寬,共享頻寬無法滿足實時語音視訊的要求。對實時語音視訊而言,100M的共享頻寬,還不如5M的獨享。這也就是為什麼通常租伺服器時,IDC會免費送你100M的共享頻寬,而租5M的獨享頻寬,卻一年要花幾千塊錢。
另外,要注意:
(1)IDC伺服器頻寬的單位是bits/s,而我們通常說的網速的單位是bytes/s。它們之間是8倍的關係 -- 比如,伺服器的頻寬是1M的,說明下載的速度最多可以達到120kB/s左右。
(2)IDC伺服器頻寬指上行和下行的總和。比如,伺服器的頻寬是1M,說明在同一時刻,下載的速度和上傳的速度加起來不會超過120kB/s。
三.頻寬計算示例
1.即時通訊:我有1000個客戶端同時線上,同時進行視訊的人數為100,請問服務端大概需要租多少頻寬?
解:假設攝像頭視訊尺寸為640*480,音、視訊為普通質量,P2P成功率為75%。
則 640*480尺寸的視訊一路頻寬佔用是:20*((640x480)/(320x240))= 80KB/s
一路音訊由表中資料得知為5KB/s
故總共需要 100*(80+5)*8/1000*25% =17Mbit/s 伺服器頻寬。
2.視訊教學:我有100個客戶端,其中1個人是老師,老師將自己的桌面和聲音廣播給99個學生,這種情況需要多少伺服器頻寬?
解:假設老師桌面解析度為1024*768,音訊為高質量
則一路音、視訊所佔頻寬為100 + 8 = 108KB/s
故總共需要 100*108*8/1000 = 86.4Mbit/s伺服器頻寬
3.視訊會議:我有10個人進行視訊會議,每個人將自己的視訊廣播給其他的9個人,服務端需要多少頻寬?
解:假設攝像頭視訊尺寸為320*240,視訊質量為高質量。
則每個人上行1路下行9路,10個人則上行10路下行90路。下行合起來是100路,即10*10路。
則總共需要 100*35*8/1000 = 28Mbit/s伺服器頻寬
四.網路品質測試與監控
1.客戶端網路抖動
在伺服器的頻寬質量得到保證後,參與語音視訊會話的各個客戶端,如果希望都能達到比較流暢的體驗,則需要達到以下亮點:
(1)客戶端到伺服器的ping延時低於100ms。
(2)ping的最大抖動範圍不超過20ms。
其中,網路抖動對流暢性的影響更大。在測試時,建議將到伺服器的ping開啟,如此可以觀察ping對語音視訊流暢性的影響。
注:ping命令加上 -t 就可以連續不斷地 ping。如 ping 192.168.0.123 -t
2.觀察網路流量
測試時,推薦在各個客戶端機器上安裝 NetLimiter 網路監控軟體,可以實時檢視客戶端和伺服器之間的上下行流量、以及客戶端與客戶端之間的P2P通道上的網路流量。
通過將網路流量監控與ping結合起來,就能很容易地測試網路的實時狀態。
3.測試客戶端與伺服器之間的網路速度
通過windows自帶的遠端桌面的拷貝檔案功能,結合上面的NetLimiter監控,我們可以很容易地測試出客戶端電腦與伺服器之間的網路速度。
(1)在客戶端電腦上,使用windows自帶的遠端桌面功能(如win7下,開始選單->所有程式->附件->遠端桌面連線),連線到目標伺服器上。
(2)上行拷貝:從當前電腦拷貝一個50M以上的檔案到伺服器上。
(3)下行拷貝:從伺服器上拷貝一個50M以上的檔案到當前電腦。
(4)在拷貝正在進行過程中,開啟NetLimiter的介面,持續觀察客戶端與伺服器之間傳遞的網路速度。
(5)測試時,建議持續觀察5分鐘以上,觀察時請特別注意:(1)上下行速度分別是多少?(2)速度是否穩定?
(6)如果是類似視訊會議這樣的系統,假設需求一般是4個人在同一個會議室,那麼,可選擇4個代表性(所在的地理區域具有代表性)的使用者,然後在這4個人的電腦上同時進行這一測試,分別記錄這4個測試結果。
(7)進行此測試時,可以同時觀察到伺服器的持續的ping值。
然後逐一分析每一個結果看其是否能滿足OMCS的頻寬要求。
NetLimiter 截圖如下所示:
相關推薦
即時通訊、線上教學、視訊會議——伺服器頻寬計算說明與網路品質測試
對一個實時的網路語音視訊系統而言,網路的品質對該系統的使用者的體驗具有決定性的作用,所以,在正式部署系統之前,進行較全面的網路測試和網路調優工作是非常必要的。這將是一個複雜的系統工程,如果有專業的團隊來做這件事情是最好的。然而,一般的公司都是由開發人員或實施人員來做這些事情。比如需要進行如下分析:目標使用
常見CIF、D1、720P、1080P視訊格式上行頻寬計算
在視訊監控系統中,對儲存空間容量的大小需求是與畫面質量的高低、及視訊線路等都有很大關係。下面對視訊儲存空間大小與傳輸頻寬的之間的計算方法做以先容。 位元率是指每秒傳送的位元(bit)數。單位為bps(BitPerSecond),位元率越高,傳送的資料越大。位元率表示經過編碼(壓縮)後的音、視訊 資
開源企業即時通訊和線上客服
距離上一次在部落格園分享即時通訊技術(Lesktop開源WebIM 2.2.0.11——增加線上客服功能)已經9年了,之後斷斷續續對Lesktop2.0進行了重構,並增加了一些新功能,今天要釋出的是Lesktop 3.0,相比2.0增加了以下功能: 1、重構UI庫 2、企業內部組織架構
微信視訊應用、視訊直播、流媒體服務、視訊教學、線上教育類原創文章彙總
原創文章 / 阿酷TONY / 更新:2018-12-12 長沙 / 陽光明媚 / yáng guāng míng mèi / 2 ~ 6℃ 微信視訊應用、視訊直播、流媒體服務、視訊教學、線上教育類原創文章彙總 (2017-2018年度) &nbs
基於WebRtc在H5視訊聊天、視訊教學、視訊會議、視訊直播、白板互動低延時方案
隨移動互聯應用加快,4G,5G網路上馬,低延時網路視訊應改越來越走近生活,在教學,會議,線上醫療,招聘交友及時視訊要求高等場景需求越來越大,傳統基於rtmp直播應用已經大量應用在各個方向,由於rtmp基於TCP延時上可控較差,有積累延時,互動效能差,而新興的Webrtc技術,
iOS 基於環信SDK實現即時通訊-語音、視訊聊天
這裡建立的專案是在文字聊天專案:http://blog.csdn.net/create_pro/article/details/62420040基礎上新增的功能,所以可能需要先去連結文章地址檢視整合過程,具體專案連結在下面,這裡只介紹使用環信SDK整合語音、視訊
在線管理、即時通訊發送通知
即時通訊 在線管理 同步刷新多個客戶端①需要的jar包java_websocket.jar②在線聊天服務池類(在線用戶管理)package com.kentra.plugin.websocketOnline; import java.util.ArrayList; import java.util.Coll
上帝之眼APP——實時定位監控、即時通訊
界面 sdk clas inf 運動 登陸 pos post 兒童 項目地址 https://github.com/guoyaohua/GodsEYE 開發環境 Android studio 2.3.1 極光推送IM SDK 百度鷹眼SDK 背景介紹 定位監控系統,不僅僅是
Socket.IO介紹:支持WebSocket、用於WEB端的即時通訊的框架
網絡 進行 最新版本 ajax 並且 移動 接口 事件 ODB 一、基本介紹 WebSocket是HTML5的一種新通信協議,它實現了瀏覽器與服務器之間的雙向通訊。而Socket.IO是一個完全由JavaScript實現、基於Node.js、支持WebSocket的協議
Layui彈出層、日期和時間選擇、即時通訊、分頁
怎樣 其中 日期時間 hub scrip 即時通 http 邏輯 asc Layui彈出層、日期和時間選擇、即時通訊、分頁 彈層組件文檔 - layui.layer 對於彈出層的感覺是:layer 至今仍作為 layui 的代表作,她的受眾廣泛並非偶然,而是這數年來的堅持、
微信、QQ等即時通訊軟體為什麼沒有取代電子郵件?
如今,社會資訊化和網路化的發展導致資料量爆炸式增長,微信、QQ、陌陌、facebook等,種類繁多的應用軟體為我們溝通交流搭建更加便捷的橋樑,那為什麼我們依然需要使用電子郵件呢? 1、電子郵件具有較高的法律效力。作為一種書面正式性的溝通方式,對於工作中的交流,一定要留下記錄,這些記錄需
(QT) C++ 版本IM通訊軟體(客戶端+伺服器文字聊天、檔案斷點續傳、線上使用者搜尋)
緊接著上一節課程,這次的作業是要求實現一個簡易版的“QQ”,可支援“軟體需求”所列出的功能。當時由於圖方便便選擇了QTCPSocket進行整個過程的通訊(事後才知道有多坑)。服務端介面比較簡單,就幾個按鈕一個進度條,主要在客戶端實現了基本的功能和介面。整個學習和
Web端即時通訊、訊息推送的實現
在瀏覽某些網頁的時候,例如 WebQQ、京東線上客服服務、CSDN私信訊息等類似的情況下,我們可以在網頁上進行線上聊天,或者即時訊息的收取與回覆,可見,這種功能的需求由來已久,並且應用廣泛。 網上關於這方面的文章也能搜到一大堆,不過基本上都是理論,真正能夠執行
即時通訊 視訊會議開源技術選擇
ffmpeg FFmpeg(現改名為Libav) FFmpeg是一個開源免費跨平臺的視訊和音訊流方案,屬於自由軟體,採用LGPL或GPL許可證(依據你選擇的元件)。它提供了錄製、轉換以及流化音視 頻的完整解決方案。它包含了非常先進的音訊/視訊編解碼庫libavcodec,為了保證高可移植性和編解碼質量
GGTalk即時通訊系統(支援廣域網)終於有移動端了!(技術原理、實現、原始碼)
首先要感謝大家一直以來對於GGTalk即時通訊系統的關注和支援!GGTalk即時通訊系統的不斷完善與大家的支援分不開! 從2013年最初的GG1.0開放原始碼以來,到後來陸續增加了網盤功能、遠端協助功能、離線檔案功能、群聊功能、語音聊天功能、視訊聊天功能、以及視訊錄製功能、和增加了資料庫——一路走
即時通訊中 資料離線接收的方法、客戶端及系統
網路即時通訊(IM)工具發展到今天,已成為接收方普遍使用的通訊工具,逐漸成為網路接收方日常生活中必不可少的一部分。即時通 信工具不但在網路接收方的工作中使用,同樣也大量使用在網路接收 方的業餘生活中,接收方通過網路即時通訊工具可以實現與聯絡人及時有效的溝通。
java 視訊會議、視訊溝通、遠端教育、java視訊會議系統
以下都是基於webrtc的實現 方案1:簡單版 基於js框架 http://www.rtcmulticonnection.org/ 只要安裝好後臺的服務即可 體驗地址:https://github.com/muaz-khan/RTCMultiConnection#v3-de
線上聊天、會議、遠端教育系統開源技術方案
1、線上聊天企業網可以使用SIP/RTP或者服務質量更高的H.323網際網路可以使用XMPP(原jabber,已被IETF標準化RFC3920),gtalk,openfire就是基於XMPP實現微信也是參照XMPP協議,activesync改進而來。XMPP本身使用http長
基於websocket的網頁即時通訊(可傳附件圖片塗鴉、最小化狀態通知).NET,winform客戶端、服務端
公司網站需要即時通訊,就研究了下主要以下功能:websocket通訊,網頁端即時通訊,可以傳送表情,可以傳送附件,可以塗鴉,可以實現客服一對多聊天,winform做服務端負責收發,notification提醒,一番百度下來發現websocket做客戶端+superwebsoc
視訊互動、視訊會議、語音對講、IM、開戶等軟體的基本流程和開發指南
視訊呼叫業務邏輯主要實現兩個終端(PC、手機、Pad等)之間的通話請求流程控制,包括請求(Request)、回覆(Reply)、開始(Start)以及結束(Finish)等過程,可以形象理解為打電話的流程:撥號、等待、通話、結束通話。 以下以AnyChat視訊