Baixe o app para aproveitar ainda mais
Prévia do material em texto
Aulas do livro disponíveis em: http://www-net.cs.umass.edu/kurose-ross-ppt-7e/ Camada de aplicação Mail eletrônico Três componentes principais: • Agentes de usuário • Servidores de mail • simple mail transfer protocol: SMTP Agente Usuário • a.k.a. “leitor de mail” • redigir, editar, ler mensagens de mail • e.g., Outlook, Thunderbird, cliente mail iPhone • Mensagens de saída e de entrada armazenadas no servidor Mailbox usuário Fila de mensagens saída mail server mail server mail server SMTP SMTP SMTP user agent user agent user agent user agent user agent user agent Mail eletrônico: servidores de mail Servidores de mail: • mailbox contém mensagens de entrada para usuário • Fila de mensagens de saída (a ser enviada) mensagens de mail • Protocolo SMTP entre servidores de mail para enviar mensagens de mail o cliente: enviando do servidor de mail o “servidor”: recebendo do servidor de mail mail server mail server mail server SMTP SMTP SMTP user agent user agent user agent user agent user agent user agent Mail Eletrônico: SMTP [RFC 2821] • Usa TCP para transferir mensagens de e-mail confiáveis de cliente para servidor, porta 25 • Transferência direta: envio do servidor para o servidor de recebimento • Três fases de transferência: o handshaking (apresentação) o transferência de mensagens o Fechamento • Interação comando / resposta (como HTTP) o comandos: texto ASCII o resposta: código de status e frase • Mensagens devem ser em 7-bit ASCI user agent Cenário: Alice envia mensagem para Bob 1) Alice uses UA to compose message “to” bob@someschool.edu 2) Alice’s UA sends message to her mail server; message placed in message queue 3) client side of SMTP opens TCP connection with Bob’s mail server 4) SMTP client sends Alice’s message over the TCP connection 5) Bob’s mail server places the message in Bob’s mailbox 6) Bob invokes his user agent to read message mail server mail server 1 2 3 4 5 6 Alice’s mail server Bob’s mail server user agent Sample SMTP interaction S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... 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 SMTP • SMTP usa conexões persistentes • SMTP requer mensagens (cabecalho & corpo) para ser em 7-bit ASCII • Servidor SMTP usa CRLF.CRLF para determinar final da mensagem Comparação com HTTP: • HTTP: puxar (pull) • SMTP: empurrar (push) • Ambos tem comandos/repostas ASCII, códigos de status • HTTP: cada objeto encapsulado em sua própria mensagem de resposta • SMTP: múltiplos objetos enviados em mensagem multiparte Formato da mensagem de Mail SMTP: protocol for exchanging email messages RFC 822: standard for text message format: • header lines, e.g., o To: o From: o Subject: different from SMTP MAIL FROM, RCPT TO: commands! • Body: the “message” o ASCII characters only header body blank line Protocolos de acesso ao mail • SMTP: Entrega / armazenamento no servidor do receptor. • Protocolo de acesso de e-mail: recuperação do servidor: o POP: Post Office Protocol [RFC 1939]: authorization, download o IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored messages on server o HTTP: gmail, Hotmail, Yahoo! Mail, etc. sender’s mail server SMTP SMTP mail access protocol receiver’s mail server (e.g., POP, IMAP) user agent user agent Protocolo POP3 Fase de autorização • Comandos do cliente: o user: declare username o pass: password • Respostas do servidor o +OK o -ERR Fase de transação, cliente: • list: list message numbers • retr: retrieve message by number • dele: delete • quit C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on POP3 e IMAP Mais sobre POP3 • Exemplo anterior usa o modo POP3 "download e apaga" o Bob não pode reler o e-mail se ele mudar de cliente • POP3 "download-e- guarda": cópias de mensagens em clientes diferentes • POP3 é stateless em todas as sessões IMAP • Mantém todas as mensagens em um só lugar: no servidor • Permite ao usuário organizar mensagens em pastas • Mantém o estado do usuário nas sessões: o Nomes de pastas e mapeamentos entre IDs de mensagens e o nome da pasta DNS: domain name system Sistema de nome de domínio Pessoas: muitos identificadores RG, CPF, nome, passaporte… Máquinas na Internet, roteadores: o Endereço IP (32 bit) – usado para endereçar datagramas o “nome”, e.g., www.yahoo.com - usado por humanos Q: Como mapear entre endereço IP e nome, e vice-versa? Sistema de nome de domínio: • Base de dados distribuída implementada em hierarquia de muitos servidores de nome • Protocolo de camada de aplicação: máquinas, servidores de nome comunicam para resolver nomes (tradução endereço/nome) o note: função core Internet, implementada como protocolo de camada de aplicação o Complexidade na "borda" da rede DNS: serviços, estrutura Porque não centralizar DNS? • Ponto único de falha • Volume de tráfego • Banco de dados centralizado distante • Manutenção Serviços DNS • Hostname para tradução de endereços IP • Host aliasing • Canônico, alias nomes • Aliasing de servidor de email • Distribuição de carga o Servidores Web replicados: muitos endereços IP correspondem a um nome Atenção: não é escalável! Root DNS Servers com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu DNS serversyahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers DNS: uma base de dados distribuída e hierárquica Cliente quer IP do www.amazon.com; 1a vez: • cliente consulta servidor raiz para encontrar servidor DNS .com • cliente consulta servidor DNS .com para obter servidor DNS amazon.com • cliente consulta servidor DNS amazon.com para obter endereço IP para www.amazon.com … … DNS: Servidores de nomes raiz • Contactado pelo servidor de nomes local que não consegue resolver o nome • Servidor de nomes raiz: o Contata servidor de nomes autoritativo se mapeamento de nome for desconhecido o Obtém mapeamento o Retorna o mapeamento para o servidor de nomes local 13 logical root name “servers” worldwide each “server” replicated many times (~200 servers in US) TLD, Servidores autorizados top-level domain (TLD) servers: o Responsável por com, org, net, edu, aero, jobs, museums, e todos domínios de países de nível superior, e.g.: uk, fr, ca, jp o A Network Solutions mantém servidores para .com TLD o Educause para .edu TLD authoritative DNS servers: o Servidor (s) DNS da organização, fornecendo nome de host autorizados para mapeamentos IP para os hosts nomeados da organização. o Podem ser mantidos pela organização ou provedor de serviços Servidor de nome de DNS local • Não pertence estritamente à hierarquia • Cada ISP (ISP residencial, empresa, universidade) tem um o Também chamado de "servidor de nomes padrão" • Quando host faz consulta DNS, a consulta é enviada para seu servidor DNS local o Tem cache local com tradução recente de nome para endereço (mas pode estar desatualizado!) o Atua como proxy, encaminha a consulta para hierarquia requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 3 4 5 6 authoritative DNS server dns.cs.umass.edu 78 TLD DNS server Exemplo de resolução de nomes DNS • Host em cis.poly.edu quer endereço IP para gaia.cs.umass.edu Consulta interativa: § O servidor contactado responde com o nome do servidorpara entrar em contato § "Eu não sei esse nome, mas pergunte a este servidor" 45 6 3 Consulta recursiva: § Coloca carga da resolução de nomes no servidor de nomes contactado § Carga pesada em níveis superiores de hierarquia? requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 7 authoritative DNS server dns.cs.umass.edu 8 Exemplo de resolução de nomes DNS TLD DNS server DNS: Cache, atualização de registros • Uma vez (qualquer) que servidor de nomes aprender mapeamento, ele armazena em cache o Entradas de cache tempo limitado (desaparecer) após algum tempo (TTL) o Servidores de TLD geralmente armazenados em cache em servidores de nomes locais • Assim servidores de nomes de raiz não são visitados frequentemente • As entradas em cache podem estar desatualizadas o Se o host alterar o endereço IP, pode não ser conhecido na Internet até que todos os TTL expirem • Atualizar / notificar mecanismos propostos IETF padrão o RFC 2136 DNS registros DNS: Banco de dados distribuído armazenando registros de recursos (RR) type=NS o name is domain (e.g., foo.com) o value is hostname of authoritative name server for this domain RR formato: (name, value, type, ttl) type=A § name is hostname § value is IP address type=CNAME § name is alias name for some “canonical” (the real) name § www.ibm.com is really servereast.backup2.ibm. com § value is canonical name type=MX § value is name of mailserver associated with name DNS protocolo, mesagens • Mensagens de consulta e resposta, ambas com o mesmo formato de mensagem message header § identification: 16 bit # for query, reply to query uses same # § flags: § query or reply § recursion desired § recursion available § reply is authoritative identification flags # questions questions (variable # of questions) # additional RRs# authority RRs # answer RRs answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) 2 bytes 2 bytes name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used identification flags # questions questions (variable # of questions) # additional RRs# authority RRs # answer RRs answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) DNS protocolo, mesagens 2 bytes 2 bytes Inserindo registros no DNS • example: new startup “Network Utopia” • register name networkuptopia.com at DNS registrar (e.g., Network Solutions) o provide names, IP addresses of authoritative name server (primary and secondary) o registrar inserts two RRs into .com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A) • create authoritative server type A record for www.networkuptopia.com; type MX record for networkutopia.com Arquitetura P2P pura • Sem servidor sempre disponível • Sistemas arbitrários de extremidade comunicam diretamente • Pares são intermitentemente conectados e alteraram endereços IP • exemplos: o Distribuição de arquivos (BitTorrent) o Streaming (KanKan) o VoIP (Skype) Distribuição de arquivos: cliente-servidor vs P2P Questão: Quanto tempo para distribuir o arquivo (tamanho F) de um servidor para N pares? • Capacidade upload/download do par é um recurso limitado us uN dN server network (with abundant bandwidth) file, size F us: server upload capacity ui: peer i upload capacity di: peer i download capacityu2 d2 u1 d1 di ui Tempo de distribuição de arquivo: cliente-servidor • Transmissão servidor: deve enviar sequencialmente (upload) N copias do arquivo: o Tempo para enviar uma cópia: F/us o time to send N copies: NF/us increases linearly in N time to distribute F to N clients using client-server approach Dc-s > max{NF/us,,F/dmin} § cliente: cada cliente deve download cópia do arquivo • dmin = taxa de download min cliente • Tempo download min cliente: F/dmin us network di ui F Tempo distribuição arquivo: P2P • Transmissão servidor: deve upload ao menos uma cópia o Tempo para enviar uma cópia: F/us Tempo para distribuir F para N clientes usando P2P us network di ui F DP2P > max{F/us,,F/dmin,,NF/(us + Sui)} § cliente: cada cliente deve download cópia do arquivo • Tempo de download min cliente: F/dmin § clientes: como agregado deve download NF bits • Max taxa upload (limitando taxa max download) é us + Sui … mas isso também acontece, pois cada peer traz capacidade de serviço Aumenta linearmente em N … 0 0.5 1 1.5 2 2.5 3 3.5 0 5 10 15 20 25 30 35 N M in im um D is tri bu tio n Ti m e P2P Client-Server Cliente-servidor vs. P2P: exemplo Taxa upload cliente= u, F/u = 1 hour, us = 10u, dmin ≥ us Distribuição de arquivos P2P: BitTorrent tracker: acompanha (tracks) pares participando de torrent torrent: grupo de pares trocando pedaços (chunks) de um arquivo Alice chega… • Arquivo dividido em pedaços (chunks) de 256Kb • Peers em torrent enviam / recebem pedaços de arquivos … obtem lista de pares do tracker … e inicia trocando pedaços do arquivo com pares no torrent • pares se juntando ao torrent: o Não tem pedaços, mas irá acumulá-los ao longo do tempo de outros pares o Registra com o tracker para obter a lista de pares, se conecta a um subconjunto de pares ("vizinhos") Distribuição de arquivos P2P: BitTorrent § Durante o download, o par carrega pedaços para outros pares § O par pode mudar os pares com quem troca pedaços § Churn: os pares podem ir e vir § Uma vez que o par tenha um arquivo inteiro, ele pode (egoisticamente) partir ou (altruisticamente) permanecer em torrent BitTorrent: requisitando, enviando pedaços (chunks) de arquivo Requisitando chunks: § Em qualquer momento, diferentes pares têm subconjuntos diferentes de chunks de arquivo § Periodicamente, Alice pergunta a cada par a lista de chunks que eles têm § Alice pede chunks ausentes dos pares, os mais raros primeiro Enviando chunks: tit-for-tat § Alice envia chunks para aqueles quatro pares atualmente enviando seus chunks na taxa mais alta § Outros pares são sufocados por Alice (não recebem pedaços dela) § Reavaliar top 4 a cada 10 segundos § A cada 30 segundos: seleciona aleatoriamente outro par, começa a enviar pedaços § Par recém-escolhido pode juntar-se top 4 BitTorrent: tit-for-tat (1) Alice “seleciona” Bob (2) Alice se torna uma das quatro maiores provedoras de Bob (3) Bob se torna um dos quatro principais fornecedores de Alice Maior taxa de upload: encontrar parceiros comerciais, obter o arquivo mais rápido! Socket programming goal: learn how to build client/server applications that communicate using sockets socket: door between application process and end-end- transport protocol Internet controlled by OS controlled by app developer transport application physical link network process transport application physical link network process socket Socket programming Two socket types for two transport services: o UDP: unreliable datagram o TCP: reliable, byte stream-oriented Application Example: 1.client reads a line of characters (data) from its keyboard and sends data to server 2.server receives the data and converts characters to uppercase 3.server sends modified data to client 4.client receives modified data and displays line on its screen Socket programming with UDP UDP: no “connection” between client & server • no handshaking before sending data • sender explicitly attaches IP destination address and port # to each packet • receiver extracts sender IP address and port# from received packet UDP: transmitted data may be lost or received out-of- order Application viewpoint: • UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server Client/server socket interaction: UDP close clientSocket read datagram from clientSocket create socket: clientSocket =socket(AF_INET,SOCK_DGRAM) Create datagram with server IP and port=x; send datagram via clientSocket create socket, port= x: serverSocket = socket(AF_INET,SOCK_DGRAM) read datagram from serverSocket write reply to serverSocket specifying client address, port number server (running on serverIP) client Example app: UDP client from socket import * serverName = ‘hostname’ serverPort = 12000 clientSocket = socket(AF_INET, SOCK_DGRAM) message = raw_input(’Input lowercase sentence:’) clientSocket.sendto(message.encode(), (serverName, serverPort)) modifiedMessage, serverAddress = clientSocket.recvfrom(2048) print modifiedMessage.decode() clientSocket.close() Python UDPClient include Python’s socket library create UDP socket for server get user keyboard input Attach server name, port to message; send into socket print out received string and close socket read reply characters from socket into string Example app: UDP server from socket import * serverPort = 12000 serverSocket = socket(AF_INET, SOCK_DGRAM) serverSocket.bind(('', serverPort)) print (“The server is ready to receive”) while True: message, clientAddress = serverSocket.recvfrom(2048) modifiedMessage = message.decode().upper() serverSocket.sendto(modifiedMessage.encode(), clientAddress) Python UDPServer create UDP socket bind socket to local port number 12000 loop forever Read from UDP socket into message, getting client’s address (client IP and port) send upper case string back to this client Socket programming with TCP client must contact server • server process must first be running • server must have created socket (door) that welcomes client’s contact client contacts server by: • Creating TCP socket, specifying IP address, port number of server process • when client creates socket: client TCP establishes connection to server TCP • when contacted by client, server TCP creates new socket for server process to communicate with that particular client o allows server to talk with multiple clients o source port numbers used to distinguish clients (more in Chap 3) TCP provides reliable, in-order byte-stream transfer (“pipe”) between client and server application viewpoint: Client/server socket interaction: TCP wait for incoming connection request connectionSocket = serverSocket.accept() create socket, port=x, for incoming request: serverSocket = socket() create socket, connect to hostid, port=x clientSocket = socket() server (running on hostid) client send request using clientSocketread request from connectionSocket write reply to connectionSocket TCP connection setup close connectionSocket read reply from clientSocket close clientSocket Example app: TCP client from socket import * serverName = ’servername’ serverPort = 12000 clientSocket = socket(AF_INET, SOCK_STREAM) clientSocket.connect((serverName,serverPort)) sentence = raw_input(‘Input lowercase sentence:’) clientSocket.send(sentence.encode()) modifiedSentence = clientSocket.recv(1024) print (‘From Server:’, modifiedSentence.decode()) clientSocket.close() Python TCPClient create TCP socket for server, remote port 12000 No need to attach server name, port Example app: TCP server from socket import * serverPort = 12000 serverSocket = socket(AF_INET,SOCK_STREAM) serverSocket.bind((‘’,serverPort)) serverSocket.listen(1) print ‘The server is ready to receive’ while True: connectionSocket, addr = serverSocket.accept() sentence = connectionSocket.recv(1024).decode() capitalizedSentence = sentence.upper() connectionSocket.send(capitalizedSentence. encode()) connectionSocket.close() Python TCPServer create TCP welcoming socket server begins listening for incoming TCP requests loop forever server waits on accept() for incoming requests, new socket created on return read bytes from socket (but not address as in UDP) close connection to this client (but not welcoming socket) • Troca de mensagens de requisição e resposta: o Cliente solicita informações ou serviços o Servidor responde com dados, código de status • Formato de mensagem: o cabeçalhos: campos que fornecem informações sobre dados o dado: info(payload) sendo comunicado Importante temas: § controle vs. mensagens • in-band, out-of-band § centralizado vs. decentralizado § Sem estado ou com estado § Transferência de mensagem confiável vs. não confiável § "Complexidade na borda da rede" Capitulo 2: resumo Mais importante: aprendeu sobre protocolos!
Compartilhar