Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Arjen van der Meijden

Lead Developer

Tweakers stapt over op https

Meer veiligheid en privacy

218 reacties

Site-performance

We hebben ruim een jaar geleden ons dilemma om wel of geen https te nemen aan de bezoekers van Tweakers voorgelegd. Uiteindelijk hebben we daarna besloten om de introductie van https uit te stellen. Een van de redenen was dat de voor encryptie benodigde rekenkracht en vooral de connection setup van https, zoals het uitwisselen van certificaten, ten opzichte van http nog een zichtbare invloed op de prestaties van de website hadden.

Intussen is de wereld echter veranderd. De benodigde rekenkracht is minder relevant geworden, onder andere door de verdere opkomst van snellere cpu's en aes-instructies in die cpu's. Daarnaast is de bijbehorende software verder geoptimaliseerd. Ten slotte hebben we zelf ook meer geleerd over https, zoals welke tunables er bestaan en welke encryptievormen sneller werken dan andere.

Met https moet in principe voor iedere verbinding onderhandeld worden over de te gebruiken certificaten. Dat geeft een relatief grote overhead en is een van de redenen dat het (vooral) in het verleden duidelijk trager was dan http. Door allerlei trucjes in de nieuwere versies van tls en optimalisaties in serversoftware en browsers is dat langzaamaan minder erg geworden.

Met http/2 wordt het nog beter. Waar in http/1.1 vaak meer dan tien losse netwerkverbindingen werden opgezet met servers, ieder met eigen https-overhead, wordt nu nog maar één verbinding per server opgezet. Alle requests worden vervolgens via multiplexing min of meer tegelijk over die ene verbinding gestuurd.

Veel meer connecties parallel met HTTP/2 (rechts) vs. HTTP/1.1. De tragere eerste request wordt veroorzaakt door de langzamere testserver.

Daardoor zijn ook maar één keer de connection setup van tcp/ip en de daarop volgende ssl-onderhandeling nodig. Daarnaast kan er beter gebruik worden gemaakt van de snelheidseigenschappen van het tcp/ip-protocol, zoals het eenmalig opbouwen van een ruimere windowsize.

Met deze en andere aanpassingen is http/2, de facto met https, in sommige benchmarks zelfs sneller dan http/1.1 zonder https. Doordat de meeste browsermakers ondertussen http/2 ondersteunen, heeft nu zo'n zeventig à tachtig procent van onze bezoekers een browser die daarvan kan profiteren. Onze schatting is dat de verliezen door de versleuteling met ssl worden gecompenseerd door de optimalisaties van http/2, waardoor de site voor bezoekers ongeveer even snel moet blijven.

Domain sharding en san-certificaten

Pagina's bestaan vaak uit tientallen of honderden losse elementen, zoals afbeeldingen, stylesheets en javascript-files. Voor ieder van die elementen moet een losse request worden gedaan en dat brengt allerlei overhead met zich mee. Een aantal jaar geleden was het gebruikelijk dat browsers maximaal twee verbindingen per domein konden opzetten. Deze verbindingen werden vervolgens opengehouden en alle elementen werden een voor een opgevraagd. Dat maximumaantal verbindingen is overigens sindsdien opgelopen tot rond de acht of tien.

Doordat er voor elk element een stukje overhead aanwezig is, kon met dat lage aantal verbindingen geen optimaal gebruik worden gemaakt van de steeds hogere bandbreedte bij internetgebruikers. Om daar toch beter gebruik van te maken is in het verleden domain sharding bedacht; daarmee worden de site-onderdelen over verschillende servers verspreid. In het geval van Tweakers is dat gedaan door eerst tweakimg.net en later ic.tweakimg.net te introduceren. Omdat de limiet van twee, of acht+, verbindingen per domein geldt, kun je daarmee extra verbindingen ontsluiten voor browsers om daarlangs elementen binnen te halen. Door die extra parallelliteit was de totale benodigde tijd voor de losse site-elementen uiteindelijk lager.

Verliezen door de versleuteling met ssl worden gecompenseerd door de optimalisaties van http/2

Bijkomend voordeel was dat je die site-elementen dan ook gelijk op een 'cookievrij' domein kon plaatsen, de totale hoeveelheid data die voor een 'request' moet worden opgestuurd, nam daarmee met tientallen tot honderden kilobytes af. Met uploadsnelheden van rond de 1Mbit/s gaf dat weer een aardige winst voor de cookiedata, die verder toch werd genegeerd bij die elementen.

Met het bundelen van requests in één verbinding bij http/2 is dat opsplitsen in losse domeinen niet meer nodig. Sterker nog, als je niet oppast, werkt het in de nieuwe situatie juist tegen. Het eerder genoemde bundelen van browser-requests over één verbinding is dan niet meer zomaar mogelijk; dan zouden er in ons geval steeds drie nodig zijn. Omdat zo'n twintig à dertig procent van onze bezoekers nog geen http/2-ondersteuning heeft, wilden we dat ook weer niet zomaar opgeven.

Gelukkig is er een oplossing die beide situaties kan combineren. We hebben ervoor gezorgd dat al onze domeinen hetzelfde certificaat en hetzelfde ip-adres hebben. Daardoor kan een browser in principe diezelfde verbindingen hergebruiken voor verschillende domeinen. Op die manier hebben we voor http/1.1-gebruikers nog steeds domain sharding en cookievrije domeinen, maar voor http/2 verloopt alles over die ene verbinding.

