標籤:

實時語音視頻出海SDK,如何覆蓋迪拜乃至全球

實時語音視頻出海SDK,如何覆蓋迪拜乃至全球

來自專欄 即構科技Zego實時語音視頻技術專欄

在大航海之前,世界地圖對人們來說是蒙查查的一片黑。即使互聯網全球化的今天,網路世界的國際地圖對開發者來說依然是蒙查查的一片黑。

文科妹子有幸參與了即構實時視頻SDK的全球效果測試,見證了工程師們一點一滴地繪畫世界網路地圖的艱辛和不易,也親歷了和迪拜美女測試視頻的場景。

那一陣子,天有點灰濛濛,開發團隊在沒日沒夜地忙著驗證實時語音視頻在全球範圍的效果。聽聞他們每晚熬到兩三點,白天還打著雞血一樣寫代碼。

我隱隱約約感覺到即將會城門失火殃及池魚,我就是那條護城河裡的那條魚。

果不其然,有一天,老大對我說:「要升級全球網路的直播後台規則,你負責協調測試。」

當時的我一臉茫然:「額……這麼重要的任務,交給一個文科妹子真的好嗎?」

雖然我是個文科妹子,可能老大看中我能說會道的體質,讓我進了技術支持的坑。當時我進即構科技才剛過一個月,對即構產品的架構只是大致了解,好在背後有幾位技術大神頂著。我以為主要的任務只是找人聊聊天,計算一下延遲時間和卡頓率就夠了。然而,事情並沒有我預期的那麼簡單。

首先,全球測試有個大麻煩得搞定:時差。

我們快下班的時候,美國和歐洲那邊剛起床。阿聯酋和非洲那邊終於有時間做視頻通話了,我們這裡正處在漆黑的凌晨一兩點。對專門負責這一項目的團隊來說,確實麻煩不小,因為時差就意味著熬夜……為了完成全球測試,整個團隊拿出「簽生死狀」死磕到底的態度,不搞定問題絕不回家……所以那段時間我基本都是晚睡晚起。這是我最近距離接觸理科生死腦筋的時刻,原來傳說中不把問題搞定不吃飯不睡覺不休息的拚命十三郎真實存在,還很多,多到可以組隊成立一家叫即構科技的公司。(不過也不能天天這麼熬吧,否則年紀不小的老大非把自己熬壞了不可。)

環球到處約朋友幫忙測試

最初階段主要的測試點是北非和中東(特別是阿聯酋迪拜及其附近區域)。幫忙測試的主要有三位朋友:大型中資企業的職員小哥哥,幫我們燒流量測試的導遊大叔,同樣做導遊工作的兩位小姐姐。

最先找到的是中資企業的小哥哥。第一次測試的體驗不理想。他使用的是家庭網路,網速是非常不錯的。但剛打開視頻時,畫面卡得只有圖片,偶爾有一段時間能語音聊聊天,緊接著又卡得只剩下PPT了。測試的那時候已經是深夜了,瞌睡蟲上腦的我把效果記錄下來。晚睡晚起,第二天中午才去上班,老大笑我笨:你當時就該幾個電話把測試相關的所有人通通都叫起來,不把問題搞定不許睡覺。

「有時差啊,那時候都半夜了,你們要熬夜哦。」我怯怯地說。

「本來就是我們的活,搞不定睡什麼覺啊。」老大大手一揮,如此回答。

坐在即構深圳的辦公室里,通過視頻感受迪拜的異國風光

於是,這天晚上,再把那位小哥哥叫出來,又測試了一把。這次測試就規範多了,我負責和小哥哥聊天吹水,後台幾位攻城獅實時盯著數據。當天晚上,整個團隊都在家裡盯著電腦辦公。我一邊和對方交流,一邊記錄數據,幾位後台攻城獅盯著連綿不斷的數據找問題。老大則忙著協調後台,憑藉多年經驗尋找卡頓的原因,如果可能與其他部門有關,立刻電話把人鬧醒叫起來一起盯著。

最後查出了問題的原因,就是某個節點有問題。我這才知道,原來網路上看似簡單的兩個人實時視頻聊天,背後其實需要一個複雜且全面的實時海量數據傳輸系統來支撐。

打個比方,我們聊天時交換的音視頻數據就像馬匹背上的貨物,網路就像馬匹奔跑的道路,而節點就是道路交叉點上更換馬匹和分發貨物的驛站。和普通的馬匹不一樣的是,網路的傳播速度基本相同,都是接近光速。所以距離對音視頻數據傳遞來說並不是難題,真正的難題,其實是網路路徑上的交通條件。

正常情況下,網路傳輸到哪都很快,上一秒發出的郵件下一秒就能送達,以人類感官來說基本就是一瞬間發生的事。但麻煩就在於,網路有時候也可能會堵車,有時候會經過泥巴路,有時候會莫名其妙繞遠路,更有甚者,有時候連路都沒有,馬匹被堵在半路上,簡直開始懷疑馬生。視頻通話另一邊的用戶收不到音視頻數據,就開始抓臉發狂,怒吼花了冤枉錢。(境外視頻服務的用戶,大部分依據時長收費。視頻卡一下試試,用戶分分鐘要求退款。)

中東美女和中國美女一樣愛自拍愛直播

