設計用於流量壓縮的移動Web服務器和客戶端

Question

我對如何最好地解決這個問題感到有些困惑。

事情 ：我正在創建一個j2me移動應用程序，它將通過HTTP將壓縮數據發送到Web服務器，然后Web服務器將解壓縮請求，獲取數據，壓縮數據並發送回客戶端。

一個類似的解決方案是： T-Booster

問題 ：我對如何從客戶端應用程序發送壓縮的http請求，服務器使用什么技術以及如何最好地實現它感到困惑。 假設服務器一次處理數千個請求，對整個應用程序的影響是什么？

評論非常感謝。 謝謝。

Answer 1

方法I：最重要的標准： 壓縮，安全和建築設計自由

實現數據壓縮的最佳可行方法是創建移動客戶端及其服務器可理解的自定義語言。 您可以使用GZIP / LZW或任何其他壓縮算法為其添加下一級壓縮。

優點：

1. 使用最少的標頭自定義有效負載內容並將其發送到服務器。
2. 從屋檐下降器相對安全，額外的加密水平也不會造成傷害，但需要根據需要進行考慮。
3. 拖曳水平壓縮減少總有效載荷。
4. 除非您使用GZIP /加密庫，否則不依賴於任何第三方編碼器/解碼器庫。 因此它可跨平台移植。
5. 由於沒有使用第三方庫，假設沒有gzip且沒有加密算法，沒有商業許可麻煩。

缺點：

1. 難以維護自定義語言，應該支持架構，設計和javadoc
2. 如果使用多個壓縮器，則創建有效負載的時間相對較長。 自定義語言編碼，GZIP壓縮和加密庫。

示例：在此鏈接中， Opera Mini閱讀有關功能的部分。

。

方法II：最高標准： 嚴格的項目時間表

為了快速支付項目，使用第三方壓縮器，如GZIP和行業標准的Web服務內容交換格式，如SOAP和JSON。

優點：

1. 快速集成，遵循標准方法，使Web服務器組件更易於開發
2. 發明輪子沒有時間消耗，就像說在構建和開發自定義語言時沒有浪費時間。

缺點：

1. 級別壓縮由第三方庫驅動，其中實際內容可能不會被壓縮。 該庫只會重構類似於香農/速率 - 失真理論。
2. 壓縮在低端/高端設備中的工作原理相同，因此堆內存消耗可能會在低內存設備上受阻。
3. 依賴於第三方庫，您永遠不知道何時撤回支持。
4. 除非使用開源庫，否則在使用第三方庫時，您可能會陷入商業許可的惡性循環。

示例： http ： //developers.sun.com/mobility/apis/articles/wsa/

。

編輯：一些非常有用的鏈接

1. InformIT的
2. DevX
3. 設計移動Web服務
4. 為移動用戶提供Web服務：移動服務門戶的體系結構設計

Answer 2

我不是J2ME開發人員，但想分享我作為Java開發人員的觀點。 如果您正在與您的Web服務器通信，那么我猜您將調用Web服務（SOAP或REST）。 我做了類似於Web服務的SOAP，以便在一段時間后壓縮通信。 這是我所遵循的。 http://www.predic8.com/soap-compression-howto.htm