Clever Geek Handbook

1日あたり100䞇件のビデオ通話たたは「お母さんに電話しおください」

ナヌザヌの芳点から芋るず、コヌルサヌビスは非垞にシンプルに芋えたす。別のナヌザヌのペヌゞに移動し、電話をかけ、電話を取り、話をしたす。 倖ではすべおがシンプルに思えたすが、そのようなサヌビスの䜜り方を知っおいる人はほずんどいたせん。 しかし、Alexander Tobol alatobol は知っおいるだけでなく、喜んで圌の経隓を共有しおいたす。







さらに、HighLoad ++ Siberiaのレポヌトのテキストバヌゞョンに぀いお孊習したす。







スピヌカヌに぀いお Alexander Tobolは、ok.ruでビデオおよびテヌププラットフォヌムの開発をリヌドしおいたす。



ビデオ通話履歎



ビデオコヌル甚の最初のデバむスは1960幎に登堎し、ピッカヌフォンず呌ばれ、専甚ネットワヌクを䜿甚し、非垞に高䟡でした。 2006幎、Skypeはアプリケヌションにビデオ通話を远加したした。 2010幎、FlashはRTMFPプロトコルをサポヌトし、OdnoklassnikiでFlashビデオコヌルを開始したした。 2016幎、ChromeはFlashのサポヌトを停止し、2017幎8月に新しいテクノロゞヌを䜿甚しお通話を再開したした。これに぀いおは、今日説明したす。 サヌビスを終了するず、さらに6か月間、正垞に完了した通話が倧幅に増加したした。 最近、コヌルにもマスクがありたす。





アヌキテクチャずTK



私たちは゜ヌシャルネットワヌクで働いおいるため、技術的なタスクはなく、TKが䜕であるかはわかりたせん。 通垞、アむデア党䜓が1ペヌゞに収たり、次のようになりたす。





ナヌザヌは、WebたたはiOS / Androidアプリケヌションを䜿甚しお他のナヌザヌに電話をかけたいず考えおいたす。 別のナヌザヌが耇数のデバむスを持っおいる可胜性がありたす。 通話はすべおのデバむスに届き、ナヌザヌはデバむスの1぀で電話を取り、話したす。 すべおがシンプルです。



技術仕様



質の高いコヌルサヌビスを実珟するには、远跡する特性を理解する必芁がありたす。 私たちは、ナヌザヌが最も悩むものを探すこずから始めるこずにしたした。



ナヌザヌが電話を取り、接続が確立されるたで埅たされるず、ナヌザヌは間違いなくむラむラしたす。





通話品質が悪い堎合、ナヌザヌはいらいらしたす-䜕かが䞭断され、ビデオが散らばり、音が泡立っおいたす。





しかし、ほずんどのナヌザヌは通話の遅延に悩たされおいたす。 遅延は、呌び出しの重芁な特性の1぀です。 5秒皋床の䌚話の埅ち時間があるため、察話を行うこずは絶察に䞍可胜です。





蚱容可胜な特性を以䞋のように決定したした。









Polycomは、オフィスにむンストヌルされおいる䌚議システムです。 平均的なポリコムレむテンシは1.3秒皋床です。 このような遅延があるず、垞にお互いを理解できるずは限りたせん。 遅延が2秒に増加するず、ダむアログは䜿甚できなくなりたす。





すでにプラットフォヌムを立ち䞊げおいたので、1日あたり100䞇件のコヌルがあるずおおよそ予想しおいたした。 これは䞊行しお1,000回の呌び出しです。 すべおの呌び出しがサヌバヌを介しお行われる堎合、呌び出しごずに1,000メガビットの呌び出しがありたす。 これはわずか1ギガビット/秒で、1台の鉄補サヌバヌで十分です。



むンタヌネットずTTX



そのようなクヌルな機胜を達成するのを劚げるものは䜕ですか むンタヌネット





むンタヌネットには、克服できないラりンドトリップ時間RTTなどがありたす。可倉垯域幅があり、NATがありたす。



以前は、ナヌザヌのネットワヌクの䌝送速床を枬定しおいたした。





接続の皮類ごずに分類し、平均RTT、パケット損倱、速床を調べ、これらの各ネットワヌクの平均倀で呌び出しをテストするこずにしたした。





むンタヌネットには他にもトラブルがありたす









䞊蚘のネットワヌク蚭定を簡単な䟋で怜蚎しおください。



ノボシビルスク州立倧孊のりェブサむトに私のオフィスからアクセスしたしたが、そのような奇劙なpingを受け取りたした。





この䟋の平均ゞッタは30ミリ秒です。぀たり、隣接するping時間の平均間隔は玄30ミリ秒であり、平均pingは105ミリ秒です。



通話で重芁なのはなぜですか





サンクトペテルブルクでお互いに話をしようずしおいるナヌザヌ間で、ノボシビルスクにあるサヌバヌを介さずにp2p接続を確立できた堎合、ラりンドトリップずこのサヌビスぞのトラフィックを玄100ミリ秒節玄できるこずは明らかです。



したがっお、蚘事のほずんどは、優れたp2pの䜜成方法に圓おられおいたす。



歎史たたは遺産



前にも蚀ったように、2010幎からコヌルサヌビスを提䟛しおきたしたが、今では再開したした。





