¿Cuál es el tamaño mínimo de un paquete TCP?


11

Una publicación aquí:

http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html

afirma que "la descarga más pequeña que pueden hacer los navegadores es de 1K bytes".

¿Se debe esto al tamaño mínimo de un paquete en la red? Si no, ¿cuál es la razón de esto (si es realmente cierto)?


2
Cumpla con los términos estándar si desea evitar confusiones. "Paquete" es un término de nivel de IP. Usted dice "paquete IP", ni "paquete TCP", ni "paquete Ethernet".
vtest

La frase que cita ("La descarga más pequeña que pueden hacer los navegadores es de 1K bytes") ciertamente no es cierta: no hay un tamaño mínimo de descarga; y si bien no es un / tamaño del paquete IP TCP mínimo (según lo explicado por @ DMA57361), ciertamente no es de 1 KB.
Piskvor salió del edificio

Respuestas:


20

Paquete es un término ambiguo aquí porque a veces se usa incorrectamente para referirse a diferentes elementos para su transmisión. Veamos en qué están envueltos sus datos y verá a qué me refiero, y espero obtener la respuesta que deseaba:


Supongamos que está enviando 1 byte de datos 1 a través de Internet, en el modelo TCP / IP .

Los datos comienzan en el nivel de la aplicación y deben estar envueltos en encabezados para los niveles inferiores para que puedan pasarse.

Primero, los datos se envuelven en un segmento TCP , que agrega un encabezado de 20 bytes (el tamaño mínimo ahora es de 21 bytes).
Esto nos pone en el nivel de transporte.

Esto se envuelve en un paquete IP , que agrega otro encabezado de 20 bytes (tamaño mínimo ahora 41 bytes).
Ahora estamos en el nivel de internet.
Tenga en cuenta que este ajuste se cambia cada vez que un nuevo enrutador reenvía sus datos a una nueva subred.

Esto está envuelto en un marco de enlace de algún tipo, cuyo tamaño de encabezado y pie de página varía según el tipo de marco utilizado, que depende del tipo de enlace que se utilice.
Esto está en el nivel de enlace.
Este ajuste se cambia cada vez que la unidad se transmite entre dos entidades.

Finalmente está la transmisión física (p. Ej., Señales eléctricas por un cable, ondas de radio, etc.).

Aquí hay algunas imágenes informativas disponibles en la página del modelo TCP / IP de Wikipedia que pueden explicar visualmente lo que está sucediendo:


Encapsulación de datos usando UDP / IP


Conexión a través de capas en el modelo TCP / IP


1. Supongo que puede enviar 0 bytes ... pero no lo ha comprobado. De hecho, tampoco he comprobado si 1 byte está permitido, pero bueno.


4

Eso es incorrecto, no hay un tamaño mínimo para una descarga. Puede verificar esto creando un pequeño archivo en su servidor web y utilizando wireshark para ver el tráfico de la red cuando descargue ese archivo.

El tamaño mínimo de un paquete de ethernet estándar es de 64 bytes.


3

A primera vista, la publicación de blog de la que está citando es incorrecta. No hay un "tamaño mínimo de descarga" para HTTP. (Y su teoría sobre los tamaños mínimos de paquetes también es incorrecta).

Sin embargo, hay un grano de verdad en esto. Y es que si el tamaño del archivo que está descargando es lo suficientemente pequeño, el mensaje de respuesta HTTP (que consta del archivo y los encabezados de respuesta HTTP) se ajustará en un solo paquete de red. Si eso sucede, es probable que el navegador obtenga el archivo más rápido que si se necesitaran dos o más paquetes para enviar la respuesta.

(Con un paquete en la respuesta, hay menos posibilidades de que un paquete se descarte y deba reenviarse, y una mayor posibilidad de que la ventana de control de flujo TCP / IP no agregue demoras adicionales de ida y vuelta para el reconocimiento de paquetes. )

El tamaño máximo típico de un paquete enviado / recibido (la MTU) es de 1500 bytes para ethernet. Cuando tiene en cuenta los gastos generales de IP y TCP, y el tamaño de un encabezado de respuesta HTTP típico, eso podría dejarle ~ 1K restante para los datos del archivo en el primer paquete de una respuesta. De ahí el grano de verdad en el comentario del blogger.


Eso sería correcto, si solo estuviera descargando esa imagen, y no, por ejemplo, una página web y sus recursos asociados (imágenes, JS, CSS), en cuyo caso está utilizando keepalives y canalizando para múltiples recursos de todos modos, entonces TCP los gastos generales y el tamaño del paquete son mucho menos relevantes. Tiene razón en este caso particular (descargando solo una imagen), pero ¿con qué frecuencia sucede eso? Parece que el blogger está estancado en 1999, donde cada solicitud HTTP necesitaba su propia conexión TCP.
Piskvor salió del edificio

2

Es peor de lo que piensas.

La carga lenta de la página se debe a que el navegador tiene problemas para procesar el píxel 1x1 800000 veces (por ejemplo, para una ventana del navegador establecida en 1000x800). Hace muchos años, tal vez en 1999, leí un artículo en algún lugar que prescribía 16x16 como el 'más rápido' x el más pequeño para el mosaico. Por supuesto, la representación puede ser diferente ahora.

Si lees la publicación del blog, la queja es en realidad sobre la carga lenta de la página. Descarga no lenta No tiene nada que ver con los paquetes, aunque ha sido una discusión interesante.

Entonces, tal vez la pregunta debería reformularse.


En ese caso, es posible que haya entendido mal la publicación del blog por completo: he pensado que el núcleo está en esta oración: "La descarga más pequeña que pueden hacer los navegadores es 1K bytes [y, por lo tanto, ajusta el tamaño de tu imagen a 1K]", que Lo he leído como "... porque de todos modos está transmitiendo 1K bytes, sin importar que su imagen tenga solo 50 bytes" (lo cual es una tontería obvia). El problema aquí puede ser usar " size" tanto para las dimensiones de píxeles como para el recuento de bytes, y combinarlas. Su explicación tiene sentido, pero es irrelevante para el recuento de bytes de imagen (contrario a lo que dice el blog).
Piskvor salió del edificio

Después de volver a leer la publicación del blog, parece desviarse del curso ya que el tercer párrafo es incoherente.
mockman

Después de volver a leer su comentario ... Su objetivo es abordar el problema planteado en el párrafo inicial. Sin embargo, erróneamente atribuye este problema al tamaño de los paquetes y pasa el resto de la publicación en él. Mi respuesta explicó el motivo de la carga lenta de la página. Como otros han señalado, las características del paquete no son la causa.
mockman
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.