彭勇华的Squid中文Blog

Somebody asked:

there's been a lot of talk about TPROXY being added back into the linux
kernel and squid changing to support it.

Currently, we do transparent proxying by policy routing port 80 traffic to
the proxy server then using DNAT (iptables) on the proxy server. 
Could someone point me to something that explains the benefit of TPROXY
over DNAT?  We would look to migrate over if there's a substantial benefit.

Amos replied:
The only documentation I know of that attempts to compare is the readme by Balabit.
http://www.balabit.com/downloads/files/tproxy/README.txt

The following is based on my knowledge of TPROXYv4, I can't speak for the older obsolete TPROXYv2.

Not requiring NAT to operate it is not limited in quite the same ways. It's also much more efficient from an application viewpoint and has the possibility of being coded to support other protocols such as IPv6 where NAT is not possible. (Though kernel support still has to be written for non-IPv4).

The other side is that it is a true source-spoofing mechanism which is both a pro and con. It's a real invisible proxy. But triangle-of-doom routing causes greater havoc and much harder to fix.

Overall, I see it as a much better alternative to the NAT methods if both are available to you and one needs to be used. But is not really something to normally go out and look for specially.

acl status403  http_status 403
http_reply_access deny status403
deny_info /path/403info.html status403

 

这里是http_reply_access而不是http_access，since the *reply* status is present.

定制squid链：

iptables -t nat -N squid

iptables -t nat -A PREROUTING --protocol tcp --dport 80 -j squid 

 

拦截：

iptables -t nat -A squid -s 10.0.0.1 -j ACCEPT

iptables -t nat -A squid -j DNAT --to-destination 10.0.0.1:81

 

不拦截某site：

iptables -t nat -A squid -d xx.xx.xx.xx -j ACCEPT

(以前写的,当时用的RH Linux AS5.)

如下网络配置参数调整,主要是针对请求压力大的Linux (2.6 kernel)服务器而言.

如果服务器压力不大,那么维持默认即可.

 

下述内容取材于"Performance Tuning For Linux Server"一书.

 

$ /proc/sys/net/core/wmem_max
最大socket写buffer,可参考的优化值:873200

 

$ /proc/sys/net/core/rmem_max
最大socket读buffer,可参考的优化值:873200

 

$ /proc/sys/net/ipv4/tcp_wmem
TCP写buffer,可参考的优化值: 8192  436600  873200

 

$ /proc/sys/net/ipv4/tcp_rmem
TCP读buffer,可参考的优化值: 32768  436600  873200

 

$ /proc/sys/net/ipv4/tcp_mem
同样有3个值,意思是:
net.ipv4.tcp_mem[0]:低于此值,TCP没有内存压力.
net.ipv4.tcp_mem[1]:在此值下,进入内存压力阶段.
net.ipv4.tcp_mem[2]:高于此值,TCP拒绝分配socket.
上述内存单位是页,而不是字节.
可参考的优化值是:786432  1048576 1572864

 

$ /proc/sys/net/core/netdev_max_backlog
进入包的最大设备队列.默认是300,对重负载服务器而言,该值太低,可调整到1000.

 

$ /proc/sys/net/core/somaxconn
listen()的默认参数,挂起请求的最大数量.默认是128.对繁忙的服务器,增加该值有助于网络性能.
可调整到256.

 

$ /proc/sys/net/core/optmem_max
socket buffer的最大初始化值,默认10K.

 

$ /proc/sys/net/ipv4/tcp_max_syn_backlog
进入SYN包的最大请求队列.默认1024.对重负载服务器,增加该值显然有好处.
可调整到2048.

 

$ /proc/sys/net/ipv4/tcp_retries2
TCP失败重传次数,默认值15,意味着重传15次才彻底放弃.可减少到5,以尽早释放内核资源.

 

$ /proc/sys/net/ipv4/tcp_keepalive_time
$ /proc/sys/net/ipv4/tcp_keepalive_intvl
$ /proc/sys/net/ipv4/tcp_keepalive_probes
这3个参数与TCP KeepAlive有关.默认值是:

tcp_keepalive_time = 7200 seconds (2 hours)
tcp_keepalive_probes = 9
tcp_keepalive_intvl = 75 seconds

意思是如果某个TCP连接在idle 2个小时后,内核才发起probe.

如果probe 9次(每次75秒)不成功,内核才彻底放弃,认为该连接已失效.

对服务器而言,显然上述值太大. 可调整到:

/proc/sys/net/ipv4/tcp_keepalive_time  1800
/proc/sys/net/ipv4/tcp_keepalive_intvl  30
/proc/sys/net/ipv4/tcp_keepalive_probes  3

 

$ proc/sys/net/ipv4/ip_local_port_range
指定端口范围的一个配置,默认是32768   61000,已够大.

Apache在使用mod_gzip或mod_deflate时，对非压缩的目标，需要返回Vary:头部吗？

答案是肯定。这一是RFC的要求，二是如果不返回，会导致前端Cache（如Squid）无法缓存压缩的目标。详见：

 

我前面也讲过，Apache对非压缩目标返回的Vary:头部会导致IE6及以下处理不了（IE的Bug）。

解决这个问题的方法是使用Apache2.2的mod_rewrite，对请求头部的Accept-Encoding关键字进行rewrite。

原理如下：

 

假设Apache的压缩目录为/path/htdocs/webdir/。

建立一个对该目录的符号链接/path/htdocs/webdir2/。

配置mod_rewrite，如果客户端请求头部不包含Accept-Encoding关键字，那么将请求rewrite到webdir2。

由于webdir2没有启用mod_deflate，所以它不会返回Vary:头部。

如果客户端请求头部包含了Accept-Encoding关键字，那么由webdir目录处理，启用压缩并返回了Vary:头部。

 

注意这个rewrite是个外部重定向，它返回302并定向到到新路径（/webdir2/），Squid将不接受压缩的客户端请求的非压缩的目标Cache在这个新路径下。

/webdir/路径下就只存放了接受压缩的客户端请求的压缩的目标。在此情形下，Etag似乎都用不上了。

 

另外注意只有Apache2.2才能基于某些特殊的头部进行rewrite。

如果是Apache2.0或1.3，需要自己编写Apache Handler。我一年前写过一个（工作在请求处理的Fixup阶段），但现在找不到了。