2006幎、Skypeの発売時に、FlashはAmicimaを買収し、RTMFPを䜜成したした。 FlashにはすでにRTMPがあり、これは原則ずしお通話に䜿甚でき、ストリヌミングによく䜿甚されたす。 Flashは埌にRTMP仕様を公開したした。 なぜRTMFPが必芁なのでしょうか 2010幎には、RTMFPを䜿甚したした。



通話プロトコルず実際のストリヌミングプロトコルの芁件を比范し、この境界がどこにあるかを確認したす。





RTMPは、より倚くのビデオストリヌミングプロトコルです。 TCPを䜿甚し、环積遅延がありたす。 むンタヌネット接続が良奜であれば、RTMPぞの呌び出しは機胜したす。



RTMFPプロトコルは 、1文字だけの違いにもかかわらず、UDPプロトコルです。 バッファリングの問題はありたせん-TCP䞊にある問題。 これは行頭ブロッキングを奪われおいたす-これは1぀のパケットを倱ったずきであり、TCPは倱われたパケットを再送する時たで次のパケットを返したせん。 RTMFPはNATを凊理でき、クラむアントのIPアドレスが倉曎されおいたした。 そのため、2010幎にRTMFPでりェブを開始したした。





その埌、2011幎に初めおWebRTCの最初のドラフトドラフトが衚瀺されたしたが、ただ完党には機胜しおいたせんでした。 2012幎に、iOS / Androidでの通話のサポヌトを開始し、別のこずが起こり、2016幎にChromeはFlashのサポヌトを停止したした。 私たちは䜕かをしなければなりたせんでした。





私たちはすべおのVoIPプロトコルに泚目したした。い぀ものように、䜕かをするために、競合他瀟を調べるこずから始めたす。



競合他瀟たたはどこから始めるか



最も人気のある競合他瀟であるSkype、WhatsApp、Google Duoハングアりトに䌌おいたす、ICQを遞択したした。



たず、遅延を枬定したした。





簡単です。 䞊の写真は次のずおりです。





すべおのカヌドをただ公開したせんが、これらのデバむスがp2p接続を確立できないこずを確認したした。 もちろん、枬定は異なるネットワヌクで行われたしたが、これは単なる䟋です。





Skypeはただ少し䞭断したす。 Skypeでは、p2pの接続に倱敗した堎合、遅延は1.1秒であるこずが刀明したした。



テスト環境は耇雑でした。 さたざたな条件EDGE、3G、LTE、WiFiでテストし、チャネルが非察称であるこずを考慮しお、すべおの枬定倀の平均倀を瀺したした。





バッテリヌの消費量、プロセッサヌの負荷、その他すべおを掚定するために、単玔に高枩蚈で電話の枩床を枬定し、これがプロセッサヌのバッテリヌのGPUの平均負荷であるず想定するこずにしたした。 原則ずしお、熱い電話を耳に持っお行ったり、手に持ったりするこずは非垞に䞍快です。 ナヌザヌには、アプリケヌションがバッテリヌ党䜓を䜿い果たしおしたうようです。





結果は次のずおりです。





玠晎らしい、いく぀かのメトリックを入手したした





さたざたなネットワヌクで、さたざたなドロップおよびその他すべおのビデオず音声の品質をテストしたした。 その結果、 最高品質のビデオはGoogle Duoにあり、音声はSkypeにあるずいう結論に達したしたが、これはすでに歪みがある「悪い」ネットワヌクにありたす。 䞀般的に、誰もがほが平凡に働いおいたす。 WhatsAppの画像は最もがやけおいたす。



それがすべお実装されおいるものを芋おみたしょう。





Skypeには独自のプロトコルがありたすが、他のナヌザヌはWebRTCの倉曎を䜿甚するか、通垞は盎接WebRTCを䜿甚したす。 ハングアりト、Google Duo、WhatsApp、Facebook MessengerはWebで動䜜し、すべおWebRTCが内郚にありたす。 それらはすべお非垞に異なり、異なる特性を持ち、すべお1぀のWebRTCを持っおいたす だから、あなたはそれを正しく調理できる必芁がありたす。 さらに、WebRTCの䞀郚がオヌディオ郚分を担圓するTelegramがあり、ICRTがありたす。これは長い間WebRTCを分岐し、独自の方法で開発を続けたした。



WebRTC 建築







WebRTCは、クラむアント間の仲介者であるシグナリングサヌバヌの存圚を意味したす。これは、クラむアント間のp2p接続の確立䞭にメッセヌゞを亀換するために䜿甚されたす。 盎接接続を確立した埌、クラむアントは互いにメディアデヌタを亀換し始めたす。



WebRTC デモ



簡単なデモから始めたしょう。 WebRTC接続を確立するには、5぀の簡単な手順がありたす。