Het lijkt misschien onlogisch om verschillende domeinen met één ssl-certificaat te faciliteren, maar daar is de 'subject alternative name'-functionaliteit voor bedoeld. We hebben daarmee onder andere tweakers.net, gathering.tweakers.net, tweakimg.net, ic.tweakimg.net en tweakers.tv samengevoegd in een san-certificaat.

Let's Encrypt

Let's EncryptHelaas bleek het lastig om betaalbare san-cerficaten te vinden die ook overweg konden met het snellere ecdsa. Bij de betaalbare aanbieder waar we al klant waren, maar geen ecdsa konden gebruiken, zouden we al gauw het dubbele kwijt zijn geweest van wat onze huidige wildcard-certificaten kosten. Gelukkig biedt Let's Encrypt wel de mogelijkheid voor ecdsa-certificaten en ondersteunt dit bovendien san-certificaten. We zijn daarom overgegaan naar het automatisch genereren van nieuwe certificaten via dat systeem en daarmee is het zelfs gratis geworden voor ons. Helaas heeft Let's Encrypt geen ondersteuning, en plannen, voor wildcardcertificaten, waardoor we met name het certificaat voor *.tweakblogs.net alsnog los moeten blijven voeren.

SSL offloading en Global Server Load Balancing

Hoewel de voor https benodigde rekenkracht relatief kleiner is geworden, heeft dat nog wel degelijk aandacht nodig. Zo wordt een aantal zaken bij de server en browser gecached om die relatief zware connection setup zoveel mogelijk te vermijden. Met twee pools van vier webservers is het echter lastig om die caches effectief te laten werken als ieder van die servers zelf de https-verwerking doet. Elke keer dat je request door een andere server afgehandeld wordt, met iets meer dan 2/3e kans, zou dan de in jouw browser bewaarde cache ongeldig zijn. Overigens zijn er wel manieren om ervoor te zorgen dat de loadbalancers steeds dezelfde server gebruiken voor specifieke gebruikers.

We waren echter al op zoek naar nieuwe application delivery controllers. Ondersteuning voor ssl offloading in combinatie met http/2 hoorde daarbij tot onze selectiecriteria. Met ssl offloading doet een proxy-server, in ons geval op de loadbalancers, het https-werk en wordt er daarna intern verder gecommuniceerd. Het voordeel daarbij is dat je in principe altijd op dezelfde server uitkomt voor https, ongeacht welke interne server je request daadwerkelijk afhandelt. Bovendien wordt het rekenwerk voor https dan op die plek gedaan, waardoor de webservers zich daar niet mee bezig hoeven te houden.

We zijn bij die zoektocht uitgekomen op Brocade Virtual Traffic Manager, kortweg vTM. Dat zijn softwarematige adc's die we op een drietal Dell R430's hebben geïnstalleerd. Die Dells hebben ieder twee Intel Xeon E5-2623 v3's met 4x 3GHz-cores, in totaal 24x cores en 48x threads, en daarmee ruim voldoende rekencapaciteit om naast de reguliere adc-taken ook al het verkeer te versleutelen.

We hebben deze nieuwe adc's al een paar weken geleden in gebruik genomen, zodat we in ieder geval zeker wisten dat ze technisch goed werken.

Screenshot uit Brocades datasheet. Klik voor een grotere versie.

In tegenstelling tot bij onze vorige opstelling hebben nu alle drie de loadbalancers 'actief' verkeer. Het voordeel daarvan is dat we alle loadbalancers continu benutten en we er niet eentje niets laten doen zolang er geen problemen zijn. Helaas betekent dit ook dat we drie losse ip-adressen hebben, voor elke loadbalancer een. Dat betekent verder dat ieder van onze domeinen drie losse ip-adressen kent. Statistisch gezien zou daardoor slechts zo'n tien procent van alle bezoekers daadwerkelijk alle requests van tweakers.net, tweakimg.net en ic.tweakimg.net vanaf hetzelfde ip-adres krijgen. Daarmee zou opnieuw het voordeel van de enkele verbinding van http/2 wegvallen.

Gelukkig konden we de global server loadbalancing in de vTM's uitbreiden met wat extra scripting om zo afhankelijk van het ip-adres van de gebruiker een specifiek ip-adres van onze kant terug te geven. Een loadbalancer mag daarmee nog steeds uitvallen, dan wordt vanzelf een andere gebruikt, maar het betekent wel dat een bezoeker normaal gesproken uiteindelijk hetzelfde ip-adres en hetzelfde certificaat voor ieder van onze losse (sub)domeinen krijgt.

Het werkt in de praktijk helaas niet perfect zoals hier beschreven. Dat komt onder andere doordat gebruikers meestal meer dns-servers gebruiken, waarbij elke nameserver een ander adres van onze dns-server kan krijgen, waardoor de gebruiker uiteindelijk alsnog verschillende ip-adressen krijgt voor tweakers.net en tweakimg.net. We zullen daarom op den duur waarschijnlijk alsnog die extra domeinen opheffen. Eigenlijk moeten we dan ook gathering.tweakers.net opheffen, maar de vraag of we dat willen, vereist nog wat diepe bezinning ;)

Overigens kunnen we met deze vTM's ook automatisch nieuwe certificaten uploaden in de api, waardoor we, hoewel Brocade het zelf nog niet ondersteunt, wel al Let's Encrypt kunnen gebruiken in de ssl-offloading.


Nintendo Switch Samsung Galaxy S8+ LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True

*