Protocolos utilizados nas camadas de Rede

Prévia do material em texto

FACULDADE ESTÁCIO DE TERESINA 
 CURSO: BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO 
 DISCIPLINA: FUNDAMENTOS DE REDES DE COMPUTADORES 
 DOCENTE: KEVENY BORGES DOS SANTOS 
TURMA: 1001 SEMESTRE LETIVO: 2020.1 
 TURNO: MANHÃ 
 
Pesquise sobre as características dos tipos de Protocolos utilizados nas camadas de Rede, de acordo 
com a imagem na página 16 do Slide da Aula 02. 
 
SMTP 
Protocolo de Transferência de Correio Simples (do inglês: Simple Mail Transfer Protocol, abreviado 
SMTP) é o protocolo padrão de envio de mensagens de correio eletrônico através da Internet entre dois 
dispositivos computacionais (emissor e receptor), definido na RFC 821. 
É um protocolo simples, em texto plano, de somente de envio (semelhante a um carteiro),onde um ou 
vários destinatários de uma mensagem são especificados (e, na maioria dos casos, validados) sendo, 
depois, a mensagem transferida, por padrão via porta TCP 25 (ou 465 para conexão criptografada com 
SSL), podendo usar a porta alternativa 587. 
O SMTP por ter a função somente de envio, isto é, não permite que um usuário descarregue/solicite as 
mensagens de um servidor. Assim para a leitura é necessário o uso de um software cliente de e-mail com 
suporte ao protocolo de leitura POP ou IMAP. 
A gestão de nomes DNS de um servidor SMTP de um certo domínio, é possibilitada por sua entrada MX 
(Mail eXchange), que aponta para os servidores determinados que deverão receber as mensagens de e-
mail. 
História 
A utilização em massa do SMTP remonta aos anos 1980. Na altura, era um complemento ao UUCP, que 
era mais adequado para transferências de correio eletrônico entre máquinas sem ligação permanente. 
Por outro lado, o desempenho do SMTP aumenta se as máquinas envolvidas, emissor e receptor, se 
encontrarem ligadas permanentemente. 
O Sendmail foi um dos primeiros (se não o primeiro) agente de transporte de email a implementar SMTP. 
Em 2001, havia, pelo menos, cerca de 50 programas que implementavam SMTP como cliente (emissor) ou 
servidor (receptor). Outros servidores SMTP muito conhecidos são: exim, Postfix, Qmail, Microsoft 
Exchange Server e o Mail da Apple, disponível apenas para usuários do Mac OS ou do iOS para 
dispositivos móveis da Apple. 
Dada a especificação inicial, que contemplava apenas texto ASCII, este protocolo não é ideal para a 
transferência de arquivos (também chamados de ficheiros). Alguns standards foram desenvolvidos para 
permitir a transferência de ficheiros em formato binário através de texto simples, como o caso do MIME. 
Hoje em dia, quase todos os servidores SMTP suportam a extensão 8BITMIME. 
Para testar um servidor SMTP, com relativa facilidade, pode-se utilizar o protocolo Telnet. 
https://pt.wikipedia.org/wiki/L%C3%ADngua_inglesa
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/E-mail
https://pt.wikipedia.org/wiki/Internet
https://tools.ietf.org/html/rfc821
https://pt.wikipedia.org/wiki/Texto_plano
https://pt.wikipedia.org/wiki/Porta_(redes_de_computadores)
https://pt.wikipedia.org/wiki/Transmission_Control_Protocol
https://pt.wikipedia.org/wiki/SSL
https://pt.wikipedia.org/wiki/Software
https://pt.wikipedia.org/wiki/Cliente_de_email
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/POP3
https://pt.wikipedia.org/wiki/IMAP
https://pt.wikipedia.org/wiki/Domain_Name_System
https://pt.wikipedia.org/wiki/Mx_record
https://pt.wikipedia.org/wiki/Anos_1980
https://pt.wikipedia.org/wiki/UUCP
https://pt.wikipedia.org/wiki/Correio_eletr%C3%B4nico
https://pt.wikipedia.org/wiki/Sendmail
https://pt.wikipedia.org/wiki/Agente_de_transporte_de_email
https://pt.wikipedia.org/wiki/Exim
https://pt.wikipedia.org/wiki/Postfix_(software)
https://pt.wikipedia.org/wiki/Qmail
https://pt.wikipedia.org/wiki/Microsoft_Exchange_Server
https://pt.wikipedia.org/wiki/Microsoft_Exchange_Server
https://pt.wikipedia.org/wiki/ASCII
https://pt.wikipedia.org/wiki/Ficheiro
https://pt.wikipedia.org/wiki/Ficheiro
https://pt.wikipedia.org/wiki/Padr%C3%A3o
https://pt.wikipedia.org/wiki/MIME
https://pt.wikipedia.org/wiki/Telnet
 
Exemplo de uma sessão SMTP 
Após o estabelecimento de uma conexão entre emissor (cliente) e receptor (servidor), o exemplo seguinte 
ilustra uma sessão SMTP. Na conversação seguinte, "C:" designa as mensagens do cliente, e "S:" as 
mensagens do servidor. Na maioria dos computadores, uma conexão pode ser estabelecida usando o 
comando telnet no emissor, por exemplo: 
C: MAIL FROM:<Smith@Alpha.ARPA> 
S: 250 OK 
C: RCPT TO:<Jones@Beta.ARPA> 
S: 250 OK 
C: RCPT TO:<Green@Beta.ARPA> 
S: 550 No such user here 
C: RCPT TO:<Brown@Beta.ARPA> 
S: 250 OK 
C: DATA 
S: 354 Start mail input; end with <CRLF>.<CRLF> 
C: Blah blah blah... 
C: ...etc. etc. etc. 
C: <CRLF>.<CRLF> 
S: 250 OK 
Embora opcional, praticamente todos os clientes questionam o servidor sobre quais as extensões SMTP 
que este suporta, utilizando o comando EHLO (em oposição ao HELO ilustrado acima), e o corpo da 
mensagem (depois de DATA) segue tipicamente em formato MIME. 
Segurança e spamming 
Uma das limitações da especificação SMTP inicial é que não existe método de autenticação dos emissores. 
Como tal, foi-lhe adicionada a extensão SMTP-AUTH. 
Apesar disso, o spamming continuava a ser um problema. Alterar o SMTP extensivamente ou substituí-lo 
completamente não se torna prático, devido à forte utilização do SMTP e aos efeitos que daí podiam 
advir. O Internet Mail 2000 é uma proposta nesse sentido. 
É por essa razão que existem várias propostas para protocolos alternativos que iriam assistir a operação 
SMTP. O Grupo de Pesquisa Anti-Spam do Internet Research Task Force encontra-se a estudar várias 
propostas para se suportar a autenticação do emissor de uma forma flexível, leve e escalável. A proposta 
aparentemente mais sólida parece ser o protocolo Sender Policy Framework. 
 
FTP 
FTP é a sigla para File Transfer Protocol, um termo que, traduzido para o português, significa Protocolo 
de Transferência de Arquivos. 
https://pt.wikipedia.org/wiki/Cliente-servidor
https://pt.wikipedia.org/wiki/Servidor
https://pt.wikipedia.org/wiki/Telnet
mailto:FROM:%3CSmith@Alpha.ARPA
mailto:TO:%3CJones@Beta.ARPA
mailto:TO:%3CGreen@Beta.ARPA
mailto:TO:%3CBrown@Beta.ARPA
https://pt.wikipedia.org/wiki/MIME
https://pt.wikipedia.org/w/index.php?title=SMTP-AUTH&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Spamming
https://pt.wikipedia.org/wiki/Internet_Mail_2000
https://pt.wikipedia.org/w/index.php?title=Anti-Spam_Research_Group&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Internet_Research_Task_Force
https://pt.wikipedia.org/wiki/Sender_Policy_Framework
Ele é basicamente um tipo de conexão que permite a troca de arquivos entre dois computadores 
conectados à internet. 
Com isso, você pode enviar qualquer coisa para uma outra máquina ou armazená-los em um servidor FTP, 
ficando ela sempre disponível para o usuário acessar. 
Para que serve o FTP? 
Imagine que você faça parte de uma grande agência especializada em produção de vídeos. Ou tenha que 
criar um site de negócios com funcionalidades complexas e recursos de programação que ocupam muitas 
páginas de um script de linguagem. 
Por mais que seu computador tenha espaço em disco suficiente para armazenar tudo, é sempre 
recomendado usar algum recurso que divida o peso dos conteúdos e que eles estejam facilmente 
acessíveis para quando alguém quiser usá-los. 
E como geralmente várias pessoas trabalham em um projeto ao mesmo tempo, é comum também querer 
dividir as tarefas e compartilhar os conteúdos criados para que o andamento das atividades seja dinâmico 
e eficiente. 
O FTP serve exatamente para fazer a ponte de comunicação entre essas pessoas através dos seus 
computadores conectados à internet. Eles se comunicam através de um servidor online, que é o local onde 
essas informações ficam hospedadas e armazenadas. 
E, como curiosidade:sabia que o protocolo FTP é usado em algumas das atividades mais simples na 
internet? O simples ato de você acessar um site, por exemplo, requer que seu computador peça ao 
servidor onde ele está hospedado para que faça o download dos dados daquela página. 
É assim que você consegue visualizar todo o conteúdo disponibilizado nela. Antes disso, claro, alguém já 
havia anteriormente enviado essas informações para o servidor através do FTP, possibilitando o seu 
acesso e de qualquer outro usuário interessado. 
Como funciona o FTP? 
No processo de transferência e recebimento de arquivos pela internet, o FTP funciona em torno de dois 
protagonistas: o cliente e o servidor. 
O cliente é o computador que solicita a conexão para ter acesso aos dados já hospedados na internet. Já o 
servidor é um outro computador que atua como um ambiente virtual, recebendo a solicitação do cliente 
para a transferência dos arquivos nele hospedados. 
O computador que atua como cliente consegue acesso aos arquivos hospedados na internet através de 
um programa que se conecta ao computador que atua como servidor. É ele quem também faz a 
transferência dos arquivos do computador para o servidor. 
Já o computador que atua como servidor geralmente possui programas disponíveis para permitir a 
conexão de computadores externos a ele. Ele simplesmente autoriza a transferência dos arquivos 
armazenados nele para o cliente que está solicitando o acesso. 
Essa é a dinâmica de comunicação entre usuários de computadores que querem compartilhar dados, 
informações ou conteúdos entre si, seja para fins pessoais ou profissionais. 
Essa operação precisa ser segura. Por isso, ela sempre pede alguma autenticação para proteger as 
transferências de dados. Ou seja, é obrigatório ter um login e uma senha de acesso para transferir 
arquivos pelo FTP. 
Segue, abaixo, um resumo do passo a passo do que acontece ao usar usar um sistema FTP. 
• Você inicia um programa de FTP no seu computador que atua como cliente; 
• Você insere um usuário e senha de acesso no programa de FTP; 
• O servidor recebe o pedido de conexão, reconhece os dados e redireciona o seu acesso para o 
diretório onde estão os arquivos; 
• Você já fez o intercâmbio de dados, transferindo arquivos do seu computador para o servidor e 
vice-versa; 
• Depois de realizar todas as tarefas, a conexão entre computador e servidor é encerrada. 
O que é um servidor FTP? 
Neste artigo já usamos os termos “FTP”, “cliente” e “servidor”. E você já sabe o que cada um deles 
significa, para que servem e como interagem entre si. Chegou a hora de conhecer mais um termo: o 
próprio “servidor FTP”. 
Um servidor FTP é o servidor que oferece um serviço de acesso a um disco rígido ou servidor de arquivos 
criados através de um protocolo FTP. É ele que armazena as informações ou dados enviados por um 
usuário e que estarão acessíveis por qualquer membro da internet. 
Conseguiu sacar a diferença entre FTP e servidor FTP? Basicamente, o primeiro é um tipo de protocolo de 
transporte e entrega de arquivos. O segundo é um ambiente virtual gerenciável por um software 
instalado em qualquer computador. 
Servidores FTP são muito usados quando se trabalha com grandes volumes de dados compartilhados pela 
rede. E eles são bastante úteis para gerenciar essas informações entre diversos clientes que solicitam o 
acesso a eles. 
HTTP 
O que é HTTP 
 
HTTP é um protocolo de transferência que possibilita que as pessoas que inserem a URL 
do seu site na Web possam ver os conteúdos e dados que nele existem. A sigla vem do 
inglês Hypertext Transfer Protocol. 
Esse sistema é a base da comunicação que existe em toda a Internet em que os sites e 
conteúdos que tragam hiperlinks possam ser encontrados mais facilmente pelo público 
por meio de um clique do mouse ou um toque na tela. 
Qualquer servidor que você escolha para hospedar o site da sua empresa tem um 
programa projetado para receber solicitações HTTP. Portanto, o navegador que você 
usa é um cliente HTTP que envia solicitações constantemente ao seu servidor. 
Assim, quando um usuário acessa ou digita a URL do seu site, o navegador cria uma 
solicitação HTTP e a envia ao endereço de IP indicado pela URL. Dessa forma, o 
servidor recebe essa solicitação e envia os arquivos associados que, nada mais são, do 
que os sites que acessamos na Internet. 
Qual é a origem do HTTP? 
 
O termo HTTP foi cunhado por Ted Nelson em 1965 no Projeto Xanadu, que por sua vez 
foi inspirado numa visão dos anos 30 tida por Vannevar Bush referente ao sistema 
https://comunidade.rockcontent.com/como-inserir-hiperlinks/
https://comunidade.rockcontent.com/como-inserir-hiperlinks/
https://rockcontent.com/blog/host/
https://rockcontent.com/blog/url/
“memex” de recuperação e gestão de informação baseado em microfilmes descrito em 
seu ensaio de 1945 “As We May Think“. 
Tim Berners-Lee e sua equipe foram os responsáveis por inventar o HTTP original, 
juntamente com o HTML e a tecnologia associada para um servidor da Web e um 
navegador da Web baseado em texto. 
Berners-Lee propôs pela primeira vez o projeto “WorldWideWeb” em 1989 – hoje 
conhecido como World Wide Web. A primeira versão do protocolo tinha apenas um 
método, chamado GET, que solicitava uma página de um servidor e tinha como resposta 
a página HTML. 
A primeira versão documentada do HTTP foi liderada por Dave Raggett em 1995 e sua 
finalidade era expandir o protocolo com operações estendidas, negociação estendida, 
informação mais rica, vinculada a um protocolo de segurança que se tornou mais 
eficiente adicionando métodos e campos de cabeçalho adicionais. 
O HTTP foi rapidamente adotado pelos principais desenvolvedores de navegadores no 
início de 1996. O padrão HTTP / 1.1, como definido no RFC 2068, foi oficialmente 
lançado em janeiro de 1997, enquanto melhorias e atualizações do padrão HTTP / 1.1 
vieram em junho de 1999. 
Por fim, em 2007, o HTTPbis Working Group foi formado, em parte, para revisar e 
esclarecer a especificação HTTP / 1.1. Em junho de 2014, o WG divulgou uma 
especificação atualizada de seis partes da obsoleta RFC 2616. 
 
Como é o funcionamento do HTTP? 
 
HTTP é um protocolo baseado em texto sem conexão. Isso significa que as pessoas que 
acessam o site da sua empresa enviam solicitações a servidores que as exibem na forma 
do seu site em formato de texto, imagens, e outros tipos de mídia. Depois que a 
solicitação é atendida por um servidor, a conexão entre o usuário e o servidor é 
desconectada. 
Uma nova conexão deve ser feita para cada solicitação, isto é, cada vez que alguém 
acessa o seu site. Em suma, quando alguém digita a URL do seu site em um navegador, é 
isto que acontece: 
1. se a URL pertencer a um domínio próprio, o navegador primeiro se conecta a um 
servidor e recuperará o endereço IP correspondente ao servidor; 
2. o navegador se conecta ao servidor e envia uma solicitação HTTP para a página 
da web desejada (que, neste exemplo, é o seu site); 
3. o servidor recebe a solicitação e verifica a página desejada. Se a página existir, o 
servidor a mostrará. Se o servidor não conseguir encontrar a página solicitada, 
ele enviará uma mensagem de erro HTTP 404, ou seja, página não encontrada; 
4. o navegador, então, recebe a página de volta e a conexão é fechada; 
http://worrydream.com/refs/Bush%20-%20As%20We%20May%20Think%20(Life%20Magazine%209-10-1945).pdf
https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Protocols/HTTP.html
https://datatracker.ietf.org/wg/httpbis/charter/
https://imasters.com.br/noticia/apos-15-anos-rfc2616-que-define-o-protocolo-http1-1-e-atualizada
https://rockcontent.com/blog/erro-404/
5. caso a página exista (e é isso que se espera), o navegador a analisa e procura 
outros elementos necessários para concluir a sua exibição, o que inclui seus 
textos, imagens e afins; 
6. para cada um desses elementos, o navegador faz conexões adicionais e 
solicitações HTTPpara o servidor para cada elemento; 
7. quando o navegador terminar de carregar todos os elementos, a página será 
carregada na janela do navegador. 
 
Qual é a diferença entre HTTP e HTTPS? 
 
Cada URL que começa com HTTP usa um tipo básico de “protocolo de transferência de 
hipertexto”. Esse padrão de protocolo de rede é o que permite que navegadores e 
servidores se comuniquem através da troca de dados. 
Ou seja, por se tratar de um protocolo da camada de aplicação, o HTTP foca em 
apresentar a informação, se preocupando menos com a maneira como essa informação é 
transmitida de um ponto para outro. Isso quer dizer que o HTTP pode ser invadido e 
alterado, tornando as informações trocadas entre o site da sua empresa e a pessoa que o 
visita vulneráveis. 
É por isso que lojas virtuais não devem ter páginas construídas em HTTP, pois não são 
tão seguras para que os usuários insiram informações necessárias para a compra como 
dados pessoais e de cartão de crédito. Sites assim devem ser feitos em HTTPS. 
Porém, ao contrário do que alguns pensam, o HTTPS não é o oposto do HTTP. 
Essencialmente, ambos se referem ao mesmo “protocolo de transferência de hipertexto” 
que permite ao usuário ver na tela os dados solicitados por meio da inserção da URL. 
Contudo, o HTTPS tem como diferencial ser mais avançado e seguro. 
Em outras palavras, o HTTPS é uma extensão do HTTP. O “S” vem da palavra “secure” 
(“segurança” em inglês) e costuma ser oferecido pelo certificado SSL, oferecidos pela 
maioria dos servidores. Ele oferece uma conexão criptografada entre o servidor e o 
navegador, de maneira que o usuário possa inserir informações com mais segurança. 
É por isso que a maioria dos e-commerces têm sites em HTTPS e o próprio navegador 
informa que é seguro digitar dados pessoais caso deseje realizar alguma ação, como 
uma compra online. 
Ou seja, sem HTTPS, qualquer dado inserido no site (nome, e-mail, senhas, cartão de 
crédito, e afins) são enviados em forma de texto simples, sendo, portanto, suscetíveis a 
intercepção ou interceptação. Por isso, mesmo se o site da sua empresa for voltado 
somente a informações sobre o seu negócio, opte por tê-lo em HTTPS. 
Inclusive, desde julho de 2018, o Google passou a marcar os sites sem HTTPS como não 
seguros, e isso é letal para o seu ranqueamento orgânico, pois sites seguros têm maior 
consideração do algoritmo do Google para aparecerem nos resultados das buscas. 
https://rockcontent.com/blog/e-commerce-guia/
https://rockcontent.com/blog/ssl/
https://rockcontent.com/blog/como-migrar-seu-site-para-https/
Por fim, os sites têm outras linguagens como o XML que se trata de uma uma linguagem 
de marcação que define um conjunto de regras para codificação de documentos. 
Portanto, não deve ser confundida com o HTTP (que você já sabe o que é e como 
funciona). 
 
TELNET 
Telnet é um protocolo de rede na Internet ou redes locais para proporcionar uma facilidade de 
comunicação baseada em texto interativo bidirecional usando uma conexão de terminal virtual. Os 
dados do usuário são intercalados em banda com informações de controle Telnet em um byte de 
conexão 8-bit de dados orientado sobre o Transmission Control Protocol (TCP). 
O Telnet foi desenvolvido em 1969 com a chegada do RFC 15, prorrogado no RFC 854, e 
padronizado como Internet Engineering Task Force (IETF) Internet STD Padrão 8, um dos primeiros 
padrões da Internet. 
Definição 
 
O protocolo Telnet é um protocolo standard de Internet que permite a interface de terminais e de 
aplicações através da Internet. Este protocolo fornece as regras básicas para permitir ligar um 
cliente (sistema composto de uma afixação e um teclado) a um intérprete de comando (do lado do 
servidor). 
O Telnet existe há mais de 40 anos, muito antes de aparecer a Internet. Este sistema de transmissão 
de dados foi inventado pelas Forças Armadas Americanas para transmissão de dados entre bases 
militares. Foi disponibilizado ao público em 1977, tendo sido os radioamadores os primeiros a 
aproveitá-lo. 
Portanto, pode-se dizer que a Internet trabalha por cima do Telnet, servindo-se do seu sistema para 
funcionar. A transmissão de dados pelo Telnet utiliza software específico que os codifica, permitindo 
utilizar centenas de portas por nós definidas e reencaminha-las, para o PC que pretendemos. Se 
tivermos uma rede interna com vários pc's instalados, utilizando um router, abrimos uma porta para 
cada PC e, com o mesmo IP, os dados fluem direccionados e reencaminhados simultaneamente, sem 
qualquer problema. O utilizador que recebe dados combina com o seu correspondente a porta de 
passagem para o sistema funcionar. A máquina que envia os dados fá-lo em pacotes. Informa o 
correspondente que tem dados. Este, por sua vez, dá o OK para a transmissão. O pacote é enviado 
com a informação do número de bits que este tem. Só depois do correspondente ter informado que 
recebeu os bits todos, é que pede o segundo pacote. Se por qualquer motivo informa que os bits não 
chegaram todos, o envio do pacote é repetido. Muita coisa fica ainda por dizer sobre este sistema. O 
protocolo baseia-se numa conexão TCP para enviar dados em formato ASCII codificado em 8 bits 
entre os quais se intercalam sequências de controle para o Telnet. Fornece assim um sistema 
orientado para a comunicação, bidireccional (half-duplex), codificado em 8 bits fácil de aplicar. Com 
essa conexão é possível o acesso remoto para qualquer máquina ou equipamento que esteja sendo 
executado em modo servidor. 
Conceitos fundamentais 
 
O protocolo Telnet assenta em três conceitos fundamentais que serão explicados a seguir: 
O paradigma do terminal rede virtual (NVT, Network Virtual Terminal); O princípio de opções 
negociadas; As regras de negociação. 
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Internet
https://pt.wikipedia.org/wiki/Rede_de_%C3%A1rea_local
https://pt.wikipedia.org/wiki/Terminal_(inform%C3%A1tica)
https://pt.wikipedia.org/wiki/Transmission_Control_Protocol
https://tools.ietf.org/html/rfc15
https://tools.ietf.org/html/rfc854
https://pt.wikipedia.org/wiki/Internet_Engineering_Task_Force
https://pt.wikipedia.org/wiki/Internet
https://pt.wikipedia.org/wiki/ASCII
Terminal virtual 
 
O Telnet consiste em criar abstrações no terminal, fazendo com que qualquer cliente ou servidor se 
comunique com outro host sem conhecer as suas características. 
A comunicação de NVT, comumente chamada de Terminal Rede Virtual, fornece uma base padrão 
de: 
• Caracteres de 7 bits ASCII 
• Três caracteres de controle 
• Cinco caracteres de controle opcionais 
• Um jogo de sinais de controle básico 
Opções negociadas 
 
As opções negociadas permitem que alguns terminais proponham serviços adicionais que não são 
definidos nas especificações básicas. Esses serviços adicionais permitem a utilização de funções 
avançadas em forma de opções, fazendo iniciar os pedidos para solicitar a autorização ao sistema 
distante a ativação desse serviço ou não. Qualquer um dos lados da rede pode emitir o sinal e logo 
em seguida a outra deve responder se aceita ou não a liberação da opção requerida. Caso o pedido 
seja para desativar a opção, quem recebe a mensagem não deve recusar a mensagem, para ser 
compatível com o modelo NVT. 
Regras de negociação 
 
As regras de negociação de opções podem evitar um caso de bloqueio do pedido, pois os pedidos só 
devem ser emitidos quando acontece a mudança de um modo. Caso exista um envio para mudança 
esse deve ser inserido no fluxo de dados apenas no lugar onde tem efeito, o receptor da mensagem só 
deve adotá-lo quando não se encontrar no mesmo modo pedido. 
Especificações 
 
Este protocolo é um protocolo básico, no qual se apoiam outros protocolos da sequência TCP/IP 
(FTP, SMTP, POP3,…). As especificações de Telnet não mencionam autenticação porque o Telnet 
está totalmente separado das aplicaçõesque o utilizam (o protocolo FTP define uma sequência de 
autenticação acima do Telnet). Além disso, o protocolo Telnet é um protocolo de transferência de 
dados não seguro, o que quer dizer que os dados que veicula circulam às claras na rede (de maneira 
não codificada). Quando o protocolo Telnet é utilizado para ligar um hóspede distante à máquina na 
qual é aplicado como servidor, este protocolo é atribuído à porta 23. 
Se fizermos uma exceção às opções e às regras de negociação associadas, as especificações do 
protocolo Telnet são básicas. A transmissão de dados através de Telnet consiste unicamente em 
transmitir bytes no fluxo TCP (o protocolo Telnet precisa que os dados devem, por default - isto é, se 
nenhuma opção precisar o contrário - ser agrupados num tampão antes de serem enviados. Mais 
concretamente, isto significa que por default os dados são enviados linha por linha). Quando o byte 
255 é transmitido, o próximo deve ser interpretado como um comando. O byte 255 é assim nomeado 
IAC (Interpret As Command, traduza-se "interpretar como um comando"). Os comandos são 
descritos posteriormente. 
As especificações básicas do protocolo Telnet estão disponíveis no RFC 854, enquanto as numerosas 
opções são descritas nos RFC 855 a 861 
 
https://pt.wikipedia.org/wiki/TCP/IP
https://pt.wikipedia.org/wiki/FTP
https://pt.wikipedia.org/wiki/SMTP
https://pt.wikipedia.org/wiki/POP3
https://pt.wikipedia.org/wiki/Lista_de_portas_dos_protocolos_TCP_e_UDP
https://pt.wikipedia.org/wiki/Default_(computa%C3%A7%C3%A3o)
https://tools.ietf.org/html/rfc854
https://tools.ietf.org/html/rfc855
BGN 
O BGP [RFCs 1771,1772,1773,1774,1657] é um protocolo de roteamento entre sistemas autônomos 
(ASs), criado para uso nos roteadores principais da Internet.[1] 
O BGP foi projetado para evitar laços de roteamento em topologias arbitrárias, o mais sério problema de 
seu antecessor, o EGP (Exterior Gateway Protocol). Outro problema que o EGP não resolve - e é 
abordado pelo BGP - é o do Roteamento Baseado em Política (policy-based routing), um roteamento com 
base em um conjunto de regras não técnicas, definidas pelos Sistemas Autônomos. Sendo assim, o BGP 
melhora o EGP. 
Descrição detalhada 
 
A função primária de um sistema BGP é trocar informação de acesso à rede, inclusive informação sobre a 
lista das trajetórias dos ASs, com outros sistemas BGP. Esta informação pode ser usada para construir 
um gráfico da conectividade dos ASs a partir do qual laços de roteamento podem ser detectados e 
reforçadas as políticas de decisão com outros ASs. 
Quando um roteador se conecta à rede pela primeira vez, os roteadores BGP trocam suas tabelas de rotas 
completas. De maneira similar, quando a tabela de rotas muda, roteadores enviam a parte da tabela que 
mudou. Roteadores BGP não enviam regularmente atualizações de roteamento planejadas e as 
atualizações de rotas informam somente a trajetória ótima para uma rede. 
BGP usa uma única métrica para determinar a melhor trajetória para uma dada rede. Esta métrica 
consiste de número arbitrário que especifica o grau de preferência de um enlace em particular e é 
atribuído pelo administrador da rede. Este número pode ser baseado em qualquer critério: número de ASs 
que a trajetória cruza, estabilidade, velocidade, retardo ou custo. Os 4 tipos de mensagens BGP são: 
1. Abertura (open message) – abre uma sessão de comunicação entre BGP pares (peers) e é a primeira 
mensagem enviada de cada lado depois que uma conexão de protocolo de transporte é estabelecida; essa 
mensagem é confirmada usando uma mensagem de keep-alive enviada pelo roteador par e tem que ser 
confirmada antes das atualizações, notificações e outras mensagens de keep-alive. 
2. Atualização (update message) – é usada para informar atualizações de rotas para outros sistemas 
BGP, permitindo que os roteadores possam construir uma visão consistente da topologia da rede, usando 
o TCP para garantir uma entrega confiável; essas mensagens podem retirar rotas inviáveis (unfeasible 
routes) da tabela de roteamento e simultaneamente informar uma nova rota. 
3. Notificação (notification message) – é enviada quando uma condição de erro é detectada; elas são 
usadas para encerrar uma sessão ativa e informar a quaisquer roteadores conectados do porquê do 
encerramento da sessão. 
4. Keep-alive – notifica aos roteadores BGP pares que um dispositivo está ativo. 
Formatos do pacote 
 
1. Cabeçalho – todos os tipos de mensagens usam o cabeçalho básico mais alguns campos adicionais, 
exceto a mensagem Keep-alive que usa somente o cabeçalho básico; seus campos são: 
• Marcador (Marker) – contém um valor de autenticação que o recebedor pode verificar. 
• Comprimento (Length) – indica o comprimento total da mensagem em bytes. 
• Tipo (Type) – especifica o tipo de mensagem. 
• Dados (Data) – opcional, contém informação das camadas superiores. 
2. Abertura –fornece o critério de troca para que dois roteadores BGP estabeleçam uma relação par 
(peer relationship); seus campos são: 
https://pt.wikipedia.org/wiki/Sistema_aut%C3%B4nomo_(Internet)
https://pt.wikipedia.org/wiki/Internet
https://pt.wikipedia.org/wiki/Border_Gateway_Protocol#cite_note-1
https://pt.wikipedia.org/wiki/Exterior_Gateway_Protocol
https://pt.wikipedia.org/wiki/Exterior_Gateway_Protocol
• Versão (Version) – informa o número da versão do protocolo BGP. 
• Sistema Autônomo (Autonomous System - AS)– número do AS do enviador. 
• Hold-time – indica o número máximo de segundos que podem decorrer, sem receber uma 
mensagem, antes que o transmissor seja assumido como não funcional. 
• Identificador do BGP (BGP Identifier) – fornece um identificador BGP do transmissor (endereço 
IP) determinado na inicialização sendo idêntico para todas as interfaces locais e para todos os 
BGPs pares. 
• Comprimento dos parâmetros opcionais (Optional Parameters Length) – indica o comprimento 
do campo opcional de parâmetros (se existir). 
• Parâmetros opcionais (Optional Parameters) – contém uma lista dos parâmetros opcionais (se 
existir); atualmente somente um tipo está definido: informação de autenticação. 
3. Atualização – ao receberem um pacote de mensagem de atualização, os roteadores estarão aptos a 
adicionar ou excluir entradas específicas de suas tabelas de roteamento; seus campos são: 
• Comprimento das Rotas Inviáveis (Unfeasible Routes Length) – indica o comprimento total do 
campo de retirada de rotas ou indica que o campo não está presente. 
• Retirada de Rotas (Withdrawn Routes) – contém a lista dos prefixos dos endereços IP para as 
rotas que estão sendo retiradas de serviço. 
• Comprimento total dos atributos de trajetória (Total Path Attribute Length) – indica o 
comprimento total do campo de atributos da trajetória ou que indica que o campo não está 
presente. 
• Atributos da Trajetória (Path Attributes) – descreve as características da trajetória informada. 
• Informação de Acessibilidade da Camada de Rede (Network Layer Reachability Information) – 
contém a lista de prefixos dos endereços IP para as rotas informadas. 
4. Notificação – este pacote é usado para indicar algum tipo de condição de erro para os pares do 
roteador de origem; seus campos são: 
• Código de Erro (Error Code) – indica o tipo de erro que ocorreu. 
• Sub-código de Erro (Error Subcode)– fornece informação mais específica sobre a natureza do 
erro informado. 
• Dados do Erro (Error Data) – contém os dados baseados no código de erro e campos de sub-
código de erro; este campo é usado para diagnosticar a causa para a mensagem de notificação. 
Formato do cabeçalho 
 
Cada pacote BGP contém um cabeçalho cujo principal propósito é identificar a função do pacote em 
questão. As seguintes descrições resume a função de cada campo do cabeçalho BGP. 
• Marcador (16 bytes) – Contém um valor de autenticação que o destinatário da mensagem poderá 
prever. 
• Comprimento (2 bytes)– Indica o comprimento total da mensagem em bytes.• Tipo (1 byte) – Especifica o tipo de mensagem desnecessária,como um dos seguintes: 
o Abrir; 
o Atualizar; 
o Notificação; 
o Keep Alive (Manter vivo) 
• Dados (tamanho variável) – Contém informações da camada superior nesse campo opcional. 
A última versão do BGP, o BGP4, foi projetada para suportar os problemas causados pelo grande 
crescimento da Internet. 
OSPF 
O OSPF - Open Shortest Path First - é um protocolo de roteamento para redes que operam com 
protocolo IP; desenvolvido pelo grupo de trabalho da IGPs (Interior Gateway Protocol) da IETF (Internet 
Engineering Task Force) e descrito inicialmente em 1989 pela RFC 1131. Baseado no algoritmo SPF - 
Shortest Path First (menor rota primeiro), o OSPF foi criado para substituir o protocolo RIP empregado 
no final da década de 1980 na então Arpanet (atual Internet) e que apresentava diversos problemas e 
limitações para operar satisfatoriamente em uma rede de porte. 
Atualmente o OSPF é um dos protocolos de roteamento mais empregados, sendo suportado pela maioria 
dos roteadores, assim como por servidores que implementem os sistemas operacionais Linux e Unix. 
Versátil, o OSPF pode ser empregado tanto a redes de pequeno quanto grande porte. 
Princípio de funcionamento 
 
Embora possua inúmeros detalhes de implementação e configuração, o princípio de roteamento do OSPF 
é relativamente simples. Ao invés de manter uma tabela com todas as rotas possíveis (como faz o 
protocolo RIP), cada nó (roteador) OSPF contêm dados sobre todos os links da rede. Cada entrada da 
tabela de roteamento OSPF contém um identificador de interface, um número do link e uma distância ou 
custo (esse último pode ser atribuído pelo administrador da rede). Com todas essas informações, cada nó 
possui uma visão da topologia da rede e pode, dessa forma, descobrir sozinho qual é a melhor rota para 
um dado destino. 
Caso ocorra uma alteração num dos links de rede, os nós adjacentes avisam seus vizinhos. Esses por sua 
vez, verificam o número da mensagem ou a hora no cabeçalho do pacote OSPF para saberem se este aviso 
é novo ou velho. Se o aviso for novo, é feita a verificação da existência da entrada. Caso ela não exista, é 
adicionada à tabela de roteamento. Se a entrada já existir, são comparados os números da mensagem 
recebida com a entrada existente na tabela de roteamento. Se o número da mensagem recebida for maior 
que a entrada existente, a entrada é substituída, caso contrário, a entrada da tabela é transmitida como 
uma nova mensagem. Se os números forem iguais, o nó não executa nenhuma ação. 
Principais características 
 
Há duas características principais no OSPF. A primeira, é que se trata de um protocolo aberto, o que 
significa que suas especificações são de domínio público; suas especificações podem ser encontradas na 
RFC (Request For Comments) número 1247 e também na RFC 2328 . A segunda, é que ele se baseia no 
algoritmo SPF, também chamado de algoritmo de Dijkstra, nome de seu criador. 
OSPF é um protocolo de roteamento do tipo link-state, que envia avisos sobre o estado da conexão (link-
state advertisements, LSA) a todos os outros roteadores em uma mesma área hierárquica. Informações 
sobre interfaces ligadas, métrica usada e outras variáveis são incluídas nas LSAs. Ao mesmo tempo em 
que o roteador OSPF acumula informações sobre o estado do link, ele usa o algoritmo SPF para calcular 
a melhor rota para cada nó. 
Por ser um protocolo do tipo link-state, o OSPF difere-se do RIP e do IGRP, que são protocolos de 
roteamento baseados em vetores de distância. Os roteadores que trabalham com algoritmos de vetor de 
distância, a cada atualização, enviam toda ou parte de suas tabelas de roteamento para seus vizinhos. 
Pacote OSPF 
 
Ao contrário de outros protocolos de roteamento, o OSPF não carrega dados por meio de um protocolo 
de transporte, como o UDP (User Datagram Protocol) ou o TCP (Transmission Control Protocol). Em vez 
disso, o OSPF forma datagramas IP diretamente, empacotando-os usando o número de protocolo 89 para 
o campo "Protocolo IP" ¹. Há cinco tipos distintos de pacotes OSPF e cada um dos cinco tipos iniciam 
com um cabeçalho padrão de 24 bytes, são eles: 
1. Pacote de aviso. (Hello packet) 
https://pt.wikipedia.org/wiki/Protocolo
https://pt.wikipedia.org/wiki/Encaminhamento
https://pt.wikipedia.org/wiki/Rede
https://pt.wikipedia.org/wiki/IP
https://pt.wikipedia.org/wiki/IETF
https://tools.ietf.org/html/rfc1131
https://pt.wikipedia.org/wiki/RIP
https://pt.wikipedia.org/wiki/Arpanet
https://pt.wikipedia.org/wiki/Internet
https://pt.wikipedia.org/wiki/Roteador
https://pt.wikipedia.org/wiki/Dom%C3%ADnio_p%C3%BAblico
http://www.ietf.org/rfc/rfc1247.txt?number=1247
https://www.ietf.org/rfc/rfc2328.txt
https://pt.wikipedia.org/wiki/Algoritmo_de_dijkstra
https://en.wikipedia.org/wiki/Open_Shortest_Path_First#OSPF_messages
2. Pacote de informações do Banco de Dados (Database Description packet) 
3. Requisição de estado de link (Link State Request packet) 
4. Atualização de estado de link (Link State Update packet) 
5. Recebimento de informações de link (Link State Acknowledgment packet) 
RPC 
Chamada remota de procedimento (RPC, acrônimo de Remote Procedure Call) é uma tecnologia de 
comunicação entre processos que permite a um programa de computador chamar um procedimento em 
outro espaço de endereçamento (geralmente em outro computador, conectado por uma rede). O 
programador não se preocupa com detalhes de implementação dessa interação remota: do ponto de vista 
do código, a chamada se assemelha a chamadas de procedimentos locais. 
RPC é uma tecnologia popular para a implementação do modelo cliente-servidor de computação 
distribuída. Uma chamada de procedimento remoto é iniciada pelo cliente enviando uma mensagem para 
um servidor remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. Uma 
diferença importante entre chamadas de procedimento remotas e chamadas de procedimento locais é que, 
no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, não há nem mesmo garantia 
de que o procedimento foi invocado. 
História 
A idéia de RPC data de 1976, quando foi descrito no RFC 707. Um dos primeiros usos comerciais da 
tecnologia foi feita pela Xerox no "Courier", de 1981. A primeira implementação popular para Unix foi o 
Sun RPC (atualmente chamado ONC RPC), usado como base do Network File System e que ainda é usada 
em diversas plataformas. 
Outra implementação pioneira em Unix foi o Network Computing System (NCS) da Apollo Computer, que 
posteriormente foi usada como fundação do DCE/RPC no Distributed Computing Environment (DCE). 
Uma década depois a Microsoft adotou o DCE/RPC como base para a sua própria implementação de 
RPC, MSRPC, a DCOM foi implementada com base nesse sistema. Ainda no mesmo período da década de 
1990, o ILU da Xerox PARC e o CORBA ofereciam outro paradigma de RPC baseado em objetos 
distribuídos, com mecanismos de herança. 
De forma análoga, atualmente utiliza-se XML e JSON como linguagem de descrição de interface e HTTP 
como protocolo de rede para formar serviços web, cujas implementações incluem SOAP, REST e XML-
RPC. 
No modelo RPC, o processo de invocação ocorre de maneira similar. Uma Thread é responsável pelo 
controle de dois processos: invocador e servidor. O processo invocador primeiro manda uma mensagem 
para o processo servidor e aguarda (autobloqueia) uma mensagem de resposta. A mensagem de invocação 
contém os parâmetros do procedimento e a mensagem de resposta contém o resultado da execução do 
procedimento. Uma vez que a mensagem de resposta é recebida, os resultados da execução do 
procedimento são coletados e a execução do invocador prossegue. 
Do lado do servidor, um processo permanece em espera até a chegada de uma mensagem de invocação. 
Quando uma mensagem de invocação é recebida, o servidor extrai os parâmetros, processa-os e produz os 
resultados, que são enviadosna mensagem de resposta. O servidor, então, volta a esperar por uma nova 
mensagem de invocação. 
O Modelo 
 
O modelo de Chamada Remota de Procedimento é similar ao modelo de chamadas locais de 
procedimentos, no qual a rotina que invoca o procedimento coloca os argumentos em uma área de 
memória bem conhecida e transfere o controle para o procedimento em execução, que lê os argumentos e 
os processa. Em algum momento, a rotina retoma o controle, extraindo o resultado da execução de uma 
área bem conhecida da memória. Após isso, a rotina prossegue com a execução normal. 
https://pt.wikipedia.org/wiki/Comunica%C3%A7%C3%A3o_entre_processos
https://pt.wikipedia.org/wiki/Programa_de_computador
https://pt.wikipedia.org/wiki/Espa%C3%A7o_de_endere%C3%A7amento
https://pt.wikipedia.org/wiki/Rede_de_computadores
https://pt.wikipedia.org/wiki/Cliente-servidor
https://pt.wikipedia.org/wiki/Computa%C3%A7%C3%A3o_distribu%C3%ADda
https://pt.wikipedia.org/wiki/Computa%C3%A7%C3%A3o_distribu%C3%ADda
https://pt.wikipedia.org/wiki/1976
https://tools.ietf.org/html/rfc707
https://pt.wikipedia.org/wiki/Xerox
https://pt.wikipedia.org/wiki/1981
https://pt.wikipedia.org/wiki/Unix
https://pt.wikipedia.org/wiki/ONC_RPC
https://pt.wikipedia.org/wiki/Network_File_System
https://pt.wikipedia.org/w/index.php?title=Apollo_Computer&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=DCE/RPC&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Distributed_Computing_Environment&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Microsoft
https://pt.wikipedia.org/w/index.php?title=MSRPC&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Distributed_Component_Object_Model
https://pt.wikipedia.org/w/index.php?title=ILU&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Xerox_PARC
https://pt.wikipedia.org/wiki/CORBA
https://pt.wikipedia.org/wiki/XML
https://pt.wikipedia.org/wiki/JSON
https://pt.wikipedia.org/wiki/Linguagem_de_descri%C3%A7%C3%A3o_de_interface
https://pt.wikipedia.org/wiki/HTTP
https://pt.wikipedia.org/wiki/Protocolo_de_rede
https://pt.wikipedia.org/wiki/Servi%C3%A7o_web
https://pt.wikipedia.org/wiki/SOAP
https://pt.wikipedia.org/wiki/REST
https://pt.wikipedia.org/wiki/XML-RPC
https://pt.wikipedia.org/wiki/XML-RPC
https://pt.wikipedia.org/wiki/Thread_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Processo_(inform%C3%A1tica)
https://pt.wikipedia.org/wiki/Mem%C3%B3ria_(computador)
Nesse modelo, apenas um dos dois processos permanece ativo, em um dado instante de tempo. No entanto, 
esse modelo serve apenas de ilustração. O protocolo ONC RPC não faz restrições à implementações que 
permitam concorrência entre esses processos. Por exemplo, uma implementação poderia optar por 
chamadas assíncronas, que permitiriam ao cliente continuar com o trabalho útil, enquanto estivesse 
aguardando a 
Do lado do servidor, um processo permanece em espera até a chegada de uma mensagem de invocação. 
Quando uma mensagem de invocação é recebida, o servidor extrai os parâmetros, processa-os e produz os 
resultados, que são enviados na mensagem de resposta. O servidor, então, volta a esperar por uma nova 
mensagem de invocação. 
Nesse modelo, apenas um dos dois processos permanece ativo, em um dado instante de tempo. No entanto, 
esse modelo serve apenas de ilustração. O protocolo ONC RPC não faz restrições à implementações que 
permitam concorrência entre esses processos. Por exemplo, uma implementação poderia optar por 
chamadas assíncronas, que permitiriam ao cliente continuar com o trabalho útil, enquanto estivesse 
aguardando a mensagem de resposta. 
Uma chamada remota de procedimento difere das chamadas locais em alguns pontos: 
8. Tratamento de erros: falhas do servidor ou da rede devem ser tratadas. 
9. Variáveis globais e efeitos colaterais: Uma vez que o servidor não possui acesso ao espaço de 
endereços do cliente, argumentos protegidos não podem ser passados como variáveis globais ou 
retornados. 
10. Desempenho: chamadas remotas geralmente operam a velocidades inferiores em uma ou mais 
ordens de grandeza em relação às chamadas locais. 
11. Autenticação: uma vez que chamadas remotas de procedimento podem ser transportadas em 
redes sem segurança, autenticação pode ser necessário. 
Dessa forma, mesmo havendo diversas ferramentas que geram automaticamente o cliente e o servidor, os 
protocolos precisam ser desenvolvidos cuidadosamente. 
Semântica de Transporte 
O protocolo RPC pode ser implementado sobre diferentes tipos de protocolos de transporte, uma vez que é 
indiferente a maneira de como uma mensagem é transmitida entre os processos. É importante salientar 
que o protocolo RPC não implementa nenhuma forma de confiabilidade e que a aplicação precisa tomar 
cuidados quanto ao tipo de protocolo sobre o qual RPC opera. Caso se trate de um protocolo confiável, 
como TCP, as preocupações com confiabilidade já são resolvidas. Por outro lado, caso a camada de 
transporte seja não-confiável, como UDP, mecanismos de timeout, retransmissão e detecção de duplicatas 
devem ser implementados, uma vez que esses serviços não são providos por RPC. 
Devido à independência da camada de transporte, o protocolo RPC não modifica a semântica das 
chamadas remotas, nem seus requisitos de execução. A semântica pode ser inferida a partir da camada de 
transporte em uso. Por exemplo, considere o caso em que RPC opera sobre uma camada de transporte 
não-confiável, como UDP. Se uma aplicação retransmite mensagens de invocação RPC, após timeouts, e 
não recebe respostas, não pode inferir o número de vezes em que o procedimento foi executado. Se uma 
mensagem é recebida, ela pode inferir que o procedimento foi executado, pelo menos, uma vez. O servidor 
pode efetuar o controle do número de execuções, simplesmente gravando o número do último 
procedimento executado com êxito, evitando assim reexecuções de uma mesma chamada. 
Por outro lado, quando RPC opera sobre uma camada de transporte confiável, como TCP, a aplicação 
pode inferir, a partir de uma mensagem de resposta, que o procedimento foi executado exatamente uma 
vez. No entanto, se nenhuma mensagem de reposta é recebida, a aplicação não pode assumir que o 
procedimento não foi executado. Perceba que, mesmo usando um protocolo orientado a conexões, 
aplicações ainda requerem timeouts para identificar falhas do servidor. 
Há, ainda, muitas outras possibilidades de transporte além de datagramas e protocolos orientados a 
conexão. Por exemplo, protocolos de consulta-resposta como VMTP pode ser usado por TCP. 
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/ONC_RPC
https://pt.wikipedia.org/wiki/Concorr%C3%AAncia_(inform%C3%A1tica)
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/ONC_RPC
https://pt.wikipedia.org/wiki/Concorr%C3%AAncia_(inform%C3%A1tica)
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Software_aplicativo
https://pt.wikipedia.org/wiki/TCP
https://pt.wikipedia.org/wiki/Confiabilidade
https://pt.wikipedia.org/wiki/Camada_de_transporte
https://pt.wikipedia.org/wiki/Camada_de_transporte
https://pt.wikipedia.org/wiki/Protocolo_UDP
https://pt.wikipedia.org/w/index.php?title=VMTP&action=edit&redlink=1
Implementando RPC 
Para permitir que os servidores sejam acessados por diferentes clientes, diversos sistemas padronizados 
de RPC foram criados. A maioria deles usa uma linguagem de descrição de interface (IDL) para que 
diferentes plataformas possam chamar procedimentos. Fazendo uso de uma ferramenta como o RPCGEN, 
pode-se gerar interfaces entre cliente e servidor a partir de um arquivo IDL, os chamados stubs. Como os 
stubs são embarcados nas aplicações cliente e servidor, a RPC não é uma camada de middleware.[1] 
Na codificação, o procedimento remoto do cliente chama o stub cliente como qualquer outro 
procedimentolocal, e a implementação interna do stub cliente é responsável por iniciar o processo de 
transmissão para stub servidor, empacotando a chamada numa mensagem. Ao chegar, o stub servidor 
desempacota a mensagem e invoca localmente o procedimento, aguardando o retorno. Quando a chamada 
local retorna, o stub servidor é responsável por iniciar o processo de transmissão para o stub cliente, 
empacotando a resposta numa mensagem. Chegando, a resposta é desempacotada pelo stub cliente, sendo 
retornada localmente para o procedimento que realizou a chamada remota. 
Ao invocar o procedimento remoto, deve-se atentar que cliente e servidor podem ser plataformas 
diferentes, que representam dados de forma diferente. Nesse caso é preciso um protocolo comum de 
representação dos dados, como o XDR, ou a garantia de que ambas as partes saibam converter os dados 
para tipos de dado suportados. Por ser uma chamada remota, noutro espaço de endereçamento, deve-se 
atentar também o desafio de passar um ponteiro. Nesse caso, a implementação interna do RPC deve 
passar o conteúdo do ponteiro por cópia e restaurar a área de memória no retorno do procedimento. 
Limitações 
Diferentes implementações de chamada de procedimento remoto costumam ser incompatíveis entre si, 
ainda que existam exceções. Por isso, o uso de uma determinada implementação, provavelmente, resultará 
na dependência com o fornecedor da implementação. Essa incompatibilidade entre implementações se 
mostra também na disponibilidade de funcionalidades, no suporte a diferentes protocolos de rede e 
diferentes sistemas de arquivo. 
A maioria das implementações não suporta P2P e ou interação assíncrona entre cliente e servidor (por 
definição, a chamada remota corresponde a uma chamada local do ponto de vista da aplicação, 
bloqueante da mesma forma). A comunicação síncrona implica a disponibilidade constante tanto do 
cliente quanto do servidor. 
 
