Facultatea de Automatica si Calculatoare,

Universitatea Politehnica din Bucuresti

Protocolul WebSocket

Stan Alexandra 331AC

2018
Introducere
Protocolul “WebSocket” permite comunicarea full-duplex, in ambele
sensuri, intre un client catre o gazda la distanța, intr-un mediu controlat.

Scopul acestei tehnologii este de a oferi un mecanism pentru aplicatiile

browser-based care necesita o comunicație in ambele sensuri cu
serverele si care nu se bazeaza pe deschiderea mai multor conexiuni
HTTP.

Din punct de vedere istoric, crearea aplicaților web care necesita o

conexiune full-duplex între un client și un server (de exemplu, aplicații
de mesagerie și aplicati joc) a necesitat un abuz de HTTP pentru a
interoga serverul de mai multe ori pentru actualizari, în timp ce
trimiterea notificari ca apeluri HTTP.

Acesta duce la o varietate de probleme:

1. Serverul este fortat sa utilizeze , pentru fiecare client, o serie de

conexiuni TCP: unul pentru trimiterea mesajului catre client, si o
noua conexiune pentru receptionarea mesajului.
2. Fiecare mesaj, client catre server, are un HTTP header.
3. Scriptul clientului este obligat sa mentina o mapare din conexiunile
de iesire catre conexiunile de intrare pentru a urmari raspunsurile.

O solutie simpla ar fi folosirea unei singure conexiuni TCP pentru trafic

in ambele sensuri. Acesta este cea ce ofera Protocolul WebSocket. In
combinatie cu WebSocket API, ofera o alternative la interogarea HTTP
pentru comunicatii full-duplex de la o pagina web catre un server la
distanta. Aceeasi tehnica poate fi utilizatapentru o varietate de aplicații
web: jocuri, aplicații multiuser cu editare simultana, real-time user
interfaces etc.
Protocolul are 2 parti: un handshake si transferul de date.

Handshake
Handshake-ul de la client :

GET /chat HTTP/1.1

Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Handshake-ul de la server:

HTTP/1.1 101 Switching Protocols

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

“Opening handshake” trebuie sa fie compatibil cu soft-ul server-side

bazat pe HTTP, astfel incat un singur port sa fie utilizat de clienții HTTP
care vorbesc cu serverul, cat și cu clienții WebSocket care vorbesc cu
serverul respectiv. Handshake-ul clientului WebSocket este un HTTP
Upgrade request:

GET /chat HTTP/1.1

Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
“Closing handshake” este o procedura mai simpla decat “opening
handshake”. Fiecare parte trimite un cadru de control cu date care contin
o secventa de control pentru a incepe procedura de “closing
handshake”.La receptionarea unui astel de cadru, partea cealalta trimite
un Close frame, daca nu a fost trimis deja.
Dupa trimiterea acestui cadru de control care indica faptul ca conexiunea
trebuie inchisa, aceasta parte nu trebuie sa trimita date suplimentare.
Dupa primirea cadrului de control indicand ca conexiunea trebuie
deschisa, cealalta parte ignora toate datele suplimentare primite. Este
mai sigur ca ambele parti sa initializeze acest “handshake” simultan.

Transferul de date
O data ce clientul si serverul au “trimis” handshake, si daca acest proces
s-a realizat cu success, atunci incepe transferul de date pe un canal de
comunicatie full-duplex care fiecare poate sa trimita date. Un mesaj este
compus din unul sau mai multe cadre. Mesajul WebSocket nu
corespunde neaparat unei incadrari specifice a unui strat de rețea,
deoarece un mesaj fragmentat poate fi coalizat sau împarțit de un
intermediar.
Legatura cu TCP
Conceptual, WebSocket este doar un strat pe partea de sus a TCP care
face urmatoarele:
1. Adauga un model de Securitate web pentru browsere.
2. Adauga un mecanism de adresare și denumire de protocol pentru a
suporta mai multe servicii pe un port și mai multe nume de gazda
pe o singura adresa IP.
3. Include o banda suplimentara de “closing handshake” care este
proiectata sa functioneze in prezența proxy-urilor si a altor
intermediari.

Protocolul WebSocket este un protocol TCP independent. Singura ei

relație cu HTTP este ca“handshake” este interpretat de serverele HTTP
ca o solicitare de upgrade (Upgrade request).
Implicit, protocolul WebSocket utilizeaza portul 80 pentru conexiunile
WebSocket obisnuite și portul 443 pentru conexiunile WebSocket tunel
atepe Transport Layer Security (TLS).

Cand un client deschide o conexiuneWebSocket, acesta trimite partea sa

de “opening handshake”. Serverul trebuie sa analizeze cel puțin o parte
din acest handshake pentru a obtine informatiile necesare pentru a
genera handshake-ul de server.
Daca serverul constata ca clientul nu a trimis un “handshake” care
corespunde de desrierii de mai jos, opreste procesarea “handshake-ului”
si returneze un raspuns HTTP cu un cod de eroare adecvat.
 Un HTTP/1.1 sau GET request mai mare, care include un "Request-
