SPDY implementatie GoT/Tweakers.net

[Smultie]

Nu we het er toch over hebben op de frontpage, zijn er plannen om tweakers.net/GoT ook op SPDY over te laten gaan?

[BtM909]

Dan moet wel alles via https worden geserveerd

[Smultie]

Ik ben niet gehinderd door enige vorm van kennis, maar vroeg het me gewoon af
Het is natuurlijk enigszins een "wij van WC-eend"-verhaal, maar op zich is het verhaal wel erg positief, en zou dus ook voor ons hier een vooruitgang betekenen!

[crisp]

Ik geloof best dat SPDY performancevoordelen biedt tov HTTPS, maar tov HTTP zal het er waarschijnlijk om hangen. Triviaal om te implementeren is het in ieder geval niet zolang we zelfs nog geen volledige HTTPS support hebben.

[ACM]

BtM909 schreef op donderdag 21 november 2013 @ 14:43:
Dan moet wel alles via https worden geserveerd

crisp schreef op donderdag 21 november 2013 @ 21:04:
Triviaal om te implementeren is het in ieder geval niet zolang we zelfs nog geen volledige HTTPS support hebben.

Of we nu al wel of niet volledige HTTPS-support hebben is technisch gezien vrijwel irrelevant. Met HTTPS heb je niet "bijna" ook SPDY. Het is domweg compleet iets anders

Er zitten allerlei haken en ogen aan, zie bijvoorbeeld deze opmerkingen bij de mod_spdy voor apache over gebruik met PHP

Blijkbaar moeten we dan eigenlijk de FastCGI-versie van PHP draaien. Momenteel hebben we gewoon de normale php-modules. Het is vast een kleine wijziging om dat te veranderen, maar met een codebase die al 13 jaar met Apache gebruikt wordt zijn er vast hier en daar wel kleine dingetjes in geslopen die niet via fascgi zullen werken...

En dan is het nog het veel grotere probleem dat we Varnish gebruiken en dat zit tussen jou en Apache in. De mensen van Varnish hebben de huidige beschikbare SSL/TLS-implementaties nooit succesvol geprobeerd te integreren omdat ze niet goed genoeg vinden.
In de blog van Varnish kan je nog wel wat meer vinden:
https://www.varnish-cache.org/docs/trunk/phk/spdy.html

Momenteel bieden we SSL voor onze Varnish-instances via de "ssl termination" van onze loadbalancers aan. Dat werkt prima, maar ze hebben uiteraard (nog?) geen support om er SPDY van te maken.

Dat zouden we dan kunnen vervangen door Nginx, maar dat is geen triviale exercitie.

En zelfs dan ben je er nog niet zomaar, het heeft weinig zin SPDY in te zetten als we niet ook echt gebruik maken van de features van SPDY. Anders is het domweg een variant op HTTPS met een binary encoded protocol ipv tekstueel en wat multi-plexing features.
Voor optimale winsten moeten we dan ook gebruik maken van het "server hint" en/of "server push"-principe, zodat de browsers direct al de benodigde javascript en css meekrijgen of gaan downloaden.

Verder zitten we nog met het probleem dat we nu al met HTTPS hebben; onze advertenties worden lang niet altijd netjes via SSL geladen als je Tweakers via SSL bezoekt. Als de huidige browsers hun gedrag daarin gelijk laten, zal dat betekenen dan de banners die niet via SSL lopen domweg geblokkeerd worden en de gebruiker een melding op zijn scherm krijgt.
Op de onderdelen die we bewust via SSL (secure.tweakers.net) doen lossen we dat maar op door dan de advertenties uit te zetten... maar dat kunnen we uiteraard niet maken voor de gehele site

Kortom, technisch gezien zijn er nog allerlei obstakels

Dus wat mij betreft blijven we nog wel een jaartje de kat uit de boom kijken, zolang er geen 'native' ondersteuning voor SPDY in Apache+PHP (ja ik weet dat mod_spdy bestaat), Varnish en/of onze loadbalancers zit zal het wel niet gebeuren.
En we hebben net even teveel andere klussen al in onze takenlijst staan om 'even' Nginx in te gaan zetten als vervanger voor Varnish en/of Apache of om allerlei alternatieve oplossingen (die vaak ook nog semi-experimenteel zijn) uit te proberen

[crisp]

ACM schreef op vrijdag 22 november 2013 @ 08:16:
[...]

Of we nu al wel of niet volledige HTTPS-support hebben is technisch gezien vrijwel irrelevant. Met HTTPS heb je niet "bijna" ook SPDY. Het is domweg compleet iets anders

Klopt, maar voor een deel moeten we daar wel dezelfde problemen voor oplossen (zie je voorbeeld over advertenties)