UDP é um protocolo de camada de transporte orientado a datagramas.Cada operação de saída do processo gera um datagrama UDP e o monta em um datagrama IP para ser enviado.
RFC 768 é a especificação oficial do UDP.
UDP não oferece confiabilidade.
Se o comprimento do datagrama IP exceder o MTU da rede, o datagrama IP deve ser fragmentado.Se necessário, todas as redes entre a origem e o destino podem ser fragmentadas, não apenas o remetente.
O número da porta indica o processo de envio e recebimento.
Se o TCP e o UDP fornecem um determinado serviço conhecido ao mesmo tempo, os dois protocolos geralmente escolhem o mesmo número de porta por conveniência.
O campo de comprimento UDP refere-se à soma do cabeçalho UDP e dos dados UDP. O valor mínimo deste campo é 8 bytes (datagramas UDP com comprimento de campo de dados 0 podem ser enviados). Este valor de comprimento é igual ao comprimento indicado por o campo de comprimento do datagrama IP menos os dados IP O comprimento do campo de cabeçalho.
UDP verifica e cobre o cabeçalho UDP e os dados UDP. No cálculo, como o UDP não preenche 0s como o cabeçalho IP, o comprimento do UDP pode ser ímpar, mas o algoritmo de soma de verificação é calculado em unidades de 16 bits, portanto, se o comprimento final for insuficiente, será adicionado 0. Isso é apenas para o cálculo da soma de verificação e não será alterado.O 0 suplementado é enviado.
Tanto o datagrama UDP quanto o segmento TCP contêm um pseudo-cabeçalho de 12 bytes, que é definido para calcular a soma de verificação. O pseudo-cabeçalho contém alguns campos no cabeçalho IP. O objetivo é permitir que o UDP verifique se os dados alcançam o destino corretamente.
Os bytes de preenchimento na figura acima são usados ao calcular a soma de verificação. O comprimento do datagrama UDP aparece duas vezes no processo de cálculo da soma de verificação.
Se o valor do campo de soma de verificação UDP enviado for todo 0, significa que o remetente não calculou a soma de verificação (se o resultado da soma de verificação calculado for todo 0, o valor armazenado será todo 1 (65535)).
Se a extremidade receptora detectar um erro na soma de verificação, o datagrama UDP será descartado e nenhuma mensagem de erro será gerada (isso também é feito quando a camada IP detecta um erro na soma de verificação do cabeçalho IP).
Embora as somas de verificação UDP sejam opcionais, elas sempre devem ser usadas. Na década de 1980, alguns fabricantes de computador desativaram a função de soma de verificação UDP por padrão para aumentar a velocidade do NFS (Network File System) do UDP. Isso pode ser aceitável em uma única LAN, mas quando o datagrama passa pelo roteador, ele passa pelo link A verificação de redundância cíclica do quadro de dados da camada (como Ethernet ou quadro de dados token ring) pode detectar a maioria dos erros, resultando em falha de transmissão. Além disso, há erros de software e hardware no roteador, que fazem com que os dados no datagrama sejam modificados. Se a função de soma de verificação UDP ponta a ponta estiver desligada, esses erros não podem ser detectados no datagrama UDP. , alguns links de dados O protocolo de camada (como SLIP) não tem nenhuma forma de soma de verificação de link de dados.
O RFC de requisitos de host declara que a opção UDP checksum está ativada por padrão, e se o remetente calcula o checksum, o receptor deve verificar o checksum recebido. No entanto, muitos sistemas não estão em conformidade com isso e só verificam a soma de verificação recebida quando a opção exportar soma de verificação está ativada.
Se os dados que você envia são importantes, não confie completamente nas somas de verificação UDP ou TCP. Essas somas são apenas somas de verificação simples e não podem detectar todos os erros possíveis.
Sempre que a camada IP recebe um datagrama IP a ser enviado, ela deve determinar para qual interface enviar os dados (roteamento) e consultar a interface para obter seu MTU. O IP compara o MTU com o comprimento do datagrama e, se necessário, Fragmentação. A fragmentação pode ocorrer no host remetente original ou no roteador intermediário.
Depois que um pedaço de datagrama IP é fragmentado, ele é remontado apenas quando atinge o destino (a remontagem aqui é diferente de outros protocolos de rede porque eles exigem remontagem na próxima parada, não no destino final). A remontagem é feita pela camada IP de destino, com o objetivo de tornar o processo de fragmentação e remontagem transparente para a camada de transporte (TCP e UDP), exceto para algumas operações que podem saltar. Os datagramas que foram fragmentados podem ser fragmentados novamente. Os dados contidos no cabeçalho IP fornecem informações suficientes para fragmentação e remontagem.
Para o cabeçalho IP, os campos relacionados à fragmentação são os seguintes: o campo de identificação de cada datagrama IP enviado pelo remetente contém um valor único, que é copiado para cada fragmento quando o datagrama é fragmentado. O campo flag usa um dos bits para indicar que há um slice a seguir, exceto para o último slice, este bit deve ser definido como 1 para cada outro slice que compõe o datagrama. O campo de deslocamento do fragmento refere-se à posição do deslocamento do fragmento desde o início do datagrama original. Quando o datagrama é fragmentado, o comprimento total de cada fragmento deve ser alterado para o comprimento do fragmento. Há um bit no campo de sinalizador do cabeçalho IP denominado bit de não fragmentação. Se esse bit for definido como 1, o IP não fragmentará o datagrama. Ao encontrar a fragmentação, ele descarta o datagrama e envia um erro ICMP. mensagem ("fragmentação é necessária, mas o bit de não fragmentação está definido") é enviada para o início final.
Depois que o datagrama IP é fragmentado, cada fragmento se torna um pacote com seu próprio cabeçalho IP e é independente de outros pacotes quando o roteamento é selecionado. Dessa forma, esses fragmentos do datagrama podem estar fora de ordem ao chegar ao destino, mas the IP header Há informações suficientes para a extremidade receptora montar essas partes do datagrama corretamente.
No entanto, mesmo se apenas um dado for perdido, os fragmentos de IP devem retransmitir todo o datagrama (se a retransmissão depende do protocolo da camada superior, para UDP, ele não tem um mecanismo de retransmissão de tempo limite (mas alguns aplicativos UDP próprios também realizam tempo limite e retransmissão)), porque se o fragmento não for dividido no remetente, o remetente não sabe como a rota intermediária está fragmentada, portanto, evite a fragmentação.
Usar UDP pode facilmente levar à fragmentação de IP (o TCP tenta evitar a fragmentação. Para aplicativos, é quase impossível forçar o TCP a enviar um segmento longo que precisa ser fragmentado).
Em uma Ethernet, o comprimento máximo de um quadro de dados é de 1500 bytes, dos quais 1472 bytes são reservados para dados. Supondo que o cabeçalho IP tenha 20 bytes e o cabeçalho UDP tenha 8 bytes, o comprimento dos dados é 1471,1472,1473, 1474 bytes. Envie um datagrama UDP, tcpdump verifica a fragmentação do datagrama UDP (os dois últimos fragmentos devem ocorrer): Depois que o
datagrama IP é fragmentado, tcpdump imprime mais informações, a terceira e quarta linhas do frag 26304 e do frag 26313 na quinta e sexta linhas refere-se ao valor do campo de identificação no cabeçalho IP.
Conforme mostrado na figura acima, quando o comprimento do datagrama UDP é 1473 bytes, ele está fragmentado.Se a Ethernet usar encapsulamento IEEE 802, porque o cabeçalho Ethernet tem 8 bytes a mais, 1465 bytes torna-se o comprimento mínimo do fragmento do datagrama UDP.
O próximo número nas informações do fragmento, ou seja, o número entre os dois pontos e o sinal @, é o comprimento do fragmento, exceto o cabeçalho IP.
Ao fragmentar, exceto para o último, a parte dos dados (exceto a parte do cabeçalho IP) em cada um dos outros fragmentos deve ser um múltiplo inteiro de 8 bytes.
O número após o símbolo @ é o valor de deslocamento da fatia calculado a partir do início do datagrama. O sinal de mais após este número corresponde a mais bits da fatia no campo de sinalizador de 3 bits no cabeçalho IP, e o objetivo é informar ao receptor que existem fatias atrás.
As linhas 4 e 6 na figura acima omitem o nome do protocolo, o número da porta de origem e o número da porta de destino. O nome do protocolo pode ser impresso porque o nome do protocolo está no cabeçalho IP, mas o número da porta está no cabeçalho UDP. Encontrado na primeira parte (qualquer cabeçalho da camada de transporte só aparece na primeira parte dos dados).
Um pacote é uma unidade de dados transmitida entre a camada IP e a camada de enlace.Um pacote pode ser um datagrama IP completo ou um fragmento do datagrama IP.
Outra situação em que ocorre um erro ICMP inacessível é quando o roteador recebe um datagrama que precisa ser fragmentado e o bit de sinalizador de não fragmentação (DF) é definido no cabeçalho IP. Se um programa precisar determinar o MTU mínimo no caminho para o destino (chamado de mecanismo de descoberta de MTU do caminho), esse erro pode ser usado pelo programa.
O campo MTU da próxima rede de estação fornece a MTU da próxima estação. Se o roteador não fornecer esse novo formato de mensagem de erro ICMP, o MTU da próxima estação será definido como 0.
Geração de erro ICMP inacessível:
Quando o SLIP é instalado no host sun, configuramos o link MTU de sun para netb durante a configuração de SLIP, e agora queremos determinar o link MTU de netb para sun (em links ponto a ponto , O MTU em ambas as direções não precisa ter o mesmo valor). O método usado é executar ping no host solaris para enviar uma solicitação de eco ICMP ao host bsdi, aumentar o comprimento do pacote de dados até que o pacote seja fragmentado e, em seguida, executar tcpdump no host sun:
a marca DF em cada linha indica que o bit de não fragmentação está definido no cabeçalho IP, que faz parte do mecanismo de descoberta de MTU do caminho.
A primeira linha mostra que a solicitação de eco atinge o host sun por meio do roteador netb, sem fragmentação, portanto, o SLIP MTU de netb não foi alcançado.
O sinalizador DF na segunda linha é copiado para a mensagem de resposta de eco. Embora as mensagens de resposta de eco e solicitação de eco tenham o mesmo comprimento (mais de 600) bytes, o MTU da interface SLIP que o sol sai é 552, então o eco a resposta precisa ser A fragmentação é executada, mas o bit do sinalizador DF está definido, então sun gera uma mensagem de erro ICMP inacessível para bsdi, e a mensagem de erro é descartada em bsdi. É por isso que você não pode ver nenhuma resposta de eco no solaris, e essas respostas nunca podem passar do sol.
Na terceira e sexta linhas, mtu = 0 significa que o host sun não retornou o valor MTU de exportação no pacote ICMP inacessível.
Muitos sistemas não suportam a função de descoberta de caminho MTU, mas você pode modificar o programa traceroute para determinar o caminho MTU. O que você precisa fazer é enviar o pacote e definir o bit de sinalizador de não fragmentação. O comprimento do primeiro pacote enviado é exatamente igual ao MTU de saída. O comprimento do pacote é reduzido toda vez que um erro ICMP não pode ser fragmentado é recebido. Se a mensagem de erro ICMP enviada pelo roteador estiver no novo formato e contiver a MTU de saída, ela será enviada com este valor de MTU, caso contrário, será enviada com o próximo menor valor de MTU. De acordo com a instrução RFC, o número de Os valores de MTU são limitados. Portanto, use o próximo valor mínimo de MTU para enviar.
Conforme mostrado na figura acima, primeiro tente o caminho MTU do host sun até o host slip. Sabemos antecipadamente que o MTU do link SLIP é 296: No
exemplo acima, o roteador bsdi não retornou o MTU de saída em a mensagem de erro ICMP, então escolhemos a próxima menor, a MTU. Ao modificar a rota intermediária bsdi para retornar o valor MTU de exportação, execute o programa traceroute modificado
neste momento : não há necessidade de tentar 8 valores MTU diferentes um por um neste momento.
Agora, muitas, mas não todas as WANs podem lidar com pacotes maiores que 512 bytes.Usando o mecanismo de descoberta de MTU de caminho, os aplicativos podem fazer uso total da MTU maior para enviar pacotes.
Conforme mostrado na figura acima, o UDP é usado do solaris para enviar dados de 650 bytes para o deslizamento. Como o host do deslizamento está atrás do link SLIP com um MTU de 296, qualquer comprimento maior que 268 (296-20-8) bytes é irrelevante.Os dados UDP com o bit de fragmento definido como 1 farão com que o roteador bsdi gere mensagens de erro ICMP não fragmentáveis.
Um datagrama UDP de 650 bytes é gerado no solaris em um intervalo de cinco segundos.O seguinte é o resultado da execução do tcpdump no sun: No
exemplo acima, o roteador bsdi não retorna as informações de MTU do próximo salto.
O bit DF é definido como 1 no primeiro datagrama enviado na primeira linha, e o resultado deve ser um resultado que possamos adivinhar do roteador bsdi (enviado de volta na segunda linha), mas o que é intrigante é que a terceira linha está em Ao enviar o próximo datagrama, o DF deve ser definido como 0 para fragmentar o datagrama de acordo com o valor máximo do resultado adivinhável enviado de volta por bsdi na segunda linha, mas o datagrama com DF de 1 ainda é enviado, e o resultado é o mesmo erro ICMP (quarta linha).
A quinta linha mostra que o IP já sabe que o datagrama enviado ao endereço de destino não pode definir o bit DF, portanto, o IP fragmenta o datagrama no site de origem e o divide em duas partes (linhas 5 e 6).
Mas na sétima linha, o datagrama enviado ainda tem o bit DF definido, então bsdi o descarta e retorna um erro ICMP. Este é um tempo limite do temporizador de IP e sua função é notificar o IP para verificar se o MTU do caminho aumentou e mude o DF Set para 1. Pode-se ver nas linhas 7 a 19 que o IP configura DF em 1 a cada 30 segundos. Estes 30 segundos são muito curtos. O RFC 1191 recomenda 10 minutos. Este valor pode ser alterado modificando o parâmetro ip_ire_pathmtu_interval.
O tamanho do fragmento na imagem acima está incorreto. O valor MTU real é de 296 bytes, o que significa que o datagrama fragmentado por solaris também será fragmentado por bsdi. A imagem abaixo é a primeira recebida no deslizamento do host de destino. o conteúdo do datagrama (a quinta e a sexta linhas na figura acima) é baseado no fato de que o campo de identificação IP é 47942: no
exemplo acima, o solaris não deve enviar fragmentos de datagrama e deve definir o bit DF para 0 para permitir o roteador com o menor MTU Conclua o trabalho de fragmentação.
O exemplo a seguir repete o exemplo anterior, mas o roteador bsdi está definido para retornar o próximo salto MTU no erro de falha de fragmentação ICMP: o
mesmo que o exemplo anterior, os dois primeiros datagramas são enviados após definir DF como 1. O destino recebeu apenas três dados, em vez de quatro, desta vez.
Gere um datagrama UDP de 8192 bytes. Prevê-se que irá gerar 6 fragmentos de datagrama na Ethernet. Ao mesmo tempo, antes de enviar este datagrama, o buffer ARP está vazio, por isso a solicitação ARP deve ser trocada antes de enviar o primeiro datagrama E a resposta, o seguinte é o resultado do tcpdump:
Pode-se ver que cada pedaço de dados gerou uma solicitação ARP. Quando a primeira resposta ARP é recebida, apenas o último fragmento de datagrama é enviado. Parece que os primeiros cinco fragmentos de datagrama foram descartados. Na verdade, esta é uma operação normal implementada pelo ARP. Ao esperar por uma resposta ARP, apenas o último fragmento de datagrama é enviado.Uma mensagem é enviada para um host específico. O RFC de requisitos de host exige que este tipo de inundação ARP (ou seja, mensagens de solicitação ARP enviadas repetidamente para o mesmo endereço IP em uma taxa alta) deve ser evitado na implementação. A taxa máxima recomendada é de uma vez por segundo. Também estipula que O ARP deve reter pelo menos uma Mensagem, esta mensagem deve ser a última mensagem, que é exatamente o resultado que vemos.
No exemplo acima, depois que o remetente envia várias solicitações ARP, o primeiro datagrama enviado é o último fragmento de datagrama deslocado, indicando que a fila de entrada ARP é a última a entrar, primeiro a sair.
No exemplo acima, há um fenômeno anormal inexplicável, svr4 envia de volta 7 respostas ARP em vez de 6.
Quando o primeiro fragmento de datagrama chega, a camada IP inicia um cronômetro com um valor de tempo de 30 ou 60 segundos. Se o cronômetro expira e todos os fragmentos de datagrama não chegam, esses fragmentos de datagrama são descartados. Se não, Então, mais cedo ou mais tarde, aqueles fragmentos de datagrama que nunca chegarão encherão o buffer da extremidade receptora.
Após o retorno da última resposta ARP, o tcpdump continuou a monitorar por 5 minutos e descobriu que svr4 não retornou um erro de tempo limite de assembly ICMP. Existem duas razões para não vermos: uma é que a maioria das implementações derivadas de Berkeley nunca geram o erro, essas implementações definirão o cronômetro e também descartarão os fragmentos de datagrama quando o cronômetro estourar; a segunda é que a inclusão não é recebida. O primeiro fragmento de datagrama com deslocamento de 0 no cabeçalho UDP não é necessário para gerar um erro ICMP para este fragmento. A razão é que, como não há cabeçalho da camada de transporte, o receptor do erro ICMP não sabe qual processo enviou o datagrama .deite fora.
Teoricamente, o comprimento máximo de um datagrama IP é 65535 bytes, que é limitado pelo campo de comprimento total de 16 bits do cabeçalho IP. Excluindo o cabeçalho IP de 20 bytes e o cabeçalho UDP de 8 bytes, o comprimento de dados do usuário mais longo em um datagrama UDP é de 65507 bytes, mas a maioria das implementações fornece um valor máximo menor que esse valor. Existem dois fatores limitantes: primeiro, o aplicativo pode ser afetado Devido a sua limitação de interface de programa, a API de soquete fornece uma função que pode ser chamada pelo aplicativo para definir o comprimento do buffer de recebimento e envio. Para sockets UDP, esse comprimento está diretamente relacionado ao comprimento do maior datagrama UDP que podem ser lidos e gravados pelo aplicativo. A maioria dos sistemas fornece datagramas UDP que podem ler e gravar mais de 8.192 bytes por padrão (este valor padrão é usado porque é o valor padrão do número de dados do usuário lidos e gravados pelo NFS) ; o segundo é da implementação do kernel TCP / IP, que pode existir Alguns recursos ou erros. O host deve ser capaz de receber datagramas IP de 576 bytes.
O fato de o IP poder enviar ou receber datagramas de um determinado comprimento não significa que os aplicativos possam ler dados desse comprimento. Portanto, o UDP se torna uma interface que permite aos aplicativos especificar o número máximo de bytes retornados a cada vez, se o comprimento do O datagrama recebido é maior que O comprimento que o aplicativo pode suportar, o que acontece depende da implementação específica: a versão Berkeley da API de soquete trunca o datagrama, descartando o excesso de dados, e o aplicativo pode receber datagramas truncados no 4.3BSD Reno e versões posteriores Mensagem; a API de soquete em SVR4 (incluindo Solaris 2.x) não trunca o datagrama e a parte excedente é retornada na leitura subseqüente, mas não notifica o aplicativo para realizar várias operações de leitura em um único datagrama UDP; a API TLI não descarta os dados, ela retorna um sinal de que mais dados podem ser obtidos e a operação de leitura após o aplicativo retornará o restante do datagrama.
O UDP também pode produzir erros de supressão de estação de origem ICMP. Quando um host ou roteador recebe datagramas mais rápido do que sua velocidade de processamento, esse erro pode ocorrer (mesmo se o host ou roteador não tiver cache e descartar o datagrama, não é necessário Enviar a estação de origem para suprimir a mensagem).
Os RFCs anteriores exigiam que os roteadores gerassem erros de supressão do site de origem quando não estavam em cache, mas os RFCs mais recentes propunham que os roteadores não gerassem mensagens de erro de supressão do site de origem, porque o site de origem sempre consome largura de banda da rede e é um efeito inválido de congestionamento. ajustes, para que as pessoas não apoiem a atitude atual de suprimir erros na origem do roteador.
Se UDP for usado, a implementação BSD geralmente ignora a mensagem de supressão da estação fonte que recebe.Parte da razão é que quando a mensagem de erro de supressão da estação fonte é recebida, o processo que causou a supressão da estação fonte pode ter sido encerrado.
Quando o cliente usa um datagrama UDP, seu cabeçalho IP contém os endereços IP de origem e destino, e o cabeçalho UDP contém o dia de Ano Novo e os números da porta UDP de destino. Quando o servidor recebe um datagrama UDP, o sistema operacional informa a origem IP do remetente Endereço e número da porta. Este recurso permite que um servidor UDP interativo processe vários clientes e envie uma resposta a cada cliente que envia uma solicitação.
Alguns aplicativos precisam saber o endereço IP de destino do datagrama, por exemplo, a RFC estipula que o servidor TFTP deve ignorar o datagrama recebido enviado ao endereço de broadcast. Isso exige que o sistema operacional envie o endereço IP de destino no datagrama UDP recebido para o aplicativo. Nem todas as implementações fornecem essa função.
A maioria dos servidores UDP são servidores interativos, o que significa que um único processo de servidor processa todas as solicitações do cliente em uma única porta UDP. Cada porta está associada a uma fila de entrada de tamanho limitado, o que causará estouro da fila e perda de datagrama. Quando a fila transborda, o aplicativo não sabe que ocorreu o estouro e o remetente não será notificado de que o datagrama foi descartado. A fila de saída UDP é o primeiro a entrar, o primeiro a sair.
A maioria dos servidores UDP torna seu endereço IP local um curinga ao criar uma porta UDP. Neste momento, se o destino de um datagrama UDP for uma porta de servidor, ele pode ser recebido em qualquer interface local.
É possível iniciar diferentes servidores na mesma porta, e cada servidor tem um endereço IP local diferente, mas geralmente é necessário informar ao sistema que não há problema em reutilizar o mesmo número de porta. Por exemplo, ao usar os soquetes API, a opção de soquete SO_REUSEADDR deve ser especificada.
Se o servidor A definir o soquete para qualquer endereço IP local + um determinado número de porta, se o servidor B definir o soquete para um endereço IP local específico + o mesmo número de porta do servidor A, o datagrama que chega ao servidor B pode, teoricamente, ser Dois servidores recebem , mas há uma relação de prioridade implícita, ou seja, o soquete mais específico, o servidor B, é selecionado primeiro.
A maioria dos sistemas permite que o UDP restrinja endereços remotos e só pode receber datagramas UDP com números de porta e IP específicos. Se nenhum endereço local for selecionado durante esta configuração, o sistema derivado de Berkeley selecionará automaticamente um endereço IP local, que se torna a interface de origem para a extremidade remota.
A ordem de cima para baixo na figura acima é a ordem usada pelo UDP para determinar qual datagrama pós-seção do programa de aplicativo usar.
A maioria dos sistemas só permite que um programa seja conectado a um determinado endereço IP local e número de porta em um determinado momento. Se outro servidor com o mesmo endereço local e número de porta for iniciado neste momento, ele não será executado, mesmo que usemos SO_REUSEADDR Opções de soquete.
Em sistemas que suportam multicast, vários programas podem usar o mesmo endereço IP e número de porta, embora o aplicativo geralmente deva informar a API que isso é possível (como usar a opção de soquete SO_REUSEADDR).
Quando o IP de destino ao qual chega um datagrama UDP é um endereço de broadcast ou um endereço multicast, e há vários processos no endereço IP de destino e no número da porta, um datagrama é enviado para cada terminal.
Supondo que haja um datagrama UDP de 8192 bytes a ser enviado, para IP, mais o cabeçalho de 8 bytes UDP, há datagramas de 8200 bytes a serem enviados.
Se um datagrama UDP for dividido em 4 partes, a extremidade receptora receberá apenas as duas primeiras partes e o aplicativo retransmitirá o datagrama UDP após o tempo limite de 10s e será dividido nas mesmas 4 partes, assumindo que a extremidade receptora só receba desta vez. últimas duas peças, e o tempo de remontagem da extremidade receptora é de 60 segundos, essas 4 peças não serão remontadas em um datagrama IP, pois o datagrama IP retransmitido possui um novo campo de identificação, e a remontagem é apenas para o mesmo Identifica o segmento do campo.
O programa netstat em um host mostra que os erros de checksum TCP e IP são muito mais do que erros de checksum UDP. O motivo pode ser que o datagrama UDP enviado ao host não calcula o checksum (quando o checksum do remetente é preenchido com 0)) Ou O datagrama UDP é principalmente para comunicação local e a probabilidade de erro é pequena.
Quando ocorre a fragmentação, as opções em diferentes cabeçalhos de IP copiam o cabeçalho de IP de maneira diferente. As opções de roteamento de site de origem flexível e restrita copiam o cabeçalho de IP para cada fragmento de datagrama; a opção de carimbo de data / hora e a opção de roteamento de registro O cabeçalho de IP só aparece no primeiro datagrama fragmento.
Existem muitas maneiras de filtrar um datagrama de entrada enviado para um determinado número de porta UDP, que pode ser filtrado com base no endereço IP de destino, endereço IP de origem e número da porta de origem.