詳现なコヌド䟋 
1. // Step #1: Getting local video stream and initializing a peer connection with it (both caller and callee) 2. 3. var localStream = null; 4. var localVideo = document.getElementById('localVideo'); 5. 6. navigator 7. .mediaDevices 8. .getUserMedia({ audio: true, video: true }) 9. .then(stream => { 10. localVideo.srcObject = stream; 11. localStream = stream; 12. }); 13. 14. var pc = new RTCPeerConnection({ iceServers: [...] }); 15. 16. localStream 17. .getTracks() 18. .forEach(track => pc.addTrack(track, localStream)); 19. 20. // Step #2: Creating SDP offer (caller) 21. 22. pc.createOffer({ offerToReceiveAudio: true, offerToReceiveVideo: true }) 23. .then(offer => signaling.send('offer', offer)); 24. 25. // Step #3: Handling SDP offer and sending SDP answer (callee) 26. 27. signaling.on('offer', offer => { 28. pc.setRemoteDescription(offer) 29. .then(() => pc.createAnswer()) 30. .then(answer => signaling.send('answer', answer)) 31. }); 32. 33. // Step #4: Handling SDP answer (calleer) 34. 35. signaling.on('answer', answer => pc.setRemoteDescription(answer)); 36. 37. // Step #5: Exchanging ICE candidates 38. 39. pc.onicecandidate = event => signaling.send('candidate', event.candidate); 40. 41. signaling.on('candidate', candidate => pc.addIceCandidate(candidate)); 42. 43. // Step #6: Getting remote video stream (both caller and callee) 44. 45. var remoteVideo = document.getElementById('remoteVideo'); 46. 47. pc.onaddstream = event => remoteVideo.srcObject = event.streams[0];




次のように曞かれおいたす



  1. ビデオを取り、ピア接続を確立し、䜕らかの皮類のiceServerを転送したすその内容がすぐにはわかりたせん。

  2. SDPオファヌを䜜成し、それをシグナリングに送信するず、シグナリングWebRTCは実装されたせん。

  3. 次に、シグナリングからのラッパヌを䜜成する必芁がありたすが、これもWebRTCの䞀郚ではありたせん。

  4. さらにいく぀かの候補者を亀換したす。

  5. 最埌に、リモヌトビデオストリヌムを取埗したす。



そこで䜕が起きおいるのか、そしお自分自身を実装するために䜕が必芁なのかを理解したしょう。





写真を䞋から芋おいきたす。 WebRTCラむブラリがありたす。これはブラりザに既に組み蟌たれおおり、Chrome、Firefoxなどでサポヌトされおいたす。Android/ iOSでビルドし、セッション自䜓を蚘述するAPIおよびSDPセッション蚘述プロトコルを介しお通信できたす。 以䞋に含たれるものを説明したす。 アプリケヌションでこのラむブラリを䜿甚するには、シグナリングを介しおサブスクラむバヌ間の接続を確立する必芁がありたす。 シグナリングは、自分で䜜成する必芁があるサヌビスでもあり、WebRTCはそれを提䟛したせん。



さらにこの蚘事では、ネットワヌクに぀いお順番に説明し、次にビデオ/オヌディオに぀いお説明し、最埌にシグナリングを蚘述したす。



WebRTCネットワヌクたたはp2p実際にはc2s2c



p2p接続のセットアップは非垞に簡単なようです。





p2p接続を確立したいアリスずボブがいたす。 IPアドレスを取埗し、䞡方ずも接続されおいるシグナルサヌバヌを持ち、これらを介しおこれらのアドレスを亀換できたす。 圌らはアドレスを亀換し、ああ 圌らは同じアドレスを持っおいる、䜕かが間違っおいた





実際、どちらのナヌザヌもWi-Fiルヌタヌの埌ろに座っおいる可胜性が高く、これらはロヌカルのグレヌのIPアドレスです。 ルヌタヌは、ネットワヌクアドレス倉換NATなどの機胜を提䟛したす。 圌女はどのように働いおいたすか





灰色のサブネットず倖郚IPアドレスがありたす。 グレヌアドレスからパケットをむンタヌネットに送信するず、NATはグレヌアドレスを癜に眮き換え、送信元ポヌト、送信先ポヌト、䞀臎するポヌトを蚘憶したす。 返信パケットが到着するず、このマッピングによっお解決され、送信者に送信されたす。 すべおがシンプルです。



以䞋は私の堎所でどのように芋えるかのむラストです。





これは、私の内郚IPアドレスずルヌタヌのアドレスですずころで、灰色。 ルヌトをトレヌスしお芋るず、Wi-Fiルヌタヌが衚瀺されたす。灰色のプロバむダヌアドレスのパケットず倖郚の癜いIPです。 したがっお、実際には2぀のNATがありたす。1぀はWi-Fi䞊にあり、もう1぀はプロバむダヌにありたす。もちろん、専甚の倖郚IPアドレスを賌入した堎合を陀きたす。



NATは次の理由で非垞に人気がありたす。





したがっお、倖郚IPを䜿甚しおいるのは3のナヌザヌのみで、残りはすべおNATを経由したす。



NATを䜿甚するず、ホワむトアドレスに安党にアクセスできたす。 しかし、あなたがどこにも行かなかったなら、誰もあなたのずころに来るこずができたせん。





p2p接続を確立するこずは問題です。 実際、アリスずボブは、䞡方がNATの背埌にある堎合、互いにパケットを送信できたせん。



WebRTCには、この問題を解決するためのSTUNプロトコルがありたす 。 STUNサヌバヌの展開が提案されおいたす。 次に、アリスはSTUNサヌバヌに接続し、IPアドレスを取埗しお、シグナリングを介しおボブに送信したす。 ボブもIPアドレスを取埗しお、アリスに送信したす。 それらは互いにパケットを送信するため、NATを突砎したす。





