Archivo de la etiqueta: HTTP

Captura de cabeceras HTTP en tiempo real

[spanish]Algunas personas me llaman friki por hacer cosas como esta, analizar una captura de tcpdump con strings y grep:[/spanish]

[english]Some people call me a freak because of doing things like this, analyzing a tcpdump capture with strings and grep:[/english]


tcpdump -i any -p -s 0 -w - "port 80" | strings | grep -E "^(GET|POST|HEAD|[a-zA-Z-]+:) "

:-D

nginx, memcached y HTTP 304

[spanish]Estoy trabajando en la arquitectura de servidores para una nueva versión de un portal web. Va a estar basada en servidores Amazon-EC2, con un front end con nginx y varios tomcat de back end. Los servidores nginx harán de proxy-caché para ciertas páginas dinámicas (resultados de búsquedas, consultas a los web-services internos) y también tendrá una caché de páginas estáticas gestionada por nosotros en código con memcached.

Al empezar a integrar memcached en esta estructura vi que ya no se enviaban respuestas HTTP 304, todo lo que se servía del memcached eran HTTP 200. Después de usar el comodín de Google parece que es el resultado esperado, ya que memcached no almacena la fecha de modificación de las páginas para poder servir la cabecera HTTP «last-modified», con lo que los clientes tampoco envían la «if-modified-since» y no hay 304. Así que le he metido mano al código, el parche está aquí.

Estoy bastante sorprendido de lo sencillo que ha sido y lo simple que es el parche, ya que no he tenido que desarrollar la lógica para ver si la página en memcache es más reciente que la que tiene el cliente en su caché y devolver 304 ó 200. Una vez que desde nginx-memcached devuelvo la cabecera «last-modified», parece que nginx se encarga el sólo de comparar cabeceras y devolver 304 ó 200 según corresponda. ¡Y funciona!

He estado probando esto esta mañana en el trabajo y parece que todo funciona como toca. Mañana haré más pruebas y modificaré el parche si hace falta. Mientras tanto si alguien se anima a probarlo y le funciona (o no), soy todo oídos. :-)[/spanish]

[english]I’m working on the server architecture for a new web portal. It’s going to be Amazon-EC2based and will have a nginx front end to several tomcat back end servers. The nginx servers will proxy-cache some dynamic pages (search results, internal web-services queries) and will also have a static page cache based on memcached.

While starting to roll memcached into the solution I noticed that I stoped receiving HTTP 304 responses, everything served off memcached where 200. After digging a little bit on Google I found out it was the expected behavior as memcached doesn’t store the timestamp (last-modified) of the files. So I’ve given it a try and developed a quick patch. You can find it here.

I’m quite puzzled at the simplicity of the patch, as I didn’t need to code the logic to check if the cached page is more recent than the client’s one and return 302 or 200. After successfully returning the last-modified header from memcached, nginx seems to do the rest of the job somewhere on its own!

I have tested the patch today at work and everything seems to work OK. Will do more extensive testings tomorrow and update the path if needed. In the meantime, if someone gives it a try and works for them (or doesn’t), I’m waiting for your feedback.[/english]

Google, reinventando Internet

Primero fue Wave, que a mi modo de ver no es un intento de crear una red social ni de desbancar a Facebook ni a Twitter en lo suyo (aunque probablemente acabará/ía pasando), si no una forma de reinventar la comunicación en Internet: el principal medio de mensajería «serio» es el correo electrónico, y cualquiera que haya administrado un servidor estará de acuerdo conmigo en que el protocolo SMTP tiene problemas, MUCHOS problemas; Y luego está la mensajería instantánea, microblogging y demás. Para mi Wave es un intento de reinventar y unificar todas estas formas de comunicación en una sola, y además hacerla abierta, extensible y muy colaborativa. BTW, ¿a alguien le sobra alguna invitación para Wave? O:-) ¡Gracias, Luismi!

Y no contentos con reinventar el correo-IM-microblogging, ahora están jugando con un sustituto para el HTTP: el protocolo se llama SPDY y por lo visto ya tienen un servidor y una versión modificada de Chrome rulando, y en pruebas de laboratorio han visto mejoras de rendimiento del 50-60%. SPDY apunta a solventar problemas de latencias y mejorar el aprovechamiento de la conexión con medidas como no reenviar cabeceras HTTP (el equivalente) con cada GET, reaprovechar una única conexión TCP para enviar/recibir en paralelo varias peticiones en lugar de abrir una conexión TCP por cada elemento o pedir varios elementos en la misma sesión pero de forma secuencial, o permitir que el servidor inicie conexiones con el cliente para enviarle datos actualizados (bye-bye, AJAX). Suena bien.

Cambiar protocolos tan básicos que usa todo el mundo es difícil. Si no mirad cuántos años llevamos haciendo el paripé con IPv6. ¿Cómo se planifica la migración? ¿Se crean puentes entre el protocolo viejo y el nuevo para que durante el proceso haya interoperabilidad, o los primeros en migrar quedan aislados? Alternativas al SMTP hay más de una, pero ninguna ha fructificado. Sin embargo estoy convencido de que Google se va a llevar el gato al agua con Wave, y de aquí a unos (pocos) años el SMTP será un recuerdo del pasado. Y no me extrañaría que con SPDY acabara pasando lo mismo. Si hay alguien con recursos (mentes brillantes) y posición como para conseguir cambios así, es Google.

¿Qué será lo próximo? ¿IPvG?