Cap. 2 – O nível aplicação

Cap. 2 – O nível aplicação 1ª Parte Departamento de Informática da Faculdade de Ciências e Tecnologia da UNL

Nota prévia • A estrutura da apresentação é semelhante e utiliza algumas das figuras, textos e outros materiais do livro de base do curso James F. Kurose and Keith W. Ross,"Computer Networking - A Top-Down Approach Featuring the Internet,“Addison Wesley Longman, Inc., 3rd Edition, 2005

Perceber como são organizadas e funcionam algumas das aplicações mais comuns Perceber o paradigma cliente / servidor e o paradigma P2P (“par a par” ou “peer-to-peer”) Conhecer protocolos aplicacionais populares Objectivos do capítulo

Organização do capítulo • Aplicações em rede ou distribuídas • Conceitos de base, paradigmas e tipos de transportes • Protocolo HTTP (Web) • O DNS (“Domain Name System”) • Protocolo SMTP — Correio electrónico • Transferência de ficheiros - Protocolo FTP e sistemas P2P • Os protocolos RTP e SIP

application transport network data link physical application transport network data link physical application transport network data link physical Aplicações distribuídas • Aplicação: processos distribuídos que comunicam através de mensagens • Executam nos hosts em “user space” • Comunicam através de protocolos do nível aplicação • Usam os serviços do nível de transporte da rede • Protocolos Aplicacionais • Definem as mensagens trocadas pelas aplicações e a sua semântica • Não são senão uma parte da aplicação

Alguma terminologia • A aplicação é formada por um conjunto de processos distribuídos • Os processos distribuídos comunicam através de um IPC Inter Process Communication Facility de comunicação em rede • Um IPC também se designa uma API (“Application Programming Interface”) de comunicação • O IPC é usado para executar um protocolo do nível aplicação • Um processo interactivo que serve directamente um utilizador diz-se um agente do utilizador (“user agent”)

request reply application transport network data link physical application transport network data link physical O paradigma cliente servidor

Características de base • Em geral, o cliente toma a iniciativa de contactar o servidor, enquanto que o servidor espera pelo contacto do cliente • O cliente solicita serviços ao servidor • Este responde ao pedido • Um servidor que serve um cliente de cada vez diz-se um servidor iterativo (serializa os pedidos) • Um servidor que serve vários clientes em paralelo diz-se um servidor concorrente • Ao protocolo base chama-se um protocolo “pedido / resposta” (“request / reply”) • A sincronização característica é semelhante à da invocação de um procedimento ou método

Arquitecturas P2P • Conjuntos de hosts comunicam directamente entre si sem uma estruturação hierárquica • Os Peers (pares, parceiros, …) nem sempre estão ligados e podem trocar de endereço IP de cada vez que estão ligados • Muito escalável • Mas mais difícil de gerir

Sistemas híbridos Cliente / Servidor e P2P Skype • A comunicação da chamada telefónica é de host a host - P2P • A pesquisa dos interlocutores é centralizada • Os utilizadores (peers) registam o seu IP no servidor • Os peers contactam o servidor para saber o IP do seu parceiro Correio electrónico • As caixas de correio estão em servidores • As mensagens são trocadas entre servidores de correio electrónico de forma horizontal (servidores actuando de forma P2P entre si) Presença e mensagens instantâneas • As aplicações dos utilizadores trocam mensagens directamente - P2P • Localização e detecção da presença centralizada num servidor: • Os utilizadores quando on-line registam o seu endereço num servidor • Os utilizadores contactam o servidor central para localizar os seus amigos

Organização do capítulo • Aplicações em rede ou distribuídas • Conceitos de base, paradigmas e tipos de transportes • Protocolo HTTP (Web) • O DNS (“Domain Name System”) • Protocolo SMTP — Correio electrónico • Transferência de ficheiros - Protocolo FTP e sistemas P2P • Os protocolos RTP e SIP

Necessidades das aplicações • Perca de dados • Algumas aplicações toleram perca de dados (som, ...) • Outras necessitam de fiabilidade a 100% (e.g. transferência de um ficheiro) • Capacidade de transferência • Algumas aplicações necessitam de uma certa garantia de capacidade mínima (som, ...) • Outras são “elásticas” e adaptam-se à capacidade disponível (e.g. transferência de um ficheiro) • Latência ou tempo de trânsito (“Timing”) • Algumas aplicações necessitam de garantias no que toca à latência e até à sua variação (Jogos, som interactivo, ...) • Outras toleram grandes variações da latência