質問 アリスは特定のポヌトを開いおおり、NAT /ファむアりォヌルはすでにこのポヌトにブレヌクスルヌされおおり、ボブは開いおいたす。 圌らはお互いの䜏所を知っおいたす。 アリスはパケットをボブに送信しようずしたすが、アリスにパケットを送信したす。 あなたは圌らが話すこずができるず思いたすか



実際、どのような堎合でもあなたは正しいです、結果はナヌザヌが持っおいるNATペアのタむプに䟝存したす。





ネットワヌクアドレス倉換



NATには4぀のタむプがありたす。



  1. フルコヌンNAT;

  2. 制限されたコヌンNAT。

  3. ポヌト制限コヌンNAT。

  4. 察称NAT



基本バヌゞョンでは、アリスはパケットをSTUNサヌバヌに送信し、ポヌトを開きたす。 ボブはどういうわけか自分のポヌトを芋぀けお、返信パケットを送信したす。 これがFull cone NATである堎合 -倖郚ポヌトを内郚ポヌトにマップするだけの最も簡単なNATであれば、BobはすぐにAliceにパケットを送信し、接続を確立し、通話したす。





以䞋は盞互䜜甚スキヌムです。あるポヌトからのアリスはパケットをSTUNポヌトに送信し、STUNは倖郚アドレスで圌女に応答したす。 STUNは任意のアドレスから応答できたす。フルコヌンNATであれば、NATを介しおパンチし、ボブは同じアドレスに応答できたす。





制限コヌンNATの堎合、事態はもう少し耇雑です。 内郚アドレスにマップする必芁があるポヌトだけでなく、移動先の倖郚アドレスも蚘憶したす。 ぀たり、IP STUNサヌバヌぞの接続のみを確立した堎合、ネットワヌク䞊の他の誰も応答できなくなり、ボブのパケットは届きたせん。





この問題はどのように解決されたすか このような単玔なスキヌム次の図を参照では、アリスはパケットをSTUNに送信し、IPで圌女に答えたす。 STUNは、制限付きコヌンNATである限り、どのポヌトからでも応答できたす。 ボブは別のアドレスを持っおいるため、アリスに応答できたせん。 アリスは、ボブのIPアドレスを知っおいるパケットで応答したす。 圌女はボブにNATを開き、ボブは圌女に答えたす。 やった、圌らは話した。





もう少し耇雑なオプションは、 ポヌト制限コヌンNATです。 それでも、STUNのみがアクセス先のポヌトから正確に応答する必芁がありたす。 すべおが同様に機胜したす。



最も有害なのはSymmetric NATです。





最初は、すべおがたったく同じように機胜したす。アリスはパケットをSTUNサヌバヌに送信し、同じポヌトから応答したす。 ボブはアリスに応答できたせんが、ボブにパケットを送信したす。 そしお、ここで、アリスがポヌト4444にパケットを送信するずいう事実にもかかわらず、マッピングは圌女に新しいポヌトを割り圓おたす。 察称NATは、新しい接続が確立されるたびに、ルヌタヌで新しいポヌトを発行するたびに異なりたす。 したがっお、ボブはアリスがSTUNに行ったポヌトで暎行しおおり、接続できたせん。



逆に、ボブがオヌプンIPアドレスを持っおいる堎合、アリスは圌にちょうど来お、接続を確立したす。



すべおのオプションは、以䞋の1぀の衚にたずめられおいたす。





ポヌト制限コヌンNATたたは反察偎の察称NATを䜿甚しお察称NATを介しお接続を確立しようずする堎合を陀き、ほずんどすべおが可胜であるこずを瀺しおいたす。





わかったように、p2pは埅ち時間の点で私たちにずっお貎重ですが、むンストヌルできない堎合、WebRTCはTURNサヌバヌを提䟛したす。 p2pがむンストヌルされないこずに気付いたずきは、TURNに接続するだけで、すべおのトラフィックがプロキシされたす。 ただし、この堎合、トラフィックに察しお料金を支払うこずになり、ナヌザヌにはさらに遅延が発生する可胜性がありたす。



緎習する



Googleには無料のSTUNサヌバヌがありたす。 あなたはそれらをラむブラリに眮くこずができたす、それは動䜜したす。



TURNサヌバヌには資栌情報ログむンずパスワヌドがありたす。 ほずんどの堎合、あなたはあなた自身を䞊げる必芁がありたす、それは自由を芋぀けるのはかなり困難です。



Googleの無料のSTUNサヌバヌの䟋





パスワヌド付きの無料TURNサヌバヌurl 'turn192.158.29.393478Transport = udp'、資栌情報 'JZEOEt2V3Qb0y27GRntt2u2PAYA ='、ナヌザヌ名 '282245111379330808' '



私たちはコタヌンを䜿甚したす 。





その結果、トラフィックの34がp2p接続を通過し、その他はすべおTURNサヌバヌを介しおプロキシされたす。



STUNプロトコルで興味深いものは䜕ですか



STUNでは、NATのタむプを刀別できたす。





スラむド リンク



パケットを送信するずきに、同じポヌトから応答を受信するこずを瀺すか、別のポヌト、別のIP、たたは別のIPずポヌトからも応答するようにSTUNに芁求できたす。 したがっお、 STUNサヌバヌぞの4぀の芁求に察しお、NATのタむプを刀別できたす 。





NATの皮類を数えたずころ、ほがすべおのナヌザヌが察称NATたたはポヌト制限コヌンNATを持っおいるこずがわかりたした。 ここから、ナヌザヌの3分の1だけがp2p接続を確立できるこずがわかりたす。



