JSON GZIP设计选择

Question

我正在开发一个Web应用程序，其中包含由运行在JBoss容器中的servlet生成的动态内容，以及由Apache + mod_jk处理的静态内容/负载平衡。

客户端使用jQuery向servlet发出AJAX请求，servlet处理它们，然后生成大量的JSON响应。

我注意到的一件事是原作者选择使用下面的方法手动压缩servlet中的输出流。

 gzout = new GZIPOutputStream(response.getOutputStream());

这可以在Apache端使用mod_deflate处理吗？如果你能做到这一点，它被认为是更好的做法，你能解释为什么或为什么不做？

Answer 1

我认为在你的情况下在Apache中应用HTTP压缩更有意义。

如果服务器已正确配置为压缩此类型的响应（application / json，如果服务器端代码设置了正确的内容类型），则无论如何都会在手动压缩后浪费地重新压缩它。

此外，如果不支持gzip的客户端发出请求，会发生什么？如果您在服务器级别压缩响应，它将根据请求的accept-encoding标头自动响应。

Answer 2

另外一项研究显示了几个不错的选择。

<强>问题：

1. Apache和Jboss之间存在一个网络通道。如果没有jboss端的任何压缩，你就会遇到Apache和客户之间相同的延迟和带宽问题。

<强>解决方案：

1. 您可以在Apache上使用mod_deflate，并在交付给您的客户之前接受来自jboss和compress的未压缩响应。我可以看到这在某些网络拓扑中是有意义的（Dave Ward提出）。

2. 您可以应用Java EE过滤器。这将过滤在它们存在JBoss容器之前压缩它们的响应。这样可以在JBoss级别进行压缩，而无需在业务servlet中使用一堆令人讨厌的GZIP相关代码。

3. JBoss默认使用Tomcat作为其Servlet引擎。如果导航到$ JBOSS_HOME / deploy / jbossweb-tomcat55.sar，则可以编辑server.xml文件以在HTTP / 1.1连接器上打开'compression = on'属性。这将压缩从容器出站的所有响应。

2和3之间的权衡是压缩不同servlet的分餐或压缩所有响应。