Aula 05 - MPLS, TCP Udp e SCTP

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Tipos de Armazenamento; Deduplicação; ILM

. Protocolos de Roteamento – Rip, OSPF, BGP,
outros; Protocolos de Roteamento Multicast; VRRP;
Análise de Tráfego;

QoS – Intserv e Diffserv; Redes e Protocolos

Multimídia; SIP; H.323; MGCP

X.500 e LDAP; Serviços de Autenticação: Radius,
TACACS, TACACS+, Kerberus; NFS, SAMBA e

CIFS;
Olá pessoal, tudo bem?
Vamos avançar!!!
1. MPLS

O protocolo MPLS (MultiProtocol Label Switching) surgiu como
alternativa de implementação ao protocolo IP puro pelos fabricantes para
buscar garantir certa otimização no roteamento dos pacotes na rede,
com critérios de QoS.
Diversas operadoras utilizam essa tecnologia como forma de prover

capacidade de tratar tráfegos específicos para serviços específicos
demandados pelos clientes.
Diz-se que é um protocolo que implementa engenharia de tráfego, pois

ele é capaz de criar rotas virtuais específicas com o devido controle da
qualidade do enlace, como o controle da taxa de bits, podendo ser
constante ou com uma linha de base de taxa mínima.
11576980693
Sua principal característica é que o roteamento não é mais feito baseado

nos endereços IP de destino, mas sim em uma indexação nas tabelas
de roteamento que surgem a partir de rótulos inseridos à frente do
cabeçalho de rede, conforme veremos adiante.
Justamente pelo fato da inserção desse cabeçalho, muitos consideram o

protocolo MPLS de camada 2,5 , devido à inserção do cabeçalho entre
os cabeçalhos de camada 2 e 3 do modelo OSI. Percebam que esse
Prof. André Castro www.estrategiaconcursos.com.br

Pág. 3 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
modelo de camadas do MPLS como intermediário é para a tecnologia

Ethernet ou outras implementações genéricas.
O MPLS pode ser utilizado também com tecnologias ATM e FrameRelay.

Nesse caso, ele utiliza campos já existentes na estrutura dessas
tecnologias, sendo considerado, portanto, sua atuação a nível da
camada de enlace.
Por esse motivo, dizemos que o MPLS pode atuar tanto na camada
de enlace como de forma intermediária entre as camadas de rede e
enlace.

Um detalhe muito importante sobre o MPLS é o fato dele ser genérico e
universal. Ou seja, independe das camadas de enlace, rede e outras,
dependendo apenas do suporte ao protocolo MPLS por parte dos
roteadores ou comutadores diversos para o estabelecimento de uma
rede MPLS.
Entretanto, vamos esclarecer um ponto: o posicionamento do

cabeçalho MPLS depende da tecnologia utilizada na camada 2.
Como exemplo, temos que para o ATM, utiliza-se os campos VPI/VCI
para inserção do cabeçalho. Nas rede Frame Relay, utiliza-se o campo
DLCI e no caso do Ethernet, temos a inserção fora do cabeçalho da
camada 2, trazendo o contexto de protocolo de camada 2,5.
O cabeçalho padrão MPLS possui 4 campos básicos e um tamanho de 4

bytes, conforme figura a seguir:
11576980693

Pág. 4 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

•

•
!∀

#∃%&∋
(
∋
#

• )
∗
∗

•
!!+

, −∃.∋

/

0 %11
)

11576980693

No roteamento dos pacotes, que pode ser feito tanto por switch (ou outro
comutador) quanto por roteador, desde que suportem o protocolo MPLS,
conforme dito, usa-se as tabelas de índices de rótulos para
encaminhamento. Tal característica aumenta o desempenho do
encaminhamento dos pacotes, uma vez que não há mais o
processamento do cabeçalho e IP e consultas a tabelas de roteamento
tradicionais.

Pág. 5 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Esses dispositivos atualizam os rótulos a cada salto. Dessa forma,

dizemos que o rótulo MPLS tem significado local e não global.Outro
ponto a se acrescentar é a possibilidade de utilização do mesmo
identificador de rótulo em subredes diferentes de forma diferenciada, pois
cada elemento dessa “subrede” interpretará o rótulo de uma maneira
distinta conforme engenharia de tráfego específica.
É importante definir o conceito de FEC (Forwarding Equivalence Class),

pois já vi sendo cobrado em algumas provas. Esse termo pode ser
entendido facilmente quando comparamos com o circuito permanente do
modelo ATM, em que várias células utilizam o mesmo identificador de
VPI e “compartilham” o circuito virtual.

No caso do MPLS, vários pacotes podem utilizar o mesmo rótulo em
um mesmo enlace ou “subrede”, dessa forma, diz-se que eles
pertencem a mesma FEC. Acrescenta-se o fato de pertencerem à
mesma classe de serviço, logo, serão tratados pelos mesmo
critérios de priorização.
Os rótulos são acrescentados e retirados pelos roteadores de borda que

servem como ponto de entrada e saída da rede MPLS. Mais uma vez,
reforça o conceito de transparência e independência de protocolos e
redes.
A figura abaixo representa visualmente o funcionamento de uma rede

MPLS:
11576980693

Pág. 6 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Analisando ainda a figura acima, podemos extrair outros conceitos que

são cobrados em prova.
Os roteadores intermediários da rede MPLS são conhecidos como

LSR (Label Switch Router). Esses roteadores só possuem a capacidade
de interpretar os rótulos e realizar a comutação conforme já abordamos.
Já os roteadores de borda da rede, são chamados de Label Edge Router

(LER). Esses equipamentos funcionamento como pontos de entrada
e saída da rede, devendo, portanto, interpretar tanto o protocolo MPLS e
o protocolo externo à rede MPLS. Logo, estes são responsáveis pela
inserção e retirada dos rótulos, na entrada e na saída, respectivamente.
Outro termo que aparece é o Next Hop Label Forwarding Entry (NHLFE).
Em cada roteador da rede MPLS, há um mapeamento do FEC e do
próximo nó correspondente ao tráfego dessa classe. Essa entrada na
tabela de mapeamento é conhecida como NHLFE. Cada FEC deve
possuir pelo menos um mapeamento NHLFE, podendo existir
caminhos alternativos ou redundantes, ou seja, pode-se ter mais de
um NHLFE por FEC.
Além dos termos que vimos, temos ainda o LSP (Label Switch Path).
Esse nada mais é do que o caminho criado virtualmente que servirá
como rota para a definição das informações dos rótulos. Utiliza-se como
referência de definição a classificação dos pacotes de acordo com o
FEC.
O LSP pode ser determinado de duas formas:

• Hop-by-hop – Também conhecido como LSP independente. Cada
nó LSR verifica o rótulo e vincula a um FEC, definindo, portanto, o
11576980693
caminho e informando aos nós vizinhos.

• Explicit Routing – Também conhecido como LSP ordenado.
Determina-se previamente um caminho específico a ser seguido
pelo pacote de acordo com o FEC na entrada da rede.

Pág. 7 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Subindo um pouco mais na nossa análise das camadas da arquitetura

TCP/IP, verificaremos as principais tecnologias e protocolos que operam
nessa camada.
Vamos revisar alguns conceitos chaves para um melhor aprendizado a

respeito da camada de rede.
• Serviço Orientado à conexão

o Baseado no sistema de telefonia;
o Lembremos que esse tipo de serviço depende de um
estabelecimento de conexão antes do efetivo envio dos
dados;
o Estruturado em 3 etapas (Baseado na negociação de
parâmetros):
Estabelecimento da conexão;
Transferência dos Dados;
Encerramento da Conexão;
o Possui maior facilidade na implementação de recursos de
QoS;
• Serviço não Orientado à Conexão

o Baseado no sistema postal;
o Cada mensagem depende de um endereçamento completo
para chegar ao destino;
o Cada mensagem pode utilizar um caminho diferente
Por esse motivo, pode ocorrer desordenamento dos
pacotes, afetando o seu sequenciamento;
Um outro ponto para abordarmos em contraponto ao que acabamos de

ver é a confiabilidade do serviço. 11576980693
• Serviços Confiáveis
o Não perdem os dados devido a capacidade de detectar
perdas através da confirmação de recebimento das
mensagens;
o Métodos de controle de recebimento implicam em uma carga
extra, gerando overload na rede;
• Serviços não confiáveis

Pág. 9 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
o Assume-se que é mais importante dar agilidade à entrega da

informação em detrimento do controle de perdas;
Além disso, a camada de transporte é responsável pelas seguintes

características:
• Provê uma comunicação fim a fim;

• Implementa controle de fluxo;
Os principais protocolos dessa camada são o TCP e UDP, os quais

veremos detalhadamente em seguida.
11576980693

Pág. 10 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
como o controle de fluxo, assume-se que tais recursos serão

fornecidos pela camada de aplicação.
Dessa forma, o serviço UDP é definido como um protocolo da camada de

transporte sem conexão fim a fim e não confiável. Por esse motivo, o
protocolo não utiliza pacotes específicos do tipo ACK para confirmação e
não trata aspectos de ordenamento e sequenciamento dos pacotes
Como vimos anteriormente, as portas são utilizadas para definir os

serviços e vão como informação nos segmentos transmitidos. Entretanto,
a referida porta deve estar habilitada para receber requisições na
estação de destino.
Logo, tomando como exemplo um serviço de acesso WEB, veremos que

a porta padrão é a 80. Um servidor que disponibilize um serviço WEB
deverá estar com a porta 80 habilitada, ou em um conceito mais técnico,
esta porta deverá estar ABERTA (OPEN).
A combinação do endereço IP deste servidor, a porta utilizada e o

protocolo UDP utilizado definirá então o tipo de APLICAÇÃO UDP
disponibilizada.

Seguindo a estrutura de encapsulamento proposto pelo modelo OSI, o
protocolo UDP possui cabeçalho com a seguinte estrutura:
11576980693
Como podemos observar, é um cabeçalho bem enxuto com apenas 4

campos de 16 bits cada:

Pág. 13 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
• PORTA DE ORIGEM (Opcional) – Diz respeito a porta que está

sendo utilizada pelo transmissor.
• PORTA DE DESTINO – Diz respeito a porta que está sendo
utilizada pelo receptor.
• TAMANHO – Diz respeito ao tamanho de TODO o segmento UDP,
ou seja, CABEÇALHO UDP + DADOS
• CHECKSUM (Opcional) – Faz o cálculo para todo O SEGMENTO
UDP para verificação de erros pelo destinatário. O UDP NÃO
CORRIGE, APENAS DETECTA ERROS;
Então quer dizer que para determinado serviço, os campos de porta de

origem e destino são fixas?
Não pessoal. Quem envia o pacote será a origem e quem recebe será o
destino. Logo, quando um servidor responder a determinada requisição,
as numerações desses campos são invertidas, pois agora a origem será
o servidor e o destino será o cliente, assim como funciona no
endereçamento IP. ATENÇÃO NESSE RACIOCÍNIO!
Agora um detalhe. Uma vez que o a porta de origem é opcional, quer

dizer que caso este campo seja omitido, as respostas poderão ser em
qualquer outra porta ou mesmo não há necessidade de mensagens de
resposta. Esse último caso pode ser exemplificado com mensagens de
notificação de erro ou falha de dispositivos.
2.2. TCP
O protocolo TCP (Transmission Control Protocol) é o principal protocolo
11576980693
da camada de transporte e o mais complexo. Possui como característica

o fato de estabelecer uma conexão antes de enviar a informação até
o destinatário. Tal conexão é conhecida como 3-way-handshake.
Veremos com mais detalhes a seguir.
Além disso, o protocolo TCP implementa as seguintes técnicas:

• Verificação e correção de erros fim a fim;
• Recuperação de perda de pacotes e descarte de pacotes
duplicados;

Pág. 14 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
• Mensagens de confirmação de recebimento por meio de pacotes

ACK (Acknoledgement);
• Controle de fluxo através de técnicas como a janela deslizante fim
a fim;
• Transferência de dados nas duas direções (Full-Duplex);
• Possibilidade de envio de dados urgentes;
Veremos cada um desses recursos detalhadamente, até porque tem sido

cobrado não só a existência dos referidos recursos, mas também o
funcionamento de cada um deles.
Mas antes, gostaria de apresentar a vocês a estrutura do cabeçalho

TCP.

O cabeçalho TCP possui muito mais campos quando comparado com o
cabeçalho UDP. Verificamos de imediato que a implementação dos
recursos que mencionamos gera um overhead considerável na rede,
isto é, para transmitir a mesma informação no protocolo TCP e UDP,
fatalmente o TCP consumirá mais recursos de processamento, memória
dos dispositivos, além do consumo de banda com informações de
controle.
Vamos analisar os campos do cabeçalho TCP:
11576980693

Pág. 15 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
A estrutura básica do cabeçalho TCP possui 20 bytes com a

possibilidade de utilização de um campo opcional, além do padding
para completar múltiplos de 32 bits, sendo, portanto, variável.
Vamos conhecer os seus campos:
• Source Port e Destination Port – Campos de 16 bits cada que

correspondem às portas de origem e destino, respectivamente;
• Sequence Number – Determina o número de sequência de cada
segmento para controle e confirmação no destino.
• Ack Number – Corresponde ao número de sequência
ESPERADO como próxima informação. Quer dizer que os
demais segmentos anteriores já foram recebidos. Indica o
próximo octeto aguardado. Pessoal, vou repetir porque muitos
11576980693
ainda deixam passar essa informação.
Leia-se o ACK NUMBER não como o termo “eu recebi tal

numeração”, mas sim “eu espero que essa seja a próxima
informação! ”.
• Data Offset – Informa quantas palavras de 32 bits existem no
cabeçalho TCP, uma vez que existe uma parcela opcional. Indica
na prática a partir de que bloco de 32 bits iniciam os dados
propriamente ditos;

Pág. 16 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
• Reserved – Campo reservado de 6 bits. Poderá ser utilizado em

implementações futuras;
• FLAG URG – Pessoal, a sequência dessas FLAGS é importante,
uma vez que nos ajudará nas questões de Análise de tráfego.
Todas as FLAGS possuem 1 bit.
A FLAG URG pode ser utilizada para gerar interrupções na

sequência dos dados a partir da aplicação trazendo o pacote para
o primeiro lugar da fila armazenada em buffer no receptor.
• FLAG ACK – Utilizado para indicar a confirmação de recebimento
de algum segmento. Caso o valor esteja em 0, o campo Ack
Number será ignorado;
• FLAG PSH – Indica o envio imediato do pacote à camada superior
ou inferior (Receptor e Emissor, respectivamente), não
necessitando preencher o buffer para enviar blocos de informação;
• FLAG RST – Utilizado para reiniciar determinada conexão.
Importante mencionar que o RST acaba por encerrar a conexão,
dependendo do envio de bits SYN para o estabelecimento de uma
nova conexão.
• FLAG SYN – Utilizado para requisitar início de estabelecimento de
conexão;
• FLAG FIN – Utilizado para requisitar encerramento de conexão;
• WINDOW – Utilizado para indicar a quantidade de informação que
poerá ser enviada sem necessidade de confirmação, sendo
suficiente confirmar apenas o último segmento da janela;
• Checksum – Campo utilizado para detectar erros em TODO O
SEGMENTO. Contempla ainda o cálculo sobre o pseudo
cabeçalho IP da camada 3, ferindo o princípio de isolamento das
camadas do modelo OS.
11576980693
Esse pseudo cabeçalho possui: Endereço IP de origem (4bytes) e

Destino (4 bytes), número de protocolo TCP e o tamanho do
segmento TCP;
• Urgent Pointer – Utilizado para indicar o término efetivo da
mensagem a ser enviada de forma urgente, tendo como início a
mensagem com a FLAG URG ativada;
• Options – Campo opcional para possibilitar utilização de recursos
extras;
• Padding – Campo utilizado para completar blocos de 32 bits em
cada segmento;

Pág. 17 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Atenção para os campos que são considerados de controle do TCP:

Sequence Number, Acknowledgment Number, Data Offset,
ACK,Window.
A confiabilidade do TCP é obtida através da utilização dos campos

SEQUENCE NUMBER e ACK NUMBER, acrescido da FLAG ACK.
Nesse ponto, cabe uma pergunta. Em um ambiente Ethernet em que

temos o MTU de 1500 bytes, implica em dizer que esses 1500 bytes é a
parcela do conteúdo ou dados da aplicação propriamente dita? A
resposta é não.
Temos que descontar os 20 bytes em regra do cabeçalho IP e os 20

bytes do cabeçalho TCP, quando ambos forem utilizados, restando então
1460 bytes para dados da aplicação. Lembremos que o cabeçalho do IP
é variável. Lembremos que serão acoplados ainda os 18 bytes de
cabeçalho do protocolo Ethernet.

Como vimos, o TCP é um protocolo orientado à conexão. Entretanto,
para se estabelecer uma conexão, deve-se estabelecer uma rotina ou
metodologia padrão para que os dispositivos possam se entender de
forma adequada.
Esse procedimento no TCP é conhecido como 3-way-handshake. Como

o próprio nome diz, para o estabelecimento da conexão, utiliza-se uma
sequência de três mensagens, a saber: 11576980693
• Sinalização de abertura de conexão da origem – FLAG SYN;

• Confirmação de abertura e Sinalização de conexão do
destino – FLAGS SYN e ACK;
• Confirmação de abertura da conexão pela origem – FLAG
ACK;
Esse procedimento é muito bem representado pela figura a seguir:

Pág. 18 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Para o devido estabelecimento da conexão, necessariamente deverá

ocorrer a troca das três mensagens. Após o estabelecimento da
conexão, passa-se então à troca de dados propriamente ditos. Vale
observar que os pacotes deverão ser sequenciados para que os
dispositivos reconheçam os pacotes e respondam de forma adequada.
Veremos com mais detalhes o referido sequenciamento.
Avançando em nosso aprendizado, já sabemos que uma comunicação

orientada à conexão passa por três fases, sendo a última delas o
encerramento da conexão. 11576980693
O encerramento da conexão pelo TCP se dá em um procedimento de 4

mensagens, em analogia ao que vimos, em um 4-way-handshake.
Vemos a sequência das mensagens na figura abaixo:

Pág. 19 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Percebemos que a FLAG FIN é utilizada para requisitar o encerramento

da conexão. Reparem ainda que não mais é enviado um pacote com
dois tipos de flags como ocorria na abertura (SYN + ACK), utiliza-se
as FLAGS ACK e FIN em mensagens separadas. Esse modo é
conhecido como encerramento Simétrico.
Essa sequência e diferença entre o estabelecimento e encerramento já

foi cobrada algumas vezes em questões, portanto fiquemos atentos. Vale
ressaltar que há a possibilidade de encerrar essa conexão através de
três mensagens apenas, igual no estabelecimento, condensando o ACK
e FIN do destinatário.
11576980693
Outro método utilizado é o envio de um único segmento com a FLAG

RST, implicando em um encerramento imediato, sem a reinicialização da
conexão, independendo, portanto, das mensagens FIN. É conhecido
como modo Assimétrico.
Para o devido estabelecimento das conexões, utiliza-se soquetes

(sockets) nos dispositivos. Um soquete é definido a partir da
combinação:
ENDEREÇO IP + PORTA

Pág. 20 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
O estabelecimento da conexão então ocorre quando há a efetiva e

explícita conexão entre os soquetes do nó transmissor e do nó
receptor.
Quanto um dispositivo qualquer está fornecendo algum serviço na

rede, este dispositivo mantém a porta do respectivo serviço no
estado LISTENING ou LISTEN, isto é, está aceitando conexões de
clientes.
Quando há o estabelecimento da conexão, a porta passa para o

estado ESTABLISHED.

Uma das características da camada de transporte é a capacidade de
realizar segmentação dos dados recebidos das camadas superiores.
O principal objetivo dessa segmentação é evitar futuras fragmentações

pela camada de rede. Dessa forma, avalia-se o MTU suportado na rede e
partir desse valor, define-se o tamanho de cada segmento. Essa
unidade é conhecida como MSS (Max Segment Size), ou seja,
tamanho máximo do segmento.
Quando esses dois parâmetros estão alinhados, evita-se sucessivas

fragmentações de todos os segmentos recebidos pela camada de rede.
Como sabemos, na maioria das redes, temos o protocolo Ethernet, o que
nos leva a um MTU padrão de 1500 bytes. Como esses 1500 bytes
correspondem ao cabeçalho e área útil da camada de rede, na
perspectiva da camada de transporte, deve-se descontar o tamanho do
11576980693
cabeçalho da camada de rede.

Como a arquitetura TCP/IP está baseada na comutação por pacotes
através do protocolo IP, sabemos então que não há garantia de entrega
na devida ordem dos diversos pacotes, pois cada um pode seguir rotas
distintas, além da possibilidade de ocorrência de perdas.

Pág. 21 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Para que tal situação seja devidamente controlada, utiliza-se o recurso

de marcação dos pacotes com números de sequência, permitindo então
que o destinatário tenha condições de remontar a informação original.
Além disso, como vimos, utiliza-se o recurso de confirmação de
recebimento através do envio de pacotes do tipo ACK, que corresponde
à simples ativação do bit ACK com a referência do número de sequência.
Analisando um pouco mais o funcionamento do sequenciamento,

imaginemos que uma informação seja dividida em 4 partes. Cada parte
então possuirá um número de sequência. Na perspectiva do destinatário,
para cada parte que ele receber, este enviará um pacote ACK de
resposta informando que está aguardando o número de sequência
seguinte.
A ideia básica é a seguinte:

• HOST A envia mensagem com número de SEQ=X;
• O HOST B, para confirmar, manda uma mensagem com
ACK=X+1, informando que está esperando uma nova mensagem
na sequência;
• O HOST B, no mesmo pacote de resposta anterior, gera um novo
número de SEQ=Y
• O HOST A, sabendo que o pacote foi recebido, manda o pacote
seguinte com SEQ=X+1 e confirma o recebimento da resposta
com ACK=Y+1
Observemos a figura abaixo que descreve o que comentamos:
11576980693

Pág. 22 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
O host A, indica que está enviando uma mensagem de SEQ=42, e que

está esperando, a partir do ACK=79, uma mensagem de resposta com
SEQ=79.
O host B recebendo essa mensagem, verifica o pedido da mensagem de

SEQ=79 e envia. Além disso, confirma o recebimento e informa que está
esperando uma nova mensagem a partir do ACK=43.
Por fim, o host A, responde à mensagem esperada com um número de

SEQ=43 e confirma o recebimento da mensagem anterior com o
ACK=80.
Vamos agora analisar algumas possibilidades de perdas de pacote e

11576980693
verificar como o TCP se comporta.
Para toda mensagem enviada, inicia-se um timer de controle interno.

Caso esse tempo expire e não haja o recebimento da confirmação,
envia-se novamente o pacote. A figura abaixo representa esse cenário e
a ocorrência do TIMEOUT para novo envio.

Pág. 23 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Uma outra possibilidade é a perda do ACK de resposta. Neste caso,

ainda que o receptor tenha recebido a informação, a confirmação
enviada foi perdida, logo, o emissor não sabe que a informação foi
recebida, há o TIMEOUT e este envia novamente. Tem-se um caso de
duplicação da informação no destino. Nesse cenário, a informação
duplicada é descartada e envia-se novamente um ACK para avisar do
recebimento.
11576980693
O protocolo TCP é capaz de implementar o recurso de controle de fluxo

previsto na arquitetura TCP/IP a nível lógico. O recurso utilizado para tal
é fornecido através do protocolo de JANELA DESLIZANTE. A ideia é
otimizar de forma geral o envio de informação.

Pág. 24 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Suponhamos que o meio seja estável e ocorram pouquíssimas perdas.

Nesse cenário, enviar apenas um segmento por vez e aguardar a
confirmação gera uma grande perda de tempo.
Portanto, na prática, envia-se diversos segmentos com quantidade

prevista no campo WINDOW do protocolo TCP. Na figura a seguir,
verificamos o funcionamento.
Reparem que o WEB BROWSER informa uma janela de tamanho 3000.

Ou seja, pode-se enviar segmentos em que a soma deles totalize 3000.
Além disso, tem-se um ACK=1000, ou seja, espera-se o pacote de
sequência igual a 1000.
11576980693
O WEB SERVER enviar então 3 segmentos de 1000 cada, totalizando os

3000 da janela. O WEB BROWSER, recebendo todos sem erro, informa
que agora espera a SEQ=4000. Como houve um envio com sucesso,
altera-se inclusive o tamanho da janela, com vistas a otimizar ainda mais
a transmissão, sendo agora o tamanho de WINDOW=4000.
Em seguida, o WEB SERVER envia então 4 segmentos que totalizam o

tamanho de 4000. Reparem na dinamicidade do tamanho da janela em
relação ao comportamento da rede.

Pág. 25 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Entretanto, podem ocorrer erros no meio do caminho, desses segmentos

em sequência, assim, o WEB BROWSER sempre responderá com um
ACK o número de sequência esperado ainda que tenha recebido
segmentos futuros. Ao receber 3 ACKS seguidos idênticos, entende-
se que o pacote foi perdido e envia-se novamente o pacote
requisitado.
Ainda analisando esse cenário, os dois conceitos de armazenamento:
• Go-Back-N: A nomenclatura N é utilizada de acordo com o

tamanho da janela. Havendo uma perda de qualquer pacote na
sequência, todos os demais pacotes posteriores recebidos
serão descartados, obrigando o transmissor a retransmitir as
informações a partir do pacote perdido. Podemos verificar o seu
funcionamento na figura abaixo:
11576980693
Reparem que na segunda sequência da janela (3,4 e 5) há a perda do

pacote número 3, porém com o recebimento correto dos pacotes 4 e 5.
Pág. 26 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Esses dois últimos serão descartados e o transmissor deverá reenviar

todos os pacotes.
• Retransmissão Seletiva: Nesse modelo, caso haja perda, os

pacotes recebidos posteriormente, serão armazenados em buffer
aguardando a retransmissão apenas do pacote perdido.
Entretanto, caso haja a perda de um pacote intermediário, o
transmissor não enviará mensagens indefinidamente. Ele
preencherá apenas o tamanho da janela, sendo que o início da
janela estará “preso” ao recebimento do pacote perdido.
11576980693
Percebam que ainda que o destinatário tenha recebidos os pacotes

posteriores ao número dois, a janela de transmissão ficou travada,
aguardando o respectivo ACK. Essa foi a melhor figura para representar
o sequenciamento. Entretanto, há um erro na numeração do ACK, uma
vez que, como vimos, o ACK corresponde ao número do pacote
esperado e não do recebido.
Esse modelo é bastante presente nas questões de ANÁLISE DE

TRÁFEGO, e aparecer com o termo SACK (Selective ACK).

Pág. 27 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
! ∀

! ∀
No início da transmissão, o protocolo define o tamanho inicial de 1MSS
[RFC 3390] para o tamanho da Janela. Por padrão, o protocolo TCP
utiliza a técnica de partida lenta que consiste em incremento do
tamanho da janela deslizante de 1 MSS para cada ACK recebido.
De forma prática, o protocolo duplica a janela a cada conjunto de

segmentos enviados e recebidos corretamente. Caso haja uma
perda, o valor da janela é restaurado a 1 MSS e recomeça o
procedimento de incremento.
Entretanto, tem-se definido um valor que chamaremos de LIMIAR. Por

padrão, o seu valor é de 64kbytes. Para cada perda, o algoritmo redefine
esse valor de limiar como sendo a metade do tamanho da janela
deslizante corrente quando houve a perda.
Isto é, se a janela estava em 40kbytes, o novo valor do LIMIAR será de

20kbytes. Quando na operação da técnica partida lenta o tamanho da
janela atingir esse LIMIAR, o incremento passará a ser de apenas 1 MSS
e não mais de forma dobrada. Esse procedimento é conhecido como a
técnica de prevenção de congestionamento.
11576980693

Pág. 28 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Abaixo um pequeno exemplo do funcionamento da técnica de PARTIDA

LENTA:
A seguir, uma representação do funcionamento da Técnicas de

PREVENÇÂO DE CONGESTIONAMENTO:
11576980693

Pág. 29 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Reparem nos detalhes:

• Após passar o LIMIAR, incrementa-se de um em um;
• Quando houve erro (TIMEOUT), o valor corrente da janela era 40.
Logo, o novo valor do LIMIAR deverá ser a metade, ou seja, igual
a 20. Além de reiniciar o procedimento de PARTIDA LENTA;
2.3. SCTP
11576980693
Pessoal, algumas bancas já têm trazido esse protocolo nas questões.

Portanto, vamos abordá-lo de forma objetiva para não sermos pegos de
surpresa na prova.
O SCTP (Stream Control Transmission Protocol) surgiu como alternativa

intermediária aos protocolos UDP e TCP. Não é tão burocrático como o
TCP, porém implementa alguns métodos de controle, coisa que o UDP
não faz.

Pág. 30 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
É um protocolo confiável, uma vez que utiliza recurso de

reconhecimento das mensagens transmitidas. Além disso, é um
protocolo orientado a conexões com alto nível de eficiência na
transferência dos dados.
Implementa alguns novos recursos:
• MultiHoming – Múltiplos endereços IP podem ser acessados para

um mesmo destino;
• MultiStreaming – Em uma mesma conexão, pode-se ter diversos
fluxos independentes de dados;
Muitas falhas de segurança do TCP foram corrigidas em sua

implementação. Possui suporte à mobilidade em termos de transporte.
11576980693

Pág. 31 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
LISTA DE EXERCÍCIOS COMENTADOS

1. CESPE - AJ TRT17/Apoio Especializado/Tecnologia da
Informação/2013

!

∀
#
∀ ∃

3 4
!

!
2. CESPE – ANAC/Analista Administrativo – Área 5/2012

% & ∋ ( )&∗

+ &

,

∃

5

∗
6 7

11576980693

!
3. CESPE – TJ(AC)/Analista de Suporte/2012

%
∃

Pág. 32 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
4!

!
4. CESPE - AJ (STF)/Apoio Especializado/Análise de Sistemas de

Informação /2013
( )&∗ −
− .
∃

8 0 0 !∋ 0

%∋1∋4∋ ∗

)

∗
!
,
∀0 ∋ ∗
∋

9:

!
5. CESPE – Telebras/Engenheiro de Telecomunicações/2013

% &
/ &
0
12

∃

3

∃

11576980693
!
6. CESPE – TRE-GO/Técnico Judiciário – Programação de

Sistemas/2015
% ( )&∗

+ &

& ∃

Pág. 33 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

2
4
!∀ ∋
!0 ∋

!

!
7. CESPE – Banco da Amazônia/Técnico Científico – Produção e

Infraestrutura/2012

∃

∀

; 0

!
8. CESPE – TJ-RO/Analista Judiciário – Analista de Sistemas

Suporte/2012

4 ∀( )&∗
/
∗ &&/
∃
∗ + & 5 67(
∗∃
∗ 67( ∗∃
11576980693
∗ .

(. ∗
∃
∗+− 89:; ∃

!∋

∗
+

∋


Pág. 34 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
!

!

)
9

! ∀
9. CESPE – TJ-ES/Analista Judiciário – Análise de Suporte/2011
% .

+
∃

, ∃<
& #
= ∃

!

10.CESPE – Banco da Amazônia/Técnico Científico/2012
1
.∃

∋

∗
∋

6

7 !

;

−. !
!∋

) 0

;

∋0
∋
11576980693
4∋

+,−
./

!
11.CESPE – Banco da Amazônia/Técnico Científico – Tecnologia da

Informação/2010
& #
%7
%7<3
∃

Pág. 35 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

: +
<

∀=
<

∋

!

Informação/2010
+ ∃
∀
+#
(>∗
∃

!>
?−.

!

13.CESPE – TCU/Analista de Controle Externo – TI/2009
0
+ ∀∃

&, ∃

!
11576980693

14.CESPE – Banco da Amazônia/Técnico Científico – TI/2010
& + &
∃

3
& &
∃

!
Pág. 36 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

15.CESPE – TCU/Analista de Controle Externo/2009
4 ∀
& + &
<? .
≅

& + &∃

=

∀ ≅!

Α8∋

Α

Α8

!

% Α ;

(Β: ∗ 77 (9 ∗
≅
Χ .∃

5

Β
11576980693
,∋

Χ∆
(;

,

∋

! +
%∃
∀Ε<#

==∋∗4
%#
∋0 (∆

6%Χ
7

Pág. 37 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
!

%
Β Α∃

!∋
,
∀=
Φ 5∆∋
?
!
∋ <

∋
?

!

18.CESPE – TCU/AUFC/2015
( )&∗
− .
∃

<

!,

Φ

∋ ? +
<<
Γ
∗

!∀ ∗
∋

)

!
11576980693

19.CESPE - TJ TRT10/Apoio Especializado/Tecnologia da
Informação/2013
;3∋

∋

,4
!

Α

,3 ≅

∋
!
3 ∋

Pág. 38 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

,
3
! ∀0 ∋ 4
∋ ?
,
, ,

!
20.CESPE - PCF/Área 2/2013

73( ∗ &
∃

∋ 4
!
= 0

!
∗ ∋
= 0

9::0

∗

!
21.CESPE - TBN (CEF)/Tecnologia da Informação/2014

<:3∋
Γ
4
Η

2
! 30
9:∋

Η 0!!

Α=
0
(?Ι∆? Η

! ! #∃%
11576980693

8
=∋
,

:
,
∀ϑ∋

+,
∀ϑ≅
,


Pág. 39 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Α4

∋!?
, !
∀0 ∋

4
∋ ? !∀ϑΚ

+ ,

∋ ,∋ !?
! !

!
23.CESPE - ANTT/Tecnologia da Informação/Infraestrutura de

TI/2013
! !

=, :Γ

)=<8

!∋
!∋
!
+

∋

0∋

)=<8)=<8)8Λ∃

!

TI/2013
% &∆
&,
&+/ ∃

!∋
? Φ∀Λ Μ 9
11576980693

!

?

9 , 9

∀

!

TI/2013
Pág. 40 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
= −73

342∃

∋ !
Χ?Ι∆? Η
0
:

;<3

∋

! ∋ 4
Ν

!
26.CESPE - ERSPT (ANATEL)/Engenharia/2014

?.
− 73
(∗∃

2

Α :
!

∋

∋3∋

)

!
27.CESPE – TCU/ Analista de Controle Interno – TI/2008

% & 73 &
∀

# & & &
∃?# &

≅& ΕΦ?

%3Γ
Η7 6.?∃?

11576980693
−0

& ∀ 73
&

∀∃

∀ ∗
∋
,


Pág. 41 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

∀ ! Φ∀Λ

!

Α !
(?Ι∆? Η

!!
(,∋ Φ∀ΛΟ8∋

∀ϑ

; !
:

∋

,
Φ∀Λ
∋ 0

∋+∋ !

!

LISTA DE EXERCÍCIOS COMPLEMENTARES

COMENTADOS
28.FCC – TJ-AP / Analista Judiciário – Tecnologia da
Informação/2014
( )&∗
11576980693

&&
.∃1 ∀

∗ +
∃
∗

%7∃
∗

∃
Pág. 42 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗

& ∃
∗

# ∃

Α
Β

7 ∀ ∗0

∗

∋ !?! ! Γ

∋

Γ

)8;55<=;

7 ;

!

)8;55<=;

7 ,

!
)8;55<=;

7 !
∋ !
,

Ε
Ι

,
;55<=;

7 ∀

,
11576980693
!

4!
)8;55<=;

! ∀
29.FCC-TRF 1ª Região/Técnico Judiciário – Operação de

Computador/2011
4 .?3ΗΗ47
Pág. 43 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗ ∃

∗∀ =(=; ∗∃
∗+ & ∀∃
∗+ & ∃
∗ , &∃

!∋0

,∋4∋
2;∋
, !

∀0 ∋
;!

!−.!

∗
∋

!
30.FCC – MPU – Analista de Informática – Suporte Técnico/2007

Ε
∗643(6)&4 ;3∗ &
∀ Α ! &
∃
∗( ∗

&

#
&

∃
∗1Η( ) Η ∗
∀ Β
Η
11576980693
Η

#
∃
∗?∆64(? −∆6)&4;∗

−≅?∆64643
∃
∗Η643 ∀
643
643−∃

Pág. 44 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

Α Φ< 0 :

,
, ,
0 !

3 ∋ ∗

4

,

Β
7∀

:
∋
Π=

+

∋
9
, ∗

!
7 ;

∗
∋ ∋

∋

! %
! ∀0 ∋ !

0 ∗ <5∋

∋
!(∋

)

7 Α
8ΜΦ< Φ<∋

!
∀0 ∋ ,
68:
Μ
Φ Ι ,<
∆7
7;
∗

Φ<

∗<5

! &

31.FCC – TRF – 1ª Região/Técnico Judiciário – Operação de
Computador/2011
% & &Ι%?
11576980693
− ∃? −.?3ΗΗ47

∗
− &∃
∗
4ϑ
∃
∗ #
∃
∗77
∃
Pág. 45 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗ ΒΚΚ

∀ ∃

8

!

Γ
∗
Α ≅ Ν

∗
∀

,

;

Β

•

11576980693

•
!∀

#∃%&∋
(
∋
#

• )
∗
∗


Pág. 46 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
!
32.FCC – TRF – 1ª Região/Analista Judiciário – Área de Apoio

Especializado/2014
)&/
4& 7+ &,
#
≅∃1 −

.∃?

∗ / −

∋ = <?∃
∗ &
− ∃
∗+ .
∃
∗
ΑΒ
&
. & ∃
∗
2 3∃

Α
Β
7 ∀ Γ ∗
∋
,

2;
∀0 ∋ ?
!
Α8 )8;55<=;
7∀
Γ 8)∀==)∀=

∋
,
:
11576980693
)8;55<=;
7 ! ; !

<5;55<=;
7Α

8
Γ ) ,
)8;55<=;
7! )8;55<=;

!

Pág. 47 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
33.FCC – Câmara Municipal de São Paulo – SP/Consultor Técnico

Legislativo – Informática/2014
( )&∗

∃3 .#

− ∀ ≅
.∃4 −

. 73
&Ε

& ∃

∗= ∃
∗ −
∀∃
∗
+∃
∗77
∃
∗
∀ ∃

∋ ∗
67 !

∋
Π,∋
0

11576980693
;

:

2;

!

34.FCC – TRT – 5ª Região (BA)/Analista Judiciário – TI/2013
%
) /6)&4 3/643

Pág. 48 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∃% 5

0 Ε;&
∗;&∃
∗ −& &∃
∗ −&∃
∗ &∃
∗;&∃

!∋ :

, 6 7 0

!
?∆?6
7

!
35.FCC – TRE-PE/Analista Judiciário – Análise de Sistemas/2011

4
&&

∃

; ∗
∗
Α ∋ ∗
,

!
36.FCC – TRT – 12ª Região(SC)/Analista Judiciário/2013

% 73Λ. # ∀
11576980693

∀∃?
&∃∃∃∃.∃∃∃
−( ∗ + !∃∃..∃∃
, −( / ∗ + ∃

%. ..

∗12/73
∗73/.3

Pág. 49 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗37/12
∗12/7
∗73/.Μ

2

∋ 3 0

9:∋0 !∀
=∋

0
∋
9 :
!

! &
37.FCC - AJ TRE SP/Apoio Especializado/Análise de Sistemas/2012

?Ν +73Ε
∗73 +& 0 ≅ & ∃
∗ & +

& ∃
∗= &

− +
& ∃
∗3 +− 5(71∗
& 71∃
∗73 ≅& + & ∃

Α
>
7 7 ;
= !
11576980693
, ! ! ,
=

∋

∋
!
, !Γ
∋

∀

7 !

∋ 0

!
=∋ !

!

,
Γ

Pág. 50 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
7!=
0

Β

!0
6
7∗

+
∀ϑ +

8

! Ε Α =

%∃∆
∋ ,
:Β

0∋
Ε

! ,
; ,

∋

: 6Ο87

: 6Φ)87 ! ,
∋

11576980693
! ∋

38.FCC - Cons Leg (CamMun SP)/Informática/2014
> 5 73
∃∃.∃∃ −73∃1 ∃∃..∃∃∃

%. ..

∗ Ο≅ 5
∗ Ο .
Pág. 51 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗Ο &

∗ Ο&Π Π
−
∗ Ο≅ 5

! Α

:
0

!0 (?Ι∆?
Η

,∋

: ∀0
∋

∋ ! ,
Ν
∋
∋ ≅ +

∋

=

! &
39.FCC - TJ TRF4/Apoio Especializado/Tecnologia da

Informação/2014
2 #73Λ.

+
&
7Η68Η &Ε

1 −
∃1 ∀
−
+ ∀ ∃

3

11576980693
∗12∃
∗67∃
∗7∃
∗73∃
∗.3∃


Pág. 52 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Α
3∋

=∋ 0
!

! &
40.FCC – MPE-PE/Analista Ministerial – Informática/2012

3 # .
73
∗
5 −∃
∗5 &+ &
−∃
∗5 &/+ & ∃
∗−
−
∃
∗ 0
&
/ ∃

=
=∋

9
: !

! <∋ ! 3 0
Γ ∋ !

∋ ! :

! ∋
41.FCC – TRE-CE/Técnico Judiciário – Programação de

Sistemas/2012
11576980693
73 12 Ε

∗73 + & 12 5
%3Γ
0
0 ∃
∗73
&

∆77 67
0 +
∃

Pág. 53 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗12 − &

# 12 ∃
∗73 & !
& 0 12 &
& ∃
∗12 0 //
& &
& &∃

2
,0

=3
7 ∀
!

∋ 3 9
,

)8;55<=;
7
! 0
−. 5

:
!

!

9Γ

=0

∋ 4

!
;55<=;
7! ! ∋0
=

)8;55<=;
7 Θ

∋ = 0
, ∋ 3)8;55<=;
7 !∋ 3 0
Γ

!

)8;55<=;

11576980693
! ∋

42.FCC – TCE-GO/Técnico de Controle Externo – TI/2009
∃∃.∃∃
0
∀ & ∃?

+
. ∃?
∃∃..∃∃∃
&
&
&
) ∃
Pág. 54 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
% & + −
&
∃∃...∃∃

& # &
5

∃∃.<∃∃
/ ,
− & 0
0 ∃

%− ∃∃<∃∃
+
& 0 &
#
∃4 +
&
(∗
+∃

∀

&
)

∃?

%3 # + %3%
∃

...
.< <Ε
∗73/12/.
∗73/./%Η
∗12/./%Η
∗∆23/%Η/.3
∗.3/∆23/%Η 11576980693

= −

# − &
∃%
.
73Λ.

73Λ.∃ +
..
?
∆7767∃

Pág. 55 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
4 &

73 , −
0
12 , −
+ ∃2 ... .<∃

≅
5,
+ 0 ∀
∀ ∃4.

<∃

! &

43.FCC – TRE-RN/Técnico Judiciário – Programação de
Sistemas/2011
? 73Λ.
) %
& ∃
Ε
∗7312∃
∗12%Η∃
∗73.∃
∗%Η.∃
∗%Η.3∃

= Π ∋
Π
9 =Ρ)0

;

=3
11576980693

3
! Φ

! =Ρ)0 ∋ 0

! &
44.FCC – TJ-PA/Analista Judiciário – TI/2009

Pág. 56 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
2 73Λ.

,

∗12
7
%Η ∆∃
∗∆77
7
∆ 2?∃
∗∆77
7
12 %Η∃
∗12
∆77
∆ 2?∃
∗12
73
. %Η∃

∋

∋
≅

3

!0
Ε30

∋ ∋ !
>

! ∋
45.FCC – TRT – 2ªRegião (SP)/Analista Judiciário – TI/2008

−

+
0 −
Θ5 &
73
& ∃7/
∗12∃
∗.∃
∗7∃
∗∃
∗7 ∃

11576980693
= ∋
Π =

3 !

− = ! ,
.∋ 0

=Ρ)=

! &
46.FCC – MPE – PB/ Administrador de Redes/2015

Pág. 57 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
Quando um processo A envia uma mensagem a um processo B

utilizando o protocolo UDP, eles identificam indiretamente um ao outro
usando um identificador abstrato normalmente chamado de porta. No
cabeçalho UDP há uma Porta Origem e uma Porta Destino,
a) ambas com 16 bits de extensão, que significa que há até 64 K portas
possíveis.
b) ambas com 8 bits de extensão, que significa que há 256 portas
possíveis.
c) respectivamente, com 24 e 32 bits de extensão.
d) que garantem a entrega do datagrama UDP.
e) ambas com 32 bits de extensão, que significa que há 232 portas
possíveis.

3∋
Β

3 ∋

0&Σ

!
,
0
≅ Σ11(1∋
! 4 ,

∋
11576980693
∋ ,
! ∋ ∋ !∋ !
!0 Σ1ϑ

! &

Pág. 58 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
( )&∗ −

− .
∃
5. CESPE – Telebras/Engenheiro de Telecomunicações/2013

% &
/ &
0
12

∃
6. CESPE – TRE-GO/Técnico Judiciário – Programação de

Sistemas/2015
% ( )&∗

+ &

& ∃
7. CESPE – Banco da Amazônia/Técnico Científico – Produção e

Infraestrutura/2012

∃
8. CESPE – TJ-RO/Analista Judiciário – Analista de Sistemas

Suporte/2012

4 ∀( )&∗
/
∗ &&/
∃
∗ + & 5 67(
11576980693
∗∃

∗ 67( ∗∃
∗ .
(. ∗
∃
∗+− 89:; ∃
9. CESPE – TJ-ES/Analista Judiciário – Análise de Suporte/2011

Pág. 60 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
% .

+
∃

10.CESPE – Banco da Amazônia/Técnico Científico/2012
1
.∃

Informação/2010
& #
%7
%7<3
∃

Informação/2010
+ ∃
∀
+#
(>∗
∃

0
+ ∀∃

14.CESPE – Banco da Amazônia/Técnico Científico – TI/2010
& + &
∃

15.CESPE – TCU/Analista de Controle Externo/2009
11576980693
4 ∀

& + &
<? .
≅

& + &∃

% Α ;

(Β: ∗ 77 (9 ∗
≅
Χ .∃

Pág. 61 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

%
Β Α∃

18.CESPE – TCU/AUFC/2015
( )&∗
− .
∃

19.CESPE - TJ TRT10/Apoio Especializado/Tecnologia da
Informação/2013
;3∋

∋

,4
!
20.CESPE - PCF/Área 2/2013

73( ∗ &
∃

<:3∋
Γ
4
Η

8
=∋
,

:
,
∀ϑ∋

+,
∀ϑ≅
,

11576980693
TI/2013
! !

=, :Γ

)=<8

TI/2013
% &∆
&,
&+/ ∃
Pág. 62 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

TI/2013
= −73

342∃
26.CESPE - ERSPT (ANATEL)/Engenharia/2014

?.
− 73
(∗∃
27.CESPE – TCU/ Analista de Controle Interno – TI/2008

% & 73 &
∀

# & & &
∃?# &

≅& ΕΦ?

%3Γ
Η7 6.?∃?

−0
& ∀ 73
&

∀∃

11576980693
LISTA DE EXERCÍCIOS COMPLEMENTARES

28.FCC – TJ-AP / Analista Judiciário – Tecnologia da
Informação/2014
( )&∗

&&
.∃1 ∀

Pág. 63 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗ +

∃
∗

%7∃
∗

∃
∗
& ∃
∗

# ∃
29.FCC-TRF 1ª Região/Técnico Judiciário – Operação de

Computador/2011
4 .?3ΗΗ47
∗ ∃
∗∀ =(=; ∗∃
∗+ & ∀∃
∗+ & ∃
∗ , &∃
30.FCC – MPU – Analista de Informática – Suporte Técnico/2007

Ε
∗643(6)&4 ;3∗ &
∀ Α ! &
∃
∗( ∗
11576980693

&

#
&

∃
∗1Η( ) Η ∗
∀ Β
Η
Η
#
∃

Pág. 64 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗?∆64(? −∆6)&4;∗

−≅?∆64643
∃
∗Η643 ∀

31.FCC – TRF – 1ª Região/Técnico Judiciário – Operação de
Computador/2011
% & &Ι%?
− ∃? −.?3ΗΗ47

∗
− &∃
∗
4ϑ
∃
∗ #
∃
∗77
∃
∗ ΒΚΚ

32.FCC – TRF – 1ª Região/Analista Judiciário – Área de Apoio

Especializado/2014
)&/
4& 7+ &,
#
≅∃1 −

.∃?

11576980693
∗ / −

∋ = <?∃
∗ &
− ∃
∗+ .
∃
∗
ΑΒ
&
. & ∃
∗
2 3∃
Pág. 65 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗

33.FCC – Câmara Municipal de São Paulo – SP/Consultor Técnico
Legislativo – Informática/2014
( )&∗

∃3 .#

− ∀ ≅
.∃4 −

. 73
&Ε

& ∃

∗= ∃
∗ −
∀∃
∗
+∃
∗77
∃
∗
∀ ∃

∋ ∗
67 !

11576980693

∋
Π,∋
0

;
:

2;

!

34.FCC – TRT – 5ª Região (BA)/Analista Judiciário – TI/2013

Pág. 66 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
%

) /6)&4 3/643
∃% 5
0 Ε;&
∗;&∃
∗ −& &∃
∗ −&∃
∗ &∃
∗;&∃
35.FCC – TRE-PE/Analista Judiciário – Análise de Sistemas/2011

4
&&

∃
36.FCC – TRT – 12ª Região(SC)/Analista Judiciário/2013

% 73Λ. # ∀

∀∃?
&∃∃∃∃.∃∃∃
−( ∗ + !∃∃..∃∃
, −( / ∗ + ∃

%. ..

∗12/73
∗73/.3
∗37/12
∗12/7 11576980693
∗73/.Μ
37.FCC - AJ TRE SP/Apoio Especializado/Análise de Sistemas/2012

?Ν +73Ε
∗73 +& 0 ≅ & ∃
Pág. 67 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗ & +

& ∃
∗= &

− +
& ∃
∗3 +− 5(71∗
& 71∃

38.FCC - Cons Leg (CamMun SP)/Informática/2014
> 5 73
∃∃.∃∃ −73∃1 ∃∃..∃∃∃

%. ..

∗ Ο≅ 5
∗ Ο .
∗Ο &
∗ Ο&Π Π
−
∗ Ο≅ 5
39.FCC - TJ TRF4/Apoio Especializado/Tecnologia da

Informação/2014
2 #73Λ.

+
&
7Η68Η &Ε

1 −
11576980693
∃1 ∀

−
+ ∀ ∃

3

∗12∃
∗67∃
∗7∃
∗73∃
∗.3∃
Pág. 68 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
40.FCC – MPE-PE/Analista Ministerial – Informática/2012

3 # .
73
∗
5 −∃
∗5 &+ &
−∃
∗5 &/+ & ∃
∗−
−
∃
∗ 0
&
/ ∃
41.FCC – TRE-CE/Técnico Judiciário – Programação de

Sistemas/2012
73 12 Ε

∗73 + & 12 5
%3Γ
0
0 ∃
∗73
&

∆77 67
0 +
∃
∗12 − &
# 12 ∃
∗73 & !
& 0 12 &
& ∃
∗12 0 //
11576980693
& &

42.FCC – TCE-GO/Técnico de Controle Externo – TI/2009
∃∃.∃∃
0
∀ & ∃?

+
. ∃?
∃∃..∃∃∃
&

Pág. 69 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
&

&
) ∃
% & + −
&
∃∃...∃∃

& # &
5

∃∃.<∃∃
/ ,
− & 0
0 ∃

%− ∃∃<∃∃
+
& 0 &
#
∃4 +
&
(∗
+∃

∀

&
)

∃?

%3 # + %3%
∃

...
.< <Ε
∗73/12/.
∗73/./%Η
∗12/./%Η 11576980693
∗∆23/%Η/.3
∗.3/∆23/%Η

43.FCC – TRE-RN/Técnico Judiciário – Programação de
Sistemas/2011
? 73Λ.
) %
& ∃
Ε
∗7312∃
Pág. 70 de 72

–

André Castro

! ∀#∃
%

& ∋
(

∃
) ∗
∗12%Η∃
∗73.∃
∗%Η.∃
∗%Η.3∃
44.FCC – TJ-PA/Analista Judiciário – TI/2009

2 73Λ.
,

∗12
7
%Η ∆∃
∗∆77
7
∆ 2?∃
∗∆77
7
12 %Η∃
∗12
∆77
∆ 2?∃
∗12
73
. %Η∃
45.FCC – TRT – 2ªRegião (SP)/Analista Judiciário – TI/2008

−

+
0 −
Θ5 &
73
& ∃7/
∗12∃
∗.∃
∗7∃
∗∃
∗7 ∃
46.FCC – MPE – PB/ Administrador de Redes/2015

Quando um processo A envia uma mensagem a um processo B
11576980693
utilizando o protocolo UDP, eles identificam indiretamente um ao outro

usando um identificador abstrato normalmente chamado de porta. No
cabeçalho UDP há uma Porta Origem e uma Porta Destino,
a) ambas com 16 bits de extensão, que significa que há até 64 K portas
possíveis.
b) ambas com 8 bits de extensão, que significa que há 256 portas
possíveis.
c) respectivamente, com 24 e 32 bits de extensão.
d) que garantem a entrega do datagrama UDP.

Pág. 71 de 72

Aula 05 - MPLS, TCP Udp e SCTP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 05 - MPLS, TCP Udp e SCTP

Enviado por

Direitos autorais:

Formatos disponíveis



Tipos de Armazenamento; Deduplicação; ILM

  QoS – Intserv e Diffserv; Redes e Protocolos

Olá pessoal, tudo bem?

Diversas operadoras utilizam essa tecnologia como forma de prover

Diz-se que é um protocolo que implementa engenharia de tráfego, pois

Sua principal característica é que o roteamento não é mais feito baseado

Justamente pelo fato da inserção desse cabeçalho, muitos consideram o

Prof. André Castro www.estrategiaconcursos.com.br

modelo de camadas do MPLS como intermediário é para a tecnologia

O MPLS pode ser utilizado também com tecnologias ATM e FrameRelay.

Entretanto, vamos esclarecer um ponto: o posicionamento do

O cabeçalho padrão MPLS possui 4 campos básicos e um tamanho de 4

Prof. André Castro www.estrategiaconcursos.com.br

Esses dispositivos atualizam os rótulos a cada salto. Dessa forma,

É importante definir o conceito de FEC (Forwarding Equivalence Class),

Os rótulos são acrescentados e retirados pelos roteadores de borda que

A figura abaixo representa visualmente o funcionamento de uma rede

Prof. André Castro www.estrategiaconcursos.com.br

Analisando ainda a figura acima, podemos extrair outros conceitos que

Os roteadores intermediários da rede MPLS são conhecidos como

Já os roteadores de borda da rede, são chamados de Label Edge Router

O LSP pode ser determinado de duas formas:

caminho e informando aos nós vizinhos.

Prof. André Castro www.estrategiaconcursos.com.br

Subindo um pouco mais na nossa análise das camadas da arquitetura

Vamos revisar alguns conceitos chaves para um melhor aprendizado a

• Serviço Orientado à conexão

• Serviço não Orientado à Conexão

Um outro ponto para abordarmos em contraponto ao que acabamos de

• Serviços não confiáveis

Prof. André Castro www.estrategiaconcursos.com.br

o Assume-se que é mais importante dar agilidade à entrega da

Além disso, a camada de transporte é responsável pelas seguintes

• Provê uma comunicação fim a fim;

Os principais protocolos dessa camada são o TCP e UDP, os quais

Prof. André Castro www.estrategiaconcursos.com.br

como o controle de fluxo, assume-se que tais recursos serão

Dessa forma, o serviço UDP é definido como um protocolo da camada de

Como vimos anteriormente, as portas são utilizadas para definir os

Logo, tomando como exemplo um serviço de acesso WEB, veremos que

A combinação do endereço IP deste servidor, a porta utilizada e o

Como podemos observar, é um cabeçalho bem enxuto com apenas 4

Prof. André Castro www.estrategiaconcursos.com.br

• PORTA DE ORIGEM (Opcional) – Diz respeito a porta que está

Então quer dizer que para determinado serviço, os campos de porta de

Agora um detalhe. Uma vez que o a porta de origem é opcional, quer

da camada de transporte e o mais complexo. Possui como característica

Além disso, o protocolo TCP implementa as seguintes técnicas:

Prof. André Castro www.estrategiaconcursos.com.br

• Mensagens de confirmação de recebimento por meio de pacotes

Veremos cada um desses recursos detalhadamente, até porque tem sido

Mas antes, gostaria de apresentar a vocês a estrutura do cabeçalho

Vamos analisar os campos do cabeçalho TCP:

Prof. André Castro www.estrategiaconcursos.com.br

A estrutura básica do cabeçalho TCP possui 20 bytes com a

• Source Port e Destination Port – Campos de 16 bits cada que

ainda deixam passar essa informação.

Leia-se o ACK NUMBER não como o termo “eu recebi tal

Prof. André Castro www.estrategiaconcursos.com.br

• Reserved – Campo reservado de 6 bits. Poderá ser utilizado em

A FLAG URG pode ser utilizada para gerar interrupções na

Esse pseudo cabeçalho possui: Endereço IP de origem (4bytes) e

QoS – Intserv e Diffserv; Redes e Protocolos

! ∀