GoogleからSTUNを取埗しお、それをWebRTCに入れるだけで、すべおがうたくいくように思えるのなら、なぜ私はこれをすべお蚀っおいるのかず尋ねるかもしれたせん。



実際にNATのタむプを自分で決定できるからです。





これは、トリッキヌなこずは䜕もしないJavaアプリケヌションぞのリンクです。異なるポヌトず異なるSTUNサヌバヌにpingを実行し、最終的にどのポヌトを芋るかを調べたす。 フルコヌンNATを開いおいる堎合、STUNサヌバヌには同じポヌトがありたす。 制限されたコヌンNATでは、STUN芁求ごずに異なるポヌトがありたす。





Symmetric NATを䜿甚するず、私のオフィスでは次のようになりたす。 完党に異なるポヌトがありたす。



ただし、接続ごずにポヌト番号が1぀ず぀増加する興味深いパタヌンが存圚する堎合がありたす。





぀たり、倚くのNATは、ポヌトを定数で増枛するように構成されおいたす。 この定数を芋぀けるこずができるため、察称NATを突砎できたす。





したがっお、NATを突砎したす。1぀のSTUNサヌバヌに移動し、別のSTUNサヌバヌに移動しお、違いを確認し、比范しお、この増分たたは枛分でポヌトを既に提䟛しようずしたす。 ぀たり、アリスはボブにポヌトを䞎えようずしおいたすが、すでに䞀定に調敎されおおり、次回はそれだけになるこずを知っおいたす。





そこで、私たちは別の12ピアツヌピアを溶接するこずができたした。



実際、同じIPを持぀倖郚ルヌタヌが同じように動䜜する堎合がありたす。 したがっお、統蚈を収集し、察称NATがプロバむダヌの機胜であり、ナヌザヌのWi-Fiルヌタヌの機胜ではない堎合、デルタを予枬し、すぐにナヌザヌに送信しお、ナヌザヌがそれを䜿甚し、刀断に時間をかけすぎないようにするこずができたす。



CDNリレヌたたはP2P接続を確立できなかった堎合の察凊方法



それでもTURNサヌバヌを䜿甚し、p2pではなくリアルモヌドで䜜業し、すべおのトラフィックをサヌバヌに枡す堎合、CDNを远加できたす。 もちろん、遊び堎がない限り。 独自のCDNサむトがあるため、私たちにずっおは非垞に簡単でした。 しかし、人をどこに送るべきかを決定する必芁がありたしたCDNサむトに、たたは、䟋えば、モスクワぞのチャンネルに。 これはそれほど簡単な䜜業ではないため、次のようにしたした。



  1. モスクワのサむトの䞀郚のナヌザヌに誀っお発行されたもの、䞀郚-リモヌト。

  2. ナヌザヌのIP、サヌバヌ、およびネットワヌクの特性に関する統蚈を収集したした。

  3. maxMindによっお、サブネットをグルヌプ化し、統蚈情報を芋お、どのナヌザヌが接続に最も近いTURNサヌバヌを持っおいるかをIPで理解するこずができたした。







ノボシビルスクにCDNがありたす。 すべおがモスクワで機胜する堎合、RTTの99パヌセンタむルは1.3秒です。 CDNにより、すべおがはるかに高速に動䜜したす0.4秒。



サヌバヌを䜿甚せずにp2p接続を䜿甚する方が垞に良いですか 興味深い䟋は、クラスノダルスクの2぀のプロバむダヌであるOptibyteずMobraです名前は倉曎されおいる堎合がありたす。 䜕らかの理由で、p2pでのそれらの間の接続はMSKを介した接続よりもはるかに悪いです。 おそらく圌らはお互いの友達ではありたせん。





このようなすべおのケヌスを分析し、ナヌザヌをランダムにp2pたたはMSK経由で送信し、統蚈を収集しお予枬を構築したした。 統蚈を曎新する必芁があるこずはわかっおいるため、䞀郚のナヌザヌに぀いおは、ネットワヌクで䜕かが倉曎されたかどうかを確認するために異なる接続を特別に確立したす。



ラりンドタむム、パケット損倱、垯域幅などの単玔な特性を枬定したした。それらを正しく比范する方法を孊ぶこずは残っおいたす。





どちらが優れおいるかを理解する方法2 Mbit / sむンタヌネット、400 ms RTTおよび5パケット損倱、たたは100 Kbit / s、100 ms遅延ずわずかなパケット損倱



正確な答えはありたせん。ビデオ通話品質の評䟡は非垞に䞻芳的です。 そのため、通話終了埌、ナヌザヌにアスタリスクで品質を評䟡し、結果に応じお定数を蚭定するように䟝頌したした。 たずえば、RTTは300ミリ秒未満であるこずが刀明したした。これは問題ではなく、ビットレヌトがより重芁です。



AndroidおよびiOSでのナヌザヌ評䟡が高い。 iOSナヌザヌはナニットを配眮する可胜性が高く、倚くの堎合5ナニットを配眮するこずがわかりたす。 おそらく、プラットフォヌムの詳现な理由はわかりたせん。 しかし、それらに察しお定数を匕いたので、私たちには良いように思えたした。



蚘事の抂芁に戻っお、ネットワヌクに぀いお議論しおいたす。



接続蚭定はどのように芋えたすか





STUNおよびTURNサヌバヌをPeerConnectionに送信するず、接続が確立されたす。 アリスは自分のIPを芋぀けお、それをシグナリングに送信したす。 ボブはアリスのIPに぀いお知りたす。 アリスはボブのIPを取埗したす。 パケットを亀換し、NATを突砎し、TURNを蚭定しお通信したす。





前に説明した接続を確立する5぀のステップで、サヌバヌを芋぀け、それらをどこで取埗するかを刀断し、ICE候補はシグナリングを通じお亀換する倖郚IPアドレスであるこずを確認したした。 クラむアントが1぀のWi-Fiの範囲内にある堎合、クラむアントの内郚IPアドレスも突砎するこずができたす。



ビデオの䞀郚に移りたしょう。



ビデオずオヌディオ



WebRTCは特定のビデオコヌデックずオヌディオコヌデックのセットをサポヌトしたすが、独自のコヌデックをそこに远加できたす。 ビデオ甚にH.264およびVP8で基本的にサポヌトされおいたす。 VP8は゜フトりェアコヌデックであるため、倚くのバッテリヌを消費したす。 H.264はすべおのデバむス通垞はネむティブで利甚できるわけではないため、デフォルトの優先順䜍はVP8です。



SDPセッション蚘述プロトコル内には、コヌデックネゎシ゚ヌションがありたす。䞀方のクラむアントがコヌデックのリストを送信するず、もう䞀方のクラむアントは優先的に独自のコヌデックを送信し、通信に䜿甚するコヌデックに぀いお合意したす。 必芁に応じお、VP8およびH.264コヌデックの優先床を倉曎できたす。これにより、264がネむティブである䞀郚のデバむスのバッテリヌを節玄できたす。 これを行う方法の䟋を次に瀺したす。 私たちはこれを行いたしたが、ナヌザヌは品質に぀いお文句を蚀わなかったように思えたしたが、同時にバッテリヌの消費はずっず少なくなりたした。



WebRTCのオヌディオには、 OPUSたたはG711があり 、通垞はすべおのOPUSが垞に機胜したす。䜕もする必芁はありたせん。



以䞋は、10分間䜿甚した埌の枩床枬定倀です。





さたざたなデバむスをテストしたこずは明らかです。 これはiPhoneの䟋であり、デバむスの枩床が最も䜎いため、OKアプリケヌションはバッテリヌを最も䜿甚したせん。



WebRTCを䜿甚する堎合に有効にできる2番目のこずは、接続が非垞に悪いずきにビデオを自動的にオフにするこずです。





40 Kbps未満の堎合、ビデオはオフになりたす。 接続を䜜成するずきにチェックボックスをオンにするだけで、むンタヌフェむスを介しおしきい倀を蚭定できたす。 開始時の珟圚のビットレヌトの最小倀ず最倧倀を蚭定するこずもできたす。





これは非垞に䟿利です。 接続を確立するずきに、予想しおいるビットレヌトが事前にわかっおいる堎合は、転送するこずができ、通話はそこから開始され、ビットレヌトを調敎する必芁はありたせん。 さらに、チャネルで頻繁にパケット損倱たたは垯域幅の䜎䞋があるこずがわかっおいる堎合は、最倧倀も制限できたす。



WhatsAppは非垞にせっけんのビデオで動䜜したすが、䞊からビットレヌトを積極的に圧瞮するため、わずかな遅延がありたす。



MaxMindを䜿甚しお統蚈を収集し、マッピングしたした。





これは、ロシアのさたざたな地域での通話に䜿甚するおおよその開始品質です。



シグナリング



呌び出しを行う堎合は、ほずんどの堎合、この郚分を蚘述する必芁がありたす。 あらゆる皮類の萜ずし穎がありたす。 芋た目を思い出しおください。





SDPに接続しお亀換するシグナリングを備えたアプリケヌションがあり、以䞋のSDPはWebRTCぞのむンタヌフェヌスです。



これは、単玔なシグナリングがどのようなものかを瀺しおいたす。





アリスはボブに電話したす。 たずえば、Web゜ケット接続を介しお接続したす。 ボブは、携垯電話たたはブラりザぞのプッシュ、たたは䜕らかのオヌプン接続ぞのプッシュを受信し、Web゜ケットを介しお接続し、その埌、電話がポケットで鳎り始めたす。 ボブは電話を取り、アリスは圌のコヌデックず圌女がサポヌトする他のWebRTC機胜を圌に送りたす。 ボブは圌女に同じように答え、その埌、圌らは芋た候補者を亀換したす。 やれやれ



これはすべおかなり長く芋えたす。 たず、Web゜ケット接続を確立するたで、プッシュが発生するたで、その他すべおの操䜜を行うたで、Bobの電話はポケットで鳎りたせん。 アリスはい぀も埅っお、ボブがどこにいるのか、なぜ圌が電話を受け取らないのかを考えたす。 確認埌、すべおに数秒かかりたす。接続が良奜な堎合でも3〜5秒、接続が䞍良な堎合はすべお10です。



これで䜕かをしなければなりたせん あなたはすべおが非垞に簡単にできるこずを教えおくれたす。







アプリケヌションの接続が既に開いおいる堎合は、すぐにプッシュを送信しお接続を確立し、目的のシグナリングサヌバヌに接続しお、すぐに呌び出しを開始できたす。



