¿Por qué el preámbulo no se considera parte del encabezado de Ethernet?

1. Si busco dónde comienzan mis datos en una trama Ethernet, obtengo una respuesta común que dice encabezado TCP (20 bytes) + encabezado IP (20 bytes) + encabezado Ethernet (SA + DA + Tipo), es decir, 14 bytes. Entonces, en resumen, la respuesta a esa pregunta se convierte en 52-54 bytes, los datos comienzan en un marco Ethernet, pero ¿no deberíamos agregar también 8 bytes de preámbulo?

2. Además, busqué sobre el tamaño del marco de ethernet que es 1514 para marcos de ethernet. ¿Por qué ignoramos el preámbulo y el CRC aquí?

Agregando a la respuesta de jonathanjo:

Ethernet tiene componentes en ambas capas 1 (porque puede ejecutarse en diferentes medios) y 2 (porque las tramas son las mismas en los diferentes medios).

El Preámbulo, el Delimitador de SoF y la Brecha entre paquetes están realmente en la capa 1 (activación del receptor, etc.), mientras que el marco (incluido el encabezado, la carga útil y el FCS) está en la capa 2.

Los datos en un marco de ethernet son la carga útil de un marco de ethernet. Su pregunta 1 supone que cada protocolo de capa 3 es IPv4, y cada protocolo de capa 4 es TCP, que son suposiciones erróneas. Ethernet no sabe ni le importa qué protocolo de capa 3 lleva (IPv4, IPX, IPv6, AppleTalk, etc.), por lo que los datos de la trama son la carga útil. Por ejemplo, el encabezado del paquete IPv4 es de 20 a 60 octetos, mientras que el encabezado del paquete IPv6 siempre es de 40 octetos. Ethernet no sabe esto, solo sabe que tiene un campo de carga útil, no lo que hay en ese campo.

El encabezado de la trama de Ethernet es normalmente de 14 octetos, a menos que tenga una trama etiquetada, entonces es de 18 octetos. La MTU es el tamaño máximo de carga útil. Ethernet también tiene un tamaño de trama mínimo de 64 octetos, incluido el FCS, por lo que la carga útil puede variar desde 42 (con etiqueta) o 46 (sin etiqueta), hasta el tamaño máximo de carga útil de 1500 octetos. Eso significa que las tramas de Ethernet (encabezado y carga útil) son de 60 octetos a 1514 (sin etiqueta) o 1518 (con etiqueta) octetos.

Si por donde comienzan los datos, se refiere a los datos de la aplicación, eso realmente dependerá de todos los protocolos. El encabezado UDP es de solo 8 octetos, y la carga útil UDP puede ser los datos de la aplicación, o puede ser un datagrama para un protocolo de capa de aplicación que tiene su propio encabezado que puede no contarse como datos de la aplicación. En su ejemplo de TCP, puede estar ejecutando un navegador web en un servidor web. ¿Cuenta HTTP (un protocolo de capa de aplicación) o HTML como datos (HTML es el dato de HTTP)? Cuando hace referencia a los datos, es relativo al protocolo al que se refiere.

El preámbulo es en realidad de 7 octetos, seguido de un octeto de trama, el delimitador de trama de inicio (SFD). Simplemente marcan que viene un marco y sirven para fines de sincronización, no son parte del marco. Al igual que la brecha entre cuadros, no cuenta como parte del cuadro. El preámbulo y el SFD nunca entran en la memoria, por lo que nunca hay ningún desplazamiento de memoria que incluya ese 8.

Las tramas de Ethernet a veces se describen como 1514 octetos porque el hardware generalmente calcula / verifica el FCS, y la CPU nunca lo ve o lo guarda en la memoria: solo el src, dest, type, payload. Pero el marco se define para incluir el FCS, sin ambigüedades, de acuerdo con el estándar. La trama básica se define como que tiene una longitud máxima de campo de datos del cliente de al menos 1500 octetos, que además del 14 más 4 FCS = 1520.

PD. No olvide la etiqueta opcional 802.1q, otros 4 octetos para paquetes en troncales; y hay otros tipos especiales

EDITAR El estándar habla principalmente de cuadros , que se definen para incluir el FCS (gracias Richard por el comentario). También habla de paquetes que van desde el comienzo del preámbulo hasta el final de los bits de extensión (que a veces se necesitan después del FCS, para garantizar una buena detección de colisión). Este paquete son todos los bits que el hardware transmite por el cable. (Este uso de "paquete" puede ser confuso, ya que normalmente hablamos de paquetes IP dentro del marco de ethernet ).

Es solo una cuestión de definiciones, al final, y afortunadamente podemos buscarlas. Si no lo sabía, el estándar está disponible gratuitamente. El núcleo tiene 4.000 páginas (!), Pero la mayoría de las cosas, como las definiciones, son muy fáciles de leer y absolutamente inequívocas. Muy recomendable haber visto al menos la Sección 3.1.1 Formato de paquete. http://www.ieee802.org/3/

Además de lo ya presente, buenas respuestas:

El preámbulo es una función esencial de la capa física. Tenga en cuenta que cuando serializa datos en un solo bit o secuencia de símbolos, debe proporcionar alguna forma de sincronización, primero a bits / símbolos, luego a palabras.

El patrón de símbolos que genera el preámbulo en el cable (en realidad es solo 01010 ... con el código 10BASE-x Manchester) permite que el receptor sintonice su reloj de símbolos a la velocidad exacta del transmisor. Sabrá cuántos símbolos acaba de recibir, incluso si no hay cambios en el cable. (Todas las capas físicas también proporcionan medios para la sincronización intermedia, por lo que es un proceso continuo).

El patrón SOF detrás del preámbulo marca el comienzo de la primera palabra (u octeto / byte). El receptor activa su búfer y registra los bits decodificados en él, deserializando los bits que salen del decodificador y transmitiéndolo palabra por palabra al búfer. No importa si es un byte o una palabra de 32 bits a la vez, pero es importante que los límites de los bytes sean correctos.

Por lo tanto, el preámbulo y SOF son necesariamente parte del mecanismo de transporte físico, por lo tanto, pertenecen a la capa física. Desde la perspectiva de la capa 2, un cuadro no requiere un marcador de inicio, solo comienza con el primer octeto entrante.

Además de las excelentes respuestas de otros sobre la estratificación, algunos protocolos se encuentran justo encima del marco de ethernet L2, de los cuales los más conocidos son ARP, RARP, CDP, etc., que se relacionan directamente con el enlace (también, como me recuerda Zac, otros protocolos, como los BPDU de LLDP y STP).

Es muy poco frecuente, pero en ocasiones encontrará aplicaciones que envían sus datos en el marco de Ethernet, aunque las únicas razones que he visto para esto son a) protocolos patentados diseñados para ser oscuros o puramente locales como la administración de licencias, b ) experimentación, especialmente transferencias en tiempo real o evaluación de timimg de pila de protocolos. ¡Los pros y los contras de esto están fuera del alcance de esta respuesta!

Esta es la salida de un paquete de prueba de temporización con "datos" que comienza en 0x0e.

14:54:29.698140 34:02:86:9f:f2:fc > 00:04:75:c8:28:e5, 802.3, length 64: length 50
    0x0000:  0004 75c8 28e5 3402 869f f2fc 0000 4041  ..u.(.4.......@A
    0x0010:  4243 4445 4647 4849 4a4b 4c4d 4e4f 5051  BCDEFGHIJKLMNOPQ
    0x0020:  5253 5455 5657 5859 5a5b 5c5d 5e5f 6061  RSTUVWXYZ[\]^_`a
    0x0030:  6263 6465 6667 6869 6a6b 6c6d 6e6f 7071  bcdefghijklmnopq