Viiveiden vähentäminen WWW-liikenteessä

Esitys aiheesta: "Viiveiden vähentäminen WWW-liikenteessä"— Esityksen transkriptio:

1 Viiveiden vähentäminen WWW-liikenteessä
Pyry Aaltonen Espoo Valvoja: Dos. Kalevi Kilkki Ohjaaja: DI. Pasi Sarolahti

2 Sisältö Työn tausta ja tutkimusmenetelmät
Työssä käsitellyt protokollat Tulokset Johtopäätökset

3 Tausta ja tutkimusmenetelmät
Internet protokollat vanhoja Maailma muuttunut Protokollien aiheuttamat viiveet keskiössä Kirjallisuuskatsaus ja vertailututkimus protokollien ominaisuuksista ja mahdollisuuksista. TCP 1981 UDP 1980 IP 1981 IPv6 1995 HTTP1/1b 1997 Viiveet, jotka aiheutuvat nykyisten protokollien rakenteellisista ominaisuuksista alkavat olemaan nykyisten viiveiden maailmassa merkittäviä. HTTP2 vähintään 2krt nopeampi, parhaimmillaan noin 10kertaa nopeampi.

4 Protokollat HTTP/1.1 – Hypertext Transfer Protocol HTTP/2.0 Binäärinen
Viestivirrat HTTP hypertext transfer protocol, WWW-teknologian perusprotokolla Ihmisluettava, paljon toistoa, otsakkeet merkittävän isoja. Käsittely “hidasta” HTTP/2.0 Standardi Binäärinen, kutsut säilyivät kuitenkin, 404 not found on edelleen. Remontti pellin alla, toimintamalli uudistui.

5 Protokollat TCP – Transmission Control Protocol
QUIC – Quick UDP Internet Connection UDP Viestivirrat TCP Transmission Control protocol Quick UDP Internet Connection – QUIC Vasta Draft Tarkoituksena nopeuttaa eriyisesti kättelyä ja keskittyä ylipäänsä HTTP yhteyden tarpeiden nopeuttamiseen.

6 Tulokset HTTP SPDY HTTP/2.0 Alustava esitys, joka loi pohjan
Uudistettu toimintamalli Server-push Viestivirtojen limitys Otsakkeiden pakkaus SPDY Googlen esitys esitteli viestivirrat esitteli käytännössä kaiken muunkin kuin HTTP, panosti kuitenkin lähinnä nopeuteen, eikä niinkään täydelliseen toimivuuteen. Tietoturva puoli sai melkoista kritiikkiä HTTP Server push – serveri lähettää asiakkaan tarvitseman datan ilman pyyntöäkin Viestivirtojen limitys yhden yhteyden sisään. Korvaa http-pipelining kikkailut, helpottaa tcp:n toimintaa koska liikenne tapahtuu aidosti yhden yhteyden sisällä. Otsakkaiden pakkaus – HPACK – HTTP protokollassa otsakkeet toistuvat monta kertaa yhteyden aikana, pakkaus kannattaa.

7 Tulokset QUIC Nopea kättely Viestivirta ja yhteyden monitorointi
Käytännössä vähintään yhtä nopea kuin TCP Viestivirta ja yhteyden monitorointi Asiakkaiden tunnistus viestivirtojen avulla Jokaiselle paketilla oma järjestysnumero Suunniteltu yhdessä HTTP/2.0 kanssa Pyrkii toteuttamaan yhteydelliselle verkkoprotokollalle tarpeelliset palvelut UDP:n päällä. Kättely toteutetaan evästeillä jotka tallennetaan asiakkaan muistiin. Mahdollistaa suoran yhteyden aloituksen, ilman kättelyä. TCP:stä löytyy TCP-Fast open tekniikka joka tarjoaa käytännössä saman. Jokainen paketti saa oman järjestysnumeron, tämä helpottaa vikatilanteissa lähetysnopeuden säätelyä. TCP:ssä uudelleen lähetyt paketit saa alkuperäisen lähetysnumeron, koska luotettavuus vaatii sitä. Asiakkaan tunnistuu viestivirtojen pohjalta, Verkkoyhteyden katkaisu ei haittaa, vaan lähetys voi jatkua uudella yhteydellä kunhan viestivirtatunnus säilyy. Lomitus paranee, rinnakkaisia viestivirtoja, joilla itsenäinen ruuhkanhallinta ja virheenkorjaus. QUIC voi korvata HTTP/2.0 viestivirran hallinnan, ruuhkanhallinta, lähetysnopeus jne.

8 Johtopäätökset HTTP/2 protokolla on onnistunut uudistus QUIC
Raju optimointi HTTP/2 protokollalle HTTP2: Hyvät uudistukset: -Binäärisyys, -Viestivirrat, -Nopea yleistyminen: kaikki selaimet,monet palvelinohjelmistot Googlella paljon omaa testidataa. QUIC käytössä esimerkiksi googlen omissa palveluissa. Työn kirjoitusaikaan julkaistu yksi Italialainen vertailu tutkimus, joka sekin hyvin rajattu Laajoja tutkimuksia, protokollien toiminnasta, mobiiliverkossa Wlan verkossa, yms kaivataan.

9 Tulevaisuuden tutkimuksen kohteita
Testauksia uusien protokollien toiminnasta QUIC+HTTP/2 QUIC+HTTP/1.1 TCP+HTTP/2+TLS TCP+HTTP/1.1+TLS WLAN Mobiiliverkko Testejä esim: QUIC+HTTP2 / QUIC+HTTP1.1 / TCP+HTTP2+TLS / TCP+HTTP1+TLS WLAN Mobiilidata Huonosti toimivat yhteydet? Koska QUIC tukee istuntokohtaista lähettämistä, olisiko se parempi ratkaisu käyttäjille huonojen yhteyksien päässä?

10 Kiitos Kysymyksiä?