2009-08-11 10 views
9

Ahora es de conocimiento común combinar hojas de estilo y scripts en un esfuerzo por reducir las solicitudes HTTP. Tengo 2 preguntas:Optimización de solicitudes HTTP: ¿Cuál es el límite?

  1. ¿Qué tan caras son, realmente?
  2. ¿Cuándo es una solicitud demasiado grande, debería dividirse?

No puedo encontrar las respuestas a estas dos preguntas en todas las lecturas en línea que hice, como Yahoo! Best Practices que establece un número de veces que las peticiones HTTP son caros, pero nunca citar por qué o cómo.

Gracias de antemano.

Respuesta

6

Una petición HTTP requiere una conexión TCP/IP a realizar (Piense, de 3 vías apretón de manos apretón de manos) antes de que pueda manejar la petición HTTP en sí

Esto implica al menos un retraso de enviar el mensaje SYN el servidor y recuperar el SYN/ACK (luego envía el ACK para ABRIR el socket).

Por lo tanto, supongamos que la demora entre el cliente y el servidor es uniforme en ambos sentidos y en 50 ms, lo que da como resultado un retraso de 100 ms antes de que pueda enviar la solicitud HTTP. Son otros 100 ms antes de que comience a recibir la solicitud real (envía la solicitud y luego el servidor responde).

Por supuesto, también debe tener en cuenta que un navegador web estándar limita el número de solicitudes HTTP simultáneas que está procesando al mismo tiempo. Si tus solicitudes tienen que esperar, no obtienes ese tiempo de handshake gratis (por así decirlo), ya que debes esperar a que termine también otra conexión. Los servidores desempeñan un papel también, dependiendo de cómo responden las solicitudes.

+2

Agregando a esta respuesta, los navegadores normalmente solo abren un número limitado de conexiones TCP a la vez (~ 2..4), por lo que si tiene más solicitudes que ese número, se pondrán en cola. –

+0

Pensé agregar eso tan pronto como llegue a la publicación. Detalle bastante importante realmente. –

1

No tengo una respuesta para qué tan costosas son las solicitudes HTTP, pero siempre es una buena idea reducir los viajes de ida y vuelta entre el cliente y el servidor. Si tiene una cantidad fija de datos para transmitir, siempre será mejor hacerlo en menos solicitudes.

2
  1. Cada vez que se realiza una solicitud, está sujeta a las duras realidades de la fiabilidad de la red. Dos solicitudes realizadas en sucesión rápida desde la misma ubicación pueden tomar rutas completamente diferentes, por lo que con cada solicitud se agrega un elemento de impredecibilidad en términos de rendimiento. Una sola solicitud consolidada puede ayudar a mitigar ese riesgo. @Dan McG escribió un punto de sonido sobre la sobrecarga de handshake de TCP.
  2. HTTP no se preocupa por el tamaño de solicitud, ya que sirve como un protocolo de capa de aplicación en la pila IP (Internet Protocol Suite). Eso es para preocuparse por TCP/IP , lo que le preocupa al editor es mantener el tamaño de los documentos/archivos lo más pequeño posible, y lo suficientemente pequeño como para que su aplicación sea lo suficientemente eficiente.

Espero que tenga sentido.

Cuestiones relacionadas