Folosești WhatsApp? Dar Facebook Messenger, poate Hangouts, de Skype măcar ai auzit. Toate aceste servicii de comunicații folosesc tehnologia WebRTC. De ce? Pentru că nu te forțează să instalezi pluginuri sau software suplimentar și pentru că permite o mai bună omogenitate a părților ce permit un serviciu coerent.
Te vei intreba pe bună dreptate, de ce să adâncim studiul la nivelul de transport, când pe noi ne-ar interesa o perspectivă arhitecturală asupra blochainului și IPFS în special. Răspunsul vine din necesitatea de a înțelege felul în care sunt „traversate” barierele tehnice și de securitate care se ivesc la stabilirea unui canal de comunicare securizat între două noduri care doresc să schimbe date între ele. Și dacă tot nu ești convins, poate că a înțelege câștigul unei comunicări dincolo de limitările arhitecturale ale Internetului actual va produce scânteia de entuziasm ce va alimenta curiozitatea să muști din prăjiturica de mai jos. Deci, să purcedem către WebRTC.
WebRTC vine de la Web Real Time Communication. WebRTC înseamnă comunicare video, audio și date în timp real. Chiar de curând, pe 2 noiembrie, 2017, W3C a lansat prima versiune a recomandării pentru standardizarea API-ului JavaScript pentru WebRTC (WebRTC becomes design-complete strengthening the Web Platform as a solid actor in the telecommunications arena). În acest moment API-ul poate fi considerat a fi unul stabil după un efort de fixare ce a durat aproape șase ani.
WebRTC vine cu trei API-uri importante:
- mediastream-erul (
getUserMedia()) - RTCPeerConnection
- RTCDataChannel
Conexiunea dintre două noduri se realizează folosind interfața RTCPeerConnection care reprezintă o conexiune dintre un computer local și un partener la distanță. În momentul în care se stabilește comunicarea și este deschisă, streamurile media (MediaStreams) și / sau canale de date (RTCDataChannels) pot fi adăugate la conexiune.
În sine, interfața RTCDataChannel reprezintă un canal în rețeaua de computere care poate fi utilizată bidirecțional ca peer-to-peer pentru a schimba date. Fiecare conexiune stabilită poate avea un maxim de 65.534 de canale.
Ceea ce ne interesează în mod deosebit, nu este partea de audio sau de video, ci zona de transport pentru date. WebRTC folosește următoarele standarde pentru a realiza o conexiune securizată:
- SRTP - Secure Real-time Transport Protocol. Acest standard asigură criptarea canalului.
- Multiplexarea, o metodă de combinare a mai multor semnale analoge sau digitale într-unul singur.
- STUN - Session Traversal Utilities for NAT, fiind un set de metode pentru a comunica dincolo de gateway-urile întâlnite la stabilirea unui canal prin „travestarea” NAT-urile (network address translator). STUN este folosit de ICE - Interactive Connectivity Establishment
- ICE - Interactive Connectivity Establishment este o tehnică folosită pentru a realiza comunicarea peer-to-peer. Acesta este un protocol care descrie traversarea prin NAT-uri folosind STUN și extensia sa TURN - Traversal Using Relay NAT
Protocolul STUN este extins de TURN și este folosit de ICE pentru a permite traversarea NAT-urilor de către API-ul RTCPeerConnection. Trebuie înțeles faptul că doi clienți pentru a se găsi pe Internet, au nevoie de a se semnaliza reciproc pentru a stabili o legătură peer-to-peer. În acest sens, cel mai ades se apelează la un server pe Internet, care are rolul de a prelua aceste semnale și de a coordona contactul inițial. Legăturile care se stabilesc sunt securizate prin criptare, fiind folosit standardul SSL - Secure Socket Layer.
În acest moment WebRTC are suport în toate browserele, mai puțin Safari, iar dacă abordările sunt diferite în felul în care este implementată stiva de protocoale, Google întreține un „adaptor” universal, ceea ce în jargonul tehnic se numește „shim”. Numele este „adapter.js” și recomand încărcarea shim-ului înainte de a lucra cu această stivă de tehnologii. Odată cu lansarea versiunii 1.0 a Recomandării W3C, rolul acestei biblioteci de cod cu rol de adaptor va scădea pe măsură ce browserele vor uniformiza propriile implementări.