Benefits of using Squid proxy in modern browsers (Chrome, Firefox, Safari)
up vote
1
down vote
favorite
With all the file caching already done in browsers, I was wondering if there is any benefit to configuring your Browser to use a local (LAN or on same machine) Squid proxy.
Looking at the console output in Chrome, most of the files are already taken from the browser cache.
Is there any use case for using Squid proxy in browsers?
browser proxy browser-cache squid
add a comment |
up vote
1
down vote
favorite
With all the file caching already done in browsers, I was wondering if there is any benefit to configuring your Browser to use a local (LAN or on same machine) Squid proxy.
Looking at the console output in Chrome, most of the files are already taken from the browser cache.
Is there any use case for using Squid proxy in browsers?
browser proxy browser-cache squid
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
With all the file caching already done in browsers, I was wondering if there is any benefit to configuring your Browser to use a local (LAN or on same machine) Squid proxy.
Looking at the console output in Chrome, most of the files are already taken from the browser cache.
Is there any use case for using Squid proxy in browsers?
browser proxy browser-cache squid
With all the file caching already done in browsers, I was wondering if there is any benefit to configuring your Browser to use a local (LAN or on same machine) Squid proxy.
Looking at the console output in Chrome, most of the files are already taken from the browser cache.
Is there any use case for using Squid proxy in browsers?
browser proxy browser-cache squid
browser proxy browser-cache squid
asked Nov 16 at 17:17
frhd
1084
1084
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
Squid dates back from when a company or enterprise, with a 1.5Mbps T1 connection (or less) to the Internet, would run a proxy server for many users on a network. This had the following benefits:
- This would prevent duplicate requests for resources going out over relatively slow WAN link (compared to 10/100/1000 LAN speeds).
- Since all Internet-facing HTTP requests have to go through Squid, logging and filtering was easy to do.
- IIRC Squid has authentication support so only allowing certain users to have Internet access is possible, as well as tracking accesses per user.
Squid benefits the best when you have multiple users/systems on a network that will pull from its cache. Browsers had some level of caching for a long time.
The benefit might be less these days because
WAN speeds are much higher than they were in T1 days
Most websites serve dynamic content.
Websites that are heavy on AJAX/XHR/Websockets for interactivity - very common now - don't generate a lot of cacheable traffic.
Many media-heavy sites would consume a lot of cache space and try to avoid caching due to copyright concerns.
HTTPS is not cacheable without a MITM setup which requires deployment of certificates to each browser wanting to use the proxy.
For a single user, Squid is overkill unless you want its logging facilities or want to purposefully not provide a system with direct Internet access but still let it get to the web in some way.
This is really brilliant information, thank you! I was wondering about the HTTPS part: These days it's obligatory in certain EU countries like Germany to provide HTTPS in business contexts (even simple websites), so this one really brings in doubt the usefulness of a web cache for the average use-case.
– frhd
Nov 17 at 22:03
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
Squid dates back from when a company or enterprise, with a 1.5Mbps T1 connection (or less) to the Internet, would run a proxy server for many users on a network. This had the following benefits:
- This would prevent duplicate requests for resources going out over relatively slow WAN link (compared to 10/100/1000 LAN speeds).
- Since all Internet-facing HTTP requests have to go through Squid, logging and filtering was easy to do.
- IIRC Squid has authentication support so only allowing certain users to have Internet access is possible, as well as tracking accesses per user.
Squid benefits the best when you have multiple users/systems on a network that will pull from its cache. Browsers had some level of caching for a long time.
The benefit might be less these days because
WAN speeds are much higher than they were in T1 days
Most websites serve dynamic content.
Websites that are heavy on AJAX/XHR/Websockets for interactivity - very common now - don't generate a lot of cacheable traffic.
Many media-heavy sites would consume a lot of cache space and try to avoid caching due to copyright concerns.
HTTPS is not cacheable without a MITM setup which requires deployment of certificates to each browser wanting to use the proxy.
For a single user, Squid is overkill unless you want its logging facilities or want to purposefully not provide a system with direct Internet access but still let it get to the web in some way.
This is really brilliant information, thank you! I was wondering about the HTTPS part: These days it's obligatory in certain EU countries like Germany to provide HTTPS in business contexts (even simple websites), so this one really brings in doubt the usefulness of a web cache for the average use-case.
– frhd
Nov 17 at 22:03
add a comment |
up vote
3
down vote
accepted
Squid dates back from when a company or enterprise, with a 1.5Mbps T1 connection (or less) to the Internet, would run a proxy server for many users on a network. This had the following benefits:
- This would prevent duplicate requests for resources going out over relatively slow WAN link (compared to 10/100/1000 LAN speeds).
- Since all Internet-facing HTTP requests have to go through Squid, logging and filtering was easy to do.
- IIRC Squid has authentication support so only allowing certain users to have Internet access is possible, as well as tracking accesses per user.
Squid benefits the best when you have multiple users/systems on a network that will pull from its cache. Browsers had some level of caching for a long time.
The benefit might be less these days because
WAN speeds are much higher than they were in T1 days
Most websites serve dynamic content.
Websites that are heavy on AJAX/XHR/Websockets for interactivity - very common now - don't generate a lot of cacheable traffic.
Many media-heavy sites would consume a lot of cache space and try to avoid caching due to copyright concerns.
HTTPS is not cacheable without a MITM setup which requires deployment of certificates to each browser wanting to use the proxy.
For a single user, Squid is overkill unless you want its logging facilities or want to purposefully not provide a system with direct Internet access but still let it get to the web in some way.
This is really brilliant information, thank you! I was wondering about the HTTPS part: These days it's obligatory in certain EU countries like Germany to provide HTTPS in business contexts (even simple websites), so this one really brings in doubt the usefulness of a web cache for the average use-case.
– frhd
Nov 17 at 22:03
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
Squid dates back from when a company or enterprise, with a 1.5Mbps T1 connection (or less) to the Internet, would run a proxy server for many users on a network. This had the following benefits:
- This would prevent duplicate requests for resources going out over relatively slow WAN link (compared to 10/100/1000 LAN speeds).
- Since all Internet-facing HTTP requests have to go through Squid, logging and filtering was easy to do.
- IIRC Squid has authentication support so only allowing certain users to have Internet access is possible, as well as tracking accesses per user.
Squid benefits the best when you have multiple users/systems on a network that will pull from its cache. Browsers had some level of caching for a long time.
The benefit might be less these days because
WAN speeds are much higher than they were in T1 days
Most websites serve dynamic content.
Websites that are heavy on AJAX/XHR/Websockets for interactivity - very common now - don't generate a lot of cacheable traffic.
Many media-heavy sites would consume a lot of cache space and try to avoid caching due to copyright concerns.
HTTPS is not cacheable without a MITM setup which requires deployment of certificates to each browser wanting to use the proxy.
For a single user, Squid is overkill unless you want its logging facilities or want to purposefully not provide a system with direct Internet access but still let it get to the web in some way.
Squid dates back from when a company or enterprise, with a 1.5Mbps T1 connection (or less) to the Internet, would run a proxy server for many users on a network. This had the following benefits:
- This would prevent duplicate requests for resources going out over relatively slow WAN link (compared to 10/100/1000 LAN speeds).
- Since all Internet-facing HTTP requests have to go through Squid, logging and filtering was easy to do.
- IIRC Squid has authentication support so only allowing certain users to have Internet access is possible, as well as tracking accesses per user.
Squid benefits the best when you have multiple users/systems on a network that will pull from its cache. Browsers had some level of caching for a long time.
The benefit might be less these days because
WAN speeds are much higher than they were in T1 days
Most websites serve dynamic content.
Websites that are heavy on AJAX/XHR/Websockets for interactivity - very common now - don't generate a lot of cacheable traffic.
Many media-heavy sites would consume a lot of cache space and try to avoid caching due to copyright concerns.
HTTPS is not cacheable without a MITM setup which requires deployment of certificates to each browser wanting to use the proxy.
For a single user, Squid is overkill unless you want its logging facilities or want to purposefully not provide a system with direct Internet access but still let it get to the web in some way.
answered Nov 16 at 17:36
LawrenceC
58.4k10100178
58.4k10100178
This is really brilliant information, thank you! I was wondering about the HTTPS part: These days it's obligatory in certain EU countries like Germany to provide HTTPS in business contexts (even simple websites), so this one really brings in doubt the usefulness of a web cache for the average use-case.
– frhd
Nov 17 at 22:03
add a comment |
This is really brilliant information, thank you! I was wondering about the HTTPS part: These days it's obligatory in certain EU countries like Germany to provide HTTPS in business contexts (even simple websites), so this one really brings in doubt the usefulness of a web cache for the average use-case.
– frhd
Nov 17 at 22:03
This is really brilliant information, thank you! I was wondering about the HTTPS part: These days it's obligatory in certain EU countries like Germany to provide HTTPS in business contexts (even simple websites), so this one really brings in doubt the usefulness of a web cache for the average use-case.
– frhd
Nov 17 at 22:03
This is really brilliant information, thank you! I was wondering about the HTTPS part: These days it's obligatory in certain EU countries like Germany to provide HTTPS in business contexts (even simple websites), so this one really brings in doubt the usefulness of a web cache for the average use-case.
– frhd
Nov 17 at 22:03
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1376052%2fbenefits-of-using-squid-proxy-in-modern-browsers-chrome-firefox-safari%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown