Google esitteli HTTP:n korvaajaksi tarkoitetun SPDY:n
Hakujätti Google kertoi keskiviikkona Chromium-blogissa HTTP:n korvaajaksi tarkoitetusta SPDY-protokollasta, joka sekä parantaa surffailun nopeutta että tuo lisää tietoturvaa.
Jo kultaisella 90-luvulla käyttöön otettu HTTP-protokolla on edelleen ylivoimaisesti suosituin tapa internet-selaimien tiedonsiirtoon, mutta protokollan suunnittelun yhteydessä ei otettu huomioon kaikkia tulevaisuuden tarpeita, jonka takia HTTP ei sovellu parhaalla mahdollisella tavalla nykypäivän vaatimuksiin.
Googlen avoimeksi standardiksi suunnittelema SPDY tuo HTTP:n verrattuna sekä isoja että pieniä uudistuksia. Ensimmäinen isompi muutos on SSL-salauksen pakollisuus, jonka myötä kaikki SPDY-yhteydet salataan aina. Toinen isompi muutos on Gzip-pakkaamiseen pakollisuus, joka vähentää puolestaan internet-liikenteen määrää erityisesti tekstipohjaisten tiedostojen kohdalla.
Kolmas suurempi muutos liittyy yhteyksiin, joita otetaan ainoastaan yksi per palvelin. Sivujen latausnopeuden parantamista varten kaikki siirrettävät tiedostot jaetaan omiin kehyksiin, jotka voidaan siirtää halutussa järjestyksessä. Tällöin selain voi poimia aluksi sopivat tiedostot (kuten HTML- ja CSS-tiedostot), jotta sivujen renderöinti luonnistuu mahdollisimman nopeasti. SPDY:ssä palvelin voi myös suositella selaimella, missä järjestyksessä tiedostot kannattaa ladata, jotta sivustoa pääsee katselemaan mahdollisimman nopeasti.
Googlen omissa mittauksissa SPDY:n käyttäminen höyläsi parhaissa tapauksissa sivustojen latausajat puoleen, joten potentiaalia protokollassa on valtavasti.
HTTP:n korvaaminen SPDY:llä ei ole kuitenkaan helppo tehtävä, koska tuki pitäisi sisällyttää suosituimpiin selaimiin ja palvelinohjelmiin, joista varsinkin palvelimien kohdalla laskentatehoa vaadittaisiin selvästi lisää, jos tarkoitus olisi palvella samaa asiakasmäärää kuin HTTP:n kanssa. Lisäksi joidenkin mobiililaitteiden kohdalla pakkauksen ja salauksen vaatimaa ylimääräistä laskentatehoa ei välttämättä ole saatavilla, joten kaikkiin laitteisiin ja tilanteisiin SPDY ei ole paras mahdollinen valinta.
12 KOMMENTTIA
tonttila1/12
Suunnilleen ainoa mikä oli selko kieltä, PUOLET NOPEAMMIN LATAUTUVAT SIVUT. Se riittää minulle. Insinöörit hoitakoot loput.
mjk2/12
Jotkut sivut kyllä tosiaan lautautuvat luvattoman kauan, tuntuisi siltä että kaffeet kierkiäisi juoda..
mRkukov3/12
Apacheen toimiva ja tehokas moduuli tätä varten.
+
Selaimiin tuki (firefox, opera, chrome).
=
Voi jopa onnistua.
Tuo kaiken salaaminen olisi kyllä hyvä asia internetin anonymiteetin puolesta. Pakkaus ja muu on kiinni vain konetehoista, joita saa aina lisää.
tonttila:
Insinöörit on hoitanut nyt osuutensa ja luonut protokolan. Nyt tarvittaisiin sille tuki muilta insinööreiltä ja ennen kaikkea verkkovastaavilta. (itseni mukaanlukien)
jhgrc4/12
Mielestäni pahin asia oli: Vaatii enemmän tehoa palvelimilta.
Se on vain niin että palvelimet ovat Internetin pullonkaula. Pingatkaa palvelinta ja hakekaa perään HTTP-sivu sieltä. Ping esim. 200ms ja HTTP-sivun ensimmäinen pätkä 2s. Tuhannet käyttäjät plus dynaamiset sivut monella SQL-haulla tietokannasta ilman minkään tason cacheä ovat no-no.
Ysf5/12
Konetehot lisäävät myös energian kulutusta. Paha arvioida paljonko sähköntarvetta konetehojen lisäyksen tarve kasvattaisi - veikkaisin kuitenkin, että se ei jää esim. yhden ydinvoimalan tuottoon.
Jo nyt 95% sivun latauskosta on epäoleellista iso grafiikkaa, flässiä ja sun muuta, eikä tuo sitä tulisi muuttamaan - itse asiassa voi käydä päinvastoin: Jos lataus nopeutuu, sitten voidaan tukea taas lisää ylimääräistä tavaraa sivulle. Kun muutenkin vilkkuvista flässeistä yms nousee vain vitutuskäyrä niin niiden lisääntyminen ei houkuttelevaa ole.
toki tuossa on se anonymiteetti mutta ainakaan minulla ei nettikäyttö niin salaista ole, etteikö nykyinen https riittäisi.
juuSOS6/12
Samaa mieltä, miksi esim. Afterdawnin tai Iltalehden kaltaisten sivustojen pitäisi olla salattuja? Ainakin itselle riittää hyvin että nettipankit ja sähköpostit ovat SSL:n takana.
Tokihan tuo sivujen 2x nopeutuminen kuulostaa erittäin hyvälle.
__int647/12
+ Vain yksi yhteys kerrallaan (helpottaa palvelinta kummasti)
- salauksen ja kompressoinnin pakollisuus (ei todellakaan helpota ketään)
kolmis8/12
Ihan hyvä juttu jos se toimii.
dRD9/12
Itse asiassa näin verkkosivuja työkseni melkein puolitoista vuosikymmentä hieroneena pakko sanoa eriävä mielipiteeni.
Kun tätä nykyistä v4 AfterDawnia suunniteltiin, törmättiin taannoin Yahoo!n, nykyisin Googlen asiantuntijana toimivan kaverin kirjoittamaan pitkään artikkeliin verkkosivujen latausnopeuksista.
Yhteenvetona oli se, että dynaaminenkin, suosittu verkkopalvelu yleensä generoi sivun alle 200 millisekuntiin (0,2 sekuntia siis). Esimerkkinä vaikkapa meidän v3:n etusivu, näkee tuolta enkkupuolelta vielä, se generoituu noin 120 millisekunnissa, vaikka olisi ruuhka-aikakin. Sitten sivuilla oleva HTML-tieto latautuu käyttäjän selaimelle yleensä alle sekunnissa. Noiden kummankin osan esim. puolittaminen on mahdollista, mutta vaatii hirveän määrän tviikkausta.
Muttamutta, se, että se sivu _rendautuu_ näkyviin käyttäjän selaimessa, kestää meidän v3 etusivulla itse asiassa melkein 10 sekuntia, jos selaimen cache on tyhjä. Ja tuohon vaikuttaa eniten se, miten HTTP kuljettaa datan ja miten selaimet sen käsittelevät -- esim. JavaScript ja CSS "pysäyttävät" selaimen kunnes ne on satu parsittua.
Jos tuo uusi protokolla oikeasti mahdollistaisi sen, että verkkosivu voi kertoa selaimelle, mitkä elementit ladataan ensin ja missä järjestyksessä, voitaisiin sivut ilman mitään kikkailua tehdä niin, että ne ovat heti luettavissa, vaikka stylesheetit, jne vielä latautuisivatkin. Tämä nykyinen v4:hän on pitkälti tehtykin noin, mutta silti tietyt HTTP:n rajoitteet on pitänyt "hackata" ohi, mm. jakamalla kuvat usealle eri subdomainille, että sivujen rendautuminen saataisiin mahd nopeaksi.
Yleensä pullonkaula sivujen rendautumisessa ei siis ole palvelimessa, eikä edes kuvien/CSS:ien/JavaScriptien siirrossa, vaan siinä, miten selaimet rendaavat sivut, mitä elementtejä ne odottavat kunnes sivu näkyy, jne.
Eli yhteenvetona: www-kehittäjän näkökulmasta olen ehdottomasti Googlen kannalla tässä. Tosin tuo salauksen pakollisuus on vähän "täh"..
ByteHeave10/12
Kuulostaa hyvältä näin päällisin puolin katsoen. Pari metakommenttia kommentteihin:
Virrankulutus: Huomatkaa että myös datan kuljettaminen kuluttaa virtaa -> pienempi kuljetettava datamäärä = vähemmän sähköä. Se mikä on nettosumma on sitten tarkemmin asiaa tietävien laskettava.
Tehontarve: Mooren laki huomioiden tuskin ongelma vähän ajan päästä. Ennen kuin tuollainen muuttuisi standardiksi jota kaikkialla käytetään vie aikaa, joten teho-ongelma ratkeaa matkalla.
Salauksen pakollisuus: Hmm, ehkä joskus turhaa, mutta yleistä tietoturvaa ajatellen. Useimmat ihmiset käyttävät samoja salasanoja eri palveluissa, tällöin ns. "turhan palvelun" kaappaaminen välistä ei paljastaisi salasanaa kaappaajalle, joka käy ehkä useampaan kohteeseen.
Verkkoturvallisuus: Voisin kuvitella että DOS hyökkäysten tekeminen vaikeutuisi merkittävästi. Palvelimet ja reitittimet kun voisi konffata kylmästi tiputtamaan jos yksi asiakas ottaa enemmän kuin yhden yhteyden. (ok vaikka muutamakin sallittaisiin, ei yksi bottiverkon kone enää kykenisi toteuttamaan miljoonia kyselyitä sekunnissa, jolloin onnistunut DOS vaatisi oikeasti koko internetin sisältävän bottiverkon...)
Ja jos tuo yhdistettäisiin seuraavan sukupolven muihin protokolliin yms. voitaisiin saada oikeasti parempi internet :)
Junafani11/12
Mainokset ensin ja sitten vasta se turhempi sisältö?
dRD12/12
Itse asiassa juuri toisinpäin :-) JavaScript, jolla mainokset yleensä avataan, on yksi noista selaimen rendauksen pysäyttävistä palikoista. Sen vuoksi esim. AfterDawnissakin latautuu nykyisin sisältö ensin ja mainokset & muu JavaScript vasta lopuksi.
TÄMÄN UUTISEN KOMMENTOINTI ON PÄÄTTYNYT