Transparentnejsi proxy cache?

[Jan "Yenya" Kasprzak]

[Jan Kasprzak o transparentni HTTP proxy, ktera by "falsovala" adresu tazatele]
[...]
>> 	Jsou nekde slabiny tohoto pristupu?

Lazo at Patria.CZ (Lazo Igor) napsal:
>>
: Neznam http a tak nevim, zda se da poznat, ze
: pozadavek na data je vysledkem akce Reload.

	Ano, v HTTP se da poznat reload (a squid ho take pozna).

: Pokud se tedy Reload da poznat:
: - cache musi ustavit TCP spojeni s klientem
:   ( asi se tedy bude vydavat za cilovy server )

	Ano, o to se postara napriklad router.

: - TCP spojeni obsahuje poradova a potvrzovaci
:   cisla, ktera zacinaji nahodnym cislem a zvetsuji
:   se primo umerne s poctem prenesenych bajtu

	Bezpochyby. Ale nema to co do cineni s vlastni proxy cache.

: - v pripade snahy o prehozeni existujiciho
:   TCP spojeni na cilovy server by tudiz
:   s pravdepodobnosti hranicici s jistotou onen
:   server poslal jine iniciacni poradove cislo
:   TCP spojeni

	Tady se neprehazuje zadne existujici spojeni. U transparentni proxy
klient primo vytvari TCP spojeni s tim proxy (i kdyz o tom nevi).

: - "srovnat krok" by bylo mozne jen prenesenim
:   adekvatniho mnozstvi dat ( az 2na31 ) - takze
:   takhle asi ne.
[...]
: Co na to znalci http, html, ASP apod. ?

	S vyse uvedenym tohle nema nic spolecneho. Tady jde o TCP.
Pripominam, ze transparentni (z hlediska klienta) proxy uz mame zvladnutou.
Jde jen o to, jestli by slo squid presvedcit, aby nepouzival bezne sockety,
ale (napriklad) raw sockety, do kterych by posilal primo packety se zdrojovou
adresou puvodniho tazatele (cili jde mi o proxy "transparentni" z hlediska
WWW _serveru_).

-Yenya

--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
/// I think I'd rather be forced to learn perl than 68020 MMU. -Alan Cox \\\