On 09.02.2012 05:35, Carsten Ralle wrote:
>>> What I was looking for is a "line sharing" the other way around
>>> (downstream traffic):
>>>
>>> client -> Cache1 -> line -> Cache2 -> Webserver
>>> (>Request)
>>> <- Cache1<- lines<- Cache2<------' (<Reply)
>>> ^
>>> |
>>> line sharing needed
>>>
>>> Did I get this right or is there a way to configure Cache2 to use
>>> separate lines for downstream traffic using your random ACLs ?
>>
>> Individual IP packets can take paths like that because each one is
>> separately address with source and destination details.
>>
>> HTTP does not work that way. The reply MUST come back on the same
>> TCP
>> connection the requests went out on. Squid can vary the IP address
>> it
>> uses, and trigger different routing for that whole connection
>> request/reply sequence. But that is as far as Squid can go.
> as you are far more familiar with the protocol details just a quick
> question about your suggestion:
>
> for me cache2 terminates the http connection, so all connections to
> web-servers are made by cache2 as the "face" of all traffic. Correct
> ?
Yes.
>
> In case we would set up direct routes from three public IPs on Cache2
> to
> three corresponding IPs on the interfaces of the multi-WAN-router
> would
> that speed up a single http/https/ftp download (Cache2->Cache1) using
> your feature and tcp_outgoing_address ?
A single request? no.
Multiple requests which overlap? yes, very likely.
Amos
Received on Wed Feb 08 2012 - 22:07:30 MST
This archive was generated by hypermail 2.2.0 : Thu Feb 09 2012 - 12:00:02 MST