Már régóta aktuális volt.

duree54

Megdöbbentő sebesség, mert meg se nyitja egyik linket se.

[ Szerkesztve ]

Mindig minden mindegy

Igen, most éppen le van halva, de amikor az anyagot írtam, látványosan működött. Nyilván összeszedi majd magát a szerverük idővel.

Resistance Is Futile. You will be assimilated!

A mobilböngészőkön is működik?

jó is lesz végre mert már 50-100-1000megabites netcsomagoknál is látszik hogy néha lomha egy oldalbetöltés

Mixgyűjteményem ---> https://www.mixcloud.com/teejayhouse/

Jól hangzik, kíváncsi vagyok milyen gyorsan terjed el

a HTTP1-es linkek, csak nekem nem töltődnek be?
A 2-esek működnek rendesen.

[ Szerkesztve ]

1hs,.2HS,.3HS, yay! ;)

ha az adott mobil böngésző támogatja akkor nyilván

kérdés hogy iis apache nginx hármas mikor fogja támogatni

[ Szerkesztve ]

"Az internet olyan, mint az MTV: annak idején az MTV nagyon trendi volt, aztán hirtelen elavult” - Prince

Működik. Redmi 1s Chrome, fel se tűnt, hogy sok pici kép. Csak amikor a forrást megnéztem.

Már ideje volt!

"Errare humanum est, sed in errare perseverare diabolicum"

Gyorsabbnak tűnik a http1.

Az, hogy a szerver kérés nélkül bármit küldhet a cache-be, nem hordoz biztonságtechnikai problémát?

Kipróbáltam a linket - Ssd-n nincs észrevehető változás. Mindez néhány tízed mp-ért? Hát grat!
Amit fejlesztésre költöttek, adták volna egy éhező családnak.

▫️ PH! FAN ▫️

Mindenki nyugodjon le, az NSA már rég benne van ebben is

Elég látványos a difi, a kérdés, hogy ebből a gyakorlatban mi lesz. Normális neten eddig sem volt gond egy oldallal sem, lassún meg szvsz nem ez fog segíteni. Bár nyilván isp/host oldalról ha már csak 1% spórolás van, az is rengeteg pénzmegtakarítás, még ha a user ebből semmit nem fog észlelni.

''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''

Mobilneten is teszteltem, látványos a különbség, de nem időben, hanem tényleg látványban. Ahogy felépül a kép.

Hiába kapcsolom be, vsz a céges proxy-nk nem támogatha a HTTP2-t...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Szerintem időben is... Durva! Bár gondolom a sok flash-sel megtámogatott oldal esetében, ahol a betöltés valóban lassú, ez nem hoz majd érdemi javulást.

Másolat_eredetije

1.) hibás a cikk végén a HTTP/2 link
2.) nekem a teszt oldalon a HTTP/1-es linkek nem mennek...

Jó kérdés, ez nekem is biztonsági kockázatnak tűnik:
"a szerver a böngésző válasza nélkül küldhet olyan adatokat a gyorsítótárába, amelyeket a weboldal megjelenítéséhez szükségesnek tart" kérés nélkül, amit akar?

protonmail.com Secure Email Based in Switzerland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . startpage.com The world's most private search engine from Netherland

Kövezzetek meg, de szerintem, ha egy adott oldal megnyitásakor nem kellene még 12 tracker és 8 ad szerverhez kapcsolódni, az is elég sokat lendítene a dolgon.

"You travel with fascinating companions, Doctor."

AdBlock.

Tényleg, ezt én is hogy utálom amikor a nosrcipt-ben találgatom, hogy most akkor melyiket engedélyezzem hogy működjön az adott funkció az oldalon, de minél kevesebb szemetet töltsön be.

protonmail.com Secure Email Based in Switzerland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . startpage.com The world's most private search engine from Netherland

Látványos a demo, ha a valóságban is így lesz, akkor nagyon örülök neki, főleg mobil net mellett, ahol amúgy is elég nagy a késleltetés.

Lehet én vagyok béna, de nem látok túl sok különbséget

"A HTTP/2 leglényegesebb újdonságai a HTTP/1.x-hez képest, hogy szöveg alapú helyett bináris (kompaktabb, egyszerűbb értelmezni és jobban tűri a hibákat), multiplexelt (a korábbi futószalagnál rugalmasabb feladatkezelés), ezzel egyetlen TCP kapcsolatban párhuzamosan több feladat végezhető (kevesebb TCP hívás), tömöríti a fejléceket (gyorsabb oldalbetöltés indítás), és a szerver a böngésző válasza nélkül küldhet olyan adatokat a gyorsítótárába, amelyeket a weboldal megjelenítéséhez szükségesnek tart (gyorsabb oldalmegjelenítés)." szép.

tehát a http2 a http1-hez képest, amelyik bináris tartalomnál bináris volt, szövegesnél szöveges, most bináris, amit egyébként nehezebb értelmezni.

a http/2 most már multiplexelt a http/1.1-hez képest, ami multiplexelt, a http2 tömöríti a fejléceket, szemben a http1-gyel, ami az egész tartalmat képes volt tömöríteni, és a szerver majd okoskodik, hogy mit tölt le a gépemre. hogy ennek hogy fognak örülni a forgalomlimites userek...

ha találgatnom kellene, mire fogadjak: hogy a cikk nem jó vagy arra, hogy a protokoll nem jó?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

ámen, impresszív a http/http2 közötti képbetöltések közötti gyorsaságkülönbség

iPhone 13 - Apple Watch Series 7 - LG 65” QNED - Ryzen7 5800X - MSI RTX 3070 - 32GB Kingston HyperX Predator - 34" Iiyama - Redragon Surara Pro - A4Tech X7 - Voopoo Argus MT - Voopoo Argus Pod

