JSON GZIP設計選擇

Question

我正在使用一個運行在JBoss容器中的servlet生成動態內容的Web應用程序，以及由Apache + mod_jk處理的靜態內容/負載平衡。

客戶端使用jQuery向處理它們的servlet發出AJAX請求，然後生成大型JSON響應。

我注意到的一件事是，原作者選擇使用類似下面的東西手動壓縮servlet中的輸出流。

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

這可能是在Apache端使用mod_deflate處理的嗎？如果你能做到這一點，這是否被認爲是更好的做法，你能解釋爲什麼或爲什麼不？

Answer 1

有一點額外的研究顯示了幾個很好的選擇。

問題：

1. 有阿帕奇和JBoss之間存在的網絡的信道。如果不在jboss端進行任何類型的壓縮，您在Apache和您的客戶端之間就會遇到相同的延遲和帶寬問題。

解決方案：

1. 您可以在Apache的使用mod_deflate模塊和JBoss的接受未壓縮的響應和交付給客戶之前壓縮。我可以看到這在某些網絡拓撲結構中有意義（由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壓縮塊料或壓縮所有響應。

Answer 2

我相信在你的情況下在Apache中應用HTTP壓縮更有意義。

如果一個服務器被正確配置爲壓縮這種類型的響應（application/json，如果服務器端代碼設置了正確的內容類型），那麼無論如何它都會在手動壓縮後被浪費地重新壓縮。

此外，如果不支持gzip的客戶端發出請求，會發生什麼情況？如果您在服務器級別壓縮響應，它將根據請求的accept-encoding標頭自動作出適當響應。