Me estoy comunicando con un servidor Tomcat utilizando una aplicación Java ME en mi dispositivo móvil.
Me preguntaba si podría comprimir mis solicitudes/respuestas usando Gzip para reducir el número de bytes enviados a través de la red.¿Puedo comprimir solicitudes HTTP usando GZIP?
Los teléfonos modernos tienen tanta potencia de CPU y la red es relativamente lenta, por lo que la compresión tiene mucho sentido. Es bastante fácil de hacer también.
En el lado J2ME, haces algo como esto (suponiendo que el uso HttpConnection),
hc.setRequestProperty("Accept-Encoding", "gzip, deflate");
if (hc.getResponseCode() == HttpConnection.HTTP_OK) {
InputStream in = hc.openInputStream();
if ("gzip".equals(hc.getEncoding()))
in = new GZIPInputStream(in);
...
Utilizamos GZIPInputStream de TinyLine pero estoy seguro de que hay otros,
http://www.tinyline.com/utils/index.html
En el lado del servidor, todo está incorporado. Sólo tiene que añadir siguientes atributos al conector en server.xml de Tomcat,
<Connector
compression="on"
compressionMinSize="2048"
compressableMimeType="text/html,application/json"
... />
Dado que está utilizando Tomcat, considere la posibilidad de colocar una instancia de Apache HTTP Server frente al servidor Tomcat.
Esto se puede hacer utilizando el módulo mod_jk para Apache HTTP Server. Una vez que haya hecho eso, puede usar mod_gzip/mod_deflate en Apache.
Por supuesto, su cliente debe tener la capacidad de manejar las respuestas comprimidas, para que esto funcione. Si fuerza a su cliente a trabajar con respuestas comprimidas, el cliente terminará mostrando un galimatías, ya que (normalmente) habría esperado respuestas de texto sin formato. Encontrará el indicador definitivo de la capacidad del cliente para manejar las respuestas comprimidas, en los encabezados de aceptación y codificación del cliente.
Esto se puede realizar programáticamente, utilizando un servlet o un filtro de servlet que escribe en un ZipOutputStream o GZipOutputStream, si desea evitar la introducción del Servidor Apache HTTP en la red. Encontrará algunos punteros en how to do this at the OReilly OnJava.com site.
Usted puede hacer la compresión gzip en Tomcat sin añadir Apache. Mire el atributo de compresión del conector HTTP: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html –
Sí, lo sé, pero hay una razón por la cual la compresión se realiza en el servidor HTTP en comparación con el servidor de aplicaciones: distribución de la carga del servidor. Uno no querría que el servidor de aplicaciones se cargara con la compresión de respuesta, aparte de su tarea habitual de ejecutar la lógica de la aplicación. Además, el servidor HTTP Apache tiene características de rendimiento mucho mejores que Tomcat. –
Puede comprimir el contenido de una solicitud o respuesta HTTP, pero no los encabezados. Consulte la sección 3.6 de la especificación HTTP 1.1 y la sección posterior que describe el encabezado Content-Encoding.
EDITAR: La otra cara de esto es que no hay garantía de que un lado del servidor HTTP acepte un formato de compresión particular. Y dependiendo de la calidad de la implementación de HTTP en el lado del servidor, es posible que ni siquiera reconozca que el contenido de la solicitud se ha comprimido. Por lo tanto, no desea hacer esto a menos que sepa que el lado del servidor admite el contenido de solicitud comprimido.
Como dice Stephen C, ¿esto solo comprimirá los datos o también los encabezados HTTP? –
@Kevin, esto no comprimirá los encabezados. Si los encabezados se comprimieran, ¿cómo determinará el cliente cómo se comprimieron? GZIP es solo un método de compresión. –
@Kevin. Eso es correcto. Los encabezados no son compresibles usando HTTP basado en estándares. –