¿Qué es un flujo de bytes?

TCP no “envía datos en una secuencia de bytes”. El concepto de una secuencia de bytes es simplemente una abstracción que proporciona TCP en ambos extremos de una conexión (lector y escritor). ¿Por qué bytes? TCP envía datos en paquetes, y esos paquetes tienen cierto número de bytes de contenido en cada paquete.

Lo que TCP hace es proporcionar una abstracción que permite al remitente escribir bytes a ciegas en una abstracción de flujo de bytes proporcionada por TCP, y el remitente puede solicitar en cualquier punto arbitrario que se envíen por la fuerza los bytes escritos previamente, que aún no se han enviado.

Esta abstracción permite que una implementación de TCP administre dos porciones diferentes de datos para enviar:

1) La porción de datos que aún no se ha enviado, que se está almacenando en el búfer por una de varias razones (generalmente porque es más eficiente esperar a que se recopile una cierta cantidad de datos en el búfer en lugar de enviar cada byte en su propio ¡paquete!); y

2) La porción de datos ha sido enviada, pero para la cual no se ha recibido un acuse de recibo correspondiente. Estos datos (bytes) deben mantenerse (¡aunque ya se hayan enviado!) Porque el remitente debe poder enviar repetidamente esos bytes hasta que se reciba un reconocimiento de esos bytes, que es lo que hace que TCP sea un protocolo “confiable”.

La razón por la que un remitente puede escribir ciegamente en la abstracción de flujo de bytes TCP es que la implementación de esa abstracción puede bloquear al escritor (es decir, puede optar por no regresar) cuando se llenan las memorias intermedias de envío, es decir, esperar a que se envíen los datos. la red y ser reconocido por el destinatario , lo que permite reclamar la (s) parte (s) reconocida (s) de las memorias intermedias. Una vez que haya más espacio para almacenar bytes en el búfer, el control puede devolverse al código (proceso, subproceso, etc.) que está escribiendo bytes en la abstracción de flujo de bytes TCP.

Si aún suena complejo, vuelva a leerlo nuevamente hasta que no suene complejo. Este es un concepto muy simple; desafortunadamente está hecho para ser mucho más complejo de lo que es (y me disculpo si agregué esa complejidad con mi respuesta). Ver también: ¿Por qué NIO es mucho más eficiente que BIO, a pesar de que NIO no guarda ningún círculo de CPU?

Bueno, el TCP original fue construido como un marco de comunicaciones para reemplazar el sistema télex para el ejército de los EE. UU. Es decir, era para entregar flujos de datos que se escribirían en papel a través de un teletipo. Y, no hay forma de determinar cómo el paquete se dividirá y se cortará en cubitos mientras transita el ARPANET a través de los enrutadores IMP. Entonces, el concepto de un datagrama es realmente ortogonal a los objetivos de diseño de la confiabilidad de lo que ofrece TCP.

Como protocolo orientado a circuitos virtuales, TCP hace exactamente lo que fue diseñado para hacer. Proporciona un mecanismo confiable para entregar octetos (también conocidos como bytes) originalmente usando codificación ASCII (muchas máquinas del día usaban codificación EBCDIC o BAUDOT) dada una ruta incierta con fragmentación incierta. Y, esto funciona tan bien, que incluso pueden usar TCP en enlaces de latencia larga a lugares como Marte.

Porque así es como está diseñado.

En serio, el byte de 8 bits ha sido la unidad de datos direccionable más pequeña en prácticamente todas las computadoras durante algún tiempo. Las computadoras individuales pueden admitir unidades de datos más grandes, por ejemplo, 16, 32 o 64 bits, pero el byte de 8 bits es lo único que todos tienen en común.

Esto probablemente proviene de su uso para contener caracteres ASCII; aunque nominalmente solo de 7 bits, el primer equipo de comunicaciones ASCII (por ejemplo, el antiguo teletipo mecánico ASR33) agregó un bit de paridad a cada carácter para formar 8 bits.

El modelo de sistema de archivos UNIX (que data de principios de la década de 1970 y fue adoptado por BSD, Linux, OSX e incluso Microsoft) siempre ha representado el tipo de archivo más básico como una secuencia sin características de bytes de 8 bits. Entonces, cuando TCP fue concebido a mediados de la década de 1970, el byte de 8 bits era una unidad de intercambio perfectamente natural.

Un flujo de bytes es como una matriz ilimitada de bytes, donde la aplicación realiza un seguimiento de cuántos bytes transferir en una operación recv () / send (). TCP / IP se implementó como un protocolo orientado a la transmisión de bytes (en lugar de basado en mensajes o registros, como por ejemplo X.25) para proporcionar transmisiones de bytes confiables sobre protocolos de nivel inferior (posiblemente no confiables).

El flujo de bytes es un canal de comunicación por el cual una entidad puede enviar una secuencia de bytes a su destino. Es bidireccional, pero a veces puede ser unidireccional y, en casi todos los casos, produce los mismos bytes exactamente en el mismo orden en que se envió al otro extremo.