GSP045

Visão geral

Neste laboratório prático, você vai analisar cenários reais, recriar os ambientes e colocar a mão na massa para otimizar o desempenho de algumas redes com problemas.

Uma atividade interessante é comparar as diferentes instâncias entre si, assim como no caso de uso de solução de problemas. Assim, você vai conseguir comprovar os resultados e se familiarizar com as etapas necessárias para melhorar o desempenho dos seus próprios sistemas.

Este laboratório foi adaptado de posts de Colt McAnlis: Core Count and the Egress problem e Internal IP vs External IP. Colt escreve sobre o desempenho de redes do Google Cloud no Medium.

Objetivos

• Aprender a testar o desempenho e a conectividade da rede usando ferramentas de código aberto
• Usar ferramentas de código aberto para inspecionar o tráfego de rede
• Entender como o tamanho da máquina pode afetar o desempenho da rede

Pré-requisitos

• Conhecimento básico sobre os serviços do Google Cloud (é recomendado concluir os laboratórios do Google Cloud Essentials)
• Conhecimento básico de redes do Google Cloud e TCP/IP (é recomendado concluir os laboratórios anteriores do curso Networking in the Google Cloud)
• Conhecimento básico de linha de comando do Unix/Linux

Configuração e requisitos

Antes de clicar no botão Começar o Laboratório

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é ativado quando você clica em Iniciar laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.

Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, e não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.

Confira os requisitos para concluir o laboratório:

• Acesso a um navegador de Internet padrão (recomendamos o Chrome).

Observação: para executar este laboratório, use o modo de navegação anônima (recomendado) ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e de estudante, o que poderia causar cobranças extras na sua conta pessoal.

• Tempo para concluir o laboratório: não se esqueça que, depois de começar, não será possível pausar o laboratório.

Observação: use apenas a conta de estudante neste laboratório. Se usar outra conta do Google Cloud, você poderá receber cobranças nela.

Como iniciar seu laboratório e fazer login no console do Google Cloud

1. Clique no botão Começar laboratório. Se for preciso pagar por ele, uma caixa de diálogo vai aparecer para você selecionar a forma de pagamento. À direita, você encontra o painel Configuração e acesso ao laboratório com as seguintes informações:

   • O botão Abrir console do Google Cloud
   • As credenciais temporárias (nome de usuário e senha) que você vai usar no laboratório
   • Outros dados, se necessários

   O timer do laboratório fica na parte de cima da página e mostra o tempo restante.

2. Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.

   O laboratório ativa os recursos e depois abre a página "Login" em outra guia.

   Dica: coloque as guias em janelas separadas lado a lado.

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Login.

   {{{user_0.username | "Username"}}}

   Você também encontra o nome de usuário no painel Configuração e acesso ao laboratório.

4. Clique em Avançar.

5. Copie a Senha abaixo e cole na caixa de diálogo Olá!.

   {{{user_0.password | "Password"}}}

   Você também encontra a senha no painel Configuração e acesso ao laboratório.

6. Clique em Avançar.

   Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, talvez receba cobranças adicionais.

7. Acesse as próximas páginas:

   • Aceite os Termos e Condições.
   • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
   • Não se inscreva em testes sem custo financeiro.

Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.

Observação: para acessar os produtos e serviços do Google Cloud, clique no Menu de navegação ou digite o nome do serviço ou produto no campo Pesquisar.

O objetivo deste laboratório é mostrar a relação entre o número de núcleos e a capacidade de processamento. Para isso, ele já vem com seis instâncias criadas. Elas foram criadas assim que você começou o laboratório.

• No console do Cloud, acesse o Menu de navegação > Compute Engine > Instâncias de VMs para ver suas instâncias:

Observação: pode ser que a região e a zona das suas instâncias sejam diferentes das que aparecem na captura de tela.

Teste de conexão

Faça um teste de conexão rápido para verificar se tudo está funcionando.

1. Clique no botão "SSH" ao lado do nome instance-1 no console para acessar a instância por SSH.

2. Na sua nova janela de shell, dê um ping em outra instância e execute o comando a seguir, substituindo <external ip address of instance-2> pelo endereço IP externo da instance-2:

ping -c 5 <external ip address of instance-2>

Exemplo de saída:

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.158.169 PING 35.194.158.169 (35.194.158.169) 56(84) bytes of data. 64 bytes from 35.194.158.169: icmp_seq=1 ttl=76 time=1.89 ms 64 bytes from 35.194.158.169: icmp_seq=2 ttl=76 time=0.409 ms 64 bytes from 35.194.158.169: icmp_seq=3 ttl=76 time=0.542 ms 64 bytes from 35.194.158.169: icmp_seq=4 ttl=76 time=0.557 ms 64 bytes from 35.194.158.169: icmp_seq=5 ttl=76 time=0.559 ms --- 35.194.158.169 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.409/0.792/1.894/0.554 ms

3. Teste com outro ping. Substitua <external ip address of instance-3> pelo endereço IP externo de instance-3 e dê um ping nela:

ping -c 5 <external ip address of instance-3>

Exemplo de saída:

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.187.75 PING 35.194.187.75 (35.194.187.75) 56(84) bytes of data. 64 bytes from 35.194.187.75: icmp_seq=1 ttl=64 time=1.59 ms 64 bytes from 35.194.187.75: icmp_seq=2 ttl=64 time=0.336 ms 64 bytes from 35.194.187.75: icmp_seq=3 ttl=64 time=0.338 ms 64 bytes from 35.194.187.75: icmp_seq=4 ttl=64 time=0.302 ms 64 bytes from 35.194.187.75: icmp_seq=5 ttl=64 time=0.270 ms --- 35.194.187.75 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.270/0.568/1.596/0.514 ms

Até aqui tudo certo, vamos em frente!

Revisão das regras de firewall

Também criamos regras de firewall para este laboratório.

• Para ver essas regras, acesse Menu de navegação > Rede VPC > Firewall e clique no firewall iperftesting.

A regra de firewall iperftesting usa esta configuração:

Campo	Valor	Comentários
Nome	iperftesting	Nome da nova regra
Destinos	Todas as instâncias na rede
Intervalos de IPs de origem	0.0.0.0/0	Vamos abrir o firewall para qualquer endereço IP da internet.
Protocolos e portas	tcp:5001; udp:5001
Direção do tráfego	Entrada
Ação em caso de correspondência	Permitir

Agora está tudo pronto para você começar a usar o laboratório.

Caso de uso 1: rede e contagem de núcleos do Compute Engine

Neste primeiro cenário, você verá na prática como o tamanho das máquinas usadas afeta a capacidade de processamento que pode ser medida.

Dobermanifesto é uma rede de microblogging de vídeos feita exclusivamente para pets. Vídeos de animais podem ser enviados de qualquer lugar do mundo.

Ao transferir dados de/para seus back-ends do Compute Engine, a largura de banda observada não foi tão alta quanto o esperado:

Tarefa 1: reproduzir o comportamento

Para tentar reproduzir esse comportamento, criamos duas instâncias na mesma zona e executamos o iperf entre elas 100 vezes.

O desempenho foi ainda pior! Está claro que algo deu errado no teste. Precisamos de mais informações e de instruções mais detalhadas da empresa para a replicação do erro.

Agora você vai preparar o cenário.

Ambiente do Dobermanifesto

1. Volte à lista de instâncias de VMs no console do Compute Engine.

2. Acesse a instance-1 (1 vCPU, 3,75 GB) por SSH e execute este comando para configurar um "receptor" iperf:

iperf -s

3. Depois, acesse a instance-2 (1 vCPU, 3,75 GB) por SSH e gere tráfego iperf direcionado à instance-1:

iperf -c <external ip address of instance-1>

Exemplo de saída:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.225.180.44 ------------------------------------------------------------ Client connecting to 35.225.180.44, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.0.4 port 56330 connected with 35.225.180.44 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0000-10.0010 sec 4.66 GBytes 4.00 Gbits/sec

4. Volte para a instance-1 e pressione CTRL + C para encerrar o processo do receptor.

Ambiente de teste

1. Volte ao console do Compute Engine e abra outra janela de SSH com a instance-6 (1 vCPU e2-micro, 0,6 GB).

2. Execute este comando, configurando a instância como "recebedor":

iperf -s

Exemplo de saída:

student-00-aafd1bd9c185@instance-6:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

3. Na janela SSH da instance-2, teste a conexão com a instance-6:

iperf -c <internal ip address of instance-6>

Exemplo de saída:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.7 ------------------------------------------------------------ Client connecting to 10.40.0.7, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.5 port 54029 connected with 10.40.0.7 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.29 GBytes 1.96 Gbits/sec

4. Volte para a instance-6 e pressione CTRL + C para encerrar o receptor.

O que aconteceu? A largura de banda parece ter aumentado. Pode ser que isso tenha acontecido no seu caso também ou talvez o resultado tenha sido menor.

Na próxima seção, você vai aprender que o número total de núcleos limita a largura de banda. Com números pequenos como esse (apenas um núcleo), a largura de banda nunca vai exceder cerca de 2 Gbits/s. Por isso, a velocidade de rede é baixa e a largura de banda é limitada, como aconteceu com o Dobermanifesto. Ao testar com máquinas de 4 CPUs em instantes, você verá que os resultados serão ainda melhores.

O número de núcleos é proporcional aos Gb/s

Por que os resultados não foram muito diferentes? A documentação do Compute Engine diz o seguinte:

O tráfego de saída de uma máquina virtual está sujeito a limites máximos de capacidade de processamento da rede. Esses limites variam de acordo com o número de vCPUs de cada instância de máquina virtual. Cada núcleo tem um limite de 2 Gbits/segundo (Gbps) para o desempenho de pico. Cada núcleo adicional aumenta o limite de rede, chegando a um máximo teórico de 16 Gbps para cada máquina virtual

Isso significa que, quanto maior o número de CPUs virtuais na rede, maior será a capacidade de processamento dela.

Para mostrar como isso funciona na prática, grupos com quantidades diferentes de núcleos foram configurados na mesma zona e o iperf foi executado entre eles mil vezes.

À medida que o número de núcleos aumenta, a capacidade de processamento média e máxima também cresce. Mesmo com esse teste simples, fica claro o limite rígido de 16 Gbps nas máquinas mais potentes.

Observação: ao executar o iperf com várias threads (por volta de oito), você pode superar os 10 Gbps e alcançar até 16 Gbps usando uma instância e2-standard-16 ou superior. Não temos uma máquina desse porte no ambiente do laboratório, mas vamos fazer o teste com vários processadores lógicos a seguir. Também existem VMs de custo mais elevado nas séries N2, N2D, C2 ou C2D que permitem selecionar uma configuração de Nível 1 de alta largura de banda para atingir de 50 a 100 Gbps.

Tarefa 2: hora de melhorar os resultados

A rede do Dobermanifesto opera com máquinas de apenas 1 vCPU. Com mais núcleos, o Dobermanifesto provavelmente terá melhores resultados. É hora de testar essa teoria.

1. Acesse a instance-3 (4 vCPUs e 15 GB de memória) por SSH e execute este comando:

iperf -s

Exemplo de saída:

student-00-aafd1bd9c185@instance-3:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. Acesse a instance-4 (4 vCPUs e 15 GB de memória) por SSH:

iperf -c <internal ip address of instance-3>

Exemplo de saída:

student-00-aafd1bd9c185@instance-4:~$ iperf -c 10.40.0.2 ------------------------------------------------------------ Client connecting to 10.40.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.4 port 54081 connected with 10.40.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 8.93 GBytes 7.67 Gbits/sec

3. Agora tente fazer isso com quatro processadores lógicos:

iperf -c <internal ip address of instance-3> -P4

4. E com oito processadores lógicos:

iperf -c <internal ip address of instance-3> -P8

5. Volte para a instance-3 e pressione CTRL + C para encerrar o receptor.

Nesses experimentos, o servidor e o cliente utilizaram 4 vCPUs, o que resultou em um ganho de velocidade impressionante. A taxa de transferência aumentou em 6,64 GBytes, e a largura de banda, em 5,71 Gbits/s. Com o uso de várias threads, o desempenho conseguiu atingir o limite máximo para essa quantidade de núcleos.

6. Continue os testes com a instance-5, uma máquina de 4 vCPUs com desempenho superior e tipo de instância "highcpu-4".

Este tipo de instância tem CPUs mais velozes, mas conta com menos memória. Você notou alguma diferença? E com vários processadores lógicos?

Agora a equipe do Dobermanifesto precisa decidir qual caminho seguir. Depois de analisar o perfil de uso da CPU e as informações de preços, a equipe decidiu usar uma máquina e2-standard-4, que basicamente quadriplicou a capacidade de processamento média, sendo mais barata que as máquinas e2-standard-8.

Um dos pontos positivos de mudar para máquinas maiores é que elas são executadas com uma frequência menor. As máquinas anteriores ficavam muito tempo em estado ativo só para transferir dados. Com o novo tamanho de máquina, as instâncias passaram a ter mais tempo de inatividade, o que permitiu que o balanceador de carga reduzisse o número total de instâncias diariamente. Assim, se por um lado eles acabaram pagando por uma máquina mais potente, por outro, vão consumir menos horas de núcleo por mês.

Quando o desempenho afeta diretamente o seu faturamento, há uma série de trocas sutis que precisam ser levadas em conta.

Caso de uso 2: rede do Google Cloud com IPs internos

Neste próximo exemplo, você vai usar o iperf para testar a capacidade de processamento. Você vai configurar uma máquina como servidor e depois direcionar outras instâncias a ela para comparar os resultados.

A Gecko Protocol, uma empresa B2B que oferece um protocolo de rede leve e personalizado para jogos e outros sistemas gráficos em tempo real, estava enfrentando uma capacidade de processamento abaixo do esperado em suas máquinas de back-end, responsáveis por transferir e transcodificar arquivos grandes de vídeo e de computação gráfica.

Estes são os resultados do teste iperf de referência deles:

------------------------------------------------------------ Client connecting to 104.155.145.79, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 53504 connected with 104.155.145.79 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.03 GBytes 884 Mbits/sec

Ao reproduzir o teste, a configuração da rede era a mesma, mas os resultados foram bem diferentes:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.128.0.2 ------------------------------------------------------------ Client connecting to 10.128.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 38978 connected with 10.128.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.27 GBytes 1.95 Gbits/sec

Os 1,95 GB/s eram um valor muito superior ao que a Gecko Protocol estava observando em seus gráficos. Afinal, o que está acontecendo?

Agora é sua vez de recriar este cenário.

1. No console, use SSH para se conectar a instance-1 e configure o receptor iperf:

iperf -s

Exemplo de saída:

student-00-aafd1bd9c185@instance-1:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. Use SSH para se conectar à instance-2 e verifique a conexão do endereço IP externo:

iperf -c <external ip address of instance-1>

Exemplo de saída:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.201.145.135 ------------------------------------------------------------ Client connecting to 35.201.145.135, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 58691 connected with 35.201.145.135 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.36 GBytes 1.16 Gbits/sec

Depois de conversar em mais detalhes com a Gecko Protocol, descobrimos que eles estavam usando IPs externos para conectar suas máquinas, e o teste utilizava IPs internos. Quando as máquinas estão em uma rede, conectá-las com IPs internos resulta em uma capacidade de processamento mais rápida.

3. Agora, teste a conexão usando o endereço interno:

iperf -c <internal ip address of instance-1>

Exemplo de saída:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 42950 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.26 GBytes 1.94 Gbits/sec

Observe a diferença entre as duas taxas de transferência e de largura de banda. Neste exemplo, a mudança para o endereço IP interno resultou em um ganho de 0,9 GB na taxa de transferência e um aumento de 0,78 Gbits/s na largura de banda. Você acaba de comprovar que a conexão interna é mais veloz.

Com base no que você aprendeu ao resolver o problema do Dobermanifesto, será que a velocidade da rede pode aumentar ainda mais se usarmos uma máquina maior? A instance-2 só tem uma vCPU. Qual será a velocidade da conexão se a máquina for um pouco maior? E se for muito maior? Continue os testes usando o endereço IP interno (mas fique à vontade para testar o externo também, se tiver tempo).

Máquina com 4 vCPUs

• Acesse a instance-3 por SSH e teste a conexão usando o endereço IP interno:

iperf -c <internal ip address of instance-1>

Exemplo de saída (seus resultados podem ser diferentes):

student-00-aafd1bd9c185@instance-3:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.6 port 39115 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 4.53 GBytes 3.89 Gbits/sec

Máquina 4 highCPU

• Acesse a instance-5 por SSH e teste a conexão usando o endereço IP interno:

iperf -c <internal ip address of instance-1>

Exemplo de saída:

student-00-aafd1bd9c185@instance-5:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.3 port 39736 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 10.3 GBytes 8.84 Gbits/sec

Isso melhora significativamente a capacidade de processamento.

Pelo visto, a Gecko Protocol também terá que avaliar qual tamanho de núcleo será o mais adequado. Com essa pequena depuração, a transferência de dados de vídeos e gráficos aumentou cerca de 14 vezes. O que é um ganho imenso, considerando que a solução deles é baseada em serviços de back-end de alta performance para cenários de computação de alto desempenho.

Tarefa 3: teste no seu próprio ambiente

Este laboratório não ensina a testar seu próprio sistema, mas preparamos algumas informações extras para você aplicar depois. Para saber mais sobre como testar sua própria rede, leia Teste de throughput de rede com iPerf.

Se quiser e tiver tempo, configure uma VM para testar. Quando for criar suas VMs, verifique se você usou a regra de firewall e a tag "iperftest". Teste seu endereço IP interno e externo.

Configurações para testar a velocidade da sua própria rede

1. No console, acesse Menu de navegação > Rede VPC > Firewall.

2. Clique em Criar regra de firewall. Use as configurações abaixo para criar uma regra de firewall:

Campo	Valor	Comentários
Nome	iperf-testing	Nome da nova regra
Destinos	Todas as instâncias na rede
Intervalos de IPs de origem	0.0.0.0/0	Vamos abrir o firewall para qualquer endereço IP da internet.
Direção do tráfego	entrada
Ação em caso de correspondência	Permitir
Protocolos e portas	tcp:5001; udp:5001

3. Clique em Criar.

Clique em Verificar meu progresso para validar sua conclusão. Criar a regra de firewall

A tendência é levar a carga de trabalho o mais próximo possível de 100%, o que deixa pouco espaço para a desfragmentação do disco, etc.

Um nível de uso entre 90% e 93% é considerado saudável, mas com 98% o desempenho cai, já que haverá muita contenção.

Fique de olho nos contadores de limitação se o desempenho de E/S cair durante os testes. Caso o tráfego não esteja sendo limitado, verifique o uso da CPU. Se ele estiver muito alto, você achou o problema!

Tarefa 4: quando você tiver tempo

Na interface do laboratório, em "Recursos para estudantes" no lado direito, você encontrará links para vídeos relacionados a este laboratório. Vale muito a pena assistir!

Parabéns!

Parabéns! Neste laboratório, você aprendeu a testar a conectividade e o desempenho de rede com ferramentas de código aberto, além de descobrir como o tamanho da sua máquina pode impactar diretamente o desempenho da rede.

Próximas etapas/Saiba mais

• Acesse o post do Google Cloud Using Google's cloud networking products: a guide to all the guides (Como usar produtos de rede de nuvem do Google: um guia para todos os guias, em tradução livre).
• Consulte a documentação de rede do Compute Engine.
• Saiba mais sobre sub-redes.
• Poste perguntas e encontre respostas no Stack Overflow usando as tags google-compute-engine ou google-cloud-platform.

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 7 de julho de 2026

Laboratório testado em 7 de julho de 2026

Copyright 2026 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.