Add persistent connection support
Brought to you by:
dmcabrita
Menu
▾
▴
This is going to be a PITA and won't be implemented to soon.
Decreasing ticket priority.
A limited and reasonably safe persistent connection support may be implemented if the following occurs:
- loop ziproxy main call.
- the request is a HEAD (thus, no data) -> mark persistence as safe
- persistence_safe == true? if so, repeat loop. otherwise finish business as usual.
Why ?
Persistent connection speeds up browsing at least 5x.
If you monitor the HTTP trafic with a tool like Wireshark, you'll see that websites that allow keep alive transfer the complete page up to 5x faster. It also decrease webserver CPU usage, and thus increase the time a webserver is able to prioritize your request.
Currently, I'm using ziproxy with my mobile phone webbrowser, and even if there is less content to download, it's slower than direct connection.
No persistent connection support is only slower if your browser is using that (because it waits for Ziproxy's reply informing that the connection cannot be persistent).
Once you disable that feature in your browser, it will be faster.
Also, though not your case it seems, for congested WAN acceleration, persistent connection is the least of your concerns.
Well, I don't get it. As the first connection from the browser is waiting for server answer anyway I don't see why persistent connection would be slower.
Also, from this:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
it seems it's required for a compliant HTTP/1.1 client
BTW, I'm speaking of persistent connection server side ("ziproxy to webserver" to speed up caching), not client side ("browser to ziproxy"), as I agree that it would be hard to implement.
You got it wrong, by "No persistent(...)" I meant "Lack of persistent(...)".
And, yes, I'm aware that persistent connection is mandatory for full HTTP/1.1 compliance.
The lack of such feature affects the user depending a lot on the characteristics of the network (that also includes the country where you and the remote hosts are).
In the particular case I used Ziproxy (I'm no longer involved with that network) latency increase wasn't much a issue, bandwidth consumption was the major factor.. So, naturally, the development tended to address that issue (also high reliability was required).
To implement persistent connection in a interesting way (for the user point-of-view), and by that I mean some smart support for pipelining, _structural_ changes in the code would be necessary.
But the unfortunate reality is: Ziproxy is a free-time project with only one active developer, and that limits a lot the things that can be done within reasonable time.
It doesn't mean that it would not happen at all, it's just that promises cannot be made.