Protocolo de rede UDP, TCP

---

1. Camada de vedação padrão na rede

1、TCP/IP

• Camada de aplicação: comunicação específica entre processos (informações específicas)
• Camada de transporte: troca de dados fim-a-fim; fim: processo (comunicação entre processos)
• Camada de rede: troca de dados entre dispositivos e dispositivos WAN, trabalho entre LANs (cross-LAN, comunicação entre hosts)
• Camada de enlace de dados: assuntos relacionados dentro de uma rede local LAN (comunicação entre hosts dentro da LAN)
• Camada física: Por exemplo, dois dispositivos podem ser conectados diretamente (conexão direta)

Reabastecimento

• Durante o processo de envio: camada de aplicação - "camada de transporte - > camada de rede - " camada de enlace, cada camada adicionará suas próprias informações necessárias ao pacote de dados (encapsulamento)
• Durante o processo de recebimento, camada de enlace -> camada de rede - "camada de transporte -> camada de aplicação, cada camada precisa ser responsável por excluir (descompactar) as informações relevantes dessa camada.
• Cada camada do pacote deve conter duas informações importantes:
  • Como dividir os dados adicionados por cada camada (comprimento, limite) para descompactar
  • Especificamente entregue ao protocolo da camada superior para processamento, a fim de dividir
  • No mesmo host, uma porta só pode ser ocupada por um processo, mesmo que vários processos pertençam ao mesmo programa.
    • Portas comuns
      http: 80
      https: 443
      ssh: 22
      mysql: 3306
      redis: 6379

Enquanto houver uma porta, ela deve estar no nível acima da camada de transporte. Existem dois protocolos importantes na camada de transporte: TCP, UDP; com base no quádruplo + número do protocolo = "quíntuplo

• Programação de rede: utilize o socket (socket) fornecido pelo os para programar a comunicação interna da comunicação em rede;
• Socket (socket): Socket, equivalente ao uso real de TCP, UDP e outros serviços de rede fornecidos por os através de socket.

2. Protocolos importantes da camada de transporte: processo a processo

2.1 Protocolo de datagrama de usuário UDP

• Sem recursos, quando comparado ao TCP: não confiável, sem conexão, orientado a mensagens
• Como o protocolo de camada de transporte mais simples, o UDP não ajuda os usuários a lidar com ambientes de rede complexos, por isso mantém as características de uma rede não confiável.
• Informações do cabeçalho do pacote UDP (cabeçalho)
  • Dados encapsulados (cabeçalho)
    • 8 bytes, comprimento fixo; número da porta de origem de 16 bits (remetente), número da porta de destino de 16 bits (receptor); comprimento UDP de 16 bits (comprimento da mensagem), soma de verificação UDP de 16 bits (soma de verificação)
    • Função Checksum: Determina se a mensagem recebida (dados) contém erros; se o checksum estiver errado, será descartado diretamente; se não houver erro, os dados serão recebidos normalmente;
    • Mecanismo de trabalho simples de soma de verificação: Usando o princípio da função hash: Ao projetar uma função hash, é alcançada uma situação em que a taxa de conflito é muito baixa.
  • dados (carga útil)
• O UDP possui um buffer de recebimento (os dados UDP que chegam depois de cheio serão descartados) e não há buffer de envio; quantos dados são enviados pela camada de usuário, quantos dados são enviados diretamente pelo UDP;
• O UDP envia dados sem qualquer preparação e pode enviar (correio) a qualquer hora, em qualquer lugar. , portanto, também é desconectado;
• Falta de confiabilidade: Não há garantia de que a mensagem será enviada para a outra parte; após a perda do pacote, o remetente não sabe disso; não é possível garantir que a mensagem esteja em ordem;
• Afetando os resultados: Como a camada inferior (camada física + camada de rede) tem um limite de tamanho nos dados enviados de uma só vez; se dados maiores que o limite forem enviados à força, ocorrerá truncamento de dados.
• O soquete UDP pode ler e escrever, o que é chamado de full duplex (ou seja, pode enviar e receber).
• O cenário mais adequado para o protocolo UDP: Cenários com altos requisitos de tempo real e baixos requisitos de confiabilidade - chat em tempo real (voz, vídeo). A transmissão é suportada.

2.2 Protocolo TCP: Protocolo de Controle de Transmissão

• Funciona na camada de transporte. Acima dela está a camada de aplicação (fornecendo serviços para a camada de aplicação); abaixo está a camada de rede (dependendo da camada de rede para funcionar); existem duas fontes de eventos externas para a pilha de protocolos TCP: chamadas de método da camada de aplicação; dados da camada de rede recebem .

• Objetivos principais: fornecer comunicação entre processos, buscar confiabilidade;

• Passando dados em unidades de processos Buscando confiabilidade;

• Confiabilidade : o TCP só pode garantir que fará o possível para enviar dados à outra parte de maneira ordenada (o TCP garante que os dados recebidos pela camada de aplicação estejam em ordem); mas não pode garantir que possam ser enviados para a outra parte. Mesmo que não seja enviado com sucesso, há feedback.

• Certifique-se de que a outra parte o aceite de maneira ordenada. Certifique-se de que a outra parte não receberá dados incorretos. O TCP projetará alguns mecanismos para otimizar a rede o máximo possível e melhorar a possibilidade de recebimento da outra parte.

• **Como alcançar a confiabilidade? **Mecanismo: mecanismo de resposta de confirmação

  • Os dados enviados são geralmente chamados: segmento (segmento de dados); resposta: reconhecer
  • O remetente envia vários segmentos ao mesmo tempo e o destinatário responde várias vezes. Como o remetente sabe qual segmento o destinatário recebeu?Mecanismo de numeração: O remetente atribui um número aos dados enviados , e só precisa trazer o número correspondente ao responder.
  • Se o remetente não receber a resposta correspondente, considera-se que a outra parte não recebeu os dados. ---- Mecanismo de retransmissão de tempo limite

• O formato do cabeçalho do protocolo TCP:

  • comprimento não fixo;
  • Número da porta de origem de 16 bits, número da porta de destino de 16 bits.
  • Número de sequência de 32 bits Número de sequência SN: O segmento que transporta os dados.
  • Número de sequência de confirmação de 32 bits Número de sequência de confirmação ASN : O segmento da confirmação.
  • O comprimento do cabeçalho de 4 bits pode garantir que a pilha de protocolos TCP do receptor execute o trabalho de descompactação.
  • Existem dois tipos de segmentos: transporte de dados, dados + segmento de resposta; mas são feitas configurações unificadas. Como distinguir se este segmento tem a função de resposta? ack = 1 tem a função de resposta, e ack = 0 não tem função de resposta.

• Números TCP de cada byte enviado (apenas a carga útil). Ao enviar, o SN no cabeçalho é preenchido com o número de sequência do primeiro byte no primeiro payload. O destinatário sabe o comprimento e, se o recibo for recebido, todos sabem.

• Quando a pilha de protocolos TCP estabelece uma conexão, ela gera aleatoriamente um ISN de Número de Sequência Inicial.

• O ASN é preenchido com o próximo byte de dados recebido pelo receptor, (o último enviado é 112, então o ASN é preenchido com 113, ou seja: todos os dados antes de 113 são recebidos).

• Se o remetente não receber uma resposta após um certo período de tempo, a original: a outra parte não a recebeu; as duas originais: a outra parte recebeu, mas a resposta foi perdida. (Premissa: O receptor pode confirmar se os dados foram aceitos de acordo com o SN.). A lógica de processamento do remetente é consistente, após o tempo limite, será retransmitido diretamente (os dados retransmitidos não serão perdidos). A parte que responde julga se aceita repetidamente, não é uma resposta normal; se for descartada, é uma resposta normal.

• E se chegar fora de ordem?

  • Os dados enviados pelo remetente primeiro e depois aceitos (o remetente pode enviar diretamente várias vezes sem esperar por uma resposta) Os primeiros dados recebidos não respondem (se responder, a outra parte pensa que todos receberam antes, se o primeiro pacote é perdido, não será repetido). A segunda resposta recebida, ASN = 2001. (Certifique-se de que a aceitação da outra parte está em ordem e os dados recebidos não serão mais aceitos. Embora a pilha de protocolos TCP do host destinatário não esteja em ordem, é garantido que o aplicativo do host destinatário Os dados recebidos pela camada são ordenados)

• Se após o tempo limite, a outra parte não recebeu a retransmissão?

  • Continue a retransmitir até que um limite seja atingido. Se não houver resposta, desista; Etapa 1: Tente notificar a outra parte que a conexão foi fechada de forma anormal e envie um segmento de reinicialização; rst = 1 é um segmento de reinicialização; rst = 0 não é. Se a outra parte pode recebê-lo não é garantido. Passo 2: Notifique a camada de aplicação que a transmissão de dados falhou.Existem diferentes métodos de notificação de acordo com as diferentes linguagens.Em Java, a notificação é através de uma exceção, e ela receberá uma IOException, descrevendo a conexão de reset.

• Se expirar, como é determinado o tempo?

  • O ideal é encontrar o tempo mínimo para garantir que "a resposta de confirmação deva ser devolvida dentro desse prazo". Se o tempo limite for definido muito longo, a eficiência geral da retransmissão será afetada. Se o tempo limite for definido muito curto, pacotes repetidos podem ser enviados com frequência.
  • Solução: RTT: Round Trip Time Em circunstâncias normais, o tempo para os dados irem e voltarem. Geralmente maior que esse tempo, geralmente há um valor de experiência. Após cada retransmissão, esse número é amplificado. No Linux, o tempo limite é controlado em uma unidade de 500ms, e o tempo limite para cada retransmissão de tempo limite é um múltiplo inteiro de 500ms. Se ainda não houver resposta após reenviar uma vez, aguarde 2.500ms antes de retransmitir, e os próximos 4.500ms acumularão um certo número de retransmissões.O TCP considera que a rede ou o host peer está anormal e fecha a conexão à força.

• Quando o TCP envia, ele não precisa esperar uma resposta antes de enviar novos dados; também é possível dar apenas uma resposta.

• O TCP ocasionalmente enviará confirmações de volta periodicamente, mesmo quando nenhum dado tiver sido recebido. (pelo menos atualize a janela).

• O TCP não entende a resposta de envio depois de receber os dados, existe um mecanismo de resposta de atraso; aguarde se os dados podem ser empilhados.

• Resposta de reserva; os dados podem ser adicionados ao responder.

• Retransmissão rápida; teoricamente, a retransmissão não será retransmitida até o tempo limite, mas o receptor envia 12 medalhas de ouro para permitir que o remetente retransmita imediatamente.

2.1.1 Três Características do TCP

• confiabilidade (raiz)
• conectado
• Para fluxos de bytes, os dados no buffer de envio não são necessariamente enviados estritamente de acordo com a situação escrita pela camada de aplicação devido à limitação do tamanho da janela de envio. A camada de aplicação do receptor não tem como ler dados da mesma forma que a camada de aplicação do remetente se divide. (Algumas pessoas chamam isso de problema do pacote pegajoso), através do projeto do protocolo da camada de aplicação: 1. O método de comprimento fixo 2. O comprimento não é fixo, carregando comprimento/caracteres especiais como separadores, como \n.
  - O protocolo HTTP é um protocolo em cima do TCP, portanto, também é necessário lidar com problemas de fluxo de bytes no protocolo. Portanto, no projeto do protocolo HTTP, a linha de solicitação e o cabeçalho da solicitação são divididos por \r\n; para a parte do corpo, o comprimento do conteúdo é usado para especificar o comprimento a ser dividido.

3. Gerenciamento de conexão

3.1 Por que você precisa de uma conexão, qual é a abstração da conexão (TCP tem uma conexão, UDP não tem conexão)

• Como uma pilha de protocolos TCP, é necessário manter um buffer de recebimento;
  • Certifique-se de que os dados que chegam fora de ordem sejam classificados;
  • Antes que os dados sejam lidos temporariamente pela camada de aplicativo, os dados são salvos temporariamente.
• Como uma pilha de protocolos TCP, é necessário manter um buffer de envio;
  • Devido à possibilidade de retransmissão, os dados não respondidos não podem ser descartados diretamente, portanto, é necessário um espaço para armazenamento temporário.
• Como a pilha de protocolos TCP, o remetente precisa manter o SN que foi enviado; o receptor precisa manter o SN que deve ser respondido.

A pilha de protocolos TCP, para garantir que os mecanismos anteriores estejam disponíveis, deve manter um conjunto de dados relacionados para cada canal. Um conjunto de dados relacionados ----" é abstraído em um objeto, e esse objeto é chamado de conexão.

• Objeto de conexão: O representante do canal pelo qual as duas partes se comunicam. Para a pilha TCP, é mantido um conjunto de dados relacionados às informações do canal.

3.2 A necessidade de estabelecer uma conexão

• O processo no host A deseja se comunicar com o processo no host B por meio de TCP.
• Como o TCP busca confiabilidade, antes de enviar dados formalmente, queremos verificar se a outra parte pode receber os dados (confirmar mutuamente se a outra parte está online).
• Para o objeto de conexão, algumas informações não podem ser conhecidas independentemente e ambas as partes precisam sincronizar as informações efetivas (ambos os lados sincronizam as informações iniciais necessárias).
• A fase de comunicação é dividida em três partes: a fase de estabelecimento da conexão (fase de handshake), a fase de disponibilidade do canal e a fase de desconexão de liberação (fase de onda).

3.3 Introduzir mecanismo de estado, diferentes estados ---- situação de conexão atual

3.3.1 Aperto de mão de três vias

• O estabelecimento de uma conexão TCP exige que as duas partes troquem informações três vezes; por que três vezes? A sincroniza as informações com B e B sincroniza as informações com A. Demora pelo menos duas vezes. O TCP precisa garantir a confiabilidade, então, além da resposta e do reset), ele precisa responder e precisa de 2 respostas no Logicamente, ele precisa de quatro vezes. , mas para melhorar a utilização da rede, é inevitável combinar (2) e (3) (B responde às informações de A e sincroniza as informações com A). Duas vezes é para sincronizar informações. Sincronizar (sincronizar sincronização).
• Quatro segmentos: segmento de dados, segmento de resposta (ack = 1), segmento de reset (rst = 1), segmento de sincronização (syn = 1).
• Mudanças de SN no handshake de três vias:
  

3.3.2 Diagrama de transição de estado (limitado à fase de handshake de três vias)

• No nível TCP, a terminologia padrão não menciona o cliente e o servidor, mas a conexão ativa e passiva; na prática, o servidor geralmente é a conexão passiva e o cliente é a conexão ativa.
• Status da fase de conexão:
  • ---------- Antes de estabelecer uma conexão
  • fechado: sem conexão / quando a conexão acaba de ser estabelecida e não inicializada;
  • listen: estado de escuta; parte de conexão passiva: esperando que outros estabeleçam uma conexão. Na verdade, apenas uma parte existe, nenhum canal existe ainda.
  • ---------- Estabelecendo conexão
  • syn_rcvd: parte de conexão passiva: acaba de receber o syn segmnet enviado pela outra parte (parte de conexão ativa).
  • syn_sent: Parte de conexão ativa: emitiu um segmento syn, aguardando a resposta da outra parte.
  • ---------- Após a conexão ser estabelecida
  • estabelecido: A conexão foi estabelecida e pode se comunicar normalmente.
    
    
• Antes do estabelecimento formal do handshake de três vias, a parte de conexão passiva tem dois estados: fechado e escutado.
  
• Uma vez que a conexão entre as duas partes é estabelecida, o status de ambas as partes na comunicação é igual: qualquer pessoa pode enviar dados ativamente ou até enviar dados ao mesmo tempo. ·

3.3.3 Ondas quatro vezes

• O fechamento da conexão TCP é independente e não afeta a outra parte.
• Por que a fase da onda é quatro vezes?
  • As duas partes comunicantes A e B (a parte que inicia o desligamento ativamente não é necessariamente a parte que estabelece a conexão ativamente.
  • A inicia ativamente o desligamento ---- "Quando B recebe a mensagem de desligamento, ele também é fechado ao mesmo tempo;
  • A inicia ativamente o desligamento----"B continua após receber a mensagem de desligamento----"após um período de tempo----"B inicia o desligamento novamente;
  • A inicia o desligamento e B inicia o desligamento quase ao mesmo tempo.
• TIME_WAIT só pode aparecer do lado da parte de fechamento ativa; CLOSE_WAIT só pode aparecer do lado da parte de fechamento passiva.
• É normal que um grande número de estados CLOSE_WAIT apareça no servidor? Se não, quais questões devem ser investigadas?
  • Não particularmente normal, mas não necessariamente errado. Solução de problemas: O servidor esqueceu de fechar a conexão. A conexão precisa ocupar pelo menos memória e um grande número de conexões perdidas são ineficazes e desperdiçam recursos.
• Necessidade do estado TIME_WAIT: é FECHADO após um período de tempo, não FECHADO diretamente? Quando uma conexão é fechada, o fenômeno é que ela morre normalmente, mas levará algum tempo para confirmar se ela realmente morre. Existem duas situações inesperadas possíveis: Situação 1: B não recebe a resposta de A, se A for fechado, então B solicita o mecanismo de resposta e não pode enviá-lo novamente; Situação 2: A etapa de comunicação é perdida por algum motivo e é transmitida mais tarde. Se fechado, não pode ser recebido.
• TIME_WAIT duração: 2* MSL (Segmento Máximo: O tempo máximo que um Segmento TCP pode sobreviver na rede.

3.3.4 Exceções TCP

• Encerramento do processo: O descritor do arquivo será liberado e o FIN ainda poderá ser enviado, o que não é diferente de um encerramento normal.
• Reinicialização da máquina: Igual ao encerramento do processo.
• A máquina está desconectada da rede e o cabo de rede está desconectado: a extremidade receptora pensa que a conexão não existe. Uma vez que a extremidade receptora tenha uma operação de gravação, a extremidade receptora descobre que a conexão não existe mais e a redefinirá . Mesmo que não haja operação de gravação, o próprio TCP possui um temporizador de manutenção de atividade embutido, que periodicamente perguntará se a outra parte ainda está lá e, caso contrário, liberará a conexão.
• Os processos terminam, as máquinas são reiniciadas e as máquinas são desligadas normalmente; o sistema operacional tem a chance de intervir. Todas as conexões podem ser fechadas normalmente (passar pelo processo de quatro ondas).
• A máquina é desligada diretamente (morte súbita); é tarde demais; o computador A não foi reiniciado ; o computador B não sabe, então ainda está conectado normalmente;
  • Quando B vai saber? Se o processo B em B tentar gravar dados na conexão e nunca receber uma resposta, ele tentará desistir após várias retransmissões. Como o processo B (camada de usuário), ele pode receber erros (falhas de gravação) da pilha TCP. (O processo B só sabe que há um problema, mas quando o problema ocorre, ele não sabe qual é o problema).
  • Se o processo B em B estiver aguardando uma mensagem da outra parte, ele está no estado de leitura. E não há mecanismo de timeout (espera ilimitada) ----" O processo B nunca saberá que há um problema com a conexão, o motivo: é impossível distinguir se a outra parte não enviou uma mensagem ou há um problema com a conexão.
  • Somente gravando dados os problemas podem ser expostos;
  • Como um processo de usuário, você deve: 1. Adicionar um tempo limite para todas as leituras 2. Adicionar um mecanismo de pulsação. Envie uma mensagem para a outra parte em intervalos regulares (intervalo fixo, intervalo não fixo) e peça que a outra parte responda.
  • Se o computador A reiniciar : se o processo B estiver lendo, o fenômeno é diferente; se o processo B gravar dados, então o processo A reinicia, fazendo com que todos os dados na memória sejam perdidos, então a conexão é perdida e depois de receber um pedaço de dados da rede Depois disso, não sei quem enviou (semelhante a amnésia), e retorno um segmento de reset (situação anormal). Para o processo B em B, após receber o reset, sei que a outra parte fechou a conexão de forma anormal, e também pode fechar a conexão e notificar o processo B..
  • Contanto que os dados sejam gravados, há uma chance de saber que a outra parte tem um problema.
  • Como desenvolvedor do processo da camada de aplicação, é melhor adicionar: 1. mecanismo de timeout de leitura 2. mecanismo de pulsação;
  • O TCP também fornece um mecanismo de heartbeat (keepalive), mas basicamente não é utilizado Motivo: em horas, configuração global.
• As máquinas dos dois lados da comunicação estão normais, e um determinado local da rede está desconectado; é tarde demais para desligar normalmente; não sei se isso está acontecendo.

4. Controle de fluxo inteligente

• O TCP é baseado na confiabilidade e o buffer de recebimento da outra parte pode acomodar os dados enviados;

4.1 Com base na capacidade de recepção da outra parte - controle de fluxo (sentido estreito) controle de fluxo

4.1.1 Como remetente, como você sabe a atual aceitabilidade da outra parte?

• Feedback um do outro, contado pelo receptor. De que maneira? ----- Deve haver uma resposta ao enviar dados, e a capacidade de recebimento pode ser enviada de volta com o segmento de resposta (segmento). Na resposta enviada pelo TCP, onde está localizada a capacidade de recebimento? ------Tamanho da janela de 16 bits (janela: a capacidade de recepção atual do receptor (o tamanho do espaço restante no buffer de recepção do receptor), para evitar confusão com outras janelas, usamos o receptor janela para consultar). Capacidade de recepção (atual) >= capacidade de recepção (no momento da resposta, os dados podem ser lidos pela rede).

4.1.2 Como remetente, como controlar a quantidade de envio

• Certifique-se de que os dados enviados desta vez <= capacidade de recebimento;
• Ao segmentar o buffer de envio (a segunda razão pela qual o TCP deve ter um buffer de envio)
  | respondido | não respondido | pendente | ocioso | para citar uma possibilidade, existem muitas possibilidades na rede, enviar buffer (fila circular)
• Aumente o mecanismo de controle de volume de envio
  • Calcule a quantidade máxima de envio de acordo com a capacidade de recebimento da outra parte (quantidade máxima de envio = capacidade de recebimento da outra parte)
  • A camada de aplicativo grava dados
    
  • Mecanismo de janela deslizante: o lado esquerdo desliza para a direita com a resposta recebida; o lado direito desliza para a direita com a resposta recebida + janela de recebimento.

4.2 Com base na qualidade da rede atual ---- controle de congestionamento

• Com base nas condições atuais da rede, o controle do volume de transmissão é realizado.

4.2.1 Como saber a situação atual da rede

• A capacidade de recebimento é o que o receptor nos diz explicitamente e é um valor exato. A capacidade de carga da rede é desconhecida. Então, algum algoritmo é usado para inferir esse valor. Use a perda de pacotes para inferir a capacidade de carga da rede.
• Use a situação de perda de pacotes para inferir a capacidade de carga da rede e use a situação de resposta para inferir a situação de perda. Se houver uma resposta toda vez que os dados forem enviados, significa que a capacidade de carga da rede é muito alta. Se cada vez que os dados são enviados, há muito poucas respostas, indicando que a qualidade é muito baixa.
• A situação de cálculo específica não será inferida por algumas perdas de pacotes para evitar jitter na avaliação da qualidade da rede. Geralmente, o número de pacotes perdidos por unidade de tempo é usado. Por exemplo, se a perda de pacotes exceder 10 vezes em 30s,
• Janela de congestionamento, o tamanho máximo de transmissão inferido com base na capacidade de carga da rede. Início lento, início rápido; quando a qualidade da rede é boa, a janela de congestionamento é muito baixa no início, o que é chamado de início lento; o crescimento exponencial, após atingir um limite, torna-se crescimento linear.
• tamanho da janela de envio = f (tamanho da janela de recebimento, tamanho da janela de congestionamento); tamanho da janela de envio = min (tamanho da janela de recebimento, tamanho da janela de congestionamento);
• Quando a qualidade da rede é relativamente ruim, a janela de congestionamento = valor inicial; crescimento exponencial --> limite de crescimento linear = janela de congestionamento cwnd/2 (a velocidade de inicialização rápida precisa ser avaliada de acordo com as condições atuais da rede; se o cwnd for relativamente grande, indica a qualidade da rede Sim, significa que a qualidade da rede já foi ruim, mas o crescimento ainda é muito rápido)

4.2.2 Como controlar o volume de envio

• É o mesmo mecanismo que o controle de fluxo

Resumir

TCP	UDP
processo a processo	processo a processo
Implemente mecanismos de confiabilidade (hard, boost)	Não confiável
conectado	não conectado
fluxo de bytes	orientado a datagramas
cara a cara	Pode ser um para um ou broadcast (um para muitos)
O desempenho em tempo real da transmissão de dados é ruim	O desempenho em tempo real é um pouco melhor

• No caso de determinar UDP, mas também deseja buscar confiabilidade? ----- Faça o mecanismo de confiabilidade na camada de aplicação, conheça as vantagens do TCP e evite suas deficiências. HTTP3 tenta usar UDP (fundo: boa qualidade de rede, HTTP3 faz alguma confiabilidade por conta própria).