comunicação na internet - fcuppbrandao/aulas/1112/telesaude/slides/... · comunicação na...

Telemedicina e e-Saúde 2011/2012

Comunicação na Internet 1

Comunicação na Internet

Telemedicina e e-Saúde

2011/12

Pedro Brandão

Referências

Estes slides são baseados nos slides fornecidos com o livro “Computer Networking: A Top Down Approach 4th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2007”

o Tendo alterações por Prof Rui Prior e Pedro Brandão

Telesaude 11/12 - Com. na Internet - pbrandao 2



Sumário

Camada de aplicação o Princípios das aplicações

em rede o Web e HTTP o Correio electrónico o Serviço de nomes

Camada de transporte o Serviços da camada de

transporte o Transferência fiável o TCP o Controlo de

congestionamento

Camada de rede o objetivo e funções o Internet Protocol (IP) o NAT


Pilha protocolar da Internet (revisão) aplicação: aplicações em rede

transporte: transferência de dados entre processos

rede: encaminhamento dos datagramas entre a origem e o destino

ligação lógica: transferência de dados entre elementos de rede adjacentes

ligação física: bits no “cabo”


Física

Lógica

Rede

Transporte

Aplicação

Ethernet, 802.11, etc

Ethernet, 802.11 (WiFi), etc

IP, ICMP, IGMP, etc

TCP, UDP, etc

FTP, SMTP, HTTP, etc

Exemplos



Protocolo de aplicação define

Tipos de mensagens trocadas o e.g., pedido, resposta

Sintaxe das mensagens o que campos contêm e como se

separam os campos

Semântica das mensagens o significado da informação

contida nos diferentes campos

Regras de como e quando devem os processos responder às mensagens

Protocolos abertos:

possibilitam interope-ração entre sistemas

e.g., HTTP, SMTP

definidos em RFCs

Protocolos fechados:

só tem aceso a eles quem o dententor dos direitos decidir

e.g., Skype

Telesaude 11/12 - Com. na Internet - pbrandao 2-5

Arquitecturas aplicacionais

Cliente-servidor

Peer-to-peer (P2P)

Híbridas de cliente-servidor e P2P

Telesaude 11/12 - Com. na Internet - pbrandao 2-6



Cliente – Servidor

servidor: o sempre ligado o endereço IP estático

cliente:

o comunica com o servidor o não precisa de estar

sempre ligado o pode ter endereço IP

dinâmico o não comunica

diretamente com outros clientes


cliente/servidor

Peer-to-peer Pura

ausência de servidores

terminais comunicam diretamente entre si

os pares podem não estar sempre ligados e mudar de endereço IP


peer-to-peer

Muito escalável, mas difícil de gerir…



0

0,5

1

1,5

2

2,5

3

3,5

0 5 10 15 20 25 30 35

Te

mp

o d

e d

istr

ibuiç

ão d

o fic

he

iro

Número de nós que pretendem o ficheiro

P2P

Client-Server

Comparação de arquiteturas: Cliente-Servidor vs. Peer-to-Peer


Arquitetura Híbrida

Exemplo: Instant messaging (MSN, ...)

omensagens de texto enviadas diretamente (P2P)

o serviço central de deteção de presença e localização

• o utilizador regista o seu endereço IP no servidor central quando se liga

• o utilizador contata o servidor central para descobrir os endereços IP dos amigos




Comunicação entre processos

Processo: instância dum programa a correr numa máquina

processos em máquinas diferentes comunicam através da troca de mensagens

Telesaude 11/12 - Com. na Internet - pbrandao

As aplicações P2P funcionam simultaneamente como clientes e servidores

Cliente: processo que inicia ativamente a comunicação Servidor: processo que espera passivamente ser contatado

11

Endereçamento de processos

para poder receber mensagens, um processo deve ter um identificador (endereço)

cada terminal tem um endereço IP de 32 bits

Q?: será o endereço IP do terminal suficiente para identificar de forma unívoca o processo? o não, porque há múltiplos

processos a correr no mesmo terminal

o identificador inclui tanto o endereço IP como o número da porta associado ao processo no terminal

Exemplos de portas: o Servidor web: 80 o Servidor de email: 25

para enviar um pedido HTTP ao servidor web www.dcc.fc.up.pt: o Endereço IP: 193.136.39.12 o Porta: 80




Serviço TCP: orientado às conexões: exige o

estabelecimento prévio de conexão entre emissor e receptor

transporte fiável entre os processos emissor e receptor

controlo de fluxo: o emissor não envia mais rápido do que o receptor consegue processar

controlo de congestionamento: redução de débito quando a rede está sobrecarregada

não tem garantias de atraso máximo nem de débito mínimo

Serviço UDP: transporte não fiável entre os

processos emissor e receptor

delineação de mensagens: um datagrama UDP corresponde a uma mensagem

não tem estabelecimento prévio de conexões, fiabilidade, controlo de fluxo, controlo de congestionamento, garantias de atraso máximo ou de débito mínimo o Nem todas as aplicações necessitam

de tudo isto...


Serviços de transporte usados pelas aplicações na Internet

13

Sumário





congestionamento





HTTP: hypertext transfer protocol

Protocolo de camada de aplicação na web

modelo cliente/servidor

o cliente: browser que pede, recebe e mostra os objetos ao utilizador

o servidor: envia os objetos em resposta aos pedidos do browser

PC com Firefox

Servidor Apache

Mac com Safari


HTTP — Panorama geral

15

Protocolos com manutenção de estado são complexos!

memória para estado se o servidor ou o cliente falham,

as suas visões do estado podem ficar inconsistentes e ter que ser ressincronizadas

aparte

HTTP — Panorama geral (cont.)

Usa o TCP: o cliente inicia a conexão

TCP para a porta 80 do servidor

o servidor aceita a conexão TCP do cliente

são trocadas mensagens HTTP (camada de aplicação) entre o browser (cliente HTTP) e o servidor web (servidor HTTP)

a conexão TCP é fechada

Sem estado o servidor não mantém

qualquer informação (estado) sobre os pedidos anteriores do cliente




Mensagem HTTP de pedido

dois tipos de mensagens HTTP: pedido e resposta

Pedido HTTP: o Texto simples (formato humanamente legível)

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu

User-agent: Mozilla/4.0

Connection: close

Accept-language: pt

linha de pedido

cabeçalhos

Linha vazia indica fim da mensagem


(mudança de linha extra)

17

HTTP/1.1 200 OK

Connection: close

Date: Thu, 06 Aug 1998 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 22 Jun 1998 ...

Content-Length: 6821

Content-Type: text/html

linha de estado (código de estado e correspondente

descrição)

cabeçalhos

linha vazia

dados (e.g., o ficheiro HTML

pedido)


dados dados dados dados...

Mensagem HTTP de resposta

18



Códigos de estado nas respostas HTTP

Enviados na primeira linha da resposta do servidor Alguns códigos: 200 OK

o sucesso, o obejcto pedido vai mais abaixo na mensagem

301 Moved Permanently o o objeto foi mudado para outro URL, especificado mais

abaixo no cabeçalho “Location:”

400 Bad Request o o servidor não entendeu o pedido

404 Not Found o o recurso pedido não existe no servidor

505 HTTP Version Not Supported


Experimentar o HTTP à mão

1. Fazer telnet para um servidor web

Abre conexão TCP para a porta 80 (porta HTTP padrão) no servidor www.dcc.fc.up.pt. Tudo o que se escrever será enviado para a porta 80 do www.dcc.fc.up.pt

telnet www.dcc.fc.up.pt 80

2. Escrever o pedido HTTP

GET /~pbrandao/index.html HTTP/1.1

Host: www.dcc.fc.up.pt

Ao escrever isto (carregar 2x no enter), vai-se enviar este um pedido GET (básico mas completo) ao servidor HTTP

3. Observar a mensagem de resposta devolvida pelo servidor HTTP




Web caches (proxy server)

utilizador configura browser para usar o proxy

o browser envia todos os pedidos HTTP ao proxy

objeto está na cache: proxy devolve-o directamente

caso contrário, pede objeto ao servidor original, devolve-o ao browser e guarda cópia local


cliente

Proxy

cliente servidor original

servidor original

objetivo: satisfazer pedidos dos clientes sem recorrer ao servidor original (maior rapidez e poupança de recursos de rede)

Sumário





congestionamento





Correio Electrónico (e-mail)

Agente de utilizador programa usado para ler e

escrever e-mail

Servidores de E-mail caixa de correio contém

mensagens recebidas fila de mensagens para

mensagens a enviar protocolo SMTP para enviar as

mensagens o “cliente”: servidor que

envia a mensagem o “servidor”: servidor que

recebe a mensagem


servidor de e-mail

SMTP

SMTP

SMTP

fila de mensagens a enviar

caixa de correio de um utilizador

servidor de e-mail

servidor de e-mail

agente de util.

agente de util.

agente de util.

agente de util.

agente de util.

agente de util.

23

Cenário: Alice envia mensagem ao Bob

1) No UA, a Alice escreve o texto da mensagem e o endereço do destinatário [email protected]

2) O UA da Alice envia a mensagem para o servidor dela; a mensagem é colocada na fila de saída

3) O “lado cliente” do SMTP da Alice abre uma conexão para o servidor de e-mail do Bob

4) A mensagem é enviada através dessa conexão TCP

5) O servidor de e-mail do Bob põe a mensagem na caixa de correio dele

6) Posteriormente, o Bob usa o seu UA para ler a mensagem


servidor de e-mail

servidor de e-mail

1

2 3 4 5 6

agente de util.

agente de util.

UA – User Agent

24



Exemplo de comunicação SMTP S: 220 hamburger.edu

C: HELO crepes.fr

S: 250 Hello crepes.fr, pleased to meet you

C: MAIL FROM: <[email protected]>

S: 250 [email protected]... Sender ok

C: RCPT TO: <[email protected]>

S: 250 [email protected] ... Recipient ok

C: DATA

S: 354 Enter mail, end with "." on a line by itself

C: Do you like ketchup?

C: How about pickles?

C: .

S: 250 Message accepted for delivery

C: QUIT

S: 221 hamburger.edu closing connection


Protocolos de acesso ao e-mail

SMTP: entrega mensagens no servidor do destinatário

Protocolo de acesso: buscar e-mail à caixa de correio no servidor

o POP3: Post Office Protocol, versão 3

• download de mensagens

o IMAP: Internet Mail Access Protocol

• mais complexo

• manipulação de mensagens armazenadas no servidor

o HTTP: Gmail, Hotmail, etc.

servidor de email do emissor

SMTP SMTP protocolo de acesso

servidor de email do destinatário




Sumário





congestionamento



DNS: Domain Name System

Pessoas: múltiplos identificadores o Nos BI, NIF, passaporte

Máquinas na Internet: o endereço IP (32 bits), usado

no encaminhamento de datagramas (e.g., 194.117.24.35)

o nome, usado por humanos (e.g. www.google.pt)

Q: como se faz a tradução entre nome e endereço IP?

Domain Name System: base de dados distribuída

implementada como uma hierarquia de servidores de nomes

os protocolos de aplicação, para comunicar, resolvem os nomes (tradução nome/endereço)

o serviço fundamental na Internet, implementado como protocolo de aplicação

o complexidade nas extremi-dades da rede




Base de Dados Distribuída e Hierárquica O cliente precisa de obter o IP de www.amazon.com. pergunta a um servidor de raiz, que lhe indica os

servidores DNS de com pergunta a um servidor de com, que lhe indica os

servidores DNS de amazon.com pergunta a um servidor de amazon.com, que lhe

responde com o endereço IP de www.amazon.com


Servidores DNS de raiz

Servidores DNS de com

Serv. DNS

cmu.edu

Serv. DNS

mit.edu Serv. DNS

google.com

Serv. DNS

amazon.com

Serv. DNS

pbs.org

Servidores DNS de org Servidores DNS de edu

máquina que faz o pedido

khao.dcc.fc.up.pt

www.mit.edu

servidor DNS de raiz

servidor DNS local dns.dcc.fc.up.pt

1

2 3

4

5

6

servidor DNS com autoridade ns.mit.edu

7 8

servidor DNS TLD

Exemplo de resolução de nome

Máquina em dcc.fc.up.pt quer o endereço de www.mit.edu

Faz pergunta (recursiva) ao servidor DNS local

Este faz perguntas (iterativas) descendo na hierarquia

O servidor contactado dá referência doutro(s) servidor(es) a contactar




Sumário





congestionamento



Serviços e protocolos de transporte

fornecer um canal lógico de comunicação entre processos a correr em máquinas diferentes

protocolo de transporte a correr nos terminais o emissor: partir

mensagens de aplicação em segmentos, que passa à camada de rede

o receptor: reconstruir mensagens a partir dos segmentos e passá-las à camada de aplicação


applicação transporte

rede lig. lógica lig. física



32



Protocolos de transporte na Internet

entrega fiável e ordenada: TCP o estabelecimento de conexões

o controlo de congestionamento

o controlo de fluxo

entrega não fiável e sem garantia de ordem: UDP o extensão simples do modelo

“melhor esforço” do IP

serviços indisponíveis: o garantia de atraso máximo

o garantia de débito mínimo





rede

lig. lógica lig. física

rede


rede


rede


rede




33

Camada de transporte vs. camada de rede camada de rede:

comunicação lógica entre máquinas

camada de transporte: comunicação lógica entre processos o usa o serviço da camada de

rede e, sobre ele, implementa um serviço de valor acrescentado

Analogia:

correio entre empresas

processos = funcionários

mensagens = cartas

máquinas = edifícios

protocolo de rede = serviço dos CTT

protocolo de transporte = encarregados pela distribuição interna do correio




Multiplexagem/desmultiplexagem

applicação

transporte

rede

lig. lógica

lig. física

P1 applicação

transporte

rede

lig. lógica

lig. física

applicação

transporte

rede

lig. lógica

lig. física

P2 P3 P4 P1

máquina 1 máquina 2 máquina 3

= processo = socket

entrega dos segmentos recebidos ao processo correcto

Desmultiplex. no receptor: recolher dados de múltiplos processos e adicionar cabe- çalhos (que depois são usados para desmultiplexar)

Multiplex. no emissor:


Como funciona a desmultiplexagem?

a máquina recebe datagramas IP

o cada datagrama contém endereços IP de origem e de destino

o cada datagrama transporta um segmento da camada de transporte

o cada segmento tem indicação das portas de origem e de destino

a máquina usa os endereços IP e as portas de origem e de destino para enviar o segmento para o processo apropriado


porta de orig. porta de dest.

32 bits

dados da aplicação

(mensagem)

outros campos do cabeçalho

formato dos segmentos TCP/UDP

36



Controlo de erros: soma de controlo

Emissor:

trata o conteúdo do segmento como uma sequência de inteiros de 16 bits

soma de controlo: adição dos inteiros que constituem o segmento (colocando zeros no próprio campo)

coloca o valor calculado no respectivo campo do cabeçalho

Receptor:

calcula soma de controlo do segmento recebido

compara o valor calculado com o recebido:

o diferentes – erro detectado

o iguais – não foram detectados erros


objetivo: detectar “erros” (e.g., bits invertidos) no segmento recebido

Pode haver erros não detectados, mas a

probabilidade é muito baixa…

37

UDP: User Datagram Protocol [RFC 768]

protocolo de transporte extremamente simples

serviço “melhor esforço”; os segmentos UDP podem: o perder-se o ser entregues à aplicação

fora de ordem sem conexões:

o cada segmento UDP é tratado de forma independente


Porque existe o UDP? sem conexões — poupa o

atraso de as estabelecer

simples: sem manutenção de estado no emissor e no receptor

cabeçalho pequeno

sem controlo de congestionamento: aplicações UDP podem enviar dados à cadência que necessitem

38



frequentemente usado em aplicações multimédia o tolerantes a perdas o sensíveis ao débito ou atraso

outros usos para o UDP o DNS

transferência fiável sobre UDP o a fiabilidade tem que ser

implementada na camada de aplicação

o recuperação de erros específica da aplicação!


porta de orig. porta de dest.

32 bits

tamanho soma de controlo

dados da aplicação

(mensagem)

formato dum segmento UDP

Mais sobre o UDP

39

Sumário





congestionamento






Princípios da transferência fiável

Processo emissor

Processo receptor

Canal fiável

dados dados

a) serviço fornecido

Canal não-fiável

Protocolo de transferência de

dados fiável (emissor)

Protocolo de transf. de dados fiável

(receptor)

dados dados

pacote pacote

Processo emissor

dados

Processo receptor

dados

b) Implementação

Cam

ada

aplic

ação

Cam

ada

tran

spo

rte

41

Transferência fiável: problemas e soluções Pacotes podem perder-se Receptor confirma (ACK) a

recepção de cada segmento Se não receber confirmação

num dado tempo, o emissor retransmite o segmento

Pacotes podem conter erros Detectados através de

somas de controlo Pacotes com erros

ignorados (tratamento igual ao dos pacotes perdidos)

Recepção de duplicados (gerados pela rede ou retransmissões por perda de ACKs)

Segmentos são numerados ACK identifica o número do

último segmento recebido Também resolve o

problema do reordenamento


O emissor envia um pacote e espera pela resposta do receptor

stop and wait



stop-and-wait: ausência de perdas


emissor receptor

envia pkt0 pkt0

ACK0 pkt1

ACK1

recebe ACK0, envia pkt1

recebe ACK1, envia pkt2 pkt2

ACK2

...

recebe pkt0, envia ACK0



stop-and-wait: perda dum pacote


emissor receptor

envia pkt0 pkt0

ACK0 pkt1 recebe ACK0, envia pkt1





pkt1

ACK1 pkt2

ACK2

...

X perdido

alarme, reenvia pkt1



stop-and-wait: perda dum ACK


emissor receptor

envia pkt0 pkt0

ACK0

pkt1

ACK1



ACK2

...




pkt1

ACK1 X

perdido

recebe pkt1, detecta dup., envia ACK1 alarme, reenvia pkt1

stop-and-wait: alarme prematuro


emissor receptor

envia pkt0 pkt0

ACK0 recebe ACK0, envia pkt1



recebe pkt1, detecta dup., envia ACK1


pkt1

ACK2

alarme, reenvia pkt1

pkt1

ACK1


ACK1

recebe ACK1 (dup),ignora-o


ACK3

...


ACK1 pkt2 ACK1



transmissão do 1º bit do pacote, t = 0

emissor

receptor

RTT

trans. do último bit do pacote, t = L / R

chegada do primeiro bit chegada do último, envio do

ACK

chegada do ACK, envio do

pacote seguinte, t = RTT + L / R


Operação do stop-and-wait

47

stop-and-wait funciona, mas com desempenho péssimo

ex.: ligação de 1 Gbps com 15 ms de atraso de propagação e pacotes de 8000 bits:


Uemissor: utilização – fracção do tempo em que o emissor efectivamente está a transmitir

1KB pacote a cada 30 ms débito 33kB/s quando R= 1 Gbps o protocolo de rede limita o uso dos recursos físicos!!!

s 8bps10

bits80009

R

Ldtrans

Desempenho do stop-and-wait

0.027% 0.00027008.30

008.0

ms

ms

RLRTT

RLUemissor

48



Utilização triplicou!

transmissão do 1º bit do pacote, t = 0

emissor

receptor

RTT

trans. do último bit do pacote, t = L / R

chegada do 1º bit do 1º pacote último bit do 1º pacote, envio do ACK

chegada do ACK, envio do

pacote seguinte, t = RTT + L / R

último bit do 2º pacote, envio do ACK último bit do 3º pacote, envio do ACK


Pipelining: maior utilização

0.08% 0.0008008.30

008.033

ms

ms

RLRTT

RLUemissor

49

Protocolos com Pipelining Go-back-N: Emissor pode ter até N

pacotes em trânsito (sem receber ACK)

Receptor envia ACKs cumulativos o Não envia ACK se houver

um “buraco”

Emissor tem tempori-zador para o pacote mais antigo ainda não confirmado o Se expirar, retransmite esse

e todos os subsequentes

Selective Repeat:

Emissor pode ser até N pacotes em trânsito (sem receber ACK)

Receptor confirma pa-cotes individualmente

Emissor mantém um temporizador por cada pacote não confirmado o Se expirar, retransmite

apenas esse pacote




Pipelining: Go-Back-N Emissor:

número de sequência no cabeçalho

“janela” de até N pacotes consecutivos não confirmados

ACK(n): confirma a recepção de todos os pacotes até ao n (inclusive) — confirmação cumulativa emissor pode receber ACKs duplicados

alarme(n): retransmite pacote n e todos os enviados posteriormente a recepção de um ACK novo (não duplicado) faz reiniciar o temporizador

base próx. nº de seq.

janela de tamanho N

já confirmados

enviados mas não confirmados

disponíveis mas não enviados

indisponíveis


Go-Back-N em acção emissor receptor

envia pkt0

envia pkt2


recebe pkt1, envia ACK1 X

envia pkt1

envia pkt3 (espera)

recebe ACK 0, envia pkt4


recebe pkt3, ignora-o, envia ACK1

reenvia pkt2

reenvia pkt3

reenvia pkt4

reenvia pkt5



alarme recebe pkt2, envia ACK2




Demonstração GBN


http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/go-back-n/index.html



Sumário





congestionamento



orientado a conexões: o estabelecimento da

conexão inicializa estado do emissor e receptor antes da troca de dados

controlo de fluxo: o emissor não sobrecarrega

o receptor

controlo de congestionamento: o emissor não sobrecarrega

a rede

ponto-a-ponto: o um emissor, um receptor

sequência de bytes fiável: o sem delimitação de mensagens

pipelined: o mecanismos de controlo de

fluxo e congestionamento determinam o tamanho da janela

conexão bidireccional: o fluxo de dados nos dois

sentidos na mesma conexão


TCP: Transmission Control Protocol

54



TCP: Estabelecimento de conexão

É necessária a troca de 3 segmentos TCP para estabelecer uma conexão

Flags SYN e SYN+ACK

Estabelecimento dos números de sequência iniciais


TCP: Terminação de conexão

É necessária a troca de 4 segmentos TCP para fechar uma conexão

Fluxo bidireccional 2 operações de fecho (para cada sentido)




TCP: nos de sequência e ACKs

Número de sequência: número do primeiro

byte de dados do segmento

ACK: número do próximo

byte esperado do outro lado

ACKs cumulativos


Terminal A Terminal B

Utilizador escreve ‘C’

terminal confirma recepção

do ‘C’ ecoado

terminal confirma recepção de ‘C’ e ecoa-o

tempo exemplo com terminal remoto

57

TCP: cenários de retransmissão

Terminal A

tempo alarme prematuro

Terminal B Terminal A

perda

perda de confirmação

Terminal B

X alar

me

tempo

(Seq

=92

alar

me)

Se

q=9

2 al

arm

e

SendBase = 100

SendBase = 120

SendBase = 120

SendBase = 100




TCP: cenários de retransmissão

Terminal A

perda

confirmação cumulativa

Terminal B

X (ala

rme)

tempo

SendBase = 120


Controlo de fluxo no TCP

Dados recebidos são armazenados num espaço próprio (buffer) até serem consumidos pela aplicação

Aplicação pode consumi-los lentamente

adaptar a taxa de envio à de consumo por parte da aplicação

para evitar extravasar o buffer do receptor

controlo de fluxo

dados

do IP

aplicação

(processo)

espaço livre

dados recebidos e ainda não con-

sumidos

janela do receptor

buffer do receptor

Controlo de fluxo no TCP Receptor anuncia o espaço livre

de que dispõe (janela de recepção)

Emissor limita a quantidade de dados em trânsito a essa janela


comunicação na internet - fcuppbrandao/aulas/1112/telesaude/slides/... · comunicação na...

Documents