Disgwylir i Firefox lansio cefnogaeth HTTP/3 erbyn diwedd mis Mai.

Mae Mozilla wedi cyhoeddi ei fwriad i ddechrau cyflwyno HTTP/3 a QUIC yn raddol gyda rhyddhau Firefox 88, a drefnwyd ar gyfer Ebrill 19 (disgwylir yn wreiddiol iddo gael ei ryddhau ar Ebrill 20, ond a barnu yn ôl yr amserlen, bydd yn cael ei wthio yn ôl un diwrnod). Dim ond ar gyfer canran fach o ddefnyddwyr y bydd cymorth HTTP/3 yn cael ei alluogi i ddechrau ac, ac eithrio unrhyw faterion annisgwyl, bydd yn cael ei gyflwyno i bawb erbyn diwedd mis Mai. Mewn adeiladau nosweithiol a fersiynau beta, galluogwyd HTTP/3 yn ddiofyn ddiwedd mis Mawrth.

Gadewch inni gofio bod gweithredu HTTP/3 yn Firefox yn seiliedig ar y prosiect neqo a ddatblygwyd gan Mozilla, sy'n darparu gweithrediad cleient a gweinydd ar gyfer protocol QUIC. Mae'r cod cydran ar gyfer cefnogaeth HTTP/3 a QUIC wedi'i ysgrifennu yn Rust. Er mwyn rheoli a yw HTTP/3 wedi'i alluogi, mae about:config yn darparu'r opsiwn “network.http.http3.enabled”. O feddalwedd cleientiaid, mae cefnogaeth arbrofol ar gyfer HTTP/3 hefyd wedi'i ychwanegu at Chrome a curl, ac ar gyfer gweinyddwyr mae ar gael yn nginx, yn ogystal ag ar ffurf modiwl nginx a gweinydd prawf gan Cloudflare. Ar ochr y wefan, darperir cefnogaeth HTTP/3 eisoes ar weinyddion Google a Facebook.

Mae'r protocol HTTP/3 yn dal yn y cyfnod manyleb drafft ac nid yw wedi'i safoni'n llawn eto gan yr IETF. Mae HTTP/3 yn gofyn am gefnogaeth cleient a gweinydd ar gyfer yr un fersiwn o safon drafft QUIC a HTTP/3, a nodir ym mhennyn Alt-Svc (mae Firefox yn cefnogi drafftiau penodol 27 i 32).

Mae HTTP/3 yn diffinio'r defnydd o'r protocol QUIC fel cludiant ar gyfer HTTP/2. Mae protocol QUIC (Cysylltiadau Rhyngrwyd Cyflym UDP) wedi'i ddatblygu gan Google ers 2013 fel dewis amgen i'r cyfuniad TCP+TLS ar gyfer y We, gan ddatrys problemau gydag amseroedd gosod a thrafod hir ar gyfer cysylltiadau yn TCP a dileu oedi pan fydd pecynnau'n cael eu colli yn ystod data trosglwyddiad. Mae QUIC yn estyniad o brotocol y CDU sy'n cefnogi amlblecsio cysylltiadau lluosog ac yn darparu dulliau amgryptio sy'n cyfateb i TLS/SSL. Yn ystod datblygiad y safon IETF, gwnaed newidiadau i'r protocol, a arweiniodd at ymddangosiad dwy gangen gyfochrog, un ar gyfer HTTP / 3, a'r ail yn cael ei gefnogi gan Google (mae Chrome yn cefnogi'r ddau opsiwn).

Nodweddion allweddol QUIC:

• Diogelwch uchel tebyg i TLS (yn y bôn mae QUIC yn darparu'r gallu i ddefnyddio TLS dros CDU);
• Rheoli uniondeb llif, atal colli pecyn;
• Y gallu i sefydlu cysylltiad ar unwaith (0-RTT, mewn tua 75% o achosion gellir trosglwyddo data yn syth ar ôl anfon y pecyn sefydlu cysylltiad) a darparu ychydig o oedi rhwng anfon cais a derbyn ymateb (RTT, Round Trip Time);
• Defnyddio rhif dilyniant gwahanol wrth ail-ddarlledu pecyn, sy'n osgoi amwysedd wrth nodi pecynnau a dderbyniwyd ac sy'n cael gwared ar oramserau;
• Mae colli pecyn yn effeithio ar gyflenwi'r ffrwd sy'n gysylltiedig ag ef yn unig ac nid yw'n atal trosglwyddo data mewn ffrydiau cyfochrog a drosglwyddir trwy'r cysylltiad presennol;
• Nodweddion cywiro gwallau sy'n lleihau oedi oherwydd ail-drosglwyddo pecynnau coll. Defnyddio codau cywiro gwall arbennig ar lefel pecyn i leihau sefyllfaoedd lle mae angen ail-drosglwyddo data pecynnau coll.
• Mae ffiniau blociau cryptograffig yn cyd-fynd â ffiniau pecynnau QUIC, sy'n lleihau effaith colledion pecynnau ar ddadgodio cynnwys pecynnau dilynol;
• Dim problemau gyda blocio ciw TCP;
• Cefnogaeth ar gyfer dynodwr cysylltiad, sy'n lleihau'r amser y mae'n ei gymryd i sefydlu ailgysylltu ar gyfer cleientiaid symudol;
• Posibilrwydd cysylltu mecanweithiau rheoli tagfeydd cysylltiad uwch;
• Yn defnyddio technegau rhagweld trwybwn fesul cyfeiriad i sicrhau bod pecynnau'n cael eu hanfon ar y cyfraddau gorau posibl, gan eu hatal rhag mynd yn llawn tagfeydd ac achosi colli pecynnau;
• Cynnydd sylweddol mewn perfformiad a thrwybwn o gymharu â TCP. Ar gyfer gwasanaethau fideo fel YouTube, dangoswyd bod QUIC yn lleihau gweithrediadau ail-glustogi wrth wylio fideos 30%.

Ffynhonnell: opennet.ru