Perca de dados ? não tolera não tolera não tolera tolera tolera tolera não tolera Capacidade garantida ? elástica elástica elástica audio: 5Kb-1Mb video:10Kb-6Mb idem > alguns Kbps elástica Sensível ao tempo ? não não não sim, 100’s ms sim, alguns seg sim, 100’s ms sim e não Aplicação file transfer e-mail Documentos Web real-time audio/video stored audio/video Jogos interactivos Aplicações financeiras Exemplos

Transportes e suas características • TCP • Orientado conexão (exige conexão prévia) • Transporte fiável de uma sequência de octetos (“bytes”) • Controlo de fluxo • Controlo de saturação • Não dá garantias de banda nem de latência • UDP • Serviço datagramas sem conexão (não exige conexão prévia) • Não fiável (“best effort”) • Não tem garantias de banda, latência, controlo de fluxo ou saturação

Exemplos Protocolo do nível aplicação smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959], NFS Protocolo de transporte TCP TCP TCP TCP TCP ou UDP TCP ou UDP tipicamente UDP Aplicação e-mail remote terminal access Web file transfer streaming multimedia remote file server Internet telephony

Organização do capítulo • Aplicações em rede ou distribuídas • Conceitos de base, paradigmas e tipos de transportes • Protocolo HTTP (Web) • Protocolo SMTP — Correio electrónico • O DNS (“Domain Name System”) • Transferência de ficheiros - Protocolos TFTP, FTP e sistemas P2P • Os protocolos RTP e SIP

O Protocolo HTTP e o serviço WWW WWW - um serviço de acesso a informação multimédia para a Internet

Terminologia • O User agent chama-se um browser: • MS Internet Explorer • Netscape Communicator • Opera, … • Existem vários servidores: • Apache (public domain) • MS Internet Information Server • ….. • Página Web: • formada por “objectos” • endereçada via um URL • As páginas Web geralmente são formadas por: • página HTML de base, e • referências para objectos. • Um URL tem duas componentes: nome de um host e nome de um objecto local ao servidor: asc.di.fct.unl.pt/rc/index.html

Aspectos fundamentais • Os servidores funcionam como repositórios de informação • A estruturação da informação baseia-se em “hyperlinks / hypermedia” • A interface dos browser é intuitiva, generalizada e permite lidar com múltiplos formatos e tipos de recursos • Os browsers admitem a “navegação” dinâmica através dos “hyperlinks” • O browser interpreta o conteúdo dos documentos, expandindo dinamicamente os formatos multimedia (texto, som, imagem, …) através de funcionalidades internas ou de programas externos • Para melhor desempenho, os browsers gerem uma cache local dos últimos documentos que foram acedidos

Forma geral de um URL - Uniform Resource Locator Os URLs são endereços de recursos WEB protocolo ou método de acesso://servidor[:porta]/nome-do-objecto Exemplos de protocolos: HTTP, FTP, TELNET, FILE, MAILTO, … Servidor: nome DNS do servidor onde reside o objecto Porta: porta a usar na conexão, pode ser omitida, nesse caso usa-se uma por defeito em função do protocolo

O protocolo HTTP • HTTP: hypertext transfer protocol • Protocolo do nível aplicação • cliente/servidor • cliente: browser envia pedidos, recebe, interpreta e mostra os objectos • servidor: o servidor Web envia os objectos em resposta aos pedidos • http1.0: RFC 1945 • http1.1: RFC 2068 http request PC running Int Explorer http response http request Server running Apache Web server http response Mac running Mozilla

Continuação • http: usa o transporte TCP: • O cliente abre uma conexão TCP para a porta 80 do servidor • O servidor aceita a conexão do cliente • O servidor e o cliente trocam mensagens HTTP • A conexão TCP é fechada • O http é sem estado (“stateless”) • O servidor não mantêm nenhuma informação sobre as conexões dos clientes • Os protocolos que mantêm “estado” são mais complexos! • O estado (“história”) tem de ser mantido • Se o servidor ou o cliente avariam, o estado pode ficar não coerente e tem de ser re-sincronizado

Como funciona o HTTP O que se passa quando é solicitado a um browser que aceda a um recurso especificado por um URL, como por exemplo: http://en.wikipedia.org/wiki/Main_Page ? 1) O browser faz a análise do URL 2) Solicita ao DNS o endereço do servidor (en.wikipedia.org) 3) O DNS responde com 145.97.39.155 por exemplo 4) O browser abre uma conexão TCP para o porto 80 de 145.97.39.155 5) Envia então o comando: “GET /wiki/Main_Page HTTP/1.0” seguido de uma linha em branco 6) O servidor responde com esse documento 7) O browser lê o documento através do canal TCP 8) O servidor e o browser fecham a conexão 9) O browser começa a interpretação do documento e abre novas conexões para ir buscar as imagens e outros documentos indicados no mesmo

O Utilizador solicita o URL http://en.wikipedia.org/wiki/Main_Page 1a. O cliente HTTP inicia a abertura de uma conexão paraen.wikipedia.org na porta 80 Exemplo (que contém texto e referências para 10 objectos) 1b. O servidor HTTPen.wikipedia.org estava à espera de pedidos de conexão na porta 80. “aceita” a conexão e indica isso ao cliente 2. O cliente HTTP envia a request message (contendo o URL) através do socket TCP. A mensagem indica que o cliente quer o objecto wiki/Main_Page 3. O servidor HTTP recebe a mensagem, forma a response message contendo o objecto e envia-a através do socket time

5. O cliente HTTP cliente recebe a mensagem contendo o objecto, interpreta-o visto ser HTML. Ao fazer a interpretação encontra a referência para 10 objectos Continuação 4. O servidor HTTP fecha a conexão TCP. 6.Os passos 1 a 5 são repetidos para os 10 objectos time

initiate TCP connection RTT request file time to transmit the object RTT object received time time Modelização do tempo de resposta RTT: tempo de ida e volta de um pequeno pacote entre o cliente e o servidor. Tempo total de resposta: • Um RTT para iniciar a conexão • Sensivelmente mais um RTT por cada pedido HTTP com alguns bytes da resposta • Tempo de transmissão do objecto total = 2.RTT+tempo total de transmissão do objecto

Conexões persistentes e não persistentes • Persistentes • Disponíveis em HTTP/1.1 • Sem fechar a conexão: o servidor analisa, responde, analisa, responde,.. • Pipelining: logo que o cliente reconhece URLs envia os pedidos mesmo sem esperar pelas respostas anteriores • Menos RTTs • Não-persistentes • HTTP/1.0 • O servidor analisa o pedido, responde, e fecha a conexão TCP • 2 RTTs pelo menos por cada objecto pedido

As mensagens HTTP request line (GET, POST, HEAD, ....) GET /somedir/page.html HTTP/1.0 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) header lines Carriage return, line feeds indicam o fim da mensagem

Forma geral de um pedido HTTP

HTTP/1.0 GET POST HEAD asks server to leave requested object out of response HTTP/1.1 GET, POST, HEAD PUT uploads file in entity body to path specified in URL field DELETE deletes file specified in the URL field Comandos do cliente

1. Fazer telnet para um servidor Web: Um cliente HTTP manual Abrir conexão para a porta 80 Tudo o que se escrever é enviado ao servidor pela conexão TCP telnet www.di.fct.unl.pt 80 2. Escrever o comando GET HTTP: Desta forma (carregando em RETURN duas vezes) envia-se o pedido manualmente GET /~jalm/ HTTP/1.0 Host: www.di.fct.unl.pt 3. Obter a resposta enviada pelo servidor HTTP!

Análise de uma resposta status line (protocol status code status phrase) 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 data data data data data ... header lines data, e.g., requested html file

Alguns cabeçalhos Os cabeçalhos usados tanto nos pedidos como nas respostas são cabeçalhos MIME que servem para indicar propriedades e outras opções do diálogo entre o browser e o servidor. Exemplos: MIME-version versão MIME usada If-Modified-Since conditional GET Last-Modified data da última modificação Content-length dimensão Content-Encoding codificação MIME Content-Type tipo MIME do documento Date data do request From e-mail do user Server identificação do servidor User-Agent identificação do browser …. Nota: o cabeçalho MIME Content-Transfer-Encoding não é necessário.

Através de um “post method”: Frequentemente as páginas têm um “form” Os dados do utilizador são transmitidos para o servidor no corpo (“body”) da mensagem Através do URL: Usa o método GET Os dados vão codificados no URL Transmissão de dados para o servidor www.somesite.com/animalsearch?monkeys&banana

CGI - Common Gateway Interface http + parâmeteros server Ficheiros não executáveis browser CGI Por convenção, o directório “/cgi-bin” contem o código executável dos “scripts”. File system

Alguns códigos de resposta Os códigos de resposta têm o formato geral: xyz (3 digitos) seguidos de uma frase informativa Exemplos: 200 Ok, request succeeded 204 Ok, but no content to return 301 Requested resource has been assigned a new URL 304 Document has not been modified (conditional GET) 400 Bad request 404 Not found …..

HTML - HyperText Markup Language Linguagem HTML é a linguagem adoptada na Web para se descreverem os documentos de hypertext que são visualizados pelo browser. Os documentos HTML são estruturados (Cabeçalhos, Títulos, Tipos/Fontes, Tamanhos, Barras, Imagens in-line, Listas, Menus, Links, …) A linguagem HTML permite a anotação de um texto com marcas (“tags”) que correspondem a directivas de formatação. HTML é um sub-conjunto da linguagem de markup SGML (Standard Generalized Markup Language) que é definida pela norma ISO 8879.

Algumas TAGS comuns <HTML> …. </HTML> Indica uma página escrita em HTML <HEAD> …. </HEAD> Delimita o cabeçalho da página <TITLE> …. </TITLE> Título da página (não afixado) <BODY> …. </BODY> Corpo da página <Hn> …. </Hn> Heading de nível n (1 a 6) …. Texto em Boldface …. Texto em itálico <UL> …. </UL> Lista não numerada de itens <OL> …. </OL> Lista numerada de itens <MENU> …. </MENU> Menu <LI> Item de uma lista Produz uma mudança de linha obrigatória Fim de parágrafo <HR> Linha horizontal <PRE> …. </PRE> Texto pré-formatado <IMG SRC=“….”> Carregar uma imagem neste ponto <A HREF=“….”> …. </A> Hyperlink (âncora)

usual http request msg + Authorization:line usual http request msg + Authorization:line usual http response msg usual http response msg tempo Interacção com autenticação servidor cliente usual http request msg • Objectivo: controlar o acesso a certos documentos • Sem estado: o cliente tem de apresentar as credenciais em cada acesso • Tipicamente nome, password 401: authorization req. WWW authenticate: O browser faz caching do nome & password para tornar a utilização mais confortável.

Muitos WEB sites que necessitam de manter estado sobre os clientes entre acessos usam cookies Quatro componentes: 1) cookie header line of HTTP response message 2) cookie header line in HTTP request message 3) cookie file kept on user’s host, managed by user’s browser 4) back-end database at Web site Exemplo: O João acede sempre à Internet usando o mesmo PC Visita com alguma frequência um dado site A quando do 1º acesso, o servidor cria para o João: um ID único Uma entrada na base de dados backend com esse ID Estado sobre um utilizador no servidor: cookies

client Amazon server usual http request msg usual http response + Set-cookie: 1678 Cookie file Cookie file Cookie file amazon: 1678 ebay: 8734 ebay: 8734 amazon: 1678 ebay: 8734 cookie- specific action usual http request msg cookie: 1678 usual http request msg cookie: 1678 usual http response msg usual http response msg cookie- spectific action Acesso a um servidor com estado: cookies server creates ID 1678 for user entry in backend database access access one week later:

What cookies can bring: authorization shopping carts recommendations user session state (Web e-mail) Cookies (continued) aside Cookies and privacy: • cookies permit sites to learn a lot about you • you may supply name and e-mail to sites How to keep “state”: • protocol endpoints: maintain state at sender/receiver over multiple transactions • cookies: http messages carry state

Web Caches (proxy server) Objectivo: satisfazer o pedido do cliente sem envolver o servidor Web origin server • O utilizador parametriza o browser para usar o proxy • O browser envia os pedidos para o proxy • Se o objecto está na cache do proxy este envia a cópia cached • Senão, vai buscar o objecto ao servidor Web, faz caching dele e responde Proxy server http request http request client http response http response http request http request http response http response client origin server

Hipóteses: Dimensão média dos objectos = 100.000 bits Média de = 15 pedidos /segundo Latência do router local a cada site web = 2 segundos em média = Internet delay Consequências: Utilização da LAN = 15% Utilização do link de acesso = 100% Latência total = Internet delay + link delay + LAN delay = 2 seg + minutos + mili segundos Alternativas de acesso à Internet origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN

Consequência Utilização da LAN = 15% Utilização do link = 15% Latência total = Internet delay + link delay + LAN delay = 2 segundos + mili segundos + mili segundos Mas a solução é cara 1ª solução possível - link a 10 Mbps origin servers public Internet 10 Mbps access link institutional network 10 Mbps LAN

Instala-se um proxy Por hipótese com um hit rate is 0.4 Consequências 40% dos pedidos satisfeitos localmente (admitamos um LAN delay de 2 ms) 60% dos pedidos satisfeitos pelo servidor final A utilização do link de acesso desceu para 60% (admitamos um delay no link de 10 ms) Latência total média = Internet delay + access delay + LAN delay = 0.6*(2.01) segundos + 0.4*0.002 < 1,2 segundos Solução baseada num proxy origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache

http response HTTP/1.0 304 Not Modified Get condicional servidor cliente • Objectivo: se a versão cached está actual, não enviar o objecto • cliente: especifica a data da versão cached • If-modified-since: <date> • servidor: a resposta só contem o objecto se este tiver sido modificado • HTTP/1.0 304 Not Modified http request msg If-modified-since: <date> object not modified http request msg If-modified-since: <date> object modified http response HTTP/1.1 200 OK … <data>

Cap. 2 – O nível aplicação