Por que o preâmbulo não é considerado parte do cabeçalho Ethernet?

1. Se eu procurar onde meus dados começam em um quadro Ethernet, recebo uma resposta comum que diz cabeçalho TCP (20 bytes) + cabeçalho IP (20 bytes) + cabeçalho Ethernet (tipo SA + DA +), ou seja, 14 bytes. Portanto, em suma, a resposta a essa pergunta se torna de 52 a 54 bytes, os dados iniciam em um quadro Ethernet, mas não devemos adicionar 8 bytes de preâmbulo também?

2. Além disso, pesquisei sobre o tamanho do quadro Ethernet, que é 1514 para quadros Ethernet. Por que estamos ignorando o preâmbulo e a CRC aqui?

Adicionando à resposta de jonathanjo:

A Ethernet possui componentes nas duas camadas 1 (porque pode ser executada em mídias diferentes) e 2 (porque os quadros são os mesmos nas mídias diferentes).

O preâmbulo, o delimitador SoF e o intervalo entre pacotes estão realmente na camada 1 (ativando o receptor etc.), enquanto o quadro (incluindo o cabeçalho, a carga útil e o FCS) está na camada 2.

Os dados em um quadro Ethernet são a carga útil de um quadro Ethernet. Sua pergunta 1 pressupõe que todo protocolo da camada 3 é IPv4 e todo protocolo da camada 4 é TCP, que são suposições ruins. A Ethernet não sabe nem se importa com o protocolo da camada 3 (IPv4, IPX, IPv6, AppleTalk etc.), portanto, os dados do quadro são a carga útil. Por exemplo, o cabeçalho do pacote IPv4 é de 20 a 60 octetos, enquanto o cabeçalho do pacote IPv6 é sempre 40 octetos. A Ethernet não sabe disso, apenas sabe que possui um campo de carga útil, não o que está nesse campo.

O cabeçalho do quadro ethernet é normalmente de 14 octetos, a menos que você tenha um quadro marcado, são 18 octetos. O MTU é o tamanho máximo da carga útil. A Ethernet também possui um tamanho de quadro mínimo de 64 octetos, incluindo o FCS, de modo que a carga útil pode variar de 42 (com tag) ou 46 (sem tag), até o tamanho máximo de carga útil de 1500 octetos. Isso significa que os quadros Ethernet (cabeçalho e carga) são de 60 octetos a 1514 (sem tag) ou 1518 (com tag) octetos.

Se por onde os dados começam, você quer dizer dados de aplicativos, isso realmente dependerá de todos os protocolos. O cabeçalho UDP tem apenas 8 octetos e a carga útil UDP pode ser os dados do aplicativo ou pode ser um datagrama para um protocolo da camada de aplicativos que possui seu próprio cabeçalho que pode não ser contado como dados do aplicativo. No seu exemplo de TCP, você pode estar executando um navegador da web em um servidor da web. Você conta HTTP (um protocolo de camada de aplicativo) ou HTML como dados (HTML são os dados para HTTP)? Quando você se refere aos dados, é relativo ao protocolo ao qual você está se referindo.

O preâmbulo é na verdade 7 octetos, seguido por um octeto de enquadramento, o delimitador de quadro inicial (SFD). Eles apenas marcam que um quadro está chegando e servem para fins de sincronização; eles não fazem parte do quadro. Assim como o espaço entre quadros, não conta como parte do quadro. O preâmbulo e o SFD nunca entram na memória e, portanto, nunca há nenhum deslocamento de memória que inclua esse 8.

Os quadros Ethernet às vezes são descritos como 1514 octetos porque o hardware geralmente calcula / verifica o FCS, e a CPU nunca o vê ou o coloca na memória: apenas o src, dest, tipo, carga útil. Mas o quadro é definido para incluir o FCS, sem ambiguidade, de acordo com o padrão. O quadro básico é definido como tendo o comprimento máximo do campo de dados do cliente de pelo menos 1500 octetos, mais o 14 mais 4 FCS = 1520.

PS. Não se esqueça da tag opcional 802.1q, outros 4 octetos para pacotes nos troncos; e existem outros tipos especiais.

EDIT O padrão fala principalmente de quadros , que são definidos para incluir o FCS (obrigado Richard por comentar). Ele também fala de pacotes que vão do início do preâmbulo até o final dos bits de extensão (que às vezes são necessários após o FCS, para garantir uma boa detecção de colisão.) Esse pacote é todos os bits que o hardware transmite no fio. (Esse uso de "pacote" pode ser confuso, pois normalmente falamos de pacotes IP dentro do quadro ethernet .)

É apenas uma questão de definições, no final, e felizmente podemos procurá-las. Se você não sabia, o padrão está disponível gratuitamente. O núcleo possui 4.000 páginas (!), Mas a maioria das coisas, como definições, é muito fácil de ler e absolutamente inequívoca. Altamente recomendado que você veja pelo menos a Seção 3.1.1 Formato de pacotes. http://www.ieee802.org/3/

Além das já presentes, boas respostas:

O preâmbulo é uma função essencial da camada física. Observe que quando você serializa dados em um único bit ou fluxo de símbolos, é necessário fornecer alguma forma de sincronização - primeiro em bits / símbolos e depois em palavras.

O padrão de símbolo que o preâmbulo gera no fio (na verdade é apenas 01010 ... com o código Manchester 10BASE-x) permite que o receptor ajuste o relógio do símbolo na velocidade exata do transmissor. Ele saberá quantos símbolos acabou de receber, mesmo que não haja alterações no fio. (Todas as camadas físicas também fornecem meios para sincronização intermediária, por isso é um processo contínuo.)

O padrão SOF atrás do preâmbulo marca o início da primeira palavra (ou octeto / byte). O receptor ativa seu buffer e coloca os bits decodificados nele, desserializando os bits que saem do decodificador e transmitindo-o ao buffer, palavra por palavra. Não importa se é um byte ou uma palavra de 32 bits por vez, mas é importante que os limites do byte estejam corretos.

Portanto, preâmbulo e SOF são necessariamente parte do mecanismo de transporte físico, portanto pertencem à camada física. Da perspectiva da camada 2, um quadro não requer um marcador de início - apenas começa com o primeiro octeto entrando.

Além das excelentes respostas de outras pessoas sobre camadas, alguns protocolos ficam no topo do quadro Ethernet L2, dos quais os mais conhecidos são ARP, RARP, CDP etc., que se relacionam diretamente ao link (também, como sou lembrado por Zac, outros protocolos como LLDP e BPDU do STP.)

É muito incomum, mas, ocasionalmente, você encontrará aplicativos que enviam seus dados no quadro Ethernet, embora as únicas razões que vi para isso sejam: a) protocolos proprietários projetados para serem obscuros ou puramente locais, como gerenciamento de licenças; ) experimentação, especialmente transferências em tempo real ou avaliação do timimg da pilha de protocolos. Prós e contras disso estão fora do escopo desta resposta!

Isso é resultado de um pacote de teste de temporização com "dados" iniciando em 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