Cum Afectează HTTPS Performanța
„S” în HTTPS înseamnă „securizat” și această securitate este asigurată de SSL (alias TLS). Este logic că trebuie să vă securizați site-ul, nu? La urma urmei, există până la 90.000 de atacuri pe site-urile WordPress în fiecare minut.
Dar din anumite motive, există un mit răspândit conform căruia SSL este lent. Că instalarea unui certificat SSL pe site-ul dvs. va introduce prea multe cheltuieli generale și va încetini lucrurile. S-ar putea să fi fost cazul în urmă cu mai bine de un deceniu, dar în 2021, iar căutările Google se fac acum toate prin HTTPS în mod implicit pentru 40.000 de interogări de căutare pe secundă.
De fapt, când Google a trecut la HTTPS pentru toate în mod implicit, gigantul de căutare nu a implementat mașini suplimentare sau hardware special. Inginerul software senior al personalului Adam Langley, care lucrează la infrastructura de servire HTTPS a Google și la rețeaua Chrome, scrie că SSL are un impact limitat asupra performanței web:
Pe serverul nostru front-end de producție, SSL/TLS reprezintă mai puțin de 1% din încărcarea procesorului, mai puțin de 10KB de memorie per conexiune și mai puțin de 2% din supraîncărcarea rețelei.
Dacă Google poate implementa SSL, poți și tu. În plus, trebuie oarecum să – din iulie, când Chrome 68 este lansat, site-urile web care nu folosesc HTTPS vor fi etichetate ca „nesigure” în bara de adrese.
În acest articol, vom arunca o privire asupra modului în care afectează HTTPS performanța site-ului web, precum și câteva sfaturi despre cum puteți îmbunătăți performanța HTTPS pentru site-ul dvs.
Care este Diferența Dintre SSL și TLS?
Dar mai întâi, s-ar putea să vă întrebați care este diferența dintre SSL (Secure Socket Layer) și TLS (Transport Layer Security). Interesant este că nu există nicio diferență.
TLS a fost introdus ca succesor al SSL 3.0 în 1999 și a fost conceput pentru a rezolva nesiguranța protocolului SSL.
Deci, de ce oamenii încă spun SSL în loc de TLS după atâta vreme?
Celor din industria securității le place atât de mult SSL, încât au continuat să folosească acronimul și încă o folosesc până în prezent. Companii precum Comodo nu au schimbat numele certificatelor SSL în certificate TLS. Software-ul care activează SSL pe un server, cum ar fi OpenSSL, nu și-a schimbat numele în OpenTLS. Numele SSL a fost înrădăcinat și pur și simplu blocat.
În ceea ce privește redenumirea protocolului SSL, se pare că a fost mai degrabă din motive politice decât tehnice. Tim Dierks, directorul pentru protecția datelor la Google, scrie că, la mijlocul anilor 90, în timpul războaielor dintre browserele Netscape și Microsoft, au fost implicate multe negocieri în timpul dezvoltării protocolului SSL și – în cele din urmă – conducerea (și proprietatea) standardului:
Ca parte a comerțului cu ,,cai verzi pe pereți’’, a trebuit să facem câteva modificări la SSL 3.0 (astfel încât să nu pară că [Internet Engineering Task Force] IETF doar a marcat protocolul Netscape) și a trebuit să redenumim protocolul (din același motiv). ). Și astfel s-a născut TLS 1.0 (care era într-adevăr SSL 3.1). Și, bineînțeles, acum, în retrospectivă, totul pare o prostie.
Și astfel s-a născut TLS. Dar oricum toată lumea a continuat să spună SSL.
Pentru restul acestei postări, vom folosi SSL și TSL în mod interschimbabil.
HTTP sau HTTPS?
HTTP înseamnă Hypertext Transfer Protocol. Când introduceți o adresă URL în bara de adrese precedată de http://, acesta îi spune browserului să se conecteze la site-ul web prin HTTP. La rândul său, HTTP utilizează protocolul de control al transmisiei (TCP) pentru a trimite și a primi pachete de date pe web pentru a încărca site-ul pe care doriți să îl accesați.
HTTPS înseamnă Hypertext Transfer Protocol Secure. Când introduceți o adresă URL precedată de https://, acesta îi spune browserului să se conecteze prin HTTPS, care folosește și TCP. Dar face acest lucru într-o conexiune criptată de TLS.
Practic, este nevoie de protocolul HTTP și pur și simplu pune un strat de criptare TLS deasupra acestuia. Serverele și clienții comunică în continuare exact același HTTP unul cu celălalt, dar printr-o conexiune TLS sigură care criptează și decriptează cererile și răspunsurile lor.
Stratul SSL are două scopuri principale:
- Acesta verifică că comunicați direct cu serviciul cu care credeți că vorbiți și…
- Se asigură că numai serverul poate citi ceea ce îi trimiteți și numai dvs. puteți citi ceea ce trimite înapoi.
Ceea ce este atât de inteligent la TLS/SSL este că oricine poate intercepta mesajele pe care le schimbați cu un server, inclusiv cele în care sunteți de acord cu cheia și strategia de criptare pe care să le utilizați, dar totuși nu poate citi niciuna dintre datele reale care sunt trimise.
TLS Handshake
Se adaugă o anumită latență atunci când treceți la HTTPS – TLS Handshake inițială necesită două călătorii dus-întors înainte de stabilirea conexiunii, în comparație cu doar una printr-un port HTTP necriptat. Dar, ca și în exemplul Google pe care l-am menționat mai devreme, este minim.
În 2010, Google a introdus False Start, o tehnică care reduce latența unei TLS handshake cu 30%. Dar a abandonat proiectul un an mai târziu pentru că a rămas incompatibil cu un număr mare de site-uri web care foloseau terminatori SSL, care descarcă procesarea SSL de pe servere.
Cu toate acestea, False Start nu este complet mort – încă funcționează pentru site-urile de pe servere care acceptă extensia NPN.
Criptare Asimetric
Există un proces de criptare între browser și server în care fac schimb de informații folosind un proces cunoscut sub numele de criptare asimetrică. Acesta stabilește un canal de comunicații securizat prin care este schimbată o cheie de sesiune, permițând browserului și serverului să treacă la un proces de criptare mai rapid cunoscut sub numele de criptare simetrică.
Criptarea asimetrică este mai lentă decât criptarea simetrică din cauza lungimii mai mari a cheilor primare și a complexității algoritmilor de criptare utilizați. Cu toate acestea, testele între conexiunile criptate și necriptate relevă o diferență de doar 5 ms și o creștere maximă a utilizării CPU de doar 2%. Cu zeci de solicitări paralele și sute de solicitări secvențiale, utilizarea procesorului în timpul testelor nu a depășit niciodată 5%.
Reluarea Sesiunii
Reluarea sesiunii îmbunătățește considerabil performanța TLS prin rechemarea informațiilor dintr-o negociere anterioară de sesiune TLS reușită pentru a ocoli părțile cele mai intense din punct de vedere computațional din negocierea cheii sesiunii TLS.
TLS oferă două mecanisme de reluare a sesiunii: ID-uri de sesiune (unde serverul și clientul își stochează fiecare starea secretă) și biletele de sesiune (unde clientul stochează starea serverului, criptată de server).
În cazul ID-urilor de sesiune, serverul trebuie să țină evidența sesiunilor anterioare care ar putea fi continuate la un moment dat. Acest lucru duce la muncă suplimentară pentru server.
Biletele de sesiune au fost introduse pentru a rezolva problema cache-urilor de server mari. Cu biletele de sesiune, serverul folosește o cheie pentru a cripta informațiile despre sesiune înainte de a le stoca la client. Deci data viitoare când clientul se conectează la server, acesta decriptează și reutilizează informațiile despre sesiune. Aceasta înseamnă că serverul poate relua sesiunile fără a păstra nicio informație și toată încărcarea suplimentară se face pe client.
Reluarea sesiunii folosind bilete de sesiune este o tehnică benefică din mai multe motive – mai puține călătorii dus-întors, mai puține calcule și o fereastră de congestie mai redusă, toate fără a împovăra serverul.
Îmbunătățirea Performanței HTTPS
Desigur, SSL/TLS și HTTPS introduc unele întârzieri ușoare care pot afecta viteza de încărcare a paginii site-ului dvs. Dar întârzierile de viteză sunt atât de marginale încât beneficiile de securitate depășesc orice impact potențial asupra vitezei.
Cu toate acestea, există câteva optimizări de performanță pe care le puteți implementa pe site-ul dvs. după instalarea unui certificat SSL, astfel încât să fie foarte sigur, dar și rapid.
1.HTTP/2
HTTP/2 este o revizuire majoră a protocolului HTTP și încearcă să rezolve multe dintre deficiențele și inflexibilitatea HTTP/1.1. Beneficiile și caracteristicile sale includ:
- Multiplexare și concurență: Mai multe solicitări pot fi trimise în succesiune rapidă pe aceeași conexiune TCP, iar răspunsurile pot fi primite neîntrerupt.
- Comprimarea antetului: Dimensiunea antetului HTTP este redusă drastic.
- Dependențe de flux: Clientul poate indica serverului care dintre resurse sunt mai importante decât celelalte.
- Server push: Serverul poate trimite resurse pe care clientul nu le-a solicitat încă, evitând întârzierile.
KeyCDN are un excelent instrument gratuit de testare HTTP/2 dacă doriți să verificați dacă serverul sau CDN-ul dvs. acceptă HTTP/2.
2.Compresia Brotli
Brotli este un algoritm de compresie fără pierderi open source dezvoltat de Google ca alternativă la Gzip, Zopfli și Deflate care reduce consumul de lățime de bandă și ajută la încărcarea mai rapidă a conținutului.
Potrivit unui studiu de caz Google, formatul atinge rate de compresie cu 20–26% mai mari decât Zopfli, cu o utilizare mai mică a procesorului.
Pentru a utiliza Brotli, atât clientul, cât și serverul trebuie să fie compatibil cu Brotli și să ruleze printr-o conexiune HTTPS pentru a-l utiliza.
Puteți testa dacă serverul sau CDN-ul dvs. acceptă Brotli folosind instrumentul gratuit de testare KeyCDN.
3.Compresie HPACK
Site-urile care folosesc HTTP/2 pot profita la maximum de compresia HPACK. Această tehnologie folosește codarea Huffman pentru a obține o reducere medie de 30% a dimensiunii antetului.
Există trei avantaje principale ale utilizării HPACK:
- Este rezistent la atacurile bazate pe compresie, cum ar fi CRIME (Compression Ratio Info-leak Made Easy),
- Capacitatea sa de a codifica anteturi mari folosind codificare Huffman fixă și…
- Este capacitatea de a codifica antetele utilizate în mod obișnuit ca un număr întreg de lungime variabilă, spre deosebire de retrimiterea întregului antet de fiecare dată.
4.Capsare OCSP
Capsarea OCSP este o metodă pentru a determina rapid dacă un certificat SSL este sau nu valid. Permite unui server să furnizeze informații despre valabilitatea propriilor certificate, mai degrabă decât să fie nevoit să solicite informațiile de la furnizorul certificatului. Acest lucru asigură siguranța și confidențialitatea datelor confidențiale și elimină necesitatea ca clientul să contacteze autoritatea de certificare, reducând o altă solicitare.
Pentru a activa capsarea OCSP pe serverul dvs., consultați instrucțiunile detaliate ale DigiCert.
5.Utilizați un CDN
Deși este posibil să nu puteți face pachetele dvs. să călătorească mai repede, este posibil să le faceți să călătorească pe o distanță mai mică. Utilizarea unui CDN poate reduce semnificativ timpul de călătorie dus-întors și costurile totale ale TLS handshakes și TCP.
Permițând utilizatorului să își încheie conexiunea cu un server edge din apropiere, în loc să traverseze țări și oceane până la originea dvs., clientul beneficiază de „încetarea timpurie” cu călătorii dus-întors mai scurte.
Utilizarea rezilierii anticipate este la fel de utilă pentru conținutul static și dinamic: în timp ce conținutul static poate fi stocat în cache și servit de serverele edge, cererile dinamice pot fi direcționate prin conexiuni stabilite de la serverele edge la origine.
Concluzie
Da, este adevărat că SSL poate afecta performanța site-ului dvs. Dar eforturile sale sunt atât de minore încât economisirea de câteva milisecunde nu va depăși nivelul crescut de securitate pe care îl oferă SSL.
Cu HTTP/2, HTTPS devine doar mai rapid, astfel încât orice impact asupra performanței pe care SSL îl adaugă conexiunilor scade rapid.
Încercați asta: test HTTP vs HTTPS. Acest site oferă o comparație vizuală a timpilor de încărcare pentru versiunile HTTP nesecurizate și HTTPS HTTP/s criptate ale aceleiași pagini. Rezultatele vorbesc de la sine.