TFTP 
Trivial File Transfer Protocol (ou apenas TFTP) é um protocolo de transferência de ficheiros, muito 
simples, semelhante ao FTP. É geralmente utilizado para transferir pequenos ficheiros entre hosts numa 
rede, tal como quando um terminal remoto ou um cliente inicia o seu funcionamento, a partir do servido 
Visão geral do protocolo[editar | editar código-fonte] 
Toda a transferência começa com um pedido de leitura ou escrita de um arquivo, que sirva também para 
pedir uma conexão. Se o servidor conceder o pedido, a conexão está aberta e o arquivo é emitido em 
blocos fixos do comprimento de 512 bytes. Cada pacote contem um bloco dos dados, e deve ser 
reconhecido por um pacote do reconhecimento antes que o pacote seguinte possa ser emitido. 
Um pacote dos dados de uma terminação de menos de 512 sinais dos bytes de transferência. Se um 
pacote começar perdido na rede, o intervalo de parada pretendido da vontade do receptor e pode 
retransmitir seu último pacote (que pode ser dados ou um reconhecimento), assim fazendo com que o 
remetente do pacote perdido retransmitir esse pacote perdido. 
O remetente tem que manter apenas um pacote na mão para o retransmissor, desde que o 
reconhecimento da etapa do fechamento garante que todos os pacotes mais antigos foram recebidos. 
Observe que ambas as máquinas envolvidas em transferência estão consideradas remetentes e 
https://pt.wikipedia.org/wiki/Linguagem_de_descri%C3%A7%C3%A3o_de_interface
https://pt.wikipedia.org/w/index.php?title=RPCGEN&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Stub
https://pt.wikipedia.org/wiki/Middleware
https://pt.wikipedia.org/wiki/Chamada_de_procedimento_remoto#cite_note-1
https://pt.wikipedia.org/wiki/External_Data_Representation
https://pt.wikipedia.org/wiki/Ponteiro_(programa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Sistema_de_arquivo
https://pt.wikipedia.org/wiki/P2P
https://pt.wikipedia.org/wiki/FTP
https://pt.wikipedia.org/wiki/Host
https://pt.wikipedia.org/w/index.php?title=Trivial_File_Transfer_Protocol&veaction=edit&section=1
https://pt.wikipedia.org/w/index.php?title=Trivial_File_Transfer_Protocol&action=edit&section=1
receptores. Um emite dados e recebe reconhecimentos, o outro emite reconhecimentos e recebe dados. A 
maioria de erros causam a terminação da conexão. Um erro é sinalizado emitindo um pacote do erro. Este 
pacote não é reconhecido, e não retransmitido (isto é, um servidor ou o usuário de TFTP podem terminar 
após ter emitido uma mensagem de erro), assim que a outra extremidade da conexão não pode começá-
la. 
Consequentemente os intervalos de parada estão usados para detectar tal terminação quando o pacote 
do erro foi perdido. Os erros são causados por três tipos de eventos: o TFTP reconhece somente uma 
condição de erro, que não causa a terminação, a porta da fonte de um pacote recebido que está 
incorreto. Neste caso, um pacote do erro é emitido ao anfitrião original. Este protocolo é muito restritivo, 
a fim de simplificar a execução. Para o exemplo, os blocos fixos do comprimento fazem o alocamento 
para diante reto, e o reconhecimento da etapa do fechamento fornece o controle de fluxo e elimina a 
necessidade de requisitar novamente pacotes entrantes dos dados. 
BOOTP 
 
BOOTP 
Origem: Wikipédia, a enciclopédia livre. 
Saltar para a navegaçãoSaltar para a pesquisa 
O protocolo BOOTP (acrônimo para Bootstrap Protocol), criado em 1985 pelo IAB, foi concebido para que 
todo dispositivo de rede receba um endereço IP permanente, o chamado direcionamento estático. Esse 
protocolo permite a alocação automática de endereços de rede, mas não é capaz de alocá-los 
dinamicamente, como faz o DHCP, sucessor do BOOTP. 
BOOTP fornece serviços auxiliares para TCP/IP, tanto na camada de enlace quanto na de aplicação do 
modelo OSI. 
BOOTP vs DHCP 
O DHCP, por sua vez, fez refinamentos ao modelo BOOTP e usa os mesmos procedimentos e estruturas de 
mensagens para pedidos e entregas de endereços IP. No entanto, estendeu os campos no formato da 
mensagem para incluir instruções de configuração. O BOOTP exige que o computador envie uma segunda 
mensagem solicitando um arquivo de início com os detalhes da configuração depois de adquirir o 
endereço IP. A operação em uma fase do DHCP é considerada uma vantagem sobre o processo de duas 
fases do BOOTP. 
Ambos direcionam IPs aos computadores por tempo limitado. Após esse tempo, um computador pode 
deixar de usar a rede, mas é incapaz de devolver o endereço formalmente. Isso pode ocorrer no caso de 
uma falha, como o desligamento abrupto. O DHCP, que aloca endereços IP dinamicamente, usa um 
sistema de alocação por 8 dias, mas esse tempo geralmente é encurtado. O BOOTP foi projetado para 
outorgar endereços estáticos e os retém por até 30 dias. Isso significa que endereços perdidos 
permanecem nessa condição e levam mais tempo para serem recuperados. 
O direcionamento dinâmico é uma forma de disponibilizar um número menor de endereços de rede para 
um número maior de computadores, uma vez que endereços IPs são escassos, assumindo que nem todos 
os computadores estejam ativos ao mesmo tempo. 
Características[editar 
• Para simplificar a operação, todos os campos de dados no pacote possuem tamanho fixo. 
• Em caso de erro, o cliente é responsável pela operação de retry. 
https://pt.wikipedia.org/wiki/BOOTP#mw-head
https://pt.wikipedia.org/wiki/BOOTP#p-search
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Acr%C3%B3nimo
https://pt.wikipedia.org/wiki/IAB
https://pt.wikipedia.org/wiki/Endere%C3%A7o_IP
https://pt.wikipedia.org/wiki/Rede_de_computadores
https://pt.wikipedia.org/wiki/DHCP
https://pt.wikipedia.org/wiki/TCP
https://pt.wikipedia.org/wiki/IP
https://pt.wikipedia.org/wiki/Modelo_OSI
• Após uma falta energia em uma rede, na ocasião de seu retorno, todas as máquinas reinicializam 
automaticamente. 
• Para evitar que os servidores recebam desnecessariamente os pacotes de resposta de outros 
servidores, são usadas duas portas UDPdiferentes para o pedido e a resposta. O servidor recebe 
o pedido na porta 67 e responde na porta 68. 
• O BOOTP não oferece o arquivo de Bootstrap, mas apenas a sua localização. 
• Para carregar este arquivo, deve ser utilizado outro protocolo de transferência de arquivos 
(TFTP). 
 
 
SNMP 
 
Simple Network Management Protocol (SNMP), em português Protocolo Simples de Gerência de Rede, 
é um "protocolo padrão da Internet para gerenciamento de dispositivos em redes IP". Dispositivos que 
normalmente suportam SNMP incluem roteadores, computadores, servidores, estações de trabalho, 
impressoras, racks modernos e etc. SNMP é usado na maioria das vezes em sistemas de gerenciamento de 
rede para monitorar dispositivos ligados na rede, assim provendo condições que garantem atenção 
administrativa. SNMP é um componente do conjunto de protocolos da Internet como definido pela Internet 
Engineering Task Force (IETF). Ele consiste de um conjunto de padrões de gerenciamento de rede, 
incluindo um protocolo da camada de aplicação, um esquema de banco de dados, e um conjunto de 
objetos de dados. 
O software de gerência de redes não segue o modelo cliente-servidor convencional, pois para as 
operações GET e SET, a estação de gerenciamento se comporta como cliente e o dispositivo de rede a ser 
analisado ou monitorado se comporta como servidor, enquanto que na operação TRAP ocorre o oposto, 
pois no envio de alarmes é o dispositivo gerenciado que toma iniciativa da comunicação. Por conta disso, 
os sistemas de gerência de redes evitam os termos 'cliente' e 'servidor' e optam por usar "gerente" para a 
aplicação que roda na estação de gerenciamento e "agente" para a aplicação que roda no dispositivo de 
rede. 
Gerência de redes 
O programa gerente da rede é a entidade responsável pelo monitoramento e controle dos sistemas de 
hardware e software que compõem a rede, e o seu trabalho consiste em detectar e corrigir problemas que 
causem ineficiência (ou impossibilidade) na comunicação e eliminar as condições que poderão levar a 
que o problema volte a surgir. 
A gerência de uma rede pode não ser simples, dada sua heterogeneidade em termos de hardware e 
software, e de componentes da rede, por vezes incompatíveis. As falhas intermitentes, se não forem 
detectadas, podem afetar o desempenho da rede. Um software de gerência de redes permite ao gestor 
monitorar e controlar os componentes da sua rede. 
Componentes Básicos do SNMP 
Uma rede gerida pelo protocolo SNMP é formada por três componentes chaves: 
12. Dispositivos Geridos 
13. Agentes 
14. Sistema de Gerenciamento de Redes (NMS - Network-Management Systems) 
Um Dispositivo Gerido é um nó de rede que possui um agente SNMP instalado e se encontra numa rede 
gerida. Estes dispositivos coletam e armazenam informações de gestão e mantém estas informações 
disponíveis para sistemas NMS através do protocolo SNMP. Dispositivos geridos, também às vezes 
https://pt.wikipedia.org/wiki/Porta_(redes_de_computadores)
https://pt.wikipedia.org/wiki/Udp_(protocolo)
https://pt.wikipedia.org/wiki/TFTP
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Internet
https://pt.wikipedia.org/wiki/IP
https://pt.wikipedia.org/wiki/Roteador
https://pt.wikipedia.org/wiki/Comutador
https://pt.wikipedia.org/w/index.php?title=Sistemas_de_gerenciamento_de_rede&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Sistemas_de_gerenciamento_de_rede&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Conjunto_de_protocolos_da_Internet&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Internet_Engineering_Task_Force
https://pt.wikipedia.org/wiki/Internet_Engineering_Task_Force
https://pt.wikipedia.org/wiki/Norma_t%C3%A9cnica
https://pt.wikipedia.org/wiki/Camada_de_aplica%C3%A7%C3%A3o
https://pt.wikipedia.org/w/index.php?title=Modelo_l%C3%B3gico_de_dados&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Objeto_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Cliente-servidor
https://pt.wikipedia.org/wiki/Hardware
https://pt.wikipedia.org/wiki/Software
denominados de dispositivos de rede, podem ser routers, servidores de acesso, impressoras, 
computadores, servidores de rede, switches, dispositivos de armazenamento, dentre outros. 
Um Agente é um módulo de software de gestão de rede que fica armazenado num Dispositivo Gerido. Um 
agente tem o conhecimento das informações de gestão locais e traduz estas informações para um formato 
compatível com o protocolo SNMP. 
Um sistema NMS é responsável pelas aplicações que monitoram e controlam os Dispositivos Geridos. 
Normalmente é instalado num (ou mais que um) servidor de rede dedicado a estas operações de gestão, 
que recebe informações (pacotes SNMP) de todos os dispositivos geridos daquela rede. 
O protocolo SNMP opera na porta 161 por padrão. A porta 162 é denominada SNMPTRAP. Um trap 
SNMP é usado para reportar uma notificação ou para outros eventos assíncronos sobre o subsistema 
gerido. 
Arquitetura 
O framework SNMP consiste de: Agentes Mestres (Master Agents), Sub-agentes (Subagents) e Estações de 
Gerenciamento (Management Stations). 
Master Agent 
O Master Agent em uma rede gerenciada é, na verdade, um software sendo executado em um dispositivo 
com suporte a SNMP, por exemplo, um roteador, que interage com uma estação de gerenciamento. É o 
equivalente a um servidor, na comunicação cliente/servidor, ou a um daemon, sob o ponto de vista de 
sistemas operacionais. Os subagentes são os responsáveis por passarem informações específicas para o 
Master Agent. 
Subagent 
Os subagentes ou subagents são pequenos programas em execução no dispositivo com suporte a SNMP, 
responsáveis pelo monitoramento de recursos específicos naquele dispositivo, como por exemplo, o status 
de um link ethernet em um roteador, ou a quantidade de espaço livre em um disco de um servidor. 
Algumas características dos softwares subagentes são: 
• Coletar informações de objetos gerenciados 
• Configurar parâmetros destes objetos gerenciados 
• Responder a solicitações do software de gerência da rede 
• Gerar alarmes ou traps em determinadas situações 
Management Station 
O Gerente da Rede ou Estação de Gerenciamento ou ainda Management Station é o componente final da 
arquitetura de uma solução SNMP. Funciona como um cliente em uma comunicação cliente/servidor. 
Realiza requisições de informações aos dispositivos gerenciados, que podem ser temporárias ou através 
de comandos a qualquer tempo. E ainda é o responsável por receber alarmes gerados pelos agentes e 
gerar saídas para estes alarmes, tais como, alterar (SET) o valor de um determinado parâmetro 
gerenciado no equipamento, enviar mensagem para o celular do administrador da rede, dentre outras. 
O SNMP e o ASN.1 
O SNMP é um protocolo padrão usado para gerência de redes, que define os formatos dos pedidos que o 
Gerente envia para o Agente e os formatos das respostas que o agente retorna, assim como o significado 
exato de cada pedido e resposta. Uma mensagem SNMP é codificada com um padrão designado de ASN.1 
(do inglês: Abstract Syntax Notation.1). 
Para permitir a transferência de grandes pacotes, sem desperdiçar espaço em cada transferência, o ASN.1 
usa uma combinação de tamanho e valor para cada objeto a ser transferido. 
Comandos do SNMP 
O SNMP não define um grande número de comandos, no lugar disso define duas operações básicas: 
• GET, para obter um valor de um dispositivo 
• SET, para colocar um valor num dispositivo 
O comando que especifica uma operação de GET ou SET deve especificar o nome do objeto, que é único. 
Podemos definir objetos. No caso de um contador de erros de CRC e uma vez que o SNMP não inclui 
comandos específicos para fazer reset do contador, uma forma simples é colocar zero no contador. Neste 
caso, o Gerente faz o GET (leitura) do parâmetro desejado para determinar o estado do dispositivo. Asoperações que controlam o dispositivo são definidas como efeitos secundários de SET (alterar/gravar 
valores) em objetos. 
Especifica (na versão 1) quatro pacotes de unidades de dados (PDU): 
15. GET, usado para retirar um pedaço de informação de gerenciamento. 
16. GETNEXT, usado interativamente para retirar sequências de informação de gerenciamento. 
17. GETBULK, usado para retirar informações de um grupo de objetos. 
18. SET, usado para fazer uma mudança no subsistema gerido. 
19. TRAP, usado para reportar uma notificação ou para outros eventos assíncronos sobre o 
subsistema gerido. 
Nomes de objetos e MIB 
Todos os objetos acedidos pelo SNMP devem ter nomes únicos definidos e atribuídos. Além disso, o 
Gerente e o Agente devem acordar os nomes e significados das operações GET e SET. O conjunto de 
todos os objetos SNMP é coletivamente conhecido como MIB (do inglês: Management Information Base). 
O standard SNMP não define o MIB, mas apenas o formato e o tipo de codificação das mensagens. A 
especificação das variáveis MIB, assim como o significado das operações GET e SET em cada variável, 
são especificados por um padrão próprio. 
A definição dos objetos do MIB é feita com o esquema de nomes do ASN.1, o qual atribui a cada objeto um 
prefixo longo que garante a unicidade do nome, a cada nome é atribuído um número inteiro. Também, o 
SNMP não especifica um conjunto de variáveis, e como a definição de objetos é independente do 
protocolo de comunicação, permite criar novos conjuntos de variáveis MIB, definidos como standards, 
para novos dispositivos ou novos protocolos. Por isso, foram criados muitos conjuntos de variáveis MIB 
que correspondem a protocolos como UDP, IP, ARP, assim como variáveis MIB para hardware de rede 
como Ethernet ou FDDI, ou para dispositivos tais como bridges, switches ou impressoras. 
Aspectos de segurança 
O SNMP, até a sua versão 2, não suportava qualquer tipo de autenticação, o que o tornava vulnerável a 
uma série de ameaças de segurança. Tais ameaças incluíam o acesso e modificação não autorizados de 
dados nas MIBs dos dispositivos gerenciados. 
Essa vulnerabilidade do protocolo fez com que diversos fabricantes não implementassem a operação Set, 
reduzindo o SNMP a uma ferramenta de monitoração apenas. 
SNMPv2 e SNMPv3[editar | editar código-fonte] 
A versão 2 do SNMP é uma evolução do protocolo inicial. O SNMPv2 oferece uma boa quantidade de 
melhoramentos em relação ao SNMPv1, incluindo operações adicionais do protocolo, melhoria na 
performance, segurança, confidencialidade e comunicações Gerente-para-Gerente. A SNMPV3 inclui 
implementação na segurança ao protocolo como privacidade, autenticação e controle de acesso. 
Na prática, as implementações do SNMP oferecem suporte para as múltiplas versões (RFC 3584), 
tipicamente SNMPv1, SNMPv2c e SNMPv3. 
TCP 
 
https://pt.wikipedia.org/wiki/Management_information_base
https://pt.wikipedia.org/w/index.php?title=Simple_Network_Management_Protocol&veaction=edit&section=11
https://pt.wikipedia.org/w/index.php?title=Simple_Network_Management_Protocol&action=edit&section=11
https://tools.ietf.org/html/rfc3584
Protocolo de Controle de Transmissão (do inglês: Transmission Control Protocol, abreviado TCP) é 
um dos protocolos de comunicação, da camada de transporte da rede de computadores do Modelo OSI,[1] 
que dão suporte a rede global Internet, verificando se os dados são enviados na sequência correta e sem 
erros via rede. É complementado pelo protocolo da Internet, normalmente chamado de, TCP/IP. 
Neste protocolo da camada de transporte (camada 4 OSI) se assentam a maioria das aplicações 
cibernéticas, como o SSH, FTP, HTTP — portanto, a World Wide Web[2], devido sua versatilidade e 
robustez. O Protocolo de controle de transmissão provê confiabilidade, entrega na sequência correta e 
verificação de erros dos pacotes de dados, entre os diferentes nós da rede, para a camada de aplicação. 
Aplicações que não requerem um serviço de confiabilidade de entrega de pacotes podem se utilizar de 
protocolos mais simples como o User Datagram Protocol (UDP), que provê um serviço que enfatiza a 
redução de latência da conexão. 
Origem histórica 
Em maio de 1974, o Instituto de Engenheiros Eletricistas e Eletrônicos publicou um artigo intitulado "A 
Protocol for Packet Network Interconnection."[2] Os autores do artigo, Vinton G. Cerf e Robert Kahn 
descreveram um protocolo de interconexão para compartilhamento de recursos usando comutação de 
pacotes ao longo dos nós. Um componente central de controle deste modelo foi o Transmission Control 
Program, que incorporou os elos e serviços orientados para datagrama entre hosts. O programa de controle 
de transmissão monolítico foi dividido depois dentro de uma arquitetura modular formada de um 
Protocolo de controle de transmissão na camada orientada a conexão e o Protocolo de internet na camada 
de interconexão. O modelo se torna informalmente conhecido como TCP/IP, embora formalmente tenha 
sido chamado de Internet Protocol Suite. 
Características técnicas 
As características fundamentais do TCP são: 
• Orientado à conexão - A aplicação envia um pedido de conexão para o destino e usa a "conexão" 
para transferir dados. Portanto, se faz necessário o estabelecimento de uma conexão, por meio de 
uma sequência de passos definida no protocolo para que os dois pontos da conexão possam 
interagir entre si. 
• Handshake - Mecanismo de estabelecimento e finalização de conexão a três e quatro tempos, 
respectivamente, o que permite a autenticação e encerramento de uma sessão completa. O TCP 
garante que, no final da conexão, todos os pacotes foram bem recebidos. 
• Ponto a ponto - uma conexão TCP é estabelecida entre dois pontos. A princípio, pacotes de 
broadcasting parecem violar esse princípio, mas o que ocorre é que é enviado um pacote com um 
endereço especial em seu cabeçalho que qualquer computador em sua rede pode responder a esse 
pacote, mesmo que não esteja explicitamente endereçado pra ele. 
• Confiabilidade - O TCP usa várias técnicas para proporcionar uma entrega confiável dos pacotes 
de dados que, dependendo da aplicação, gera uma grande vantagem que tem em relação ao UDP. 
Aliado a outros fatores, o protocolo se mantém bastante difundido nas redes de computadores. O 
TCP permite a recuperação de pacotes perdidos, a eliminação de pacotes duplicados, a 
recuperação de dados corrompidos e pode recuperar a ligação em caso de problemas no sistema e 
na rede. 
• Full duplex - É possível a transferência simultânea em ambas direções (cliente-servidor) durante 
toda a sessão. Apesar disso, em alguns momentos, o protocolo necessita que algum pacotes de 
dados cheguem para que se dê o envio de outros, o que limita as transmissões. 
• Entrega ordenada - A aplicação faz a entrega ao TCP de blocos de dados com um tamanho 
arbitrário num fluxo (ou stream) de dados, tipicamente em octetos. O TCP parte estes dados em 
segmentos de tamanho especificado pelo valor MTU. Porém, a circulação dos pacotes ao longo da 
rede (utilizando um protocolo de encaminhamento, na camada inferior, como o IP) pode fazer com 
que os pacotes não cheguem ordenados. O TCP garante a reconstrução do stream no destinatário 
mediante os números de sequência. 
• Controle de fluxo - O TCP usa o campo janela ou window para controlar o fluxo. O receptor, à 
medida que recebe os dados, envia mensagens ACK (=Acknowledgement), confirmando a 
https://pt.wikipedia.org/wiki/L%C3%ADngua_inglesa
https://pt.wikipedia.org/wiki/Protocolo_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Camada_de_transporte
https://pt.wikipedia.org/wiki/Rede_de_computadores
https://pt.wikipedia.org/wiki/Modelo_OSI
https://pt.wikipedia.org/wiki/Modelo_OSI
https://pt.wikipedia.org/wiki/Transmission_Control_Protocol#cite_note-1
https://pt.wikipedia.org/wiki/Rede_de_computadores
https://pt.wikipedia.org/wiki/Internet
https://pt.wikipedia.org/wiki/Protocolo_de_Internethttps://pt.wikipedia.org/wiki/TCP/IP
https://pt.wikipedia.org/wiki/Camada_de_transporte
https://pt.wikipedia.org/wiki/SSH
https://pt.wikipedia.org/wiki/FTP
https://pt.wikipedia.org/wiki/HTTP
https://pt.wikipedia.org/wiki/World_Wide_Web
https://pt.wikipedia.org/wiki/Transmission_Control_Protocol#cite_note-:0-2
https://pt.wikipedia.org/wiki/Pacotes_de_dados
https://pt.wikipedia.org/wiki/Camada_de_aplica%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/User_Datagram_Protocol
https://pt.wikipedia.org/wiki/Lat%C3%AAncia
https://pt.wikipedia.org/wiki/Instituto_de_Engenheiros_Eletricistas_e_Eletr%C3%B4nicos
https://pt.wikipedia.org/wiki/Transmission_Control_Protocol#cite_note-:0-2
https://pt.wikipedia.org/wiki/Vint_Cerf
https://pt.wikipedia.org/wiki/Robert_Kahn
https://pt.wikipedia.org/wiki/N%C3%B3s
https://pt.wikipedia.org/wiki/Host
https://pt.wikipedia.org/wiki/Broadcasting_(rede_de_computadores)
https://pt.wikipedia.org/wiki/Protocolo_UDP
https://pt.wikipedia.org/wiki/Rede_de_computadores
https://pt.wikipedia.org/wiki/Full_duplex
https://pt.wikipedia.org/wiki/Octeto
https://pt.wikipedia.org/wiki/MTU
https://pt.wikipedia.org/wiki/Protocolo_IP
recepção de um segmento; como funcionalidade extra, estas mensagens podem especificar o 
tamanho máximo do buffer no campo (janela) do segmento TCP, determinando a quantidade 
máxima de bytes aceita pelo receptor. O transmissor pode transmitir segmentos com um número 
de bytes que deverá estar confinado ao tamanho da janela permitido: o menor valor entre sua 
capacidade de envio e a capacidade informada pelo receptor. 
• Controle de congestionamento - Baseado no número de mensagens de reconhecimentos ACK 
(=Acknowledgement) recebidos pelo remetente por unidade de tempo calculada com os dados do 
tempo de ida e de volta, ou em inglês RTT (Round Trip Travel), o protocolo prediz o quanto a 
rede está congestionada e diminui sua taxa de transmissão de modo que o núcleo da rede não se 
sobrecarregue. Esse tipo de comportamento, a princípio ineficiente, se baseia fortemente na teoria 
dos jogos - especificamente em jogos simétricos que, dentre várias coisas, difunde a ideia de que 
se ninguém recua um pouco, para dar passagem aos demais, todos perdem. 
Funcionamento do protocolo 
O protocolo TCP especifica três fases durante uma conexão: estabelecimento da ligação, transferência e 
término de ligação. O estabelecimento da ligação é feito em três passos, enquanto que o término é feito em 
quatro. Durante a inicialização são inicializados alguns parâmetros, como o Sequence Number (número de 
sequência) para garantir a entrega ordenada e robustez durante a transferência. 
Estabelecimento da conexão 
Para estabelecer uma conexão, o TCP usa um handshake (aperto de mão) de três vias. Antes que o cliente 
tente se conectar com o servidor, o servidor deve primeiro ligar e escutar a sua própria porta, para só 
depois abri-la para conexões: isto é chamado de abertura passiva. Uma vez que a abertura passiva esteja 
estabelecida, um cliente pode iniciar uma abertura ativa. Para estabelecer uma conexão, o aperto de mão de 
três vias (ou 3 etapas) é realizado: 
20. SYN: A abertura ativa é realizada por meio do envio de um SYN pelo cliente ao servidor. O 
cliente define o número de sequência de segmento como um valor aleatório A. 
21. SYN+ACK: Em resposta, o servidor responde com um SYN-ACK. O número de reconhecimento 
(acknowledgment) é definido como sendo um a mais que o número de sequência recebido, i.e. 
A+1, e o número de sequência que o servidor escolhe para o pacote é outro número aleatório B. 
22. ACK: Finalmente, o cliente envia um ACK de volta ao servidor. O número de sequência é 
definido ao valor de reconhecimento recebido, i.e. A+1, e o número de reconhecimento é definido 
como um a mais que o número de sequência recebido, i.e B+1. 
Neste ponto, o cliente e o servidor receberam um reconhecimento de conexão. As etapas 1 e 2 estabelecem 
o parâmetro (número de sequência) de conexão para uma direção e ele é reconhecido. As etapas 2 e 3 
estabelecem o parâmetro de conexão (número de sequência) para a outra direção e ele é reconhecido. Com 
isto, uma comunicação full-duplex é estabelecida. 
Tipicamente, numa ligação TCP existe aquele designado de servidor (que abre um socket e espera 
passivamente por ligações) num extremo, e o cliente no outro. O cliente inicia a ligação enviando um 
pacote TCP com a flag SYN activa e espera-se que o servidor aceite a ligação enviando um pacote 
SYN+ACK. Se, durante um determinado espaço de tempo, esse pacote não for recebido ocorre um timeout 
e o pacote SYN é reenviado. O estabelecimento da ligação é concluído por parte do cliente, confirmando a 
aceitação do servidor respondendo-lhe com um pacote ACK. 
Durante estas trocas, são trocados números de sequência iniciais (ISN) entre os interlocutores que irão 
servir para identificar os dados ao longo do fluxo, bem como servir de contador de bytes transmitidos 
durante a fase de transferência de dados (sessão). 
No final desta fase, o servidor inscreve o cliente como uma ligação estabelecida numa tabela própria que 
contém um limite de conexões, o backlog. No caso do backlog ficar completamente preenchido a ligação é 
rejeitada ignorando (silenciosamente) todos os subsequentes pacotes SYN. 
https://en.wikipedia.org/wiki/Round-trip_delay_time
https://pt.wikipedia.org/wiki/Teoria_dos_jogos
https://pt.wikipedia.org/wiki/Teoria_dos_jogos
https://pt.wikipedia.org/wiki/Jogo_da_galinha
https://pt.wikipedia.org/wiki/Handshake
https://pt.wikipedia.org/wiki/Full-duplex
https://pt.wikipedia.org/wiki/Servidor
https://pt.wikipedia.org/wiki/Socket
https://pt.wikipedia.org/wiki/Transmission_Control_Protocol#Transfer%C3%AAncia_de_dados_(sess%C3%A3o)
Transferência de dados (sessão)[editar | editar código-fonte] 
Durante a fase de transferência o TCP está equipado com vários mecanismos que asseguram a 
confiabilidade e robustez: números de sequência que garantem a entrega ordenada, código detector de 
erros (checksum) para detecção de falhas em segmentos específicos, confirmação de recepção e 
temporizadores que permitem o ajuste e contorno de eventuais atrasos e perdas de segmentos. 
Como se pode observar pelo cabeçalho TCP, existem permanentemente um par de números de sequência, 
doravante referidos como número de sequência e número de confirmação (ACKnowledgement). O emissor 
determina o seu próprio número de sequência e o receptor confirma o segmento usando como número 
ACK o número de sequência do emissor. Para manter a confiabilidade, o receptor confirma os segmentos 
indicando que recebeu um determinado número de bytes contíguos. Uma das melhorias introduzidas no 
TCP foi a possibilidade do receptor confirmar blocos fora da ordem esperada. Esta característica designa-
se por selective ACK, ou apenas SACK. 
A remontagem ordenada dos segmentos é feita usando os números de sequência, de 32 bit, que reiniciam a 
zero quando ultrapassam o valor máximo, 231-1, tomando o valor da diferença. Assim, a escolha do ISN 
torna-se vital para a robustez deste protocolo. 
O campo checksum permite assegurar a integridade do segmento. Este campo é expresso em complemento 
para um consistindo na soma dos valores (em complemento para um) da trama. A escolha da operação de 
soma em complemento para um deve-se ao fato de esta poder ser calculada da mesma forma para múltiplos 
desse comprimento - 16 bit, 32 bit, 64 bit, etc - e o resultado, quando encapsulado, será o mesmo. A 
verificação deste campo por parte do receptor é feita com a recomputação da soma em complemento para 
um que dará -0 caso o pacote tenha sido recebido intacto. 
Esta técnica (checksum), embora muito inferior a outros métodos detectores, como o CRC, é parcialmente 
compensada com a aplicação do CRC ou outros testes de integridade melhores ao nível da camada 2, logo 
abaixo do TCP, como no caso do PPP e Ethernet. Contudo, isto não torna este campo redundante: com 
efeito, estudos de tráfego revelam