Habr, hallo! Dies ist eine Transkription des Berichts von Artyom ximaera Gavrichenkov, den er auf der BackendConf 2018 im Rahmen des RIT ++ Festivals las.
- Guten Tag!
Der Titel des Berichts enthält eine lange Liste von Protokollen. Wir werden sie schrittweise durchgehen, aber beginnen wir mit dem, was nicht im Titel enthalten ist.
Diese (unter dem Schnitt) Überschrift eines der Blogs, im Internet konnte man viele solcher Überschriften sehen. In diesem Beitrag steht geschrieben, dass HTTP / 2 keine ferne Zukunft ist, sondern unsere Gegenwart. Dies ist ein modernes Protokoll, das von Google und Hunderten von Fachleuten aus vielen fortgeschrittenen Unternehmen entwickelt wurde und von der IETF bereits 2015, also bereits vor drei Jahren, als RFC veröffentlicht wurde.
IETF-Standards werden von der Industrie akzeptiert, beispielsweise Stahlbetondokumente wie Grabsteine.
Es ist geplant, dass sie die Entwicklung des Internets bestimmen und alle möglichen Nutzungsszenarien berücksichtigen. Das heißt, wenn wir eine alte Version des Protokolls hatten und dann eine neue erschien, dann behält es definitiv die Kompatibilität mit allen vorherigen Benutzerfällen bei und löst zusätzlich eine Reihe von Problemen, optimiert die Arbeit und so weiter.
HTTP / 2 musste für das erweiterte Web angepasst werden und für den Einsatz in modernen Diensten und Anwendungen bereit sein. Tatsächlich sollte es
ein Ersatz für ältere Versionen des HTTP-Protokolls sein. Es sollte die Leistung der Site steigern und gleichzeitig die Backend-Last reduzieren.
Sogar die SEOs sagten, sie brauchten HTTP / 2.
Und es schien sehr einfach zu unterstützen. Insbesondere Neil Craig von der BBC schrieb in seinem Blog, dass es ausreiche, es nur auf dem Server zu aktivieren. Es gibt immer noch viele Präsentationen, in denen angegeben ist, dass HTTP / 2 wie folgt enthalten ist: Wenn Sie über Nginx verfügen, können Sie die Konfiguration an einer Stelle korrigieren. Wenn kein HTTPS vorhanden ist, müssen Sie zusätzlich ein Zertifikat erstellen. Im Prinzip handelt es sich jedoch um ein Token in der Konfigurationsdatei.
Und natürlich erhalten Sie nach der Registrierung dieses Tokens sofort Boni aus höherer Produktivität, neuen verfügbaren Funktionen und Möglichkeiten - im Allgemeinen wird alles wunderbar.
Links von der Folie:
1. medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
2. www.cloudflare.com/website-optimization/http2Die weitere Geschichte basiert auf realen Ereignissen. Das Unternehmen verfügt über einen Onlinedienst, der etwa 500 bis 1000 HTTP-Anforderungen pro Sekunde verarbeitet. Dieser Dienst steht unter dem DDoS-Schutz von Cloudflare.
Es gibt viele Benchmarks, die bestätigen, dass das Umschalten auf HTTP / 2 die Belastung des Servers verringert, da der Browser beim Umschalten auf HTTP / 2 nicht 7 Verbindungen herstellt, sondern eine gemäß Plan. Es wurde erwartet, dass beim Umschalten auf HTTP / 2 weniger Speicher verwendet wird und der Prozessor weniger belastet wird.
Das Cloudflare-Blog und die Cloudflare-Website schlagen außerdem vor, HTTP / 2 mit nur einem Klick zu aktivieren. Frage: Warum nicht?
Am 1. Februar 2018 enthält das Unternehmen HTTP / 2 mit dieser Schaltfläche in Cloudflare und in lokalem Nginx auch. Monatsdaten werden gesammelt. Am 1. März werden die verbrauchten Ressourcen gemessen, und dann überprüft Sysops die Anzahl der Anforderungen in den Protokollen, die über HTTP / 2 an den Server hinter Cloudflare gesendet werden. Die nächste Folie gibt den Prozentsatz der Anforderungen an, die über HTTP / 2 an den Server gesendet wurden. Heben Sie Ihre Hände, wer weiß, wie hoch dieser Prozentsatz sein wird?
[Aus dem Publikum: "1-2%!"]
- Null. Aus welchem Grund?
Cloudflare sowie andere Angriffsschutzdienste, MSSP- und Cloud-Dienste arbeiten im
Reverse-Proxy- Modus. Wenn der Browser in einer normalen Situation direkt eine Verbindung zu Ihrem Nginx herstellt, dh die Verbindung direkt vom Browser zu Ihrem HTTP-Server hergestellt wird, können Sie das vom Browser unterstützte Protokoll verwenden.
Wenn sich zwischen dem Browser und Ihrem Server eine Cloud befindet, die eingehende TCP-Verbindung in der Cloud beendet wird, TLS auch dort beendet wird und die HTTP-Anforderung zuerst in die Cloud geht, verarbeitet die Cloud diese Anforderung tatsächlich.
Die Cloud verfügt über einen eigenen HTTP-Server, in den meisten Fällen denselben Nginx-Server. In seltenen Fällen handelt es sich um einen "selbstgeschriebenen" Server. Dieser Server analysiert die Anforderung, verarbeitet sie irgendwie, konsultiert Caches und bildet schließlich eine neue Anforderung und sendet sie bereits mit dem von ihm unterstützten Protokoll an Ihren Server.
Alle vorhandenen Clouds, die behaupten, HTTP / 2 zu unterstützen, unterstützen HTTP / 2 auf der Seite des Browsers. Aber unterstütze ihn nicht auf der Seite, die zu dir schaut.
Warum?
Eine einfache und nicht ganz richtige Antwort: "In den meisten Fällen wird Nginx bereitgestellt, und Nginx kann nicht über HTTP / 2 in den Upstream übertragen werden." Okay, diese Antwort ist
richtig , aber nicht
vollständig .
Die vollständige Antwort geben uns die Cloudflare-Ingenieure. Tatsache ist, dass der Schwerpunkt der 2015 geschriebenen und veröffentlichten HTTP / 2-Spezifikation auf der Steigerung der Browserleistung in bestimmten Anwendungsfällen, beispielsweise für Google, lag.
Google verwendet seine eigenen Technologien, verwendet keinen Reverse-Proxy vor seinen Produktionsservern, daher hat niemand über Reverse-Proxy nachgedacht, und deshalb wird HTTP / 2 von der Cloud zum Upstream nicht verwendet. Dort gibt es in der Tat wenig Gewinn, da im Reverse-Proxy-Modus beispielsweise von dem, was im HTTP / 2-Protokoll beschrieben ist, Server Push nicht unterstützt wird, da nicht klar ist, wie es funktionieren soll, wenn wir Pipelining haben.
Die Tatsache, dass HTTP / 2 Verbindungen speichert, ist cool, aber Reverse Proxy allein speichert sie, da nicht eine Verbindung pro Benutzer geöffnet wird. Es macht wenig Sinn, HTTP / 2 hier zu unterstützen, und der damit verbundene Overhead und die damit verbundenen Probleme sind groß.
Was wichtig ist: Reverse Proxy ist eine Technologie, die vor etwa 13 Jahren aktiv eingesetzt wurde. Das heißt, dies ist die Technologie der Mitte der 2000er Jahre: Ich ging zur Schule, während sie bereits in Gebrauch war. Es wird in dem 2015 herausgegebenen Standard nicht erwähnt, es wird nicht unterstützt, und Arbeiten zur Unterstützung werden derzeit nicht in der httpbis-Arbeitsgruppe in der IETF durchgeführt.
Dies ist ein Beispiel für die Probleme, die auftreten, wenn Benutzer mit der Implementierung von HTTP / 2 beginnen. Wenn Sie mit Personen sprechen, die bereits eingesetzt haben und bereits Erfahrung damit haben, hören Sie ständig dieselben Wörter.
Sie wurden am besten von Maxim Matyukhin aus Badoo
in einem Beitrag auf Habré formuliert, in dem er über die Funktionsweise von HTTP / 2 Server Push sprach. Er schrieb, dass er sehr überrascht war, wie unterschiedlich die Interaktion dieser speziellen Funktionalität mit Browsern war,
da er dachte, es sei eine voll entwickelte Funktion, die für die Produktion bereit sei . Ich habe diesen Satz in Bezug auf HTTP / 2 schon oft gehört: Wir dachten, es sei ein Drop-In-Ersatzprotokoll - das heißt, Sie schalten es ein und alles ist in Ordnung - warum ist in der Praxis alles so kompliziert, woher all diese Probleme kommen und Mängel?
Lass es uns herausfinden.
Historisch gesehen sah die Architektur des Internets in der Antike ungefähr so aus. Irgendwann gab es kein grünes Rechteck mehr, aber dann erschien es.
Die folgenden Protokolle wurden verwendet: Da es sich um das Internet und nicht um das lokale Netzwerk handelt, beginnen wir auf der unteren Ebene mit IPv4. Darüber wurde das TCP- oder UDP-Protokoll verwendet, aber in 90% der Fälle (da 80-90% des Internetverkehrs das Web ist) war TCP das nächste, dann SSL (das dann durch TLS ersetzt wurde) und darüber der HTTP-Hypertext . Allmählich entwickelte sich die Situation, dass sich die Architektur des Internets laut Plan bis 2020 radikal hätte ändern müssen.
IPv6 ist schon sehr lange bei uns. TLS wurde kürzlich aktualisiert. Wir werden weiterhin diskutieren, wie dies geschehen ist. Das HTTP / 2-Protokoll wurde ebenfalls aktualisiert.
Der wundervolle einheimische Science-Fiction-Schriftsteller Vadim Panov im Enklaven-Zyklus hatte einen
wunderbaren Satz : „Sie haben auf die Zukunft gewartet. Willst du eine Zukunft? Es ist gekommen. Du wolltest ihn nicht? Es ist sowieso gekommen. " Das einzige, was - seit ein paar Jahren - praktisch unberührt blieb, ist das TCP-Protokoll.
Menschen, die sich mit der Gestaltung des Internets beschäftigen, konnten an solch einer offensichtlichen Ungerechtigkeit nicht vorbeikommen und beschlossen, auch das TCP-Protokoll zu werfen.
Okay, das ist natürlich ein Witz. Das Problem ist nicht nur, dass das Protokoll zu alt ist. Es gibt Fehler in TCP. Für viele war es besonders besorgniserregend, dass das HTTP / 2-Protokoll bereits geschrieben wurde, der Standard von 2015 bereits implementiert wurde, aber nicht immer speziell mit TCP funktionierte, und es wäre schön, einen anderen Transport darunter zu platzieren, der für was früher besser geeignet ist rief SPDY an, als diese Gespräche gingen, und dann für HTTP / 2.
Das Protokoll beschloss, QUIC aufzurufen. QUIC ist ein Protokoll, das derzeit für den Transport entwickelt wird. Es basiert auf UDP,
dh es ist ein
Datagrammprotokoll . Der erste Entwurf des Standards wurde im Juli 2016 veröffentlicht, und der aktuelle Entwurf der Version ...
[Sprecher überprüft E-Mails am Telefon]"... ja, immer noch der 12 .."
Im Moment ist QUIC noch kein Standard - es wird aktiv geschrieben. Wenn ich mich nicht irre - ich habe nicht auf die Folie geschrieben, weil ich Angst hatte, einen Fehler zu machen -, aber auf der IETF 101 in London wurde gesagt, dass es bis November 2018 geplant war, es als endgültiges Dokument zu veröffentlichen. Es ist der QUIC-Standard selbst, da die Arbeitsgruppe der Dokumente
acht weitere Dokumente enthält.
Das heißt, es gibt noch keinen Standard, aber ein aktiver Hype ist bereits im Gange. Ich habe nur die Konferenzen aufgelistet, auf denen ich in den letzten sechs Monaten war und auf denen mindestens eine Präsentation über QUIC stattfand. Über "wie cool es ist", "wie wir darauf umsteigen müssen", "was für Betreiber zu tun ist", "UDP nicht mehr filtern - QUIC wird es jetzt durcharbeiten". Dieser ganze Hype dauert schon eine ganze Weile an - ich habe bereits viele Artikel gesehen, in denen die Spielebranche aufgefordert wurde, anstelle des üblichen UDP auf QUIC umzusteigen.
Links von der Folie:
1. Konferenzen.sigcomm.org/imc/2017/papers/imc17-final39.pdf
2. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktopIm November 2017 wurde der folgende Link in der Mailingliste der QUIC-Arbeitsgruppe angezeigt: der obere für Whitepaper und der untere für diejenigen, denen das Lesen von Whitepaper schwer fällt - dies ist ein Link zum APNIC-Blog mit einer Zusammenfassung.
Die Forscher beschlossen, die Leistung von TCP und QUIC in der aktuellen Form zu vergleichen. Zum Vergleich: Um nicht zu klären, wer schuld ist und wo Windows schuld sein könnte, haben sie auf der Clientseite Chrome unter Ubuntu und zwei mobile Geräte verwendet: ein Nexus und einige Samsung
(Anmerkung des Herausgebers: Nexus 6 und MotoG) mit Android 4 und 6 Versionen, und sie haben auch Chrome gestartet.
Auf der Serverseite haben sie Apache installiert, um zu sehen, wie der TCP-Server funktioniert, und um QUIC zu überwachen, haben sie einen Teil des Open-Source-Codes aus dem Chromium-Projekt herausgerissen. Die Benchmark-Ergebnisse zeigten, dass QUIC unter allen Gewächshausbedingungen zwar TCP wirklich übertrifft, jedoch einige Eckpfeiler verliert.
Beispielsweise funktioniert die QUIC-Implementierung von Google erheblich schlechter als TCP, wenn die Paketumordnung im Netzwerk erfolgt, dh Pakete in der falschen Reihenfolge ankommen, in der sie vom Server gesendet wurden. In den Jahren 2017-2018, im Zeitalter mobiler und drahtloser Netzwerke, gibt es im Allgemeinen keine Garantie dafür, dass das Paket im Prinzip fliegen wird, ganz zu schweigen von der Reihenfolge. QUIC funktioniert hervorragend in einem kabelgebundenen Netzwerk, aber wer verwendet jetzt ein kabelgebundenes Netzwerk?
Im Allgemeinen mögen die Entwickler dieses Codes in Google offenbar keine Handys.
QUIC ist ein Protokoll, das über UDP im Benutzerbereich implementiert wird. Und auch auf mobilen Geräten im Benutzerbereich. Gemäß den Messergebnissen verbringt die Implementierung des QUIC-Protokolls in einer normalen Situation, dh wenn über ein drahtloses Netzwerk gearbeitet wird, 58% der Zeit in Android im Status "Application Limited". Was ist dieser Zustand? Dies ist der Zustand, in dem wir einige Daten gesendet haben und auf eine Bestätigung warten. Zum Vergleich: Auf Desktops lag der Wert bei etwa 7%.
Nur zwei Anwendungsfälle: Der erste ist ein drahtloses Netzwerk, der zweite ist ein mobiles Gerät; und QUIC funktioniert entweder als TCP oder wesentlich schlechter. Dies stellte sich natürlich in der IETF-Arbeitsgruppe heraus, die sich QUIC widmete, und natürlich reagierte Google darauf. Die Antwort von Google lautete wie folgt:
mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGENun, wir haben gelacht, aber eigentlich ist es absolut logisch.
Warum? Denn das Design von QUIC - obwohl wir bereits über die Implementierung in der Produktion sprechen, aber - in der Tat das wildeste Experiment.
Hier ist beispielsweise ein siebenstufiges ISO / OSI-Modell. Wer erinnert sich hier an sie? Erinnern Sie sich an die Ebenen: physisch, Kanal, Netzwerk, Transport, etwas Unsinn, etwas Unsinn und angewendet, richtig?
Ja, es wurde vor sehr langer Zeit entwickelt und irgendwie haben wir mit diesem Level-Modell gelebt. QUIC ist ein Experiment, um das Netzwerkschichtsystem selbst zu eliminieren. Es kombiniert Verschlüsselung, Transport und zuverlässige Datenlieferung. All dies liegt nicht in der Ebenenstruktur, sondern im Mähdrescher, in dem jede Komponente Zugriff auf die API anderer Komponenten hat.
Zitat eines der Designer des QUIC-Protokolls Christian Guitem: „Einer der Hauptvorteile von QUIC aus architektonischer Sicht ist das Fehlen einer Ebenenstruktur.“ Wir verfügen über Bestätigung, Flusskontrolle, Verschlüsselung und die gesamte Kryptografie - all dies erfolgt vollständig in einem Transport, und unsere Transportinnovationen implizieren den direkten Zugriff auf die Netzwerk-API, sodass wir keine abgestufte Architektur in QUIC wünschen.
Das Gespräch in der Arbeitsgruppe darüber begann aufgrund der Tatsache, dass Anfang März ein anderer QUIC-Protokolldesigner, nämlich Eric Rescorla, beschlossen hatte, eine Variante zur Diskussion vorzuschlagen, bei der die gesamte Verschlüsselung von QUIC im Allgemeinen entfernt wird. Es bleibt nur eine Transportfunktion, die über DTLS ausgeführt wird. DTLS wiederum ist TLS über UDP, insgesamt stellt sich heraus: QUIC über TLS über UDP.
Woher kam ein solches Angebot? Übrigens hat Rescorla ein großes Dokument geschrieben, das aber keineswegs zum Standard wurde - es war ein Diskussionsthema, da beim Entwerfen der QUIC-Architektur, beim Testen der Interoperabilität und Implementierung viele Probleme auftraten. Hauptsächlich im Zusammenhang mit "Stream 0".
Was ist Stream 0 in QUIC? Dies ist die gleiche Idee wie in HTTP / 2: Wir haben eine Verbindung, in der wir mehrere gemultiplexte Streams haben. Ich erinnere mich, dass die Verschlüsselung von QUIC nach demselben Protokoll erfolgt. Dies geschah wie folgt: Es wird ein "magischer" Stream mit der Nummer 0 geöffnet, der für das Herstellen einer Verbindung, das Händeschütteln und die Verschlüsselung verantwortlich ist. Anschließend wird dieser Stream 0 verschlüsselt und alle anderen werden ebenfalls verschlüsselt. Damit sind viele Probleme aufgetreten, sie sind auf der Mailingliste aufgeführt, es gibt 10 Artikel, ich werde nicht bei jedem aufhören. Ich werde nur eine herausgreifen, die mir wirklich gefällt.
www.ietf.org/mail-archive/web/quic/current/msg03498.htmlDas Problem mit Thread 0, von denen eines darin besteht, dass wir Pakete erneut senden müssen, wenn wir sie verlieren. Gleichzeitig kann beispielsweise auf der Serverseite die Verbindung bereits als verschlüsselt markiert werden, und das verlorene Paket stammt aus der Zeit, als es unverschlüsselt war. In diesem Fall kann die Implementierung beim Weiterleiten Pakete zufällig verschlüsseln.
Noch einmal:
Pakete nach dem Zufallsprinzip verschlüsseln.Dies ist ziemlich schwer zu kommentieren, zusätzlich zu der Aussage, wie all dies tatsächlich gestaltet ist. Die QUIC-Entwicklung verwendet tatsächlich den ersatz-agilen Ansatz. Das heißt, es ist nicht so, dass jemand einen Stahlbetonstandard geschrieben hat, der nach einigen Iterationen offiziell veröffentlicht werden kann. Nein.
Die Arbeit ist wie folgt:
1. Der Standardentwurf beginnt beispielsweise mit Nummer 5;
2. Auf den Mailinglisten sowie bei IETF-Treffen - drei Stücke pro Jahr - wird diskutiert, dann wird die Implementierung bei Hackathons durchgeführt, Interop-Tests durchgeführt und Feedback gesammelt.
3. Google implementiert einige der Änderungen in Chrome in seiner eigenen Infrastruktur, analysiert die Konsequenzen und dann wird der Zähler erhöht und Standard 6 wird angezeigt.
Nun erinnere ich Sie daran, Version 12.
Hinweis Ed.: Ab dem 10. Juli 2018 ist es bereits der 13 ..Was ist hier wichtig?
Erstens haben wir nur die Nachteile gesehen, aber es gibt Pluspunkte. Tatsächlich können Sie an diesem Prozess teilnehmen. Feedback wird von allen Beteiligten gesammelt: Wenn Sie am Spielen beteiligt sind und der Meinung sind, dass Sie in der Spielebranche einfach UDP ändern und ändern können, setzen Sie stattdessen QUIC, und alles wird funktionieren - nein, das wird nicht. Aber im Moment können Sie es beeinflussen, Sie können irgendwie damit arbeiten.
Und das ist in der Tat eine gemeinsame Geschichte. Feedback von Ihnen wird erwartet, jeder möchte es sehen.
Google entwickelt ein Protokoll, in das einige Ideen einfließen - für eigene Zwecke. Unternehmen, die andere Dinge tun (wenn dies kein typisches Web, Gaming oder mobile Anwendungen sind, ist SEO dasselbe), können sie standardmäßig nicht erwarten, dass das Protokoll ihre Interessen berücksichtigt: nicht nur, weil es niemanden interessiert, sondern weil niemand nur über diese Interessen Bescheid weiß.
Dies ist übrigens ein Geständnis. Die Frage ist natürlich für mich, warum wir als
Qrator Labs insbesondere nicht an der Entwicklung des HTTP / 2-Protokolls beteiligt waren und niemandem von Reverse Proxy erzählt haben. Aber die gleichen Cloudflare und Nginx haben dort auch nicht teilgenommen.
Während die Branche nicht daran beteiligt ist, entwickeln sich Google, Facebook, einige andere Unternehmen und
Wissenschaftler . Um Sie wissen zu lassen, ist das Wort "Akademiker" in der IETF-nahen Partei beispielsweise nicht lobenswert. Es klingt wie die Beinamen "schizophren" und "hypochondrisch". Menschen kommen oft ohne praktische Ziele, ohne die wirklichen Aufgaben zu verstehen, passen aber dazu, weil es einfacher ist, eine Doktorarbeit zu bekommen.
Natürlich muss man daran teilnehmen und es gibt keine anderen Möglichkeiten.
Zurück zu QUIC: Das Protokoll ist also im Benutzerbereich implementiert, auf Mobilgeräten gibt es ... Blah blah. "Im Benutzerbereich implementiert." Reden wir darüber.
Wie haben wir den Transport im Allgemeinen arrangiert, bevor wir QUIC entwickelt haben? Wie funktioniert es jetzt in der Produktion? Es gibt ein TCP-Protokoll, wenn es um das Web geht.
In TCP gibt es einen
dreifachen Handshake : SYN, SYN / ACK, ACK. Es wird für eine Reihe von Dingen benötigt: um zu verhindern, dass der Server verwendet wird, um andere anzugreifen, um bestimmte Angriffe auf das TCP-Protokoll, wie z. B.
SYN Flood , erfolgreich zu filtern. Erst nachdem 3 Segmente des dreifachen Handshakes vergangen sind, beginnen wir mit dem Senden von Daten.
Gleichzeitig gibt es 4 Aktionen, von denen 3 im Kernel ausgeführt werden, die recht effizient ausgeführt werden und Daten bereits beim Herstellen der Verbindung in den Benutzerbereich gelangen.
In der Situation mit QUIC liegt all dieses Glück im Benutzerraum. , «SYN, SYN/ACK», , , , user space. 20 / TCP
SYN- , user space, c context switch'. - .
? QUIC – user space'? , , - .
, , Google . , , . user space, ( , , ) .
, , Google – . - , Google ( ). - , Google, , .
www.ietf.org/mail-archive/web/quic/current/msg03736.htmlAuf dem Bildschirm wird ein wörtliches Zitat aus der QUIC-Mailingliste angezeigt, in der nur darüber diskutiert wurde, dass das Protokoll für die Implementierung im Benutzerbereich geplant ist. Dies ist ein wörtliches Zitat: „Wir möchten QUIC auf jedem Computer ohne Betriebssystemunterstützung bereitstellen. Wenn jemand Leistungsprobleme hat, wird er alles auf den Punkt bringen. “ QUIC ist bereits so locker, dass es beängstigend ist, dies mit Verschlüsselung und allem anderen auf den Punkt zu bringen, aber die Arbeitsgruppe zu diesem Thema ist auch nicht besonders besorgt.
– . . , QUIC , , , , , , . – .
Linux, , QUIC , UDP, , … TCP, .
vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf. , UDP- Linux , TCP-, , . 2 ( , ):
1. UDP-;
2. «large segment offload». TCP , CPU, UDP , . , , , , , TCP , , , UDP, QUIC.
www.ietf.org/mail-archive/web/quic/current/msg03720.htmlGoogle, , , . Linux, , Windows, , , . , , Google QUIC, ( ) UDP- TCP-. Linux , .
.
QUIC. . , – , : HTTP/2 HTTP/1.1, QUIC TCP, DNS, IPv6 IPv4… , , production – , , benchmarking.
, , « // » –
! – , , .
, , , , -, , , .
, IPv6. , IPv6, , - , agile-. . , , , 10-20% IPv6. , .
IPv6 . , «Happy Eyeballs»? , , IPv6, , . , , , IPv6, , IPv6 , – , – IPv6, .
«Happy Eyeballs» ( , IETF): 0,3 IPv6-, , IPv4.
, , , , ! . , - - iPad, IPv6 IPv4 , 0,3 : 1 – 1 .
- IETF 99 : « Happy Eyeballs syslog' , , – - ». syslog – , , . , .
– , IPv6 – /64 , , , . - , .
, , - IPv6 . , . IPv4. , — . , , , , .
, , .
blog.apnic.net/2018/02/26/peak-dnssec– DNSSEC. , , , , .
IPv6, , , , , . , DNSSEC .
- ( APNIC Labs), , DNSSEC. : , , – 2016 .
DNSSEC , , - , , .
datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01DNS . IETF
dnsop 3 ,
15 , , « » : RFC.
DNS, , . TCP ( ,
).
TLS ,
HTTPS ,
QUIC .
, , . 2017 . OpenDNS IETF
«DNS Camel» , « DNS». : (aka DNS), ?
, . , ,
-. , . , , production – , . , – .
? IETF – «RFC» – - . : SSL TLS.
, SSL 2, 0.9 1.0 production, , Netscape . SSL 2.0, . SSL 3.0 .
TLS 1.0 3 ; 1.1 – 7 ; 1.2 2 , ; , – 27- , –
10 .
, , TLS 1.3 use case', , , . , , , US Bank. , , , ,
, .
, - – – // , , , , .
, , .
: , – «- ». , , .
: , , , .
, :
. , Google, , , , .
, , - - , , , , , , , .
Vielen Dank!