Kuidas ma näen, et see HTTP/2 ikka töötab?

HTTP/2 peaks muutma brauseri ja serveri suhtluse kiiremaks ning netist leiab nii kenasid demosid selle tõestuseks (nt Akamai, Gophertiles) kui võimalusi kontrollida HTTP/2 toe olemasolu oma veebil (nt keycdn).

Kuna kõigil Zone HTTPS-iga Virtuaalserveritel on nüüd HTTP/2 vaikimisi lubatud (vt: Järgmine veebilehtede turbonupp sisse lülitatud: HTTP/2) siis … kuidas näha, et see ka tegelikult toimib ja midagi kiiremaks teeb? Ja kust ma üldse näen, et brauser HTTP/2 ühendust kasutab?

Võttes nt zone.ee esilehel lahti brauseri inspektori (paremklõps > Inspector > Network), lisades kuvatavate veergude hulka Protocol’i ja laadides lehe uuesti peaks avanema selline pilt:

inspector-protocols-h2-spdy-1.1Nagu näha on enamus ühendusi h2 ehk HTTP/2, aga näha on ka mõned välised vanemaid protokolle kasutavad CDNid (millest ilmselt võiks nüüd loobuda, vähendamaks tehtavate ühenduste arvu).

HTTP/2 nähtav ja demotav kiiruse-võit tuleb sellest, et brauser saab küsida kõik lehe kuvamiseks vajalikud pildi/stiili/skripti-failid serverilt ühe TCP-ühendusega, määrates ühtlasi ära nende olulisuse. Server saab saata vastused parimas võimalikus järjekorras ning eriti nutikas server võib juba algsele päringule vastates anda kaasa nimekirja vajalikest lisafailidest ja need ühe hooga ka teele panna.

Kui viimane variant ehk server push välja arvata, ei vaja efektiivsem ühendus täiendavat seadistamist ehk HTTP/2 sisselülitamisega hakkasid kõik senised Zone Virtuaalserverite turvalised HTTPS-ühendused kasutama uut protokolli (kuigi teoreetiliselt toetab HTTP/2 ka mitte-turvalist ühendust on brauserivalmistajad öelnud, et nemad seda toetama ei hakka).

Lihtsaks testiks sattus näppu Eesti E-kaubanduse Liidu e-poodide sooduskampaania E-smaspäev, mille lehelt leiab 128 ühesuurust logo.

Välistamaks kõiki muid mõjusid genereerib lihtne skript (vt repo GIThubis) neist igal lehe-laadimisel unikaalsete nimedega pildipilve, täpselt sama skript on nähtav kolmelt URLilt:

Erinevuse nägemiseks tasuks seda teha mõne mobiilse või muul põhjusel mitte-kõige-kiirema ühenduse abil, sest kiire fiiberoptika otsas on päringu ja vastuse vahele jääv viivitus pea olematu.

Testides 10Mbps koduse ADSLi ja WiFi abil näeb erinevus välja selline (sedapuhku laetakse 2 komplekti logosid):

See katse pole mõistagi eriti teaduslik (kes teab mis mu koduvõrgus veel toimus, kogutud pole piisavalt andmeid ja arvutatud standardhälbeid) – aga video on lõikamata ja 5+5 järjestikust laadimist annavad empiirilise eelise HTTP/2 versioonile. Nagu laadimise mustrist näha tulevad HTTP 1.1 puhul pildid vastavalt brauseri poolt paralleelselt saadetud päringutele trobikondade kaupa, HTTP/2 puhul aga korrapäraselt järjekorras.

Millega veel testida? www.webpagetest.org Lubab katsetada erinevatest asukohtadest, Ardil on tavaks proovida Prahas oleva serveriga, tulemused sellised:

HTTP 1.1:

http1-ardi

HTTP/2:http2-ardi

