¿Por qué la descarga utiliza más datos que el tamaño real del archivo?

Cuando los datos se transmiten a través de una red (o también dentro de una computadora), generalmente se implementa algún tipo de método de prevención de errores y, a menudo, también debe colocar una dirección de destinatario en los datos, como una carta en el correo.

Si imaginamos tener una conversación por teléfono y la conexión no es tan buena como podría ser, se produce un ruido notable o distorsión, y posiblemente interrupciones breves.
Este tipo de comportamiento imperfecto es cierto para todas las redes, si transmite una señal no puede esperar que llegue al otro extremo exactamente como se envió.
Por lo tanto, durante esa conversación por teléfono, tendrá que pasar cierta información a la otra persona, y es absolutamente crucial que obtenga todos los detalles correctos. Como probablemente sepa por haber tenido esa experiencia, se necesita un poco de información adicional y hablar para garantizar que todo salga bien. Primero tiene que decir “Voy a pasarle alguna información” y esperar a que la otra parte diga “¡Estoy escuchando y lista para escribirla!”, Luego pasa la información un poco a un tiempo y esperas a que la otra persona lo verifique, y así sucesivamente. Toda esta charla adicional que se necesita en este caso es comparable a cómo funcionan las redes de computadoras.

Al enviar y recibir datos a través de Internet, implica utilizar un protocolo (o varios) para transmitir y recibir los datos. Voy a mantener esto bastante simple.
Un protocolo es esencialmente un estándar acordado sobre cómo hacer esto, para que ambas partes sepan exactamente qué esperar, qué responder y qué hacer si sucede algo inesperado, etc.

Para algo como una transferencia de archivos, será crucial que los datos se reciban e interpreten exactamente como se transmitieron, cualquier otra cosa daría como resultado un archivo dañado e inutilizable.
Por lo tanto, las transferencias de archivos tienden a depender de un protocolo que utiliza algún tipo de método de prevención de errores. Esto a menudo implica que cada vez que se envían datos, incluye un poco de datos adicionales que no son los datos que desea descargar o transmitir, sino los datos necesarios para garantizar que puedan transmitirse intactos a su destino, algo así como la dirección en un sobre y el sobre en sí, es necesario para llevar el mensaje dentro de forma segura a su destino correcto.
Estos datos adicionales contribuyen a lo que se conoce como sobrecarga, por lo que en su caso hay una sobrecarga de 12 MB.

Los gastos generales no son solo la dirección y el sobre, sino también un poco de datos adicionales que se pueden comparar con los datos reales para determinar si son válidos o no. Una manera simple de entender un sistema de este tipo es pensar en transmitir una gran cantidad de números largos por teléfono a alguien, por ejemplo, números largos como 28388949674990034. Se necesita bastante tiempo para revisar cada dígito, por lo que podríamos usar un error simple método de verificación que requiere que se pase menos información que el número mismo.

Se puede pensar de esta manera:

  • Por razones prácticas, vamos a usar 984836 como nuestro número muuuucho largo, pero supongamos que es mucho más largo.
  • El número se lee en voz alta dígito por dígito.
  • Al final del número se agrega la letra “E” seguida de “38”
  • El destinatario lo anota, tanto el número 984836 como el E38.
  • El reciclante suma los dígitos individuales del número 9 + 8 + 4 + 8 + 3 + 6 = 38, que coincide con el número al final. La letra E está allí porque el número 38 es un número par. Si hubiera sido extraño, podríamos usar O.
  • Debido a que la suma de cada dígito coincide con nuestro número de suma de verificación 38 y E coincide con 38 siendo un número par, tenemos cierta certeza adicional de que el número que anotamos es de hecho el número que supuestamente debíamos anotar.
  • Si un solo dígito ha sido malinterpretado y escrito incorrectamente, podríamos tener un caso en el que esto está escrito: 985836E38.
    En este caso, el tercer dígito debe ser 4 pero es 5, por lo que el destinatario calcula 9 + 8 + 5 + 8 + 3 + 6 = 39.
    Por lo tanto, el destinatario puede concluir que el número debe ser Par, pero no lo es, y que la suma de verificación proporcionada (38) no coincide con la que calculó el receptor (39).
  • El destinatario ahora puede pedir que se retransmita todo el mensaje para que tenga una segunda oportunidad de escribirlo, con la esperanza de corregirlo esta vez.
  • Por supuesto, es posible que la suma de verificación en sí misma se malinterprete, en cuyo caso el número real y la suma de verificación no coinciden, por lo que se solicita una retransmisión.
    También es posible que tanto la suma de verificación como el número real se malinterpreten. Sin embargo, es poco probable que el número defectuoso coincida con la suma de verificación defectuosa, pero puede suceder. También es posible que dos números diferentes (3754 y 1425421, por ejemplo) resulten en la misma suma de comprobación (aquí 19). Las implementaciones reales tienen esto en cuenta e intentan evitar el problema.
  • Cuanto más rígido y mejor implementado y pensado este sistema de verificación de errores, con menos frecuencia fallará. Por ejemplo, aquí tener E (ven) u O (dd) agregado da un poco de certeza adicional en comparación con solo tener la suma de verificación, pero también resulta en un poco más de sobrecarga.