その埌、別の最適化。 電話がただポケットに鳎っおいお、電話を受け取っおいない堎合でも、サポヌトされおいるコヌデック、倖郚IPアドレスに関する情報を実際に亀換し、空のビデオパケットの送信を開始するこずができたす。 電話を手にしたら、すべおが玠晎らしいものになりたす。



私たちはそうしたしたが、すべおがクヌルであるように芋えたした。 しかし、ありたせん。





最初の問題は、ナヌザヌが頻繁に通話をキャンセルするこずです。 「通話」をクリックしおすぐにキャンセルしたす。 それに応じお、プッシュに電話がかかり、ナヌザヌは姿を消したすむンタヌネットたたは他の䜕かを倱いたした。 その間、誰かの電話が鳎り、圌は電話を取りたすが、圌らはそこで圌を埅っおいたせん。 したがっお、できるだけ早く呌び出しを開始するためのプリミティブな最適化は実際には機胜したせん。





クむックコヌルキャンセルでは、2番目の有害なこずがありたす。 サヌバヌで䌚話のIDを生成する堎合、応答を埅぀必芁がありたす。 ぀たり、呌び出しを䜜成し、IDを取埗し、その埌でのみ、パケットの送信、呌び出しのキャンセルなどのやり取りを行うこずができたす。 これは非垞に悪い話です。応答が到着するたで、クラむアントから䜕も実際にキャンセルできないこずが刀明したためです。 したがっお、GUIDなどの䜕らかのIDをクラむアントで生成し、呌び出しを開始したず蚀うのが最善です。 人々はただ頻繁にこれを行いたす呌ばれ、キャンセルされ、すぐに再び呌び出されたす。 これが混乱しないようにするには、GUIDを実行しお送信したす。





䜕もないように芋えたすが、別の問題がありたす。 ボブに2台の電話がある堎合、たたはブラりザが開いたたたの堎合、パケットを亀換するためのマゞックスキヌム党䜓が、別のデバむスから突然応答した堎合、接続を確立できたせん。



どうする 基本的なシンプルな䜎速信号方匏に戻っお最適化しお、少し前にプッシュを送信したしょう。 ナヌザヌはより高速に接続を開始したすが、これにより数セント節玄できたす。





圌が電話を取り、亀換を始めた埌、最も長い郚分をどうするか





次のこずができたす。 アリスがすでにすべおのコヌデックを知っおおり、ボブの䞡方の電話に送信できるこずは明らかです。 圌女はすべおのIPアドレスを解決し、それらをキュヌに保持するシグナリングに送信するこずもできたすが、クラむアントずの接続を事前に開始できるように、クラむアントには送信したせん。



ボブは䜕ができたすかオファヌを受け取った圌は、そこにあったコヌデックを確認し、独自のコヌデックを生成し、所有しおいるものを曞き、送信するこずもできたす。しかし、ボブには2台の電話があり、コヌデックネゎシ゚ヌションが異なりたす。そのため、シグナリングはそれをすべお保持し、電話を受け取るデバむスを芋぀けるたで順番に埅機したす。圌らの候補者はたた、䞡方のデバむスを生成し、シグナリングに送信したす。



したがっお、シグナリングには、アリスからの1぀のメッセヌゞキュヌず、異なるデバむス䞊のボブからの耇数のメッセヌゞキュヌがありたす。圌はそれをすべお保管し、これらのデバむスの1぀が拟われるずすぐに、圌は既に準備されたパッケヌゞのセット党䜓を単に投げたす。



非垞に高速に動䜜したす。このようなアルゎリズムを䜿甚しお、Google DuoやWhatsAppに䌌た特性に到達したした。





おそらく、もっず良いものを思い぀くこずができたす。たずえば、シグナリング甚ではなく耇数のキュヌを保持し、それらをクラむアントに送信しおから、その番号を発声したすが、ほずんどの堎合、ゲむンは非垞に小さくなりたす。そこで停止するこずにしたした。



他にどんな問題が埅っおいたすか





コヌルバックのようなものがありたす1぀は別のものを呌び出し、他は鳎りたす。圌らが競争しようずしなかったらいいず思いたす-信号レベルで、誰かが2番目に来た堎合、ただ電話を受け入れおすぐに電話をかけるずきにモヌドに切り替える必芁があるずいうコマンドを远加したす。





ネットワヌクが消え、メッセヌゞが倱われるため、すべおがキュヌを介しお行われる必芁がありたす。぀たり、クラむアントにディスパッチキュヌが必芁です。クラむアントから送信したメッセヌゞは、サヌバヌがメッセヌゞを凊理したこずを確認した埌にのみキュヌから削陀する必芁がありたす。サヌバヌには、送信甚のキュヌもあり、確認もありたす。



したがっお、これらはすべお24時間幎䞭無䌑のサヌビスを考慮しお瀟内で実装されおおり、デヌタセンタヌを倱い、゜フトりェアのバヌゞョンを倉曎および曎新できるようにしたいず考えおいたす。





リンク スラむド䞊のビデオぞの蚀及にテキスト版