Selle testi järgi annab HTTP/2 ca 26% võitu lehe laadimise kiiruses. Aga paraku on numbrid võrdlemisi ebastabiilsed, miska … olgu, lisame testlehele ka kiiruse mõõtmise performance.timing abil… Ja kordame vidos näha olevat eksperimenti ehk laeme üle 4G telefoni jagatud WiFi vaheldumisi kahte lehte, tehtud sai 39 laadimist ning tulemused on sellised:

HTTP 1.1  – keskmine 2281ms, mediaan 1815ms
HTTP/2 – keskmine 1682ms, mediaan 1315ms

Ehk siis HTTP/2 oli ka selles testis 26-28% kiirem kui HTTP 1.1, lisaks stabiilsem – kui välja arvata need kaks katse pikimat laadimisaega:

http1-http2-graph

(kellel huvi testi korrata, siis kood on GIThubis ja soovi korral võin reeta ka logide asukoha)

Testi kokkuvõtteks: kui su veebis on hulk pilte, skripte ja stiilifaile – näiteks on tegu optimeerimata Magentoga ehk valdava enamusega Magentodest – annab HTTP/2 kõvasti võitu ning tagab lehe kiirema ja sujuvama laadimise ka nõrgema ühenduse otsas. Kui lehel on aga vaid kaks pilti ning vajalik JS ja CSS on hoole ja armastusega paari faili kokku kogutud, pole effekt ilmselt eriti märgatav.

Aga server push, see peaks ju andma mega-edu?

Server push’i näide vajaks keerulisemat testi – ilmselt peaks tekitama olukorra, kus brauseril kulub aega tuvastamaks mida on vaja alla laadida ning siis üllatada teda faktiga, et kõik on juba saadetud. Ja mõistagi eeldaks push päris-saitides kasutuselevõtuks serveripoolset tuge, näiteks võiks sisuhaldustarkvara või selle cache-moodul panna kokku nimekirja kõigest vajalikust. WordPress jaoks on olemas HTTP/2 Server Push plugin ja meie arendajatel kirjutatud ka lisa-plugin WP Super Cache jaoks, aga …

… on mõned agad. Ja mitte ainult meil – väidetavalt 70% maailma HTTP/2 liiklusest käib läbi CloudFlare ja nad teatasid 28. aprillil, et toetavad nüüd ka server push’i: Announcing Support for HTTP/2 Server Push. Paraku ei suuda mina seal viidatud demolehelt mingit pushi toimimist tuvastada ning kui vaadata kommentaariumit on näha, et kõik justnagu katsetavad midagi, ent tulemust ei ole. Toimub intensiivne musta kassi otsimine pimedas toas.

Kes tahab proovida, siis vajaliku päise saadavad ka e-smaspäeva testid kui lisada päringule argument push – https://http2.miljonivaade.eu/?push. Paraku näib olevat mingi probleem Chrome’l, sest push’i puhul tehakse iga pildi kohta täiendav päring veendumaks, et see viimase sekundi jooksul muutunud pole (ja cache keelamise või Chrome Canary puhul tõmmatakse pilt ka 2x alla, torpedeerides edukalt kogu ürituse) – abi selle müstika lahendamisel on teretulnud. Jah, sama jama on läbi CloudFlare testides.

Firefox toimib muideks korrektselt, sellel pildil viitavad hallid mummud piltidele mis saadi (ilmselt) tänu server push’ile ja näha on ka jupike Link-headerist:

firefox-with-push

Kes tahab oma Zone Virtuaalserveris katsetada, siis võib teha nagu mina – lisasin kaks alamdomeeni mis viitavad samale kataloogile, tellisin mõlemale tasuta Let’s Encrypt serdi ja siis lülitasin ühel HTTP/2 toe välja, alamdomeeni puhul saab seda teha kui minna serverihalduses Veebiserver > Alamdomeenid > [vastav alamdomeen] > Muuda SSL tuge:

alamdomeen-http2

Ladusat lisalugemist (ja veidi vaidlust teemal kui palju ikka HTTP/2 eelist annab) leiab siit:

PHP 7 Apache moodulis ja /usr/bin/env php

Järgmisel teisipäeval ehk 17.05.2016 teeme virtuaalserverite seadistustes kaks PHP versiooniga seotud muudatust, vältimaks millegi katkiminekut ja asjatut debugeerimist väikest hulka kliente puudutav eelteavitus:

PHP Apache mooduli (SAPI) versioon muutub 5.6 > 7.0

Enamus virtuaalservereid kasutab PHPd vaikeseadeks olevas FastCGI režiimis ja endale meelepärase versiooniga, väike hulk on aga valinud PHP Apache mooduli (SAPI) kasutamise. Selles kasutatavat PHP-versiooni oleme uuendanud alati ca pool aastat pärast uue stabiilse versiooni ilmumist ning nüüd on käes hetk minna üle PHP 5.6 pealt PHP 7 peale.

SAPI kasutajatele läks e-postiga ka teavitus viidetega konkreetsetele serveritele, seega kui sa pole kirja saanud, siis ilmselt see muudatus sind otseselt ei puuduta – aga PHP versiooni tõstmine “nii uueks, kui soft kannatab” on mõistlik ka FastCGI kasutajatel. Põhidomeeni versiooni leiab Virtuaalserverite haldusest Veebiserver > Seaded alt, alamdomeenid sealt kõrvalt:

php-versioon

Neil, kellel on PHP režiimiks valitud Apache Module, tasuks aga veenduda oma veebirakenduste toimimises versiooniga 7.0. Seda saab teha näiteks vahetades testiks režiimi 7.0 FastCGI peale (selle jõustumine võtab ca 10 minutit aega). Kui peaks tekkima vajadus jääda kasutama PHP 5.6 FastCGI’d tasub arvestada erinevate failiõigustega – kõik Apache mooduli poolt lisatud pildid, cache jms on mõistagi loodud veebiserveri õigustes ja neile ei pääse kirjutamisõigustes ligi ei FastCGI režiimis kood ega kasutaja FTPga. Õiguste muutmist saab vajadusel küsida info@zone.ee

/usr/bin/env php viidatud versioon muutub 5.2 > 7.0

See on nüüd natuke piinlik – aga ajaloolistel põhjustel on mitmete skriptide poolt universaalseks PHP käivitamiseks kasutatav /usr/bin/env php jäänud viitama versioonile 5.2. Järgmisest teisipäevast ehk 17.05.2016 alates viitab see versioonile 7.0 – ja hakkab edaspidi viitama värskele versioonile sünkroonis SAPIga.

Olles vaadanud läbi serveriteülese grep’i tulemuse (algselt 18tuh rida) paistab, et 99,99% kasutuskohtadest on vabavaralised lahendused või raamistikud – mis eeldatavasti rõõmustavad normaalse versiooni üle. Kui mõni skript peaks siiski vajama vanemat versiooni võib seda kohandada andes ette värskeima sobiliku versiooni, näiteks nii:

/usr/bin/env php56-cli

 

“Teeme ära” koristustalgud sinu (tehtud) veebis – kõik /uus, /vana, /arhiiv ja /newsletter välja!

Fakt: kui su veebi vana versioon on liigutatud alamkataloogi /vana, /old ja uuendamata/turvapaikamata – või kui paned tegemisel oleva ja veel mitte igast nurgast turvatud/uuendatud veebi kataloogi /uus, /new vms – võtavad kurinahad selle varem või hiljem üle.

Pigem varem – ühe turvaintsidendiga tegeledes leidsime näiteks, et uus veeb oli üles pandud /uus alamkataloogi (mõistagi!) mullu 15. septembril ning 25. liigutatud veebi juurkataloogi ehk võetud kasutusele. FTP-logist on näha, et üles laetud veeb oli puhas, liigutamise ajal on seal aga juba sees ühe Hiina reklaamivõrgustiku häkk. 10 päeva, “keegi ei tea, et meil on /uus”. Kes teab, äkki oli adminni parool “test”? Mõni plugin uuendamata? Igatahes leidis selle augu jaanuari lõpus üles järgmine rühmitus ning pani veebi raha teenima.

Talvel koristasin üht teist veebi ja leidsin sealt 6 erinevat WordPress’i, mis paigaldatud viimase 5 aasta jooksul. Ja jupikese ISISe häkist. @martinsookael jagas aga sellist pilti – logides kliendi veebiserverisse leidis ta sealt 8 erinevas kõdunemisfaasis WPd:

Paraku on olemas tööriistad nagu DirBuster (ja selle massrünneteks sobivad analoogid), mille sõnastikud sisaldavad levinud nimekujusid – test.php, phpmyadmin, new, old, dev jne – ning sageli on sellisel viisil avastatud koodi kaudu sisse murdmine lausa tüütult lihtne. Neid veebe krõbistavad nooremhäkkerid hommikukohvi kõrvale, lihtsalt näpuharjutuseks.

Sellest ka “Teeme ära!” üleskutse, mille esimest otsa saab teha ka üldse-mitte-tehniline inimene – tuleta meelde, kas veebiuuenduse ajal on kuhugi vana versioon alles jäetud? Kui meelde ei tule, proovi järgi asukohad stiilis domain.ee/uus, domain.ee/vana, vana.domain.ee … või äkki vedeleb kusagil domain.ee/blogi oma ainsa tervituspostitusega?

Siit edasi võiks FTPga veebiserverisse sisse logida ja vaadata, ega loomehoos arendaja ole mõnda veidi erinevat nimekuju kasutanud – vana-web, vana2, archive jne. Pane kirja, lase veebimeistril igaks juhuks üle vaadata (äkki ikka on millekski vajalik?), siis arhiveerida ja kustutada.

Kui selle käigus hakkab silma aasta 2012 kampaania-maandumisleht, kunagine ise kirjutatud uudiskirjalahendus alamkataloogis /newsletter vms – siis täpselt samasse nimekirja.

Päisepilt ongi ühe täiesti reaalse firma veebiserverist – igati lugupeetav ettevõte, inimesed käivad lipsuga tööl ja büroojuht pakub kohvi kõrvale šokolaadikompvekki. Nende vana uudiskirja-lahenduse kataloogis on süütuna näiv configure.php, mis lähemal vaatlusel võimaldab veebiserverisse uusi faile üles laadida. Ehk teha seda, mida iganes kurinahk teha plaanis.

Jõudu tööle!

PHP 7 on kohal!

php7_300x152

Viimati laulsime siin blogis PHP 7. versioonile hoosiannat siis, kui esimese Release Candidate versiooni oma platvormi lisasime. Täna on mul hea meel teada anda, et PHP 7 on “valmis saanud” ja neil, kel on ühilduv veebileht, hea võimalus see kuni 2x kiiremaks teha.

PHP režiimi vahetamine on võimalik "Minu Zone" haldusliidese vahendusel.
PHP režiimi vahetamine on võimalik “Minu Zone” haldusliidese vahendusel.

PHP 7-ga töötavad juba mitmed sisuhaldussüsteemid ja arendusraamistikud, sealhulgas näiteks WordPress 4.3, Drupal 8, Symfony jt. Hoopis teine lugu võib loomulikult olla erinevate teemade või pluginatega, seetõttu ei maksaks ettevaatlikkust päris unustada. Kannatlikud võiks olla Joomla kasutajad, sest PHP 7 tugi peaks saabuma versiooniga 3.5, mis omakorda ilmub järgmisel nädalal.

Neil, kes oma rakendusi ise ei värskenda ja ei kasuta ka Zone+ abil tehtavaid automaatseid uuendusi, tasub samuti oma järsult tekkinud tegutsemisjanu ohjata. Kui ikka tarkvara versiooninumber on mitu põlvkonda aktuaalsest maas, siis kohe ei maksa PHP režiimi vahetama tormata. Tuleks eelnevalt oma rakendused kaasaega tuua.

Tarkvaraarendajatel tasuks loomulikult heita pilk peale asjadele, mis on muutunud ja leida oma loomingus esinevatele ühilduvusprobleemidele elegantsed lahendused 🙂