why webproxy not work with normal pcc
i want to have clear idea about that
Because it takes what would normally be one connection (client to server) and makes it into two connections (client to proxy, proxy to server) and shifts the one connection from going through the router to two connections, one going to the router and the other coming from the router. That means you have to mark both connections, and do so in different chains.
real thx but i has many thing to make it clear
sorry but i don’t know if that what you mean,
one go to router and one go to server(internet)
one come for router and one come for server
or you mean different thing
shift connection form one connection to tow connection happen when we use web-proxy with
one dsl (without pcc) web-proxy work normal, just redirect port 80 to web-proxy port.
Normal connection:
1.1.1.1 (client) -------> (server) 2.2.2.2
1.1.1.1 (client) <------- (server) 2.2.2.2
Proxy (simplified):
1.1.1.1 (client) -------> (router) 3.3.3.3
3.3.3.3 (router) -------> (server) 2.2.2.2
3.3.3.3 (router) <------- (server) 2.2.2.2
1.1.1.1 (client) <------- (router) 3.3.3.3
With PCC used for balancing load across ISP links you’re influencing routing of packets by applying routing marks. The router fundamentally treats packets that are flowing THROUGH it (server to client) differently from packets that are destined to the router itself and packets generated by the router itself.
Packets destined to the router itself shouldn’t have routing influenced at all since the router will not forward them at all. PCC usually applies all that in the prerouting chain, which is before destination NAT (which is what would redirect the packets to the proxy process by rewriting the destination IP address in the IP header of the packet to an IP address that is implemented on a router interface) - those packets that are going to be redirected to the proxy shouldn’t have routing marks and you have to decide that before you apply them to other packets.
Also, packets generated by the router (packets generated by the proxy process contacting a webserver in lieu of the real client) are never going to see the prerouting chain because they are generated by a local process and put straight into the output chain.