Las implementaciones de la vida real a menudo son bastante avanzadas y las computadoras usan 0 y 1, no de 0 a 9, pero el concepto general es el mismo.
Se agrega un poco de datos al mensaje real y el destinatario puede comparar estos dos. Si hay una falta de coincidencia, el destinatario puede solicitar una retransmisión.

Por lo tanto, además de los datos que desea descargar, también hay algunos datos utilizados para evitar errores en la transmisión y el sobre con una dirección que asegura que el mensaje llegue al destino correcto.

Es diferente con algo como juegos en línea o llamadas de voz, en esos casos no importa demasiado si se pierden algunos datos. Lo que es más importante es que los datos siguen fluyendo tanto como sea posible y lo más rápido posible todo el tiempo. Si tiene una conversación en Skype y un pequeño porcentaje de la conversación se pierde en algún lugar durante la transmisión, es poco probable que lo note.
Esto se debe a que el protocolo sigue enviando datos continuamente y no le importa si llega o no. En este caso, la llamada pérdida de paquetes es aceptable y se prefiere a la introducción de más sobrecarga y retraso, por ejemplo, en una conversación, si algo se pierde, no tiene sentido transmitirlo medio segundo después. Pero si estás descargando un archivo, ¡los errores apestarían!

a) Sobrecarga de protocolo. Dependiendo de qué protocolos esté utilizando, hay al menos un punto porcentual de sobrecarga.

b) Retransmisiones. Si los paquetes se pierden (y sucede … mucho), las cosas deben enviarse nuevamente.

Encapsulación

Si simplemente coloca el archivo “a través de Internet” (desde la perspectiva del servidor), ¿cómo puede saber que tiene que ir a su PC? Simplemente no puede.

En cambio, cada archivo (pero también páginas web, correos electrónicos y prácticamente cualquier contenido de Internet) se divide en pequeños fragmentos (de aproximadamente 1400bytes de tamaño cada uno). En cada uno de ellos, agregamos las direcciones IP de origen y de destino para que cada fragmento pueda ser enviado a usted.

Esto agrega gastos generales, pero no es la única razón. Si se pierde un paquete, se retransmitirá, pero también contará como consumo de ancho de banda.

Esta fue una descripción demasiado simple de lo que es la encapsulación, pero debería darle una idea. Si desea saber más, puede consultar esta guía de direccionamiento IPv4.

El paquete real de datos enviados a través de una red contiene más que los datos reales. Primero están los datos del protocolo (TCP / IP) y también podría haber otra información como parte del control de la red. Los paquetes IP no son muy grandes con un tamaño máximo de 1500 bytes y cada paquete tiene algunos datos de control. Por lo tanto, todos estos datos de control adicionales, además de los datos reales, se cuentan como datos consumidos.

Depende de dónde esté midiendo los bits. El uso del protocolo de Internet tcp / ip agrega bits para la dirección del paquete. También hay bits para la verificación y corrección de mensajes.