這就是中國境內外視頻直播互通主要面對的問題了。對於國內的網路情況還好,大家都習慣了國內的網路交通情況,哪裡「橋斷了」,「哪個時段堵車」,「哪裡有坑」,「哪裡有土匪強行換掉馬背上的音視頻數據」之類,什麼時候什麼情況發生,大部分做語音視頻的團隊都心裡有數。但國外的網路情況不同,誰知道什麼時候是高峰期,誰知道哪個地方網路交通條件好,哪個地方交通條件差?中國再大也只是地球上的其中一塊土地,「外國」這個詞可不是一個簡單的國家,而是包含地球92.8%的土地範圍和千奇百怪天知道長什麼樣的網路環境。一不小心走錯路,你的音視頻數據就栽坑裡去了,導致視頻通話的對方撕臉抓狂。

因此,境外視頻直播所需要的並不僅僅是技術那麼簡單,還有長期部署和運營境外節點的經驗和持續不斷的監控測試。沒有深厚技術底子和經驗積累,恐怕是做不出來的。(插一句題外話,我們把全球各大洲的情況都摸了一遍,做到全球無死角覆蓋,過程說起來容易,事實上整個團隊在這段時間都熬了不少夜的。倒不是故意加班,確實是因為時差緣故,得等到對方有時間才能測試。磕磕絆絆的小事故不斷,特別是項目剛開始的一段時間,幾乎每一次通話都出現這樣或者那樣的問題。再次驚嘆一下理科生的執著,這幫理工男不是為了工資或績效之類,是真的問題沒解決連飯都吃不下。親眼所見,這幫人不像混職場的上班族,反而像只專註手中玩具刨根問題的孩子。)

言歸測試,剛開始走不通的原因,就是節點有問題。一開始我們選擇從深圳節點走香港節點,再轉阿聯酋節點,效果並不好。香港節點到阿聯酋節點的這段路不知道出了什麼問題,總之卡頓得很厲害。於是我們換了一條路,從深圳節點直接奔去阿聯酋節點再轉中東其它地方(此處省略技術細節兩萬字,其實我也表示不懂),效果一下子就好多了。線路調整之後,我們又與燒流量的大叔視頻通話,效果非常好,簡直好得不得了,居然和使用wifi效果差不多!大叔比較耿直,脫口而出就嚷嚷:「我擦,這個甩了微信視頻好幾條街啊!」兩位小姐姐不但幫我們視頻,還測試了迪拜節點和迪拜節點本地視頻的效果,和深圳節點與迪拜節點視頻的流暢度差不多。

優選國際網路鏈路,繞著彎走往往是更快的

最開始時,迪拜的卡頓情況比較嚴重,有多次明顯的卡頓,並且一定程度影響到交流。但經過路線優化和節點調整後,卡頓情況幾乎消失了。接著,我開始精細記錄:迪拜連深圳,延遲一般400ms以下,偶爾升至680ms(燒流量的那位大叔),最低的時候達到100ms左右。總體交流情況非常好,畫面一直都是高清的狀態,交流能感覺到非常微妙的延遲。(拿一個基準做對比,即構科技的方案一般國內連國內的延遲是100ms到200ms,感覺就是跟站在對面說話差不多。)

接著,我們又忙著測試美國,然後歐洲,最後非洲。美國和歐洲其實困難不大,畢竟是老牌的資本主義,網路基建是桿桿的。「運送音視頻數據的馬匹」無論走哪條路都很順暢,不過,在精益求精的要求下,為了提高「延遲毫秒數」、「流暢觀感」和「畫質音質」的主觀體驗,我們還是選擇了一條最優的線路。過程流暢迅速,很愉快地把歐美「交通地圖」繪畫出來了。

即構全球的伺服器節點和CDN節點分布

紐約節點連深圳節點的延遲,好的情況下只有200ms左右的延遲,稍差一點到達500ms,偶爾會出現600ms以上的延遲。比迪拜的流暢度要稍高一點,基本感覺不到延遲了,但畫面差不多,都十分清晰。(其實網路條件不差的情況下,美國和迪拜差不多,如果用肉眼識別,100ms的差別實在很難區分。只有在畫面動作很劇烈的時候才會出現明顯區別。一般兩個人隔空通話,基本感覺不到什麼延遲的區別。)

另外,值得一提的是,我們還測試了紐約本地用戶連接另外一個紐約用戶的情況,延遲100ms到200ms左右,跟國內視頻的延遲一樣。在紐約遠隔重洋協助我測試的小叔叔說:視頻非常順暢和清晰,就像在中國國內跟與國內的朋友視頻通話差不多一樣順暢。

最後,我們開始專註非洲大陸的無死角覆蓋測試。篇幅有點太長了,那麼,非洲測試發生的浪漫故事就放在下篇吧。這真是一篇神奇的黑色大陸啊,先通過幾個關鍵詞劇透一下:在非洲買菜、豪車在沙漠狂奔、華人的超級豪宅、和感人的網速……

即構科技的環球測試數據記錄

<The End>


推薦閱讀:

Android SDK 開發紀要
基於Netty的IM簡單實現原理
15款國內移動應用開發者都必須知道的小而美SDK
矽谷和國內的 iOS 開發到底有何不同?

TAG:視頻 | 語音 | SDK |