TCP proporciona un flujo continuo de datos. TCP es implementado utilizando paquetes, pero el objetivo de TCP es ocultarlos.
Piense en ello como si fuera una pared sobre la que desea dibujar. La pared está hecha de ladrillos. Los ladrillos se pegan con mortero y se aplica yeso para que la superficie de la pared se vuelva lisa. Los ladrillos son los paquetes de IP, TCP es el yeso.
Así que ahora tiene su túnel TCP enlucido liso, y desea agregar algo de estructura en él. Desea dibujar cuadros, para que sus dibujos se mantengan separados el uno del otro. Esto es lo que quiere hacer: agregar un poco de estructura "administrativa" (recuadros alrededor de los dibujos) a sus datos.
Muchos protocolos utilizan el concepto de packet
, que es un conjunto de datos que comienza con un encabezado administrativo de formato fijo. El encabezado contiene suficiente información para decidir dónde termina el paquete; por ejemplo, incluye la longitud del paquete. HTTP lo hace, con un encabezado Content-Length
, o (con HTTP/1.1) con la "codificación de transferencia fragmentada" donde los datos se dividen en uno o varios mini-paquetes, cada uno con un encabezado simple que consiste exactamente en una indicación de mini-paquete-longitud .
Otra forma es tener una secuencia de terminador especial que no puede aparecer en "datos normales". Si sus datos son texto, entonces podría usar un byte de valor cero como terminador.
Otra forma es usar datos con terminación propia. Estos son datos estructurados de tal forma que usted puede saber en cualquier momento si se ha alcanzado el final del elemento. Por ejemplo, los datos XML se organizan como pares anidados de marcadores como <foo>...</foo>
. Cuando se alcanza el marcador final (</foo>
), sabrá que el elemento está terminado.
Supongo que no le preocupan los paquetes TCP, sino los mensajes a nivel de aplicación dentro de la transmisión TCP, ¿no? –