Plus quam XX annos inspeximus paginas interretiales utentes protocollo HTTP. Maxime utentes ne cogitare quidem quid sit et quomodo operatur. Alii sciunt alicubi sub HTTP esse TLS, sub eo TCP, sub quo IP, et sic porro. Et adhuc alii - haeretici - credunt TCP rem esse praeteritae, cupiunt aliquid velocius, certius et securius. Sed in conatibus ad novum exemplar commentarium excogitandum, ad technologiam 20s redierunt et in eo novum mundum fortes suos aedificare conantur.
Historia parva: HTTP/1.1
Anno 1997, textus informationis permutationis protocollo HTTP versio 1.1 propriam RFC quaesivit. Illo tempore protocollum navigatoris aliquot annis adhibitum erat, et novum vexillum alterum quindecim perduravit. Protocollum solum in principio rogationis responsionis laboravit et maxime destinabatur ad informationes textuum tradendas.
HTTP designatus est in summitate protocolli TCP currere, ut fasciculi destinati certo traderentur. TCP opera facit certam connexionem inter terminos et negotiationem in segmenta dividendo et conservando. Segmenta propria numerum serialem et checksum habent. Si subito unum ex segmentis non pervenerit vel cum checksum incompositum pervenerit, tunc transmissio cessabit donec segmentum amissum restituatur.
In HTTP/1.0, nexus TCP post singulas petitionem clausus est. Hoc perquam prodigi, quod... nexum constituendum TCP (3-Way-Handshake) est processus tardus. HTTP/1.1 mechanismum servativum induxit, quod te permittit ut unum nexum pro multis petitionibus recipias. Sed cum facile fieri potest bottleneck, variae exsecutiones HTTP/1.1 permittunt multiplices coniunctiones TCP eidem exercitui aperiendae. Exempli gratia, Chrome et recentes versiones Firefox usque ad sex coniunctiones permittunt.
Encryption etiam aliis protocollis relinqui putabatur, eoque protocollo TLS super TCP adhibitum est, quod notitias fideliter tutatus est, sed tempus ad nexum constituendum augebat. Quam ob rem processus handshake sic coepit spectare:
Cloudflare illustration
Ita HTTP/1.1 plures difficultates habebat:
- Tardus nexus setup.
- Data in textibus transmittitur forma, quae significat transmissionem picturarum, imaginum et aliarum informationum non textuum inefficax.
- Una TCP connexio pro una petitione adhibetur, quae significat alias petitiones necesse est vel aliam nexum invenire vel exspectare donec instantiam illam solvat.
- Exemplar solum viverra sustentatur. Nihil est in regula de servo dis.
- Capitula in textu transmittuntur.
Si servo-urna saltem effectum est utens protocollo WebSocket, tunc reliquae difficultates funditus tractandae erant.
Paulo recentioris aetatis: HTTP/2
Anno 2012, Google in SPDY opus (protocollum "celer" prolatum est. Protocollum destinatum erat principales quaestiones HTTP/1.1 solvere et simul supposita convenientiae retrorsum conservare. Anno 2015, coetus laborantis IETF speciem HTTP/II in protocollo SPDY induxit. Hic differentiae sunt in HTTP/2:
- Binarii serialization.
- Multiplicans multiplices petitiones HTTP in nexum unum TCP.
- Dis servitores ex archa (sine WebSocket).
Protocollum magni gradus erat. Ille fortiter et plurium nexus TCP creationem non requirit: omnes petitiones ad unum exercitum multiplicantur in unum. Id est, in uno nexu sunt plures rivi sic dicti, quorum quodlibet proprium ID. Bonus server dis cohibenti est.
Sed multiplex quaestio ad aliam quaestionem ducit. Finge nos asynchrone exsequi 5 petitiones uni servo. Cum usus HTTP/2, hae omnes petitiones intra eundem TCP nexum agentur, quod significat, si una ex segmentis cuiusvis petitionis male amissa vel recepta sit, transmissio omnium petitionum et responsionum cessabit donec segmentum amissum sit. restituta. Uti patet, deterior nexus qualitas, eo tardius opera HTTP/2. , in conditionibus ubi deperditae fasciculi rationem 2% omnium fasciculorum, HTTP/1.1 in navigatro melius praestat quam HTTP/2, ob hoc quod plus quam unum 6 nexus aperit.
Quaestio haec "caput-lineae obstructionis" appellatur et, proh dolor, eam solvere non potest cum usus TCP.
Illustration by Daniel Steinberg
Quam ob rem, tincidunt vexillum HTTP/2 magnum officium fecerunt et fere omnia quae fieri poterant in schedula tabulae OSI exemplar. Tempus est descendere ad stratum onerariam ac novam onerariam protocollo excogitare.
Novo protocollo opus est: UDP nobis TCP
Cito satis manifestum est exsequendo protocollum tabulatum onerarium omnino novum negotium in hodiernis rebus impossibile esse. Re vera ferramenta vel pyxides mediae (iteri, firewalls, servientes NAT...) sciunt de iacuit onerariis, eosque docendo aliquid novi est difficillimum. Praeterea subsidia protocolla in nucleum systematis operandi aedificatur, et nuclei quoque non admodum volunt.
Et hic aliquis manus ejicere potuit et dicere "Nos, scilicet, novas HTTP/3 cum potioribus et meretricibus inventuros, sed 10-15 annis perficiendum erit (post hoc fere tempus plures ferrariae erunt. substitutum est), sed unum magis non est ita Oppositio manifesta uti protocollo UDP est. Ita, ita, idem protocollum quem lima in LAN nuper nineties et primo XNUMXs annorum mittere solebamus. Fere omnes hodie ferramenta cum ea laborare possunt.
Quae sunt commoda UDP super TCP? Ante omnia sessionem onerariam non habemus quod ferramenta scit de. Hoc nobis concedit sessionem in terminis ipsis determinare et conflictus ibi componi. Hoc est, non uni vel pluribus sessionibus circumscriptae sumus (ut in TCP), sed tot ex quibus opus est creare possumus. Secundo, data transmissio per UDP velocior est quam per TCP. Sic in theoria hodiernam celeritatem laquearia consecuta in HTTP perrumpere possumus.
Sed UDP non praestat certa notitia tradenda. Re vera fasciculos tantum mittimus, sperantes summum illum accepturum esse. Non accepisti? Bene, nulla fortuna... Hoc satis fuit pro adultis videos transmittendis, sed pro gravioribus rebus firmitate opus est, quod significatum habes aliud involvere super UDP.
Ut cum HTTP/2, opus novum protocollum creandi incepit apud Google anno 2012, id est, eodem fere tempore quo opus in SPDY incepit. Anno 2013, Jim Roskind publico publico praesentatus est et iam anno 2015 Interreti Draft pro standardisation in IETF introducta est. Iam tum, protocollum apud Google a Roskind evolvit longe a signo diversum, itaque versio Google gQUIC appellari coepta est.
Quid est QUIC?
Uno modo, ut iam dictum est, fascia super UDP est. A QUIC nexus super UDP oritur, in quo, ad similitudinem cum HTTP/2, plures rivi existere possunt. Hi rivi solum in terminis existunt et independenter inserviunt. Si damnum fasciculus in uno rivo fiat, alios non tanget.
Illustration by Daniel Steinberg
Secundo encryption non amplius in gradu separato perficitur, sed in protocollo continetur. Hoc tibi permittit ut nexum et claves publicas in uno maculoso constituas, et etiam permittit ut machinula machinula callida 0-RTT et ne moras maculosas omnino. Praeterea nunc fieri potest ut singulas notitias fasciculis encrypt. Hoc tibi permittit non ut complementum acceptionis ex rivo notitiae exspectes, sed decryptas receptas independenter. Hic modus operandi plerumque in TCP impossibilis fuit, quia TLS et TCP separatim inter se laboraverunt, et TLS sciri potuerunt in quas partes TCP notitia concisa esset. Ideoque segmenta sua parare non potuit ut in TCP segmenta una ad unum coaptantur, et independenter minui possint. Omnes hae emendationes permittunt QUIC ad latentiam comparatam TCP reducere.
Tertio, conceptus lucis effusis te permittit ut nexum decoquatur e IP oratio ipsius clientis. Hoc magni momenti est, exempli gratia, cum clientis permutat ab uno Wi-Fi accessus ad punctum in alium, IP suum mutans. In hoc casu, cum utendo TCP, processus longus occurrit in quo nexus TCP existentes tempus egrediuntur et novae nexus ex novo IP creantur. In casu QUIC, cliens solum pergit ut servo e novo IP cum veteri flumine ID fasciculos mittere. Quod Fluvius ID nunc unicus est et non redditur, minister intellegens clientem IP mutatum esse, facis perditas resicit et communicationem continuat in inscriptione nova.
Quartum, QUIC in gradu applicationis effectum est, non ad systema operantem. Id, ex altera parte, permittit vos cito mutare protocollum, quia Ut renovationem accipias, opus solum bibliothecam renovare debes, quam novam OS versionis exspecta. Contra, haec consummatio processuum auget ad vehementem.
Ac denique aliquam lacus. Compressio Header una est rerum quae inter QUIC et gQUIC differt. Punctum in hoc multum temporis impendere non video, modo dicam in versione normaizationis proposita, compressio capitis facta est quam simillima compressioni capitis in HTTP/2. Potes legere plus .
Quanto citius est?
Quaestio difficilis est. Ita enim, donec vexillum habeamus, nihil speciale metiri. Sola fortasse statistica nos habemus statistica ex Google, quae gQUIC ab anno 2013 et 2016 usus est quod circiter 90% negocii eundi ad suos servientes ex navigatro Chrome nunc QUIC utitur. In eadem praesentatione narrant paginas circiter 5% velociores per gQUIC onerare et 30% pauciores balbutientes in video effusis cum TCP comparari.
Anno 2017, coetus investigatorum ab Arash Molavi Kakhki editus est ad studium gQUIC exercendum comparari TCP.
Studium varias infirmitates gQUIC patefecit, ut instabilitas ad commiscendum retis, avaritia (iniquitatis) ad canalem latitudinem et tardius translatio rerum parvarum (usque ad 10 kb). posterius tamen compensari potest utendo 0-RTT. In omnibus aliis casibus studuit, gQUIC celeritatis auctum ostendit cum TCP comparatum. Difficile est hic de numeris specificis loqui. Melius legere aut .
Hic dicendum est hanc datam in specie de gQUIC esse, nec ad regulam augendam pertinere. Quid pro QUIC fiet: occultum adhuc est, sed spes est infirmitates, quae in gQUIC sunt, ratio habenda et corrigenda est.
Aliquantum futuri: quid de HTTP/3?
Sed hic omnia perspicua sunt: ββAPI nullo modo mutabitur. Omnia prorsus eadem erunt quae in HTTP/2. Bene, si API remanet idem, transitus ad HTTP/3 solvendum erit utendo nova versione bibliothecae in backend quae QUIC onerariam sustinet. Verum, lapsus servare debebis in versionibus antiquis HTTP per aliquod tempus, quod Interretus in praesenti paratus est ad UDP transitum completam.
Quis iam sustinet
hic existentium QUIC exsecutiones. Quamvis vexillum desit, non est malum album.
Nullum navigatrum currently QUIC in emissione productionis sustinet. Nuper compertum est subsidium HTTP/3 in Chrome inclusum esse, sed tantum in Canariis.
De tergum, HTTP/3 subsidia tantum ΠΈ sed tamen experimentum. NGINX fine vere MMXIX " , HTTP/3 auxilio laborare inceperunt, sed nondum illud perfecerunt.
Quae sunt problemata?
Tu et ego in reali mundo habito, ubi nulla magna technica ars ad missas sine occursu resistente pervenire potest, et QUIC exceptio nulla est.
Maximi momenti est quod aliquo modo debes explicare ad navigatrum quod "https://" iam non est quod ad portum TCP perducit 443 . Non sit TCP omnino. Alt-Svc header pro hoc ponitur. Permittit tibi ut navigatrum dicas hunc locum etiam in tali protocollo tali et tali inscriptione praesto esse. In speculatione, hoc opus est ut venustas, sed in usu veniemus per id quod UDP potest, exempli gratia, prohiberi in firewall ad vitare DDoS impetus.
Sed etiamsi UDP non prohibetur, cliens potest esse post iter NAT, qui configuratus est habere sessionem TCP ab IP inscriptione, et quoniam utimur UDP, quae sessionem ferrariam non habet, NAT nexum non teneat et sessionem QUIC .
Omnia haec problemata debentur eo quod UDP antea usus non fuerat ut per Internet contentus transmitteret, et ferramenta artifices praevidere non possent hoc umquam eventurum esse. Eodem modo administratores nondum vere intellegunt quomodo retiacula sua rite configurare ad operandum QUIC. Haec condicio sensim mutabitur, et, certe, huiusmodi mutationes minus temporis capient quam exsecutionem tabulae novae tabulae onerariae protocolli.
Accedit, ut iam dictum est, QUIC CPU usus magnopere augetur. Daniel Stenberg processus incrementum usque ad ter.
Quando HTTP / III perveniet?
Standard a Maio 2020, sed documenta quae ad mensem Iulium 2019 accedant, in momento imperfecta manent, affirmare possumus diem verisimillimum esse repelli.
Bene, Google usus est ad exsequendam gQUIC suam ex 2013 . Si petitionem HTTP inspicias quae ad machinam Google missam spectant, hoc videbis:
Inventiones
QUIC nunc rudem magis spectat, sed technologiam valde pollicetur. Cum per annos XX proxime praeteritis omnibus optimizations iacuit protocolla protocolla curaverunt maxime TCP, QUIC, quod in pluribus optimum effectum habet, iam perquam bonum spectat.
Sunt tamen adhuc problemata quae in proximo paucis annis tractanda sunt. Processus differri potest ex eo quod ferramentum implicatur, quod nemo renovare vult, sed tamen omnes difficultates satis solubiles spectant, et citius aut serius omnes HTTP/3 habebimus.
Futurum est circa anguli!
Source: www.habr.com