Új hozzászólás Aktív témák
-
PistiSan
addikt
Félek is rendesen, hogy egyszer ha költözöm a szolgáltató rögtön valami natolt ip-t fog adni!
B-teltől kaptam egy akkor marketing levelet, tavaly júniusban.Idézet:
Tisztelt Ügyfelünk!Ezúton szeretnénk tájékoztatni, hogy műszaki fejlesztésünk eredményeként 2014. július 15-i hatállyal Önnek, még biztonságosabb internet hozzáférést biztosítunk.
Ez azt jelenti, hogy a publikus IP címe helyett privát IP címmel használhatja tovább hálózatunkat.
A privát IP cím előnye, hogy sokkal biztonságosabban internetezhet számítógépén.
Ugyanakkor szeretnénk felhívni figyelmét, hogy a privát IP címet használó számítógépek éppen a nagyobb védettség érdekében, biztonsági okokból semmiféle olyan alkalmazást nem használhatnak, amik a számítógépet „szerver” (kiszolgáló) szerepben igénylik.
Az átállással kapcsolatban Önnek további teendője nincs!
Amennyiben mégsem kívánja a jövőben előfizetését privát IP címmel használni, kérjük hívja ügyfélszolgálatunkat a 1442-es telefonszámon.
Igényét jelezheti e-mailben is a hiba@btel.hu címen, ügyfél azonosítójának vagy az internet szolgáltatás használatához szükséges bejelentkezési azonosítójának megadásával és ingyenesen visszaállítjuk jelenlegi publikus IP címét.
Reméljük a jövőben is elégedett lesz szolgáltatásunkkal!
Üdvözlettel:
Business Telecom Nyrt.Rögtön írtam is nekik levelet, de úgy tippelem hogy a felhasználók 99%-a azt sem tudja miről van szó, és szépen be lettek natolva!
-
djgeg
őstag
Elfogyni elfogyott 2011-ben, Viszont az nem azt jelenti, hogy minden IPv4 cím allokálva is van. Ha így lenne akkor már rég nyomnák az IPv6 ot. Amíg gazdálkodni tudnak az IPv4 el addig "szarnak" az egész IPv6-ra consumer szinten.
Szerinted mi lenne a jó áttérési/átállási folyamat? -
djgeg
őstag
Nem gondolnám, hogy ISP oldalon gond lenne, azonban az elszigetelődés kérdése így is adott. IPv4 el fog fogyni. Egyszer biztos. Az után már nem fogsz tudni mást adni mint IPv6 ot. Az, hogy e között milyen átmenet van vagy kellene, hogy majd legyen az más kérdés. Szerintem kezdetnek, a jelenleg összes IPv4 el rendelkező felhasználóhoz hozzávághatnának IPv6 ot is... Aztán a jövőben mehetne csak az IPv6-os cím osztás, így nem lenne "elszigetelődés".
-
bambano
titán
nem azért nem osztogatnak fogyasztói szinten v6-ot (egyébként de, osztogatnak, a t-home 2009 óta teszteli a v6-ot), mert az isp oldalán gond van, hanem azért, mert a tartalomszolgáltatóknál sokáig nem volt.
meg ha egy előfizetőnek csak v6-ot adsz egy olyan világban, ahol a többség még v4-es, akkor elszigeteled.
maradjunk annyiban, hogy ez egy kicsit bonyolultabb kérdés, mint ahogy a kívülállók elképzelik.
-
djgeg
őstag
Az egy dolog, hogy meg az ügyeskedés natolással stb, de ha nem "fájna" már rég menne az IPv6 osztogatása átlag fogyasztói szinten is. Természetes, hogy amíg van és amíg nem szúr annyira az a szög addig nem térnek át teljesen(értem ezt úgy, hogy elhatározás lenne legalább, hogy pl a jövőben csak IPv6 ot osztunk kistb) IPv6-re.
Azt pedig nem állítottam, hogy kapcsoló szerűen menne az átállás... természetes, hogy folyamatosan(OS szinten már rég megoldott az említett dual stack), de lesz áttérés, aki pedig ezt vagy annak az okait, hogy még miért nem dübörög az IPv6 azt tudom sajnálni... No meg, hogy két egymással nem kompatibilis protokolt miért akarunk összehasonlítani egy egymással kompatibilisal... Lényegtelen...
Jó éjt az éjjeli baglyoknak -
bambano
titán
nincs temérdek rendelkezésre álló szabad ipv4-es cím.
évek óta nincs. a legtöbb gerinchálózati szolgáltatóval szabályosan verekedni kell a címekért, és van, hogy ennek ellenére sem adnak.nem véletlen, hogy egyre több szolgáltató kezd el sunyiban natolni meg privát címet osztani, és ha nem raplizol miatta, nem is kapsz többet publikus ip-t (mint user).
az ipv6-ra való átállás meg nem úgy fog lezajlani, hogy puff, kivágják a fenébe a v4-es címeket, hanem úgy, hogy a legtöbb oprendszer dual stackes és egyszerre lesz mindkét címtartományból címe. akinek jut v4, annak lesz, akinek nem jut v4, annak marad a tisztán v6.
-
djgeg
őstag
Na miért is? Szerinted ISP-ék poénból nem térnek át teljesen IPv6 ra? Nagyon nem... Minek térne át teljesen, ha van még IPv4 címe? Nem mintha csak ezért nem térne át teljesen...
(#105) rt06
Ki írta, hogy " le van fedve" a piac?
"ferditesz, hazudsz, hulyezel" oha tényleg? Olvasd már vissza a kommentjeimet? Én konkrétan fogalmazok... ha nem tetszik az, hogy te nem de közbe neked áll feljebb és a fogalmakat is félremagyarázod akkor ez van... Nem tudok vele mit kezdeni."nem, nem ugy mint te, aki mar ketszer behazudta, hogy nem reagal, de csak nem birja ki, hogy lehulyezze megegyszer a masikat" Sok mindent elszoktam tűrni, de a "ferdítést" és a baromságot nem...
Jócakát... -
bambano
titán
-
rt06
veterán
nem, nem, nem elkeszulettol szamitott 2-3 ev, az elobb meg azt irtad, hogy le van fedve a piac nagyja (az a baj, hogy vagy szandekosan trollkodsz, vagy tenyleg nem fogod fel mirol beszelek, es ferditesz, hazudsz, hulyezel ossze vissza)
most en itt befejeztem (nem, nem ugy mint te, aki mar ketszer behazudta, hogy nem reagal, de csak nem birja ki, hogy lehulyezze megegyszer a masikat)
-
djgeg
őstag
Először is. Nem hülyéztelek le. "Szívrohamot ne kapj"
Nem értem a párhuzamot igen... A HTTP1-2 két egymással kompatibilis protokol. Az IPv4-IPv6 rohadtul nem... és még temérdek dolog van ott a háttérben amiért még nem dübörög...(mint az, hogy bőven van még szabad IPv4 cím)
Nem arról van szó, hogy azért írom amit írok mert te nem értesz velem egyet... Egyszerűen a baromságokkal nem értek egyet... Mint a többség fogalmának félremagyarázása("ebben az esetben" meg társai). Vagy barom párhuzam, HTTP2-IPV6 között...Már megint a "szolgáltatót" és ISP... Ha gondolsz valamire írd le azt ne gyűjtő fogalmat használj aztán még cseszd le a másikat mert nem ért... Üzleti előfizetőnek ad szinte bármelyik ha kér (volt ahol ingyen volt ahol plusz pénzért) Inviteltől hang szolgáltatás pl IPv6 on megy az egyik cégnél ahol dolgoztam.
Miért adna vagy térne át egy országokon át nyűló hálózatot üzemeltető ISP t az IPv6 ra amikor szép összegekbe kerülne neki, miközben ott a temérdek IPv4 cím és tartomány ami a rendelkezésére áll?
Bele gondoltál egyszer is, mekkora költségvonzata lehet egy teljes áttérésnek a UPC, T-csoport, vagy Digi-nél? Látszik nem nagyon...(az egy dolog, hogy készek rá és részben folyamatban az áttérés...)Küld ha akarod a személyes infóidat, nem riadok vissza ilyen fogadásoktól... de max a protokol valós elkészülésétől számítva számított 2-3 év.( és pontosítsunk, hogy te Magyar vagy Globál szinten gondolkodsz?
)
-
rt06
veterán
ismet kerlek, mondj egy olyan szolgaltatot (nem hosting, hanem isp), aki az elofizetonek ad ipv6 cimet
utana hulyezz le ilyen eroteljesen csak, ha kerhetnemaz meg, hogy nem vagy kepes felfogni, miert huzok parhuzamot a http2-nek orvendezes es az ipv6 (ipv4 cimek elfogyasa) koruli hype kozott, nem engem minosit (ahogyan az sem, hogy konstans a magas lorol, nulla hatterrel probalsz oltogatni mindenkit, aki nem ert veled egyet)
de hogy megnezzuk, nott-e gerinced is (vagy csak szad), ha szeretned privatban megirom az elerhetosegem, s ha te is igy teszel, en benne vagyok, hogy egy kocka sort felteszek arra, hogy 2-3 ev mulva elhanyagolhato (<10%) mennyisegu lesz azon tartalmak mennyisege, amik elsodlegesen http2 protokollon keresztul erhetoek el
-
djgeg
őstag
Ideges?
Rád nem, csak k-ra nincs kedvem hülyeségekről beszélni értetlen emberekkel... Néz körbe talán egy picit... VPS bérlésnél is már lehet találkozni IPv6 címmel. Vagy épp a normális Szerver hosting szolgáltató már ad IPv6 ot is...de biztos te vagy az agy mert te vagy itt a "jani" kedvence meg kipróbáltad anno amikor elérhető lett... Gratula neked. Csak így tovább. Mint már írtam... Az értelmes emberek felfogták, hogy kihalás (elfogyás) alapon fog a nép áttérni IPv6-ra globális mértékben...
(Logout-os bejegyzésedkor tényleg azt vártad el, hogy a "megjelenése"(elérhetősége után) hatalmas tömegek térnek majd át? Gratula...
)
Írhatsz még pár értetetlen kommentet de már nem reagálok rá. -
rt06
veterán
jolvan bubi, latom ideges vagy, meg nagyon okos, sztrokot ne kapj az en kontomra
az elso bekezdesben irtak amugy szepek, meg minden, de mi koze a weblapok cserejehez?
az ipv4/ipv6 temat meg ugy-ahogy ertem, a lenyeg nem ez volt, hanem az, hogy annak is hogy orult mindenki, aztan mutass olyan magyar szolgaltatot, aki ad neked 6-os cimet
-
djgeg
őstag
Már megint magyarázkodhatom neked?
Nagy forgalmú weboldalakkal rendelkező cégek általában saját vagy bérelt webszerverrel rendelkeznek... (tapasztalataim szerint). Egy nagyobb fejlesztés vagy komplett cserekor szokott mindig előjönni még egy csomó kérdés. Többek között véleményem szerint egy HTTP2 kompatibilitás story is valószínű itt jönne elő mint más esetben...IPv4 tartományt nagyon ide kellet keverni
Ha úgy vesszük 2011 ben "elfogytak"(kiallokálták az utolsó tartományt) ami természetesen nem azt jelenti, hogy nincs több éppen nem használt IPv4 cím vagy tartomány... Nehéz felfogni tudom. Ahogy azt is, hogy gyakorlatilag 2012-től érhetőek el normálisan az IPv6 recordok 2-2.5 éve...
Mivel van még fel nem használt szabad IPv4 tartomány így nem is fog egyhamar nagyobb szeletet hasítani az IPv6. Majd ha kezd ténylegesen elfogyni az IPv4 akkor egyre többen IPv6 ot fognak használni ennyire egyszerű.... Sokkal komolyabb áttérés minden téren egy IPv6 mint egy nyamvadt updatet vagy plugint fel fabrikálni egy webszerverre (úgy hogy közben visszafelé kompatibilis protokollról beszélünk.) de tudom biztos nehéz felfogni. A Legtöbb értelmes ember felfogta, hogy az IPv4--->IPv6 kvázi kihalás alapú. "Meghal"(elfogy) az IPv4 akkor jön az IPv6... Ezért nem is volt "pánik" ilyen téren...ui.: Több "halal folosleges" beszélgetést nem folytatok veled...
-
rt06
veterán
addig halal foloslegesen ugralsz, meg irsz hulyesegeket (milyen weblap lecsereles?), amig a szerveroldali implementaciok nem fedik le a nepszerubb webszerver-eket
korabban rosszul irtam, ujabb iis tamogatja, apache-hoz van modul (bar lehet az csak a spdy-t tudja), nginx csak spdy-t tud - lighttpd-ben meg nem is lesz http2 tamogatas (legalabbis a jelenlegi tervek szerint)a "dalolva teszik magukeva" dologrol meg annyit, hoy az ipv6-rol is ezt mondtak, mikor kethetente lehozta minden masodik it site, hogy elfogytak az ip cimek, aztan nezd meg, mennyien terjedt el
-
-
djgeg
őstag
Az egy dolog, hogy mi van most, viszont idővel le kell majd cserélni a weblapokat így is úgy is. Így a lassan felfogók is el fognak jutni odáig.
Nagy látogatottságú weblapok illetve webshopok, vagy képmegosztók meg önként és dalolva fogják majd magukévá tenni a protokolt, főleg, hogy nem hatalmas erőfeszítés majd, hogy mind két protokollon menjen a szolgáltatás.
(vicces vagy nem 9gag fejlesztésekkel kapcsolatos fórumán már megy az eszmecsere az áttérésről.Igaz ez nem egy hatalmas story de azért érdekes.)
Természetesen ez az egész HTTP2 szerveroldalon az érdekesebb, és értelmes "vezetők" kellenek, hogy jobban terjedjen, de ez az egész csak idő kérdése.
Lényeg, hogy ma jelen állás szerint úgy hogy a protokoll még kész sincs ( és valószínű 1-2 évig nem is lesz) már az internet felhasználók több mint 50% alkalmas a használatára.IE témában hál isten nem vagyunk egyedül
-
Nem nehéz felfogni, cak a cégek nagy része nem engedhet meg magának 20% látogatóveszteséget egy protokoll miatt. Pénzt kiadni meg nem nagyon szeretnek, ha amúgy működik az oldaluk. Szóval amíg 99 körüli nem lesz a támogatottság, nem fognak.
Nem józan ésszel kell hozzáállni, hanem úgy, ahogy a cégek szoktak ilyen helyzetben.
meg lesz egy rakat cég, aki azután sem, mert aki erről dönt, azt se tudja, mi az a http.
Az IE részesedéscsökkenését én is üdvözlöm
-
fordfairlane
veterán
Szerintem már most érdemes foglalkozni vele. Lehet. hogy csak egy plusz webszerver modult kell belőni, és annyi. Akinek a böngészője támogatja az új protokollt, az egyből élvezheti is az előnyeit.
Persze egy alapos tesztelés nem árt, de mivel a HTTP/2 protokoll úgy van kitalálva, hogyha a böngésző nem támogatja azt, akkor a kiszolgálóval HTTP/1.1-ben kommunikál, ezért nem kell várni arra, hogy a kliensek túlnyomó többségbe (9x% fölé) kerüljenek.
-
djgeg
őstag
Most komolyan ennyire nehéz felfogni? Protokol váltás nem egyről a kettőre megy! Stim... Van átmeneti időszak, de arra várni, hogy a felhasználók "többsége" (szerintük 99.5%.... ) alkalmas legyen a prtokol fogadására és használatára, hogy egyáltalán neki álljon az ember a szolgáltatását kompatibilisá tenni az baromság.
A Felhasználónak nem kell értenie hozzá. A Chrome automatikusa updatel internet használat esetén és máris http2 ready... A többi böngésző is adaptálni fogja, de már ma a felhasználók tényleges többsége (50% fölött) alkalmas a protokol használatára.... MINDEZT ÚGY, HOGY A PROTOKOL MÉG KÉSZ SINCS....(véglegesen)Amúgy Internet Explorer 1/3? 15 nagyon max 20% és csökken... Hál istennek... Mind az Internet explorer és a Firefox % kai évről évre csökkennek és a Chrome-é meg nő... "érthetetlen" okokból
-
-
djgeg
őstag
Trollkodás az, ha a "Többség" fogalma számomra lefedi a felhasználók 60-70%-kát és e közben nem értek egyet azzal, ha valaki a "Többség" fogalmát rá akarja húzni a 99.5%-ra?
Szerintem nagy gond van nálad a trollkodás fogalmával is...de hagyjuk ezt az egészet mert hasonló értelmes eszmecsérre fogalmakról nincs türelmem....
Protokoll téren meg ugyan arról beszélünk... Ezek mellet pedig akinek nem elég az, hogy a felhasználók 60-70% ka már most ready a http2 re akkor nem tudom mi lehet elég ahhoz, hogy legalább nézzen körbe a témában.
(#91) bambano
Azta de k-ra hackelni kell... 34 től benne van csak engedélyezni kell... A következő 36 os verzióban pedig benne lesz alapértelmezetten engedélyezve., De még mindig nem arról megy a fáma, hogy csak HTTP2 re kell áttérni és le kell szarni az 1 et... Hanem arról, hogy ha úgy vesszük akkor a internet felhasználók 60-70% ka már ready rá... Még ha csak a chrome 50-60% kát is vesszük csak alapul... Úgy gondolom ezek után rohadtul nem ez az akadájozó tényező... főleg hogy még be sincs fejezve a nyamvadt protolol... de már a felhasználók többsége ready használni..."Firefox added experimental support for HTTP/2 in version 34,[45][46] although not by default. HTTP/2 was enabled by default in Firefox 36.[47] Firefox only supports HTTP/2 over TLS.[20]"
-
rt06
veterán
"Jó lenne ha tisztáznánk az általános fogalmakat..."
jolenne, ha megtanulnal olvasni trollkodas helyett
a forumtars ha nem is tulnyomo, de nagy tobbseggrol irt, es igaz, hogy az sincs 99.5%, de az sem art, ha a kiindulasi problemat erted, es fel tudod fogni elso nekifutasra, miert nem eleg a ket emlitett bongeszo 60-70%-os piaci reszesedesea protocol fallback pedig nem agysebeszet kerdese, hanem definialva van, mikent kell megvalositani
-
djgeg
őstag
A "Többség".... Jó lenne ha tisztáznánk az általános fogalmakat... A többség az több mint 50% Az nem 95%.... nincs ilyen, hogy ebben az esetben... Azt max túlnyomó többségnek lehetne nevezni... 95% meg a büdös életbe se lesz "ebben az esetben" főleg nem....
Az meg tényleg más kérdés, hogy a kompatibilis protokolt figyelembe venni/ user nem agysebészet... és nem ez az indok a HTTP2 protokol el ne terjedésére.
-
rt06
veterán
60-70% nem nagy tobbseg, nagy tobbseg ilyen esetben (ahol a latogato kiesese tobbnyire bevetelkiesest is jelent) 99.5%, ahol annak a fel%-nak mar lehet mondani, hogy hasznalj mast
persze ennek igazabol nincs jelentossege itt, mert normalis implementacio eseten ugy kell mukodnie a dolognak, ahogy irod (handshake alatt le kell beszelnie a szervernek es a kliensnek a tamogatott protokollokat)
-
djgeg
őstag
Már ne haragudj de a Firefox és a Chrome az mi szerinted?
" böngészők nagy többsége " A Chrome és a Firefox már lefedte neked a 60-70% kát a netezőknek... Egyébként nem hiszem, hogy baromi nehéz lenne kivitelezni azt, hogy érzékelve a böngészőfajtát megy az épp kiválasztott protokol.
-
caprine
senior tag
Szerintem én megvárom amíg a böngészők nagy többsége fogja kezelni, és már csak akkor foglalkozok vele. Addig elég ciki lenne ha az űgyfélnek nem jönne az oldal.
-
brd
nagyúr
Esetleg ki lehetne bővíteni a cikket, hogy Operával is működik (a Chrome-bázis okán), a következő opciót kell bekapcsolni hozzá (ahogy írják is, ha valaki Operával támadja a linkeket):
opera://flags/#enable-spdy4
(vagy amit konkrétan ajánlanak, ha nincs bekapcsolva, az is működik:
chrome://flags/#enable-spdy4).
-
BazsiBazsi
aktív tag
Nagyon jóság
verethetik rá a netre ezerrel
-
pakriksz
őstag
nem semmi. 0 latencynél érzékelhető a legnagyobb különbség.
-
#56474624
törölt tag
Szerintem meg nem, ugyanis ezt nem a cache-ből tölti be. Elsőre ugye semmiképp, viszont ahogy észleltem, másodjára, harmadjára sem, de legalábbis nincs különbség sebességben az első és az akárhányadik betöltés között. Ellenben a http2 javára már van, markáns különbség. Méghozzá SSD-n. Sokan azt hiszik, hogy az SSD mindenható, de nem, szimplán csak gyorsabb - amikor épp szerephez jut- a rég elavult HDD-nél. Egyébként továbbra is nagyságrendekkel elmarad a memóriától, processzortól.
-
-
brd
nagyúr
Valamit elnéztél (esetleg elállítottál), a speedtest.net is több szálon tesztel. Továbbá az eredmény is kb. ugyanannyi (talán a digis gyorsabb egy hangyafasznyival - pár10, talán pár100 kb talán -, valószínűleg azért, mert az nem megy ki a hálózatukból). Továbbá2: simán 1 FTP/HTTP szálon (1 TCP kapcsolat) is hozza az előfizetés szerinti max. közeli sebességet (DL/UP irányban is).
-
MaUser
addikt
Na pont ez a gond. Ha az ő szerverüket nézem semmi nem garantálja hogy valid a tesztjük és nem egy kihegyezett valami. Ezért mondtam, hogy nagyjából így semmi értelme, csak egy rossz case study, amit nem illik csinálni.
Javaslatodra ezért kiválasztottam a golang-on egy aloldalt, ahol vannak képek, szintén nem arányos a render time a http1 példával. Nyilván erre is lehet mondani, hogy másik szerver, de valahogy csak a példa oldaluk a lassú...
-
Egon
nagyúr
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).
Kb. csont ugyanazt mérem a speedtest-en, mint a digi saját mérőjén (217,3/54,3 vs. 219,1/53,8 MBit fel/le).
-
rt06
veterán
ok, akkor elso korben felejtsd el az index-et
valoszinuleg kozelebb is vagy hozza, meg abbol kiindulva, hogy a hirben szereplo teszt rendre bedol, kisebb is rajta a terheles es/vagy nagyobb van van alattakizarolag a hirben szereplo tesztet nezd, azt is csak firefox, vagy chrome bongeszovel
itt talalsz 8 linket, azokat kell soronkent parban osszehasonlitani (a bal oldali rendre http/2, a jobb oldali http/1.x)
a sorokon lefele haladva egyre nagyobb latency-t allitottak be, ezzel szimulalva, hogy pl tavolabb levo szervertol kersz adatotamit eddig csinaltal, az kb olyan, mintha valaki az gazos/dizeles/benzines suzukijarol irna tesztet, hogy melyik gyorsabb, te meg csak vakarnad a fejed, hogy a te mercedeszedhez kepest mindegyik lassu mint a szemet
-
MaUser
addikt
Jogos, de mivel már nulla késleltetésnél és kérdőjeles, hogy van-e a gyakorlatban tényleges előnye, nincs értelme a többi tesztnek sem jelen formájában. A tesztnek úgy lenne értelme, ha egy élő weboldalon mutatják be. Ez így egy "artificial case study" (lásd alább a gondom) amivel ugye nem prezentálunk semmi, mert nem real-world szitut mutat be.
rt06: A tesztet nem tudom értelmezni. Az index.hu-n amikor néztem volt hetven valahány kép lekérése. A tesztoldalon van 180. Ennek ellenére nulla késleltetésnél is az jön ki, hogy az index.hu a millió egyéb forrással is kb. 8x gyorsabban bejön, mint a nulla késleltetésűnek szánt http1-es tesztoldal. Innentől kezdve viszont nem értem, mivel az index.hu-nak max. kétszer gyorsabbnak szabadna lennie a lekérések száma miatt, de inkább lassabbnak, mert azon ugye fut még millió más is a 7x képlekérésen kívül. Szóval valami nem kóser a teszt kapcsán mert úgy néz ki iszonyatosan optimalizált a http jelenlegi gyengeségére. Erre próbáltam rávilágítani.
-
iSheep
csendes tag
"(...) é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 (...)"
Latnok vagyok, itt fognak eloszor biztonsagi rest talani a "bunozok". -
szaszlaci
addikt
HTTP/1, 0 latency = 5 mp
HTTP/2, 0 latency = 2 mpHTTP/1, 1s latency = 23 mp
HTTP/2, 1s latency = 2 mpHa ez ilyen jó a gyakorlatban, úgyis kapunk valami ostobaságot, ami majd lassítja a gépet. Ha a flash nem lenne elég.
-
fordfairlane
veterán
Nem tudom, mi a bajotok az index.hu-val, az még a jobbik fajta.
index.hu: 100 request, 5,06 sec, 7,68 MB
origo.hu: 300 request, 16,56 sec, 13,56 MB
444.hu 330 request, 20,88 sec, 27,65 MBA hirdetések változnak, úgyhogy van némi szórás, de nagy átlagban kábé ilyen.
-
Tharkoul
tag
A cikk felső részében lévő linkek között semmi különbséget nem láttam. Tényleg nem, ugyanúgy töltődött be az összes. Viszont az alul szereplő "Így aztán mondhatni kötelező a kipróbálás – megdöbbentő a gyorsulás!" az tényleg jól mutatja, hogy döbbenetes a változás. Igen, még 0ms latency mellett is, hát még ott, ahol egy teljes másodperc volt. 2.23s vs 34.698s. Végre nem kellene percekig nézni a kínai oldalakat, míg végre méltóztatik betölteni.
-
PistiSan
addikt
Ha a 0 késleltetést nézted, akkor pont nem sikerült értelmezned, miért is jó az http2, nyilván a 0 késleltetésnél is jobb lesz nagyobb oldalaknál, de ahol több a késleltetés ott lényegesen jobb eredményeket produkál.
Elhiszem hogy aki 4G-n netezik, annak nem igazán van késleltetése, de vannak még területek ahol a 3g sincs mindenhol, ott nagyon látványos hatása lesz a http2-nek. -
MaUser
addikt
válasz
dragon1993 #58 üzenetére
Nem, direkt a nulla késleltetésűt nézem Chrome alól. A tesztoldalon van durva különbség, de egy kb. fele annyi képet (és még plusz kismillió mindent) tartalmazó index.hu betöltésénél viszont már nincs érdemi különbség a betöltési időben.
-
-
Dr. Akula
félisten
Nálam nincs semmi különbség a 0 és 1 sec latency közt, ilyenkor mi van? Túl jó a gépem hozzá?
-
bambano
titán
olvasgatva ezt a webet, kiderül, hogy a cikk első része téves.
nincs elfogadott http/2 protokoll, nincs felújított szabvány, stb."A protokollt gondozó Internet Engineering Task Force (IETF) tegnapi blogbejegyzésében adta hírül, hogy elfogadták a HTTP/2-t, ami az átviteli szabvány legnagyobb frissítése az elmúlt 15 évben.": ez a mondat téves.
Az ietf nem a szabványt fogadta el, hanem elfogadta, hogy a szabványtervezetet elindíthatja a szabványosítás felé vezető úton. jelenleg a szabványtervezet internet draft állapotban van augusztus 15-ig. A szabványosítással foglalkozó bcp tizedik oldalán kifejtik bővebben, hogy mi ez az internet standards track:
Specifications that are intended to become Internet Standards evolve through a set of maturity levels known as the "standards track".These maturity levels -- "Proposed Standard", "Draft Standard", and "Standard" -- are defined and discussed in section 4.1. The way in which specifications move along the standards track is described in section 6."
-
oraihunter
aktív tag
Hm... ez tényleg klafa,
csak aztán valóban így is működjön majd.!
-
MaUser
addikt
Ahh, most nézem, hogy az index.hu még ehhez a próba oldalhoz képest is jobb. Valami itt el van cseszve a teszttel. index.hu főoladal 74 <img> tag-et tartalmaz, a példa 180-at, mégis az index.hu kb. 8x gyorsabban jön be nálam, pedig ott van bőven tartalom még és várni kell amíg adblock is szűr. Ezt így akkor nem értem.
-
djgeg
őstag
Most komolyan az egész HTTP2 létjogosultságával szállsz "vitába"? Szerintem azért a IETF-nél nem szarral gurigáznak tudás és rálátás színjén, ezek mellet valószínű nekik van nagyobb betekintésük akár hálózat összetétel vagy terheltségi statisztikákra nem, hogy Magyar viszonylatban hanem világ szinten.
Szerintem ez tökéletesen összefoglalja. Azzal lehet vitatkozni, hogy szerinted előnyösebb a több session... de szerintem egyikünk se lát rá a témára akkora részletestességgel mint azok akik ténylegesen csinálják az IETF-nél...
"With HTTP/1, browsers open between four and eight connections per origin. Since many sites use multiple origins, this could mean that a single page load opens more than thirty connections.One application opening so many connections simultaneously breaks a lot of the assumptions that TCP was built upon; since each connection will start a flood of data in the response, there’s a real risk that buffers in the intervening network will overflow, causing a congestion event and retransmits.
Additionally, using so many connections unfairly monopolizes network resources, “stealing” them from other, better-behaved applications"
-
jengab
tag
Leginkább már annak lenne ideje, hogy végre állapotteljes legyen a protokol, és akkor el lehetne felejteni a cookiekat. Amúgy is nagyon sok probléma forrása ez.
Egyébként a cache nem hordoz biztonsági hibát magán, ameddig nem lehet ráadni a vezérlést nyugodtan szabad tárolni bármit local gépen.
-
Tutu7030
veterán
-
=WiNTeR=
senior tag
A képen szereplő figurák bármelyikét (ideális esetben mindkettőt) tudja valaki hol lehet beszerezni?
-
rt06
veterán
"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."
ok, akkor most azt meseld el, hogy a debreceni petofi teren hany vegpont kapcsolodik a nehany (nehany tiz) vonalra, amik kozott el kell osztani a terhelest?
mert erosen ketlem, hogy annyira keves, hogy problemat okozzon az, ha egy user forgalma egyben, egy tyukbelen szalad fel pestig, s nem lehet feldarabolni (ez ugye azt jelentene, hogy az upc meg a digi annyira hulye, hogy 3 user-re huz ki 10 kabelt)az viszont nekik sem mindegy, hogy az N darab user X forgalmat produkal Y szalon, vagy X*.8 forgalmat N(=Y/10) szalon, egesz addig, amig N jelentosen nagyobb, mint a linkek szama, mert ekkor meg ugyanugy el tudjak azt a forgalmat osztani, viszont felszabadul 20%-a a savszelnek (mezei bongeszesnel, olyan lobaszo nagy kukikkal, mint amik kimennek manapsag mindenhova, minden egyes request-ben, lehet ez a 20% meg joindulatu becsles)
-
bambano
titán
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.
-
rt06
veterán
mivel egy webszerver altalaban nem egy klienst szolgal ki, igy a parhuzamositas mindenkepp kihasznalasra kerul
innentol pedig igenis dragabb tobb tcp kapcsolatot nyitni egy kliensnekugyanigy, a terhelesmegosztoknak sem egy kliensrol kell gondoskodniuk
a speedtest-nek meg jobban utana kell nezzek, hogy hany, s mi lyen kapcsolatot nyit, de nalam egy szalon (http/ftp letoltes) siman meghaladhato volt mar nem egyszer a 10-12 mbps (mikor foglalkoztam vele, hogy olyan szervert keressek, ahol masik fel is kepes erre a sebessegre)
es igen, kijohet http-nel is amit irsz (mondjuk egy pont ugyanannyira specialis tesztben, mint ami a hirben is szerepel), viszont nem ott fog kijonni tobbnyire
legalabbis amig az ip forgalom java rtmp (video streaming), meg p2p filecsere, addig nem -
bambano
titán
"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.
-
rt06
veterán
"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."
de az draga (tobb handshake, nagyobb overhead, nagyobb connection pool a szerveren)"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."
egy session-t azert nem szoktak szetdobalni tobb upstream szerverre (de meg ugyanattol a klienstol jovo tobb session-t sem annyira)a speedtest es a szolgaltato sajat sebessegmeroje kozt pedig elsosorban azert szokott akkora kulonbseg lenni, mert utobbi esetben nem lepunk ki a szolgaltato halozatbol
de meg ha valoban jelentene is jelentos sebessegnovekedest a tobb kapcsolat, az nem a http-nel fog kijonni -
bambano
titán
az index.hu nem a http/1.1 miatt egy ócska szemétdomb, hanem amiatt, hogy hetven tonna flash reklám, animáció, index2, meg egy másik kosár javascript fut folyamatosan az oldalon, saját fontokkal, ilyenekkel.
nagyon súlyosan elgurult a gyógyszere az indexes html guruknak és webdizájnereknek.
-
MaUser
addikt
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.
-
bambano
titán
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.
-
dragon1993
addikt
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.
-
rt06
veterán
"a http/1.1-hez képest, ami multiplexelt"
mert a spdy-t a fel vilag hasznalja (plusz ebbol indult a http2 is, plusz nem resze a protokollnak)"és a szerver majd okoskodik, hogy mit tölt le a gépemre. hogy ennek hogy fognak örülni a forgalomlimites userek..."
szerintem itt nem arra kell gondolni, hogy ha betoltod az index honlapot, leszedi neked a teljes napirajz archivumot is, meg par videot is elotolt, hanem olyasmire, hogy elkuldi egy korben az oldal css-et, js-et (amik ugye sokszor nagyobbak, mint a html maga), esetleg a logot, es a html-ben hivatkozott, azon a szerveren talalhato kepeket
-
saelin
veterán
válasz
dragon1993 #29 üzenetére
Ég és föld a kettő!
Mennyi időbe telik, hogy ez elterjedjen? Remélem nem sokba.
-
fordfairlane
veterán
válasz
dragon1993 #29 üzenetére
Ha a HTTP 1.1 és a HTTP 2 között nincs különbség akkor nálad van valami gond.
Az oldal néha eléggé belassul. Mindenesetre örülök, hogy végre kicsit gatyába rázták ezt az ősrégi protokollt.
-
mizu
aktív tag
válasz
dragon1993 #29 üzenetére
~1s egy oldalbetöltés - szó sincs gondról.
-
PistiSan
addikt
válasz
dragon1993 #29 üzenetére
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. -
bunevo
tag
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. -
bambano
titán
"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ó?
-
#10691584
törölt tag
Lehet én vagyok béna, de nem látok túl sok különbséget
-
PistiSan
addikt
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.
-
sTERNI
senior tag
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.
-
Taybore
aktív tag
1.) hibás a cikk végén a HTTP/2 link
2.) nekem a teszt oldalon a HTTP/1-es linkek nem mennek... -
Hiába kapcsolom be, vsz a céges proxy-nk nem támogatha a HTTP2-t...
-
MaUser
addikt
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.
-
Mindenki nyugodjon le, az NSA már rég benne van ebben is
-
mizu
aktív tag
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. -
Chrys_
addikt
Az, hogy a szerver kérés nélkül bármit küldhet a cache-be, nem hordoz biztonságtechnikai problémát?
-
Lacok
őstag
Már ideje volt!
-
macman507
aktív tag
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. -
TeeJay
félisten
jó is lesz végre mert már 50-100-1000megabites netcsomagoknál is látszik hogy néha lomha egy oldalbetöltés
-
Dr. X
aktív tag
A mobilböngészőkön is működik?
-
cheatergs
senior tag
Megdöbbentő sebesség, mert meg se nyitja egyik linket se.
-
Már régóta aktuális volt.
Új hozzászólás Aktív témák
- Xbox Series X|S
- Fényeskedjék: ROG Strix OLED XG32UCWMG monitor tesztje
- eBay-es kütyük kis pénzért
- exHWSW - Értünk mindenhez IS
- Ubiquiti hálózati eszközök
- Synology NAS
- Amazon Kindle JailBreak
- NOTEBOOK / NETBOOK / Mac beárazás
- E-roller topik
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- További aktív témák...
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- AKCIÓ! Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Antivírus szoftverek, VPN
- Nintendo Switch Oled Zelda Edition
- BESZÁMÍTÁS! 64GB (2x32) G.Skill Trident Z RGB 4000MHz DDR4 memória garanciával hibátlan működéssel
- GYÖNYÖRŰ iPhone 13 Pro 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3358
- Apple iPad Air 4 64GB, Újszerű, 1 Év Garanciával
- Bontatlan Lenovo T14S WUXGA Touch Ryzen5 Pro 7540U 16GB 256GB Radeon 740M Win11 Pro 3év Garancia
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest