Názory k článku
Zrychlete komunikaci s Apache pomocí Google SPDY

Alespoň další důvod, proč začít šifrovat (dneska to není vůbec od věci).

Předpokládám, že na ten blog občas něco píšeš a do galerie přidáváš fotky. Jméno a heslo posíláš jak? Nebo je tam anonymní přístup pro zápis? To by pak HTTP nevadilo.

Ne, musíš šifrovat celou administraci (kradení cookies a podobné).

proc bych sifroval praci na obycejnych webovkach? pokud by to nekomu stalo za to tak at si to klidne hackne, nemam problem...

Přechod na https asi bude trendem. https též přináší vyšší míru soukromí pro surfaře - nikdo po cestě nemůže sledovat, které stránky přesně navštěvuje (ví se jen s jakým komunikuje serverem). Také není možné po cestě sledovat co surfař na stránky vkládá... Bezpečnost a vyšší míra soukromí nejsou špatné věci...

Nojo, ale zavedením HTTPS přestanou fungovat transparentní cache po cestě.

Coz je jedine dobre.

Ad „Rozhodne se tak na základě svých algoritmů, které mohou vycházet z toho, co se posílalo v podobných požadavcích předtím.“

Jen doufám, že nebude posílat třeba data jiných uživatelů – např. jeden vleze na URL https://example.com/muj-ucet/faktury a tam stahuje svoji fakturu. A jiný uživatel vleze na stejné URL a server mu natlačí fakturu toho prvního.

Úplně takhle hloupé chyby tam snad nebudou, ale jako prostor pro bezpečnostní díry to každopádně vidím.

nesmysl, stranky se vyrabi furt stejne, rozdil je jen ve zpusobu prenosu.

Na mass hostingoch nepouzitelne, kedze to nie je kompatibilne s PHP (to, bohuzial, nie je thread-safe a SPDY bezi vo vlaknach).

IMHO se distribuuje i thread-safe verze php

Žádná verze PHP není thread-safe, když do ní začnete nahrávat externí moduly.

V podstatě je výrazně lepší kombo fastcgi + php-fpm.

Jsem trochu zmaten. Mám tomu rozumět tak, že SPDY nepoběží s Apache mpm-prefork či mpm-itk? Nemyslím nyní konkrétně na php.

Největší zabiják připojení je ping. U šifrovaného spojení se před zahájením komunikace provádí několik výměn během ověření, a tím je dané zpomalení. Proto pro HTTPS ty asi má smysl a něco to urychlí.

U HTTP ale takové urychlení nevidím. Browser naváže N spojení (může až 10 spojení paralelně, nicméně mám někdy pocit, že jedou tak 3-4) a přenos pak probíhá s nastaveným keep-alive, takže spojení se nezavírají. Většinou jde provádět i pipelining (dokud druhá strana jede v HTTP/1.1).

A teď námět k přemýšlení. Jakou režii má SPDY na paralelní přenos? Režii, kterou má TCP spojení nelze tímto způsobem snížit a TCP spojení paralelní přenos podporuje z principu. Nebude nakonec SPDY větší zátěž na přenosovou linku, než kdyby se data posílala paralelně po více spojení?

Není náhodou zpomalení HTTP tradičním způsobem jen důsledkem toho, že prohlížeče neumí hospodařit s otevřenými linkami. Například na stahování obrázku by klidně stačily dvě spojení. Pokud má spojení delší prodlevu, mohu navázat další spojení a stáhnout něco co má vyšší prioritu. Jenže prohlížeče tohle nedělají a obávám se, že se SPDY to dělat nebudou.

Hlavní benefit vidím v tom, že SPDY šetří prostředky na serveru. Avšak, namísto vymýšlení protokolu by stačilo popřemýšlet, jak optimalizovat server pro větší množství spojení. Není možné se držet jen zaběhnutých schemat ve stylu "linux to neumí, tak to nejde".

Mohli prejit na http pres SCTP

+1                                      .