Nachdem Sie die vorherigen Teile angedeutet haben, sollten Sie ein allgemeines Verständnis des Prozesses der P2P-Audio- und -Video-Interaktion haben.Sie haben vielleicht das Gefühl, dass der Prozess umständlich ist und sogar die unterste Schicht des Netzwerks betrifft. Aber keine Sorge, WebRTC hat viel für uns getan und es uns leicht gemacht, Audio und Video zu entwickeln. Was genau ist WebRTC?
WebRTC (Web Real-Time Communications) ist eine Echtzeit-Kommunikationstechnologie, die es Netzwerkanwendungen oder Websites ermöglicht, eine Peer-to-Peer-Verbindung (Peer-to-Peer) zwischen Browsern ohne Zwischenhändler herzustellen, um Videostreaming und/oder -übertragung zu erreichen von Audiostreams oder anderen beliebigen Daten. Diese in WebRTC enthaltenen Standards ermöglichen es Benutzern, Peer-to-Peer (Peer-to-Peer)-Datenaustausch und Telefonkonferenzen zu erstellen, ohne Plug-Ins oder Software von Drittanbietern zu installieren.
WebRTC ist nicht die Originaltechnologie von Google. Im Jahr 2010 erwarb Google den VoIP-Softwareentwickler Global IP Solutions für etwa 68,2 Millionen US-Dollar und erwarb damit die WebRTC-Technologie des Unternehmens. Heutzutage sind Audio- und Videokommunikationsdiensttechnologien des Internets im Allgemeinen proprietäre Technologien, wie z. B. Skype , die Plug-Ins oder Desktop-Clients installieren müssen, um Kommunikationsfunktionen zu realisieren. Google hofft, dass Webentwickler Video- oder Voice-Chat-Anwendungen direkt im Browser erstellen können. Global IP Solutions hat zuvor WebRTC-basierte mobile Clients für Android, Windows Mobile und iPhone produziert. Google hat WebRTC dieses Mal zu Open Source gemacht, in der Hoffnung, dass Browserhersteller die Technologie direkt in den Browser einbetten können, um Webentwicklern die Arbeit zu erleichtern.
Konzeptergänzung
Lassen Sie mich zusätzlich zu den zuvor erwähnten Konzepten einige verwandte Konzepte hinzufügen
interaktive Link-Möglichkeit
Interactive Connectivity Establishment (ICE): Ein Protokollrahmen, der es Ihrem Browser ermöglicht, eine Verbindung mit einem Peer-Browser herzustellen. In einem realen Netzwerk gibt es viele Gründe, warum eine einfache Direktverbindung von A nach B nicht wie gewünscht hergestellt werden kann. Dazu müssen Sie die Firewall umgehen, die den Verbindungsaufbau verhindert, Ihrem Gerät eine eindeutig sichtbare Adresse zuweisen (normalerweise haben die meisten unserer Geräte keine feste öffentliche Netzwerkadresse) und, wenn der Router dem Host keine direkte Verbindung zulässt, Sie muss ein Der Server leitet die Daten weiter. Vielleicht haben Sie festgestellt, dass dieser ICE eine Zusammenfassung unserer bisherigen Verbindungsmethoden wie STUN und TURN darstellt. Formal wird unsere Entwicklungsarbeit durch das ICE-Framework stark vereinfacht, und ICE wählt automatisch die Verbindungsmethode entsprechend der Priorität aus;
Signalserver
Signalserver (Signalserver): Tauschen Sie die Kommunikationsadressen zwischen Peers aus, nachdem Sie ihre eigenen Kommunikationsadressen über STUN erhalten haben, registrieren Sie sich auf dem Signalisierungsserver, um Kommunikationsadressen zwischen Geräten auszutauschen, und stellen Sie so die P2P-Verbindung her;
Sitzungsbeschreibungsprotokoll
Sitzungsbeschreibungsprotokoll (Session Description Protocol, SDP): Ein Protokoll, das den Inhalt einer Multimedia-Verbindung beschreibt, z. B. Auflösung, Format, Kodierung, Verschlüsselungsalgorithmus usw. Vor dem Start einer P2P-Verbindung muss ein Sitzungsprotokoll ausgehandelt werden, das von beiden Parteien unterstützt wird. Wenn ein Benutzer einen WebRTC-Anruf an einen anderen Benutzer initiiert, wird eine spezifische Beschreibung namens Angebot erstellt . Die Beschreibung enthält alle Informationen über die vom Anrufer vorgeschlagene Anrufkonfiguration. Der Empfänger antwortet dann mit einer Antwort, die seine Beschreibung des Endes des Anrufs darstellt. Auf diese Weise teilen sich zwei Geräte die zum Austausch von Mediendaten benötigten Informationen, ein SDP beschreibt den Inhalt so („There can no space on both pages“)
v=0
o=- 212360934117607227 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
a=rtpmap:111 opus/48000/2
......
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116
a=rtpmap:96 VP8/90000
......
Eine SDP-Beschreibung besteht aus einer Sitzung und mehreren Medienbeschreibungen. Die Sitzungsbeschreibung geht von v= bis zur ersten Medienbeschreibung (1-4 Zeilen) und die Medienbeschreibung geht von m= bis zur nächsten Medienbeschreibung (5-6 Zeilen— - Audio, Zeilen 8-9 - Video).
Beschreibung auf Sitzungsebene
Es gibt viele Sitzungsbeschreibungsfelder, die wichtigsten sind 4 Felder
- v=: UDP-Versionsnummer, ohne die Nebenversion* o=: eine Beschreibung des Sitzungsinitiators > o=*
<username>: Benutzername, wenn Ihnen der Benutzername egal ist, können Sie stattdessen „-“ verwenden; *<session id>: Zahlenfolge, muss in der gesamten Sitzung eindeutig sein, und es wird empfohlen, NTP-Zeitstempel zu verwenden; *<version>: Versionsnummer, der Versionswert wird jedes Mal erhöht, wenn die Sitzungsdaten geändert werden; *<network type>: Netzwerktyp, im Allgemeinen "IN", was "Internet" bedeutet; *<address type>: Adresstyp, normalerweise IP4; *<address>: IP-Adresse - Sitzungsname: Gibt eine Sitzung an * t=: Beschreibung der Start- und Endzeit
t=<start time> <stop time>, Wenn beide Ereignisse 0 sind, bedeutet dies eine dauerhafte Sitzung ##### SDP in WebRTC
Unter WebRTC wurden einige Modifikationen an SDP vorgenommen, und einige andere Beschreibungen wurden auf der Grundlage des Originals hinzugefügt
// 音频使用9端口收发;
// UDP / TLS / RTP / SAVPF 表示使用 dtls / srtp 协议对数据加密传输;
m = audio 9 UDP / TLS / RTP / SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
// 网络描述, webRTC不使用
c = IN IP4 0.0.0.0
// 设置rtcp地址和端口, webRTC不使用
a = rtcp: 9 IN IP4 0.0.0.0
// 安全验证信息
a=ice-ufrag:duP8
a=ice-pwd:/7pIrSvgESATKPZUVzHhLQ0E
a=ice-options:trickle
// 音频流媒体描述
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
Medienbeschreibung
- m=: Gibt eine Sitzung an,
m=<media> <port> <transport> <fmt list>*<media>: Medientyp, wie Audio/Video usw.; *<port>: Port; *<transport>: Transportprotokoll, es gibt zwei Arten – RTP/AVP und UDP; *<fmt list>: Medienformat, d Liste des Datennutzlasttyps (Nutzlasttyp). - a=*:
a=<type>odera=<type>:<value>, type hat zwei Typen rtpmap und fmap
Lassen Sie uns nun das schematische Diagramm des vorherigen Gateways verbessern und hier einige Konzepte hinzufügen
Sammeln Sie Kandidatenadressen
Die sogenannte Sammlung von Kandidatenadressen soll ihre eigene kommunizierbare Adresse durch den zuvor erwähnten STUN-Server erhalten.
| Arten von | alias | So senden Sie an Peer | Verwendung |
|---|---|---|---|
| Host-Kandidaten | Gastgeber | Signalserver | Die von der Netzwerkkarte erhaltene lokale Transportadresse, wenn diese Adresse hinter NAT steht, ist es die Intranetadresse |
| Serverreflexionskandidaten | srfx | Signalserver | Die aus der Bindungsprüfung erhaltene Transportadresse, die an den Stun-Server gesendet wurde. Wenn diese Adresse hinter NAT steht, ist es die öffentliche Netzwerkadresse des äußersten NAT |
| Peer-Reflexionskandidaten | prflx | Betäubungsbindungsanfrage | Die Transportadresse, die aus der vom Peer gesendeten Stun-Bindungsanforderung erhalten wurde. Dies ist ein neuer Kandidatentyp, der bei Konnektivitätsprüfungen auftritt |
| Staffelkandidaten | Relais | Signalserver | Die Transportadresse des Media-Relay-Servers. Erworben durch Verwendung der TURN-Allocate-Anfrage |
Kandidatenadressen austauschen
A sendet die im ersten Schritt gesammelte Kandidatenadresse über den Signalisierungsserver an B, und B sendet die gesammelte Kandidatenadresse ebenfalls an A. Nachdem A alle Kandidatenadressen von B erhalten hat, vergleicht A seine eigene Kandidatenadresse mit der Peer-Kandidatenadresse Perform eine vollständige Anordnung und speichern sie in der Zustandstabelle. Beispielsweise ist der Host von A zu diesem Zeitpunkt 192.168.0.100:60000, srflx ist 11.102.30.3:30110, der Host von B ist 192.168.0.15:10001, srflx ist 1.10.108.25:30110, die Statustabelle lautet wie folgt
| Adresse der lokalen Netzwerkkarte | Peer-Adresse | Zustand |
|---|---|---|
| 192.168.1.105:60001 | 192.168.0.204:40001 | Betäubungstest nicht durchgeführt |
| 172.16.40.6:60003 | 192.168.0.204:40001 | Betäubungstest nicht durchgeführt |
| 192.168.1.105:60001 | 11.92.14.8:50002 | Betäubungstest nicht durchgeführt |
| 172.16.40.6:60003 | 11.92.14.8:50002 | Betäubungstest nicht durchgeführt |
| 192.168.1.105:60001 | 192.168.0.181:40003 | Betäubungstest nicht durchgeführt |
| 172.16.40.6:60003 | 192.168.0.181:40003 | Betäubungstest nicht durchgeführt |
Zu diesem Zeitpunkt werden nicht alle Aufzeichnungsstatus STUN-geprüft, und die STUN-Prüfung jeder Aufzeichnung wird im nächsten Schritt ausgeführt.
STUN-Check
Wir haben den STUN-Inspektionsprozess bereits eingeführt, wenn Sie ihn vergessen, können Sie das p2p-Lochstanzen überprüfen
Verbinden, Bootmedium
Nachdem die STUN-Prüfung abgeschlossen ist, wird die Verbindung vorbereitet. Zu diesem Zeitpunkt hat die Statustabelle im P2PTransportChannel die Kosten für jeden Datensatz aufgezeichnet (unter Einbeziehung vieler Faktoren, wie z. .).
**Wenn Video-RTP-Daten zu senden sind, überprüfen Sie den ersten Datensatz in der Statustabelle, wenn beurteilt wird, dass sein Status zum Senden bereit ist, wird diese Verbindung zum Senden verwendet. Andernfalls geben Sie den Sendeauftrag direkt auf. **Das heißt, die Aufgabe des Medienmoduls wird nicht vom Verbindungsstatus beeinflusst, es überprüft nur den Status, wenn es senden möchte, und gibt das Senden auf, wenn es nicht verbunden ist.
Um sicherzustellen, dass NAT-Zuordnungs- und Filterregeln während einer Mediensitzung nicht ablaufen, sendet ICE kontinuierlich Stun-Verbindungsprüfungen gegen in Gebrauch befindliche Kandidaten. Laienhaft ausgedrückt handelt es sich um „Polling". Wenn die STUN-Antwortzeit abläuft, werden die Kosten erhöht, was sich in der Statustabelle widerspiegelt, da die Priorität reduziert wird, das heißt, die P2PTransportChannel-Statustabelle ist in Echtzeit.
Zu guter Letzt
Organisierte 75 JS-Hochfrequenz-Interviewfragen und gab Antworten und Analysen, die im Grunde garantieren können, dass Sie mit den Fragen des Interviewers zu JS fertig werden.
Freunde in Not, Sie können auf die Karte unten klicken, um sie kostenlos zu erhalten und zu teilen