クラむアントは、Web゜ケットを介しおロヌドバランサヌに接続し、異なるデヌタセンタヌのシグナリングサヌバヌに送信したす。異なるクラむアントは異なるサヌバヌにアクセスできたす。 Zookeeperでは、この遞挙区を管理するシグナリングサヌバヌを定矩するリヌダヌ遞挙を行いたす。サヌバヌがこの䌚話のリヌダヌではない堎合、サヌバヌはすべおのメッセヌゞを別のナヌザヌに送信したす。



次に、分散ストレヌゞを䜿甚したす。Cassandraの䞊にNewSQLがありたす。。䜕を䜿甚するかは問題ではありたせん。どこでも信号を送信しおいるすべおのキュヌの状態を保存しお、信号サヌバヌが消えたり、電源が切れたり、他の䜕かが発生した堎合、リヌダヌ遞挙がZookeeperで動䜜し、リヌダヌになる別のサヌバヌが起動しお、デヌタベヌスからすべおのキュヌを埩元できたすメッセヌゞを送信したす。



アルゎリズムは次のようになりたす。





混同しないように、すべおのパッケヌゞには䞀意の番号が付けられおいたす。



デヌタベヌスの芳点からは、Cassandraのアドオンを䜿甚したす。これにより、デヌタベヌスでトランザクションを行うこずができたすビデオはたさにそれです。



だから、あなたは孊んだ









私達は受け取った





わあ





セキュリティ WebRTCの䞭間者攻撃



WebRTCの䞭間者攻撃に぀いお話したしょう。実際、WebRTCは、1996幎のRTPに基づいおいるずいう点で非垞に難しいプロトコルであり、SDPは1998幎にSIPから来たした。





䞀番䞋の巚倧なリストは、RTP WebRTCを䜜成する倚くのRFCおよびその他のRTP拡匵機胜です。



リストの最初の2぀の興味深いRFC-1぀はパケットに音声レベルを远加し、もう1぀はパケットで音声レベルをオヌプンに送信するこずは安党ではないず述べ、暗号化したす。したがっお、SDPを亀換するずきは、クラむアントがサポヌトする拡匵機胜のセットを知るこずが重芁です。いく぀かの茻茳アルゎリズム、倱われたパケットを回埩するためのいく぀かのアルゎリズム、その他すべおがありたす。



WebRTCの歎史は耇雑でした。最初のドラフトリリヌスは2011幎にリリヌスされ、2013幎にFirefoxはこのプロトコルをサポヌトし、その埌2014 OperaでiOS / Androidでのビルドが開始されたした。䞀般に、それは長幎にわたっお開発されたしたが、それでも1぀の興味深い問題を解決しおいたせん。





アリスずボブがシグナリングに接続するず、このチャネルを䜿甚しお、DTLSハンドシェむクを確立し、接続を保護したす。すべおが玠晎らしいですが、それが私たちの信号ではないこずが刀明した堎合、原則ずしお、真ん䞭の人はアリスずボブの䞡方で「お金を皌ぐ」機䌚があり、すべおのトラフィックをブロックし、そこで起こっおいるこずを盗聎したす。





信頌床の高いサヌビスがある堎合は、もちろん、HTTPS、WSSなどを䜿甚する必芁がありたす。別の興味深い゜リュヌションがありたす-ZRTP、それは、たずえばTelegramによっお䜿甚されたす。



接続が確立されたずきにTelegramで絵文字を芋た人は倚くいたすが、それを䜿甚する人はほずんどいたせん。実際、友人にあなたが持っおいる絵文字を䌝えるず、圌は圌がたったく同じであるこずを確認し、あなたは絶察に安党なP2P接続を保蚌したす。



どのように機胜したすか





これらすべおのプロトコルの内郚では、通垞のDiffie-Hellmanアルゎリズムが最初に䜿甚されたす。アリスはいく぀かの番号を生成し、1぀を陀くすべおをボブに送信したす。たた、ボブは乱数を生成し、それをアリスに送信したす。この亀換の結果ずしお、アリスずボブは特定の倧きなKを取埗したす。これに぀いおは、チャネル党䜓を聞いた䞭間の人は䜕も知らず、たったく掚枬できたせん。



デむブがアリスずボブの間に珟れるず、圌らは圌ず同じ鍵を亀換し、それぞれK 1ずK 2を取埗したす。䞭倮にこの人物の存圚を远跡する方法はありたせん。次に、このようなトリックが適甚されたす。これらのキヌはK 1およびK 2ですアリスずボブは鍵をランダムに生成するため、デむブは間違いなく異なりたす。K 1ずK 2からいく぀かのハッシュを取埗しお、絵文字で衚瀺したす。リンゎ、ナシ、䜕でも、そしお人々は自分が芋た写真を自分の声で呌ぶだけです。音声でお互いを識別でき、これらの写真が異なる堎合は、あなたずあなたの間に誰かがいお、圌があなたを聞いおいるかもしれたせん。



結果









このグラフは、最初にRTMFPの叀い呌び出しがあり、WebRTCに切り替えたずきに小さな障害が発生し、その埌ピヌクが䞊昇するこずを瀺しおいたす。すべおがすぐに機胜したわけではありたせんその結果、保留されるコヌルの数が4倍に増えたした。



簡単な指瀺



これらすべおを必芁ずしない堎合、非垞に簡単な指瀺がありたす。





すべおが鳎りたすが、鳎りはかなり良いです。



報告埌の質問ぞの回答を聞く




HighLoad++ 4-.



, . , 19 (10 9 -) , - . , , .



More articles:


All Articles