kvp#13
Lassuk mit talaltak ki:
-ssl-t hasznalnak, mert az a legtobb tuzfalon atmegy
-tomoiritik az egesz kapcsolatot (az ssl mellekhatasa)
-van http push (az ssl tunnel miatt mukodik is oda-vissza)
-tobb kapcsolat mehet egy tcp kapcsolatban
-kihagyjak a mar elkuldott fejleceket
Hogy kellene ezt megoldani, hogy ne szegjek meg a meglevo szabvanyokat:
-ssl modositas nelkuli hasznalata, ha kell akar titkositas nelkul, csak a tomorites miatt (de van ra egyszerubb alternativa is, lasd lent)
-mukodo http pipelining megvalositasa (a http/1.1 teljes tamogatasa)
-az osszetartozo adatokat jo lenne osszecsomagolva atadni, igy egy keresre a bongeszo kuldhet tobb objektumot is, mint ahogy email eseten is egy html oldal egybe van csomagolva az osszes statikus elemevel (rfc2046)
-http protocol extension (http/1.2) a push es a header skip tamogatasara (1 uj valasz kod, pl. HTTP/1.2 600 Push Message es egy uj header az elso keresben pl. x-presistent-headers:)
-out of order http valaszok tamogatasa request id-n keresztul (ez a push uzenetek azonositasat is megkonnyiti, request-id header mar amugy is van)
-a prioritasok kezelese pedig megoldhato az out of order valaszokon keresztul
-a request hint-ek esetleg mehetnek extension header-kent a tobbi header kozott (pl. x-should-also-get:, x-may-also-get:)
-fejlec tomoritesre van mar egy hivatalos szabvany, ami a wap protokoll resze, de nehany desktop bongeszo is tamogatja (pl. opera), igy teljesen elkerulheto a cpu-t terhelo ssl hasznalata es meg szabvanyos is lenne
A fentiek a google uj protokolljatol annyiban ternek el, hogy mindegyik esetben van mod bizonyos reszek kikapcsolasara es visszateresre a korabbi protokoll valtozathoz. Ha a tuzfal nem szereti, mehet ssl helyett sima tcp kapcsolaton. Ha nem jo a pipelining, akkor visszaterhet a hagyomanyos modhoz. A pipeline-ben erkezo es nem tamogatott push uzeneteket a legtobb bongeszo kepes figyelmen kivul hagyni. Ha valahol a lancban valaki nem tamogat valamilyen szolgaltatast, akkor csak azt az egy dolgot kell kikapcsolni, de nem kell protokollt valtani, igy ugyanaz a webszerver kiszolgalhatna minden bongeszot a http/1.0-tol, a http/1.1-esen at az itt altalam leirt http/1.2-esig. Tovabbi elony, hogy sok jelenleg hasznalatban levo tuzfal es egyeb termek kepes lenne transzparensen atengedni a modositott http protokollt, mig egy teljesen uj protokoll eseten komoly fejlesztesekre lenne szukseg.