Facebook werkt aan ondersteuning spdy-protocol
In een e-mail naar een w3-mailinglijst heeft Facebook aangegeven volop bezig te zijn het spdy-protocol te implementeren in zijn website. De sociale-netwerksite hoopt met deze implementatie een grote snelheidswinst te realiseren.
Facebook-engineer Doug Beaver meldt in een e-mail aan een w3-mailinglijst dat Facebook bezig is met het implementeren van het spdy-protocol in zijn website. Ook legt de engineer uit waarom het bedrijf niet geïnteresseerd is in de andere twee http/2.0-voorstellen.
Het spdy-protocol is een van de voorstellen voor een nieuwe http/2.0-implementatie. Met het spdy-protocol worden webpagina's sneller en veiliger geladen, dankzij enkele aanvullingen op het oude http-protocol. Dataverbindingen worden automatisch gemultiplext, gecomprimeerd en meestal ook versleuteld. Servers kunnen ook data pushen naar clients zonder dat daarvoor een request moet worden gestuurd.
In de e-mail vertelt Beaver dat Facebook eisen stelt aan een nieuwe http-implementatie. Zo moet het protocol onder andere multiplexing, encryptie op de transportlaag, zero-latency upgrade, per-request flow control en server push ondersteunen. Om die reden steunt Facebook het spdy-protocol, ten nadele van de andere voorstellen voor het http/2.0-implementatie. Ook is het bedrijf bezig het spdy/v2-protocol alvast te implementeren, omdat recente browsers het protocol al ondersteunen, waarmee dus directe snelheidswinst wordt behaald.
Het nieuwe protocol draait nog niet op de productieservers, maar volgens Beaver is de implementatie bijna compleet en heeft Facebook voldoende informatie om commentaar te leveren op de standaard vanuit het perspectief van ontwikkelaars. Hoewel het bedrijf al bezig is het huidige spdy-protocol te implementeren, zoekt Facebook nog naar verbeteringen.
Twitter liet in maart al weten het spdy-protocol te hebben geïmplementeerd en in gebruik te hebben genomen, en heeft gereageerd op de eisen van Facebook aan het protocol. Hierin legt Twitter uit het grotendeels eens te zijn met de eisen van Facebook, maar nog wel vraagtekens te plaatsen bij de voordelen van de huidige implementatie van de compressiefunctionaliteit.
Reacties (41)
Kunnen servers dan ongevraagd rommel naar mijn PCtje sturen? Kan iemand misschien hier op uitbreiden?Servers kunnen ook data pushen naar clients zonder dat daarvoor een request moet worden gestuurd.
Er moet wel eerst een verbinding zijn gemaakt, wat je doet door de Facebook-site te bezoeken met een client die SPDY ondersteunt.
Over de verbinding worden dan updates gepusht, zoals nieuwe timeline-events en chatberichten. Omdat één verbinding actief blijft, gaat dit sneller en kost het minder resources (in tegenstelling tot pollen).
Over de verbinding worden dan updates gepusht, zoals nieuwe timeline-events en chatberichten. Omdat één verbinding actief blijft, gaat dit sneller en kost het minder resources (in tegenstelling tot pollen).
Het bekende probleem bij constant open verbindingen is dat aan de serverkant het aantal TCP sockets gelimiteerd is, ik ben benieuwd of ze daar ook aan gedacht hebben.
alsof ze 65k gebruikers tegelijk op 1 server laten hangen
Ja hoor geen probleem, maar dat is een ander verhaal...
Hoe dan ook een http en ook spdy verbinding is niet constant open maar eerder alleen open op het moment dat er een verzoek komt en als jij verzoekt om informatie van de server dan doe je ook automatisch verzoeken om de updates die bij die pagina horen. Dat houd dus ook in dat op het moment dat je de pagina niet meer bezoekt en een volgende push krijgt jouw client automatisch aan zal moeten geven hier geen prijs meer op te stellen iets dan neem ik aan (heb er ngo niet verder naar gekeken gedaan wordt door simpel weg geen reactie terug te sturen. Op die manier kun je namelijk ook een afgesloten client automatisch de push laten stoppen.
Wat betreft het aantal clients dat je aan een server kan hangen dat hangt heel erg af van het geen je serveert van af die machine maar 65k mensen kunnen makkelijk bediend worden omdat je ze toch nooit allemaal tegelijk zal bedienen nog altijd maar een verbinding open zal houden en dank zij een fatsoenlijke load balancer moet je wel heel erg belachelijk veel requests krijgen voor dat de server echt in de problemen komt als de requests maar weinig werk op leveren dan hoeft zelfs 100k gebruikers nog geen probleem te zijn. Gelijktijdig is een ander verhaal maar dat is zo extreem onwaarschijnlijk als je een beetje redelijke setup hebt draaien.
Hoe dan ook een http en ook spdy verbinding is niet constant open maar eerder alleen open op het moment dat er een verzoek komt en als jij verzoekt om informatie van de server dan doe je ook automatisch verzoeken om de updates die bij die pagina horen. Dat houd dus ook in dat op het moment dat je de pagina niet meer bezoekt en een volgende push krijgt jouw client automatisch aan zal moeten geven hier geen prijs meer op te stellen iets dan neem ik aan (heb er ngo niet verder naar gekeken gedaan wordt door simpel weg geen reactie terug te sturen. Op die manier kun je namelijk ook een afgesloten client automatisch de push laten stoppen.
Wat betreft het aantal clients dat je aan een server kan hangen dat hangt heel erg af van het geen je serveert van af die machine maar 65k mensen kunnen makkelijk bediend worden omdat je ze toch nooit allemaal tegelijk zal bedienen nog altijd maar een verbinding open zal houden en dank zij een fatsoenlijke load balancer moet je wel heel erg belachelijk veel requests krijgen voor dat de server echt in de problemen komt als de requests maar weinig werk op leveren dan hoeft zelfs 100k gebruikers nog geen probleem te zijn. Gelijktijdig is een ander verhaal maar dat is zo extreem onwaarschijnlijk als je een beetje redelijke setup hebt draaien.
De website moet mij natuurlijk nog wel kunnen bereiken, en dat kan alleen over een verbinding die al is opgezet. En als ik moet verzoeken om updates, dan zit ik te pollen.Ja hoor geen probleem, maar dat is een ander verhaal...
Hoe dan ook een http en ook spdy verbinding is niet constant open maar eerder alleen open op het moment dat er een verzoek komt en als jij verzoekt om informatie van de server dan doe je ook automatisch verzoeken om de updates die bij die pagina horen.
Niet dat ik er in de praktijk veel mee werk, maar als ik me de theorie goed herinner wordt een socket geďdentificeerd door server-ip + server-port + client-ip + client-port. Dus dan heb je (zelfs als een client op een vaste port (80) moet connecten) nog steeds 64k connecties per client-ip, in plaats van in totaal.
Waardoor je dus niet meer transparant kan loadbalancen, zoals dat momenteel wel kan.
Hetzelfde aantal clients zou zonder SPDY meer resources trekken, omdat ze voor iedere resource en ieder AJAX-script een nieuwe verbinding openen (of keepalive gebruiken, maar dat is weer een stuk trager).
De oude methode kost weliswaar meer overhead, maar je hoeft het gelimiteerd aantal sockets dat je hebt niet open te houden, waardoor ze herbruikt kunnen worden. Al is het theoretisch wel mogelijk om meerdere TCP connecties open te hebben op 1 source port, zolang destination ip/port maar verschillend is.
.edit: ik praat sowieso poep, bij HTTP is er typisch altijd maar 1 poort in gebruik: poort 80.
.edit: ik praat sowieso poep, bij HTTP is er typisch altijd maar 1 poort in gebruik: poort 80.
[Reactie gewijzigd door .oisyn op 16 juli 2012 17:54]
Je vergeet dat SPDY verplicht een gzip-resource open te houden voor de headercompressie. Hierdoor heb je in sommige gevallen ruim 250KB aan RAM nodig... per connectie. Stel dat we 50000 idle clients hebben dan is dat toch al bijna 25GB RAM, en dan hebben we het nog niet gehad over de daadwerkelijke connecties, SSL overhead en dat soort dingen.
Maar dát kun je natuurlijk gewoon loadbalancen. Een loadbalancer hoeft zelf die decompressie niet te doen, die kan de boel gewoon offloaden naar een specifieke server.
[Reactie gewijzigd door .oisyn op 16 juli 2012 17:54]
Een TCP-socket heeft 4 kenmerken: source IP, destination IP, source port en destination port. Op basis daarvan wordt gemultiplext. Je kunt dus VEEL MEER dan de veel genoemde 65k verbindingen aan (die 65k is het aantal beschikbare serverpoorten, maar dat is iets anders dan een socket).
ter illustratie: bij whatsapp handelen ze op één server (getuned.. dat wel) 1 miljoen sockets af. Zie dit bericht:
http://blog.whatsapp.com/index.php/2011/09/one-million/
ter illustratie: bij whatsapp handelen ze op één server (getuned.. dat wel) 1 miljoen sockets af. Zie dit bericht:
http://blog.whatsapp.com/index.php/2011/09/one-million/
Zit dat niet ook al in HTML5?
Kan zijn, maar ik neem aan dat SPDY niet alleen voor webpagina's gebruikt kan worden. Maar ook voor webservices e.d. die niets met HTML5 te maken hebben. Het maakt denk ik de implementatie van de HTML5 functionaliteit alleen maar eenvoudiger omdat het onderliggende protocol het ook ondersteund.
[Reactie gewijzigd door HerrPino op 16 juli 2012 12:53]
http/spdy zit niet in html 5. met beide protocollen kunnen html5 berichten verzonden worden.
Net zoals je PCtje via AJAX momenteel rommel naar binnen haalt.
Het idee is dat de server zelf kan besluiten updates te sturen naar de client als de client die website aan het bezoeken is, in plaats van dat de client de hele tijd moet pollen voor updates. Zodra de client wegsurft van de website wordt natuurlijk ook de verbinding verbroken.
Het idee is dat de server zelf kan besluiten updates te sturen naar de client als de client die website aan het bezoeken is, in plaats van dat de client de hele tijd moet pollen voor updates. Zodra de client wegsurft van de website wordt natuurlijk ook de verbinding verbroken.
Alleen als jou browser (of ander programma) die pagina geopend heeft.
Ja dat klinkt niet handig gezegd in het artikel zeker niet als het protocol in kwestie met 1 letter verschil wordt uitgesproken als SPY. spy deamon.
Het feit dat je een homepage bezoekt betekent al dat de server van zo'n site al alles op je computer kan doen ook in het huidige protocol. Juist in het huidig protocol.
Dus als je al een verbinding gemaakt hebt is het niet zo relevant wat ze wel en niet sturen omdat ze al alles kunnen maken wat ze willen op dat moment. De verbeteringen hebben dus niks te maken met spionage. Ik zou willen beweren ze willen de spionage van de hackende consultants uit Azie/Afrika juist VERMINDEREN met encryptie in de transportlaag.
Het feit dat je een homepage bezoekt betekent al dat de server van zo'n site al alles op je computer kan doen ook in het huidige protocol. Juist in het huidig protocol.
Dus als je al een verbinding gemaakt hebt is het niet zo relevant wat ze wel en niet sturen omdat ze al alles kunnen maken wat ze willen op dat moment. De verbeteringen hebben dus niks te maken met spionage. Ik zou willen beweren ze willen de spionage van de hackende consultants uit Azie/Afrika juist VERMINDEREN met encryptie in de transportlaag.
Leuk om te weten, http 1.1 komt uit 1997.
Oorspronkelijk bedoeld om enkel html te versturen en misschien afentoe een plaatje.
Tegenwoordig gaan er hele films en muziek, maar ook vertrouwelijke data over dit lijntje.
Oorspronkelijk bedoeld om enkel html te versturen en misschien afentoe een plaatje.
Tegenwoordig gaan er hele films en muziek, maar ook vertrouwelijke data over dit lijntje.
Zou content dan ook gepusht kunnen worden via "like buttons"??
Voor de rest is een mooie test voor spdy als protocol.
Voor de rest is een mooie test voor spdy als protocol.
Kan nu ook al. Als er een iframe ingeladen wordt, kan het iframe ook AJAX calls doen. Echter, net als bij iframes zal er waarschijnlijk wel een security laag omheen zitten, zodat je alleen bij het actieve frame kan en niet daarbuiten.
Nee dat kan dus niet. Een frame kan niets doen op een ander frame buiten z'n domein.
Ben ik de enige bij wie dit nogal arrogant overkomt?
"In de e-mail vertelt Beaver dat Facebook eisen stelt aan een nieuwe http-implementatie."
"In de e-mail vertelt Beaver dat Facebook eisen stelt aan een nieuwe http-implementatie."
Heeft niets met arrogantie te maken.
Dit is een nieuwe techniek, ze zeggen simpelweg dat als zij, als facebook zijnde, een nieuwe techniek willen implementeren dat dat aan bepaalde eisen moet voldoen.
Dit is een nieuwe techniek, ze zeggen simpelweg dat als zij, als facebook zijnde, een nieuwe techniek willen implementeren dat dat aan bepaalde eisen moet voldoen.
Doen we allemaal toch?
"Er is een nieuwe dit of dat!"
"Ja leuk, maar dat moet ie wel A en B kunnen"
"Er is een nieuwe dit of dat!"
"Ja leuk, maar dat moet ie wel A en B kunnen"
In zekere zin wel. Langs de andere kant, Facebook is een van de meest bezochte websites ter wereld en als ze hun website weten uit te rusten met het SPDY protocol, weten ze gelijk ook hoe dit presteert op grote schaal. Vanuit dit opzicht is de commentaar en dergelijke van Facebook wel het lezen waard 
Dat heet RFC. Ga maar eens naar IETF, jij kan net zo goed een mailtje sturen. Kans is dat je niet echt iets toe te voegen hebt, maar iedereen mag gewoon mailen hoor.
"Om die reden steunt Facebook het spdy-protocol, ten nadele van de andere voorstellen voor het http/2.0-implementatie."
Ik vind dit ook nogal arrogant overkomen, het maakt wel weer duidelijk dat hoe groter je bent en des te meer geld je te spenderen hebt je gemakkelijker de dienst uitmaakt.
Ik vind dit ook nogal arrogant overkomen, het maakt wel weer duidelijk dat hoe groter je bent en des te meer geld je te spenderen hebt je gemakkelijker de dienst uitmaakt.
Dat is gewoon de "afkorting" van "In de e-mail vertelt Beaver dat Facebook eisen stelt aan een nieuwe http-implementatie, voordat ze besluiten die te willen implementeren en (uiteindelijk) op productie te gaan draaien.".Ben ik de enige bij wie dit nogal arrogant overkomt?
"In de e-mail vertelt Beaver dat Facebook eisen stelt aan een nieuwe http-implementatie."
Je moet dit niet lezen als "de rest van de wereld mag geen http-versies ontwikkelen die niet aan onze eisen voldoen", maar alleen als "mocht iemand een http-versie ontwikkelen die niet aan onze eisen voldoet, dan zullen we die niet gebruiken".
Als ik het goed heb ondersteunen Chrome en FireFox dit al? Maar als gebruiker ga je daar weinig van merken, toch?
Hopelijk merk je als gebruiker vooral dat sites snel en responsief zijn. Maar je hoeft inderdaad zelf geen rare trucs uit te halen, gewoon je favoriete browser up-to-date blijven houden.
Toch wel apart aangezien er laatst nog een artikel was over de geringe snelheidswinst van spdy:
nieuws: Spdy misschien niet significant sneller dan http of https
nieuws: Spdy misschien niet significant sneller dan http of https
Zoals te lezen valt in de reacties aldaar was de conclusie van dat onderzoek niet al te veel zeggend.
Zoals ook al in de bijbehorende Reddit-thread is genoemd, valt het wel mee met de kwaliteit van de conclusie, de auteur wordt voornamelijk afgerekend op het feit dat hij een proxy gebruikte om de vergelijking "eerlijk" te houden:
[...]
Verder wordt genoemd dat de verzameling sites die hij heeft geanalyseerd niet handig is; deze top-500 sites hebben namelijk al dermate veel bezoekers te verwerken, dat de makers de sites helemaal hebben geoptimaliseerd volgens HTTP/1.1. Met het bestaan van SPDY is geen rekening gehouden bij het opzetten van CDN's en dergelijke. Juist reguliere sites waar minder aandacht is voor optimalisatie (die dus uit veel losse requests naar dezelfde host bestaan) kunnen erg profiteren van SPDY.
Meestal ook versleuteld? Hoe moet ik me dat voorstellen? Wordt een verbinding at random, af en toe versleuteld of is dit iets dat per pagina in te stellen is?"Dataverbindingen worden automatisch gemultiplext, gecomprimeerd en meestal ook versleuteld."
waarschijnlijk een parametertje op de server oid
Dataverbindingen via spdy zijn net als https versleuteld, behalve bij het opzetten van de verbinding (daar wordt een public key en een certificaat verzonden). Daarnaast kun je als server opdracht geven het niet versleuteld te verzenden omdat je het een proxy wilt laten doen.
Ja, SPDY is geimplementeerd boven op SSL/TLS, en is daarmee (bijna altijd) encrypted. Op de uitzonderingen na waarbij de server expliciet toestaat dat er ook NULL encryptie gekozen wordt, maar dat is niet heel typisch.
Als je browser dus SPDY ondersteunt en de server ook, dan wordt tijdens de HTTPS:// handshake onderhandeld dat SPDY gebruikt kan worden.
Als je browser dus SPDY ondersteunt en de server ook, dan wordt tijdens de HTTPS:// handshake onderhandeld dat SPDY gebruikt kan worden.
Als je op Chrome wilt weten of SPDY ingeschakeld staat (vanaf v20 of iets eerder is dit standaard zo) en welke SPDY-verbindingen er momenteel zijn, moet je eens kijken op chrome://net-internals/#spdy
Voor Firefox zijn daar extensie(s) voor. Ook kan je in about:config opzoeken of SPDY aan staat. Simpelweg zoeken op 'spdy'.
Voor Firefox zijn daar extensie(s) voor. Ook kan je in about:config opzoeken of SPDY aan staat. Simpelweg zoeken op 'spdy'.
Op dit item kan niet meer gereageerd worden.
Populair: Xbox E3 2013 Mobiele telefoons Google Sony Microsoft Apple Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