Semmi köze a SSD-nek semmihez.
Ha a HTTP 1.1 és a HTTP 2 között nincs különbség akkor nálad van valami gond.

Nálam is nagyon-nagyon a különbség (asztali gép, 100Mbit):
HTTP1-nél 6-osával tölti be a részképeket, aztán mindig vár a latency-re,
HTTP2-nél meg szinte egyszerre jön az összes részlet, így 1 mp alatt kész az egész a negyedik esetben is.

De legalább dicsekedhetett, hogy neki ssd van a gépében! (Biztosan menő dolog... )

(#32) r3dsnake
Csak pont ehhez a hírhez semmi köze az ssd-nek.

[ Szerkesztve ]

(Inkább alap...)

~1s egy oldalbetöltés - szó sincs gondról.

▫️ PH! FAN ▫️

Ég és föld a kettő! Mennyi időbe telik, hogy ez elterjedjen? Remélem nem sokba.

"It is only with heart that one can see rightly; what is essential is invisible to the eye."

Hagyd, neki SSD-je van nem érted, hogy azzal betölt neki.
Nekem is az van, de az övé olyan gyors, hogy meghajlik az téridő.

(#36) saelin

Ha jól tudom visszafele kompatibilis a dolog szóval nem kell túl sokat várni rá.

Szerveroldalról kezdeményezhető push, hogyan lesz visszafele kompatibilis arra kíváncsi leszek.

[ Szerkesztve ]

de ha párhuzamos letöltést akarok, akkor nyitok még egy tcp sessiont. mint ahogy az én firefoxom kapásból hármat nyitott az index kezdőlap betöltésekor.

A több tcp kapcsolat azért is jobb, mert egy csomó terhelésmegosztó ip cím és port szám alapján is szétpakolja a terhelést. Például ha egy digis előfizetésről speedtest-telsz, akkor a speedtest.net egy szálon egy kapcsolattal tesztel, a digi saját speedtestje meg vagy 8-on, és lényeges különbség van a mért sebességek között (nálam mostanában 10-12 megabitet mérek az idegen speedtesttel, és 75-82 között a digissel). komolyan hiszek benne, hogy az összes cég, aki nagyobb sávszélességű csomagot árul, digi és upc kifejezetten ide értendő, az valamilyen terhelésmegosztással, több gerinchálózati vonallal hozza el a forgalmat, és ennek nagyon betesz az a fajta multiplexelés, amiről a poszt szól.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nem így értem, gyors neten is látványos a difi, de azért, mert az oldal erre van kihegyezve, hogy millió, ma lassú http paranccsot hajtasson végre. Élő web programozó így nem ír meg egy oldalt sem. És nem tudnék olyan oldalt mondani, ami ilyen lassan töltene be, mint itt a http 1.x-es példa. Erre értettem, hogy kíváncsi leszek a valóságban lesz-e valami értelme, mert ez alapján egy index.hu-t átrakni http2-re nagyjából semmi érezhető gyorsulást nem hozna user oldalon, mert ennyire azért nincs elcseszve a kódja.

''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''

"de az draga (tobb handshake, nagyobb overhead, nagyobb connection pool a szerveren)": ezt vitatnám. párhuzamos végrehajtás esetén kb. ugyanannyi idő a handshake, mivel gyorsabban lezajlik a lap kiszolgálása, hamarabb felszabadulhatnak az erőforrások, összességében ugyanannyi vagy kevesebb erőforrás kellhet hozzá.

"egy session-t azert nem szoktak szetdobalni tobb upstream szerverre": mint a példa alapján sejteni lehet, nem a szerver oldali terhelésmegosztókra céloztam, hanem a hálózatira. a hálózati terhelésmegosztókon egyértelműen hátrányban van az egy sessionos verzió, mint azt a mérési eredmény is mutatja.

"a speedtest es a szolgaltato sajat sebessegmeroje kozt pedig elsosorban azert szokott akkora kulonbseg lenni, mert utobbi esetben nem lepunk ki a szolgaltato halozatbol": ez megint vita tárgya lehetne, hogy konkrétan a diginél az a speedtest a gyorsabb, amit dunaújvárosban futtatnak, vagy a matávos, ami pesten a bix mellett van közvetlenül. egyértelműen az látszik, hogy egy-egy session nem tud 10-12 megabitnél többet elérni, de ha ebből 8-at összenyalábolsz, megvan az előfizetési korlát.

"de meg ha valoban jelentene is jelentos sebessegnovekedest a tobb kapcsolat, az nem a http-nel fog kijonni": ott kijött.

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

te nagyon nem akarsz elszakadni a webszervertől.
nem csak webszerver frontend terheléselosztó van, hanem például bérelt vonali is. például a digi pesti központi routeréből sem egy darab egy gigás linken jön a forgalom debrecenbe, hanem több egy gigáson vagy több 10 gigáson. az upcnak is van vagy 2-3 10 gigás linkje a 9. kerületi kinizsi utcai központjából a debrecen petőfi téri központjáig.

és ha több a link, kell a terheléselosztás. és ezt a terheléselosztást rontja el az egy sessionben való multiplexelés a több sessionhoz képest.

nekem a sima apacs is 900 Mbps-t tud, úgyhogy a rossz teszteredményekért nem a webszerver és nem a kliens felel, hanem az ócska gerinchálózat.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

A képen szereplő figurák bármelyikét (ideális esetben mindkettőt) tudja valaki hol lehet beszerezni?

"I will become a true hardscoping hitmarking sample text legend."

Go Gopher Blue Squishable

LG Optimus G E975 v20 -> LG G4 H815 V29a-EUR-XX -> Huawei Mate 9(MHA-L29) -> Huawei P30 Pro -> Honor Magic5 Pro