DEV Community

ZeroTrust Architect
ZeroTrust Architect

Posted on • Originally published at cacheguard.com

Reducing Office Bandwidth With Squid Caching, HTB QoS, and Category Filtering: A Technical Walkthrough

#opensource #linux #devops #networking

Three techniques reduce office internet bandwidth consumption: web caching (reduce traffic volume), QoS (prioritize what reaches the connection), and content filtering (eliminate unnecessary traffic). Here is the technical implementation of each.

Reducing Office Bandwidth

Web caching: Squid configuration and cache hit mechanics

Squid is the standard open-source proxy cache. Cache hit rate — the proportion of requests served from cache — determines actual bandwidth savings.

# /etc/squid/squid.conf — basic caching configuration
cache_mem 512 MB
maximum_object_size_in_memory 1 MB
cache_dir ufs /var/spool/squid 20000 16 256
maximum_object_size 200 MB
minimum_object_size 0 KB

# Cache freshness
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320
Enter fullscreen mode Exit fullscreen mode

What drives cache hit rate

The Cache-Control response header determines cacheability:

Cache-Control: max-age=86400      # Cacheable for 24 hours → cache hit on repeat request
Cache-Control: no-store           # Never cached → always fetches from origin
Cache-Control: private            # Browser cache only, not proxy → always fetches
Enter fullscreen mode Exit fullscreen mode

In practice, most SaaS application responses are Cache-Control: no-store or private. Static assets (CSS, JS, images, fonts, software packages) are typically cacheable. Realistic cache hit rates in an office environment: 15-40% of requests by count, but static assets are small — actual bandwidth savings may be 10-25% of bytes transferred.

HTTPS and the SSL inspection requirement

HTTPS traffic is not cacheable without SSL inspection. The proxy cannot read Cache-Control headers in an encrypted response. Enabling ssl-bump (TLS MITM) makes HTTPS content cacheable and dramatically increases hit rates:

# ssl-bump for HTTPS caching
http_port 3128 ssl-bump cert=/etc/squid/ca.pem key=/etc/squid/ca.key
ssl_bump stare all
ssl_bump bump all

# Exempt domains that use certificate pinning
acl no_ssl_bump ssl::server_name_regex -i apple.com google-update.com
ssl_bump splice no_ssl_bump
Enter fullscreen mode Exit fullscreen mode

QoS: HTB + SFQ with tc

HTB (Hierarchical Token Bucket) guarantees bandwidth minimums and allows borrowing from idle classes. SFQ (Stochastic Fairness Queuing) provides per-flow fairness within each class.

# Attach HTB root qdisc to WAN interface
tc qdisc add dev eth0 root handle 1: htb default 30

# Total bandwidth: 100Mbit
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit

# Class 1:10 — Real-time (VoIP, video calls): 20Mbit guaranteed, burst to 100Mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 20mbit ceil 100mbit prio 1

# Class 1:20 — Business traffic: 70Mbit guaranteed
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 70mbit ceil 100mbit prio 2

# Class 1:30 — Bulk/background: 10Mbit guaranteed, capped at 30Mbit
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 10mbit ceil 30mbit prio 3

# Add SFQ to each leaf class for per-flow fairness
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

# Classify traffic: DSCP EF (VoIP/video) → high priority class
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 \
  match ip tos 0xb8 0xfc flowid 1:10

# Classify HTTP/HTTPS to business class
tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 \
  match ip dport 443 0xffff flowid 1:20

# Everything else → bulk class (default 30)
Enter fullscreen mode Exit fullscreen mode

Content filtering: eliminate non-work bandwidth entirely

Category-based URL filtering removes streaming, file-sharing, and social media traffic during business hours — not throttled, eliminated:

# SquidGuard integration for category-based filtering
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
Enter fullscreen mode Exit fullscreen mode 
# /etc/squidguard/squidGuard.conf
dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

dest streaming {
    domainlist streaming/domains
    urllist streaming/urls
}

dest social {
    domainlist social/domains
}

acl {
    # Apply during business hours
    default {
        pass !streaming !social all
        redirect http://gateway/blocked.html
    }
}
Enter fullscreen mode Exit fullscreen mode

Time-based rules restrict blocking to business hours; outside those hours all traffic is permitted.

Combined effect

On a typical 30-person office network:

  • Web caching (with SSL inspection): 15-30% of bytes served locally
  • QoS: no bandwidth saved, but VoIP/video call quality maintained under load
  • Content filtering (streaming blocked 9-18h): 20-40% reduction in peak-hour bytes

The sequence matters: cache first (reduce volume), shape second (manage what remains), filter third (eliminate unnecessary load).

CacheGuard ships Squid, HTB+SFQ QoS, and URL filtering pre-integrated in a single appliance OS, configured through a browser-based interface.

→ https://www.cacheguard.com/reduce-internet-bandwidth-usage-office/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Top comments (0)