URI" care trebuie interpretat ca un /resource name/.
 Un antet |Host| header care contine autoritatea serverului.
  Un antet |Upgrade| header care contine valoarea"websocket",
tratat ca o valoare ASCII case-insensitive.
 Un antet |Connection| header care include token-ul "Upgrade",
tratat ca o valoare ASCII case-insensitive.
 Un antet |Sec-WebSocket-Key| header cu o valoare base64-encoded
care cand este decodificat are lungime 16 bytes.
 Un antet |Sec-WebSocket-Version| header, cu valoarea 13.
 Optional, un antet |Origin| header. Acest antet este trimis de toti
client browser.
 Optional, un antet |Sec-WebSocket-Protocol| header, cu o lista de
valori care indica ce protocale ar dori clientul sa foloseasca,
ordonati dupa preferinta.
 Optional, un antet |Sec-WebSocket-Extensions| header,cu o lista de
valori care indica ce extensii ar dori clientul sa foloseasca.

Cadre de control
Cadre de control (Control frames) sunt identificati de opcoduri unde cel
mai significativ bit este 1.
Opcode definite includ:
1. 0x8 (Close)
2. 0x9 (Ping)
3. 0xA (Pong).
Cadrele de control sunt folosite pentru a comunica starea WebSocket-
ului.
Toate cadrele trebuie sa aiba un payload maxim de 125 bytes si nu
trebuie fragmentata.
Close Frame.
Cadrul de inchidere( Close Frame) contine un opcode de 0x8.

Poate sa contina portiunea de “Application Data” a cadrului, care indica

un motiv pentru inchidere. Daca exista aceasta portiune atunci primii 2
octeti ai corpului trebuie sa fie un numar intreg fara semn de 2 octeti
reprezentand un cod de valoare.

Pe langa numarului de 2 bytes, portiunea poate sa contina si date codate

cu UTF-8, care nu este neaparat human readable.

Ping Frame
Cadrul Ping ( Ping Frame) contine un opcode de 0x9.
Cadrul poate sa include si “Application Data”.
La primirea unui cadru Pong, un punct final trebuie sa trimita un raspuns
la Pong, cu excepția cazului in care acesta a primit deja un cadru Close. Ar
trebui sa raspunda cu un cadru Pong cat mai curand posibil.

Pong Frame
Cadrul Pong (Pong Frame) contine un opcode de 0xA.
Un cadru Pong trimis ca raspuns la un cadru Ping trebuie sa aiba acelasi
camp "Application Data" la fel ca si in corpul de mesaje al cadrului Pong
caruia i s-a raspuns.
Daca un punct final primeste un cadru Ping si nu a trimis in
cacadrul/cadrelede pong ca raspuns la cadrele anterioare de ping,
punctul final poate alege sa trimita un cadru Pong doar pentru cel mai
recent procesat cadru Ping. Un cadru Pong POATE fi trimis nesolicitat.
Aceasta serveste ca o bataie de inima unidirectionale. Nu este de asteptat
un raspuns la un cadru Pong nesolicitat.

Trimitera datelor
Pentru a trimite un mesaj folosind o Conexiune WebSocket, un endpoint
trebuie sa efectueze urmatorii pasi:
1. Endpoint trubuie sa se asigure ca conexiunea WebSocket se afla in
starea Deschis (OPEN state). Daca la un moment dat starea se
schimba, endpoint trebuie sa intrerupa pasii urmatori.

2. Un endpoint trebuie sa incapsuleze /date/ intr-un

cadruWebSocket, daca datele care trebuie trimise sunt foarte mari.

3. Opcode-ul (Frame-Opcode) al primului cadru care contin datele,

TREBUIE sa fie setat la valoarea corespunzatoare, pentru datele
care urmeaza sa fie interpretate de catre destinatar ca text sau date
binare

4. Bitul FIN (Frame-FIN) al ultimului cadru care contine datele

TREBUIE setat la 1.

5. Daca clientul este cel care trimite date, cadrele trebuie sa fie
mascate.

6. Cadrul/Cadrele care au fost formate, trebuie sa fie transmise prin

conexiunea
Underlying Network.
Receptionarea datelor
Pentru a primi date WebSocket, un endpoint asculta conexiunea din
retea. Datele trebuie sa fie parsate in cadrul WebSocket. Daca un cadru
de control este receptionat atunci trebuie sa fie “manipulate”. La
primirea unui cadru de date, endpoint trebuie sa noteze tipul /type/
mesajului, cum este definit de opcode(frame-opcode).
“Application data” a acestui cadru este definit ca /data/ mesajului.
Daca cadrul cuprinde un mesaj nefragmentat, se spune ca “_A WebSocket
Message Has Been Received_” cu tipul /type/ si mesajul /data/.
Daca cadrul face parte dintr-un mesaj fragmentat atunci “Application
data” ale cadrelor de date ulterioare sunt concatenate pentru a forma
/data/.
Cand ultimul fragment este primit asa cum este indicat de FIN bit, se
spune ca “_A WebSocket Message Has Been Received_” cu mesaj /date/ si
tipul /type/.
Bibliografie
https://tools.ietf.org/html/ rfc8307