HTTP

Comunicações por Computador

Mestrado Integrado em Engenharia Informática
3º ano/2º semestre
2020/2021

Computer Networking: A Top Down Approach,

Capítulo 2
Jim Kurose, Keith Ross, Addison-Wesley ©2016 .
HTTP
Hypertext Transfer Protocol
Conceitos básicos, bem conhecidos…
l Uma página Web consiste numa coleção de objetos
l Um objeto pode ser um ficheiro HTML, uma imagem JPEG image, um
applet Java, um ficheiro audio…
l Uma página Web consiste num ficheiro de base HTML que inclui várias
referências a outros objetos
l Cada objeto é endereçado por uma URL (Uniform Resource Locator)

URL exemplo:

http://www.di.uminho.pt/cursos/miei.html

host name path name

28/04/21 Universidade do Minho 1

HTTP
Como funciona?
HTTP: hypertext transfer protocol PC a executar o
Firefox
l Protocolo do nível da aplicação

l Modelo cliente/servidor
P ed
ido
l cliente: browser pede, recebe e HT
Re s TP
mostra objetos Web po s
ta
HT
l servidor: servidor envia objetos TP
como resposta a pedidos
T P
HT P Servidor a
HTTP 0.9: versão inicial (não oficial) dido H TT executar
P e
o sta o servidor
HTTP 1.0: RFC 1945 (maio 1996) s p
Re WEB Apache
HTTP 1.1: RFC 2068 (janeiro 1997)
HTTP 2.0: RFC 7540 (maio 2015)
Mac a executar o
HTTP 3.0: Draft de 23 março 2021 Safari

28/04/21 Universidade do Minho 2

HTTP
Como funciona?
Utiliza o TCP: O HTTP não tem estado
l O servidor não mantém estado
l O cliente inicia uma conexão TCP
acerca dos pedidos anteriores dos
(cria um socket) com um servidor
clientes
HTTP (porta 80).
l O servidor TCP aceita o pedido de
conexão do cliente Os protocolos orientados ao
estado são mais complexos!
l São trocadas mensagens HTTP
l O passado tem que ser
(mensagens de protocolo de nível
armazenado
de aplicação) entre o browser
l Se o servidor/cliente falham a
(cliente HTTP) e o servidor Web
sua visão do estado pode ficar
(servidor HTTP) inconsistente e terá que ser
l A ligação TCP é terminada sincronizada

28/04/21 Universidade do Minho 3

Aplicações de rede
Exemplo: HTTP Formato dos PDU

method sp URL sp version cr lf request

line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

28/04/21 Universidade do Minho 4

Aplicações de rede
Exemplo: HTTP Formato dos PDU

Exemplo de uma HTTP Request Message

GET /directoria/pagina.html HTTP/1.1 Linha do pedido

Host: www.sitio.pt
Connection: close Linhas do
cabeçalho
User-Agent: Mozilla/4.0
Accept-Language: PT
<new line>
Dados da
Corpo da mensagem (vazio no caso do GET) mensagem

28/04/21 Universidade do Minho 5

Aplicações de rede
Exemplo: HTTP Formato dos PDU

HTTP Request Message

Linha do pedido

HEAD
POST URL HTTP/v
GET...

Método objecto versão do protocolo

HTTP/1.0 usa conexões TCP não-persistentes:
a conexão é terminada após o envio de cada mensagem
HTTP/1.1 usa conexões TCP persistentes, por defeito

28/04/21 Universidade do Minho 6

Intput de dados através de formulários
Método Post: Método URL:
l É frequente as páginas Web
l Utiliza o método GET
incluírem um formulário para
l O Input é enviado para o servidor
introdução de dados.
HTTP utilizando o campo URL da
l Nesse caso pode utilizar-se o
HTTP Request Message, com o
método POST em vez do método método GET.
GET.
www.somesite.com/animalsearch?monkeys=1&banana=4
l O método POST é muito
semelhante ao método GET, mas o HOSTNAME PATH QUERY_STRING

objeto requerido depende do input

introduzido pelo utilizador através
de um formulário.
l O Input introduzido pelo utilizador
é enviado para o servidor HTTP no
corpo da HTTP Request Message,
utilizando o método POST.
28/04/21 Universidade do Minho 7
Tipos de Métodos
HTTP/1.0 HTTP/1.1
l GET l GET, POST, HEAD

l POST l PUT

l HEAD l faz o upload do objeto

l pede ao servidor para não contido no corpo da

incluir o objeto requerido na mensagem na localização
resposta especificada no campo URL
da mesma mensagem
l DELETE

l apaga o ficheiro especificado

no campo URL

28/04/21 Universidade do Minho 8

Métodos HTTP: REST API Design
l Lista de operações sobre um RECURSO (ex: livros) é definida
aproveitando a semântica dos métodos do protocolo HTTP:
POST GET PUT DELETE
Recurso (Create) (Read) (Update) (Delete)
/livros Cria um novo Lista todos os Atualiza um Apaga todos os
livro; livros; conjunto de livros livros;
Pedido: objeto Pedido: vazio; passados no Pedido: vazio;
“livro” no corpo Resposta: corpo do pedido Resposta:
do HTTP listagem de HTTP sucesso ou
Request! livros; insucesso;
/livros/01 Normalmente Devolve o objeto Se existe livro 01 Se existe livro 01
não é usado! que representa o então atualiza-o; apaga-o;
Erro! livro com id 01 Senão dá erro!

CRUD (Create / Read / Update / Delete)

[email protected] GCOM – DI – Universidade do Minho 9
 Aplicações de rede
Exemplo: HTTP Formato dos PDU

HTTP Response Message

Linha do tipo
HTTP/1.1 200 OK da resposta
Connection: close
Date: 07 Mai 2003 11:35:15 UTC+1
Server: Apache/1.3.0 (Unix) Linhas do
Last-Modified: 05 Mai 2003 09:23:45 UTC+1 cabeçalho
Content-Length: 6825
Content-Type: text/html
<new line>
Dados da
Corpo da mensagem (objecto) mensagem
28/04/21 Universidade do Minho 10
Aplicações de rede
Exemplo: HTTP Formato dos PDU

HTTP Response Message

Linha do tipo
da resposta
HTTP/1.0
HTTP/1.1 200 OK

Versão do código nome do tipo

protocolo do (significado: servidor
no servidor tipo encontrou o objecto)

28/04/21 Universidade do Minho 11

Aplicações de rede
Exemplo: HTTP Formato dos PDU

Alguns códigos de tipo e seu significado

200 OK
301 Moved permanently, location: xyz
304 Not modified
400 Bad request (pedido não entendido)
401 Authorization required
404 Not found (objecto não encontrado)
505 HTTP version not supported

28/04/21 Universidade do Minho 12

HTTP (command line)
$ http -v GET www.di.uminho.pt
GET / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: www.di.uminho.pt
User-Agent: HTTPie/2.0.0
....
(ver os últimos 4 slides, para mais exemplos com API REST,
eo site do HTTPie https://httpie.org/ )

28/04/21 Universidade do Minho 13

HTTP
Tipos de ligações
HTTP não persistente HTTP persistente
l Só pode ser enviado no máximo l Podem ser enviados múltiplos
um objeto Web por cada conexão objetos Web por cada ligação
estabelecida estabelecida entre o cliente e o
l O HTTP/1.0 utiliza HTTP não servidor.
persistente l O HTTP/1.1 usa por defeito
conexões persistentes

28/04/21 Universidade do Minho 14

 HTTP
Persistente
HTTP não persistente: Persistente sem pipelining:
l O cliente envia um novo pedido
l exige 2 RTTs por objecto
apenas quando recebe a resposta
l O Sistema Operativo tem que ao anterior
reservar recursos para cada l Um RTT por cada objeto referido
ligação TCP estabelecida
l Muitos browsers abrem ligações Persistente com pipelining:
TCP paralelas para irem buscar os l Modo por defeito no HTTP/1.1
objectos referidos
l O cliente envia os pedido assim
HTTP persistente: que os encontra no objecto
l O servidor deixa a ligação aberta referenciador
depois de enviar a mensagem de l No mínimo é consumido um RTT
resposta por todos os objetos referenciados
l Os pedidos HTTP posteriores são
enviados através da mesma ligação

28/04/21 Universidade do Minho 15

HTTP
Não persistente
Supondo que o utilizador introduziu a url www.uminho.pt/DI/index.html
(contém texto e referência
para imagens jpeg)
1a. O cliente HTTP inicia uma conexão TCP 1b. O servidor HTTP que está a ser
com o servidor HTTP que está a ser executado no sistema www.uminho.pt
executado no sistema www.uminho.pt e e está à escuta na porta 80 aceita o
está à escuta na porta 80 pedido de conexão e avisa o cliente

2. O cliente HTTP envia uma mensagem

HTTP do tipo request message 3. O servidor HTTP recebe a request
(contendo a URL) através de um novo message e constrói uma response
socket TCP. A mensagem indica que o message que contém o objeto Web
cliente deseja o objecto Web requerido, enviando depois essa
DI/index.html mensagem através do socket TCP
estabelecido
tempo
28/04/21 Universidade do Minho 17
 HTTP
Não persistente

4. O servidor HTTP pede para terminar a

conexão, mas a ligação só é
5. O cliente HTTP recebe a response message terminada quando o cliente receber a
que contem o ficheiro html, mostra o response message
ficheiro e faz o parsing do seu conteúdo
encontrando a referência a vários objetos
jpeg

6. Repete os passos 1-5 para cada

objecto referenciado

tempo

28/04/21 Universidade do Minho 18

HTTP
Modelo do Tempo de Resposta
Definição de RTT: tempo que o sinal
(1 bit) demora a ir do cliente para
o servidor e voltar
(2*TempoPropagação + Iniciar
N*tempoEsperanasQueues+ Conexão
N*tempoProcessamento) TCP

Tempo de Resposta RTT

l um RTT para iniciar uma conexão

Requere
Ficheiro
TCP Tempo
RTT
l um RTT para enviar a request necessário
para
message e receber o primeiro bit Ficheiro transferir
da response message Recebido o ficheiro
l tempo de transmissão do ficheiro
tempo tempo
total = 2RTT+ tempo_transmissão
28/04/21 Universidade do Minho 19
Exercício
l Pretende-se estimar o tempo mínimo necessário para obter um
documento da Web. O documento é constituído por 6 objectos: o objecto
base HTML e cinco imagens referenciadas no objecto base. O browser
está ligado ao servidor HTTP por uma única linha com RTT de 20 ms. O
tempo mínimo de transmissão na linha do objecto base HTML é de 8 ms
e o tempo mínimo de transmissão na linha de cada imagem é de 80 ms.
Admita que o browser só pode pedir as imagens quando receber
completamente o objecto base. Admita que o utilizador o utilizador sabe
o endereço IP do servidor, indicando-o no browser. A dimensão dos
pacotes de estabelecimento de ligação, de confirmação de
estabelecimento de ligação e de envio dos pedidos HTTP é desprezável.
Os tempos de processamento dos pacotes são também desprezáveis.
Não há mais tráfego nenhum na rede.
l Ilustrando a situação com um diagrama temporal, qual o tempo necessário para
obter o documento (todos os objectos) se utilizar HTTP não persistente com um
máximo de 4 ligações paralelas?
l Ilustrando a situação com um diagrama temporal, qual o tempo necessário para
obter o documento (todos os objectos) se utilizar HTTP/1.1 com pipelining em
todos os pedidos?
28/04/21 Universidade do Minho 20
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

28/04/21 Universidade do Minho 21

 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

28/04/21 22
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0

28/04/21 23
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn

28/04/21 24
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn

28/04/21 25
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html

28/04/21 26
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
tt(html)=8ms
(simplificado!)

28/04/21 27
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 fin

28/04/21 28
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 fin
ack + fin

28/04/21 29
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 fin
RTT ack + fin
ack
t=68

28/04/21 30
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 fin
RTT ack + fin
ack
t=68

28/04/21 31
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68
t=68

28/04/21 32
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1

28/04/21 33
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1
RTT
tt’(img1)= ??
t=108

28/04/21 34
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn Mas... há que dividir a largura de banda pelos 4!
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1
RTT
tt’(img1)= ??
t=108

28/04/21 35
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn Mas... há que dividir a largura de banda pelos 4!
RTT ack + syn como tt = L/R e agora temos R’ = R/4
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1
RTT
tt’(img1)= ??
t=108

28/04/21 36
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn Mas... há que dividir a largura de banda pelos 4!
RTT ack + syn como tt = L/R e agora temos R’ = R/4
t=20 ack + GET html então tt’ = L/R’ = L/(R/4) =4 * L/R => tt’ = 4 tt
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1
RTT
tt’(img1)= ??
t=108

28/04/21 37
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn Mas... há que dividir a largura de banda pelos 4!
RTT ack + syn como tt = L/R e agora temos R’ = R/4
t=20 ack + GET html então tt’ = L/R’ = L/(R/4) =4 * L/R => tt’ = 4 tt
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1
RTT
tt’(img1)=320ms !!!
t=108
(simplificado!)

fin
t=428

28/04/21 38
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn Mas... há que dividir a largura de banda pelos 4!
RTT ack + syn como tt = L/R e agora temos R’ = R/4
t=20 ack + GET html então tt’ = L/R’ = L/(R/4) =4 * L/R => tt’ = 4 tt
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1
RTT
tt’(img1)=320ms !!!
t=108
(simplificado!)

fin
t=428
RTT ack + fin
t=448 ack
28/04/21 39
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) HTTP/1.0 Não persistente, com 4 conexões em paralelo

t=0 syn Mas... há que dividir a largura de banda pelos 4!
RTT ack + syn como tt = L/R e agora temos R’ = R/4
t=20 ack + GET html então tt’ = L/R’ = L/(R/4) =4 * L/R => tt’ = 4 tt
RTT
tt(html)=8ms
t=40 4 conexões em paralelo (4 threads)
(simplificado!)
t=48 fin
RTT ack + fin
ack t=68 syn
t=68
RTT ack + syn
t=88 ack + GET img1
RTT
tt’(img1)=320ms !!!
t=108
(simplificado!)

fin
t=428
RTT ack + fin
t=448 ack
28/04/21 40
... ainda falta uma imagem img5 à
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) ... continuação: descarregar a ultima imagem numa nova conexão

28/04/21
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) ... continuação: descarregar a ultima imagem numa nova conexão

t=448 syn

28/04/21
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) ... continuação: descarregar a ultima imagem numa nova conexão

t=448 syn
RTT ack + syn
t=468 ack + GET html

28/04/21
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) ... continuação: descarregar a ultima imagem numa nova conexão

t=448 syn
RTT ack + syn
t=468 ack + GET html
RTT
tt(img5)=80ms
t=488
(simplificado!)

t=568

28/04/21
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) ... continuação: descarregar a ultima imagem numa nova conexão

t=448 syn
RTT ack + syn
t=468 ack + GET html
RTT
tt(img5)=80ms
t=488
(simplificado!)

t=568 fin
RTT ack + fin
t=588 ack

28/04/21
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

a) ... continuação: descarregar a ultima imagem numa nova conexão

t=448 syn
RTT ack + syn
t=468 ack + GET html
RTT
tt(img5)=80ms
t=488
(simplificado!)

t=568 fin
RTT ack + fin
t=588 ack

T.a.total = 568 ms (ou 588 ms contando com fecho conexão)

28/04/21
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

28/04/21 47
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48

28/04/21 48
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1

28/04/21 49
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148

28/04/21 50
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148 ack + GET img2

28/04/21 51
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148 ack + GET img2

t=168 tt(img2)=80ms
(simplificado!)

t=248

28/04/21 52
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148 ack + GET img2

t=168 tt(img2)=80ms
(simplificado!)

t=248 ack + GET img3

28/04/21 53
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
t=348
RTT ack + syn GET img4
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148 ack + GET img2

t=168 tt(img2)=80ms
(simplificado!)

t=248 ack + GET img3

28/04/21 54
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
t=348
RTT ack + syn GET img4
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148 ack + GET img2

t=168 tt(img2)=80ms
(simplificado!)

t=248 ack + GET img3

28/04/21 55
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
t=348
RTT ack + syn GET img4
t=20 ack + GET html
RTT
tt(html)=8ms GET img5
t=40 t=448
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms t=548
(simplificado!)

t=148 ack + GET img2

t=168 tt(img2)=80ms
(simplificado!)

t=248 ack + GET img3

28/04/21 56
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
t=348
RTT ack + syn GET img4
t=20 ack + GET html
RTT
tt(html)=8ms GET img5
t=40 t=448
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms fin
t=548
(simplificado!) ack + fin
RTT
ack
t=568
t=148 ack + GET img2

t=168 tt(img2)=80ms
(simplificado!)

t=248 ack + GET img3

28/04/21 57
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

b) HTTP/1.1 persistente, sem pipeline, sem conexões em paralelo

t=0 syn
t=348
RTT ack + syn GET img4
t=20 ack + GET html
RTT
tt(html)=8ms GET img5
t=40 t=448
(simplificado!)
t=48 ack + GET img1
RTT
t=68 tt(img1)=80ms fin
t=548
(simplificado!) ack + fin
RTT
ack
t=568
t=148 ack + GET img2

t=168 tt(img2)=80ms
(simplificado!)

t=248 ack + GET img3

T.b.total = 548 ms (ou 568 ms contando com fecho conexão)

28/04/21 58
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

28/04/21 59
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48

28/04/21 60
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1 / GET Img2 / ... / GET img5

28/04/21 61
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1 / GET Img2 / ... / GET img5
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148

28/04/21 62
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1 / GET Img2 / ... / GET img5
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148 tt(img2)=80ms

t=228

28/04/21 63
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40
(simplificado!)
t=48 ack + GET img1 / GET Img2 / ... / GET img5
RTT
t=68 tt(img1)=80ms
(simplificado!)

t=148 tt(img2)=80ms

t=228
tt(img3)=80ms

t=308

28/04/21 64
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 t=308
(simplificado!)
t=48 ack + GET img1 / GET Img2 / ... / GET img5
RTT
t=68 tt(img1)=80ms t=388
(simplificado!)

t=148 tt(img2)=80ms t=468 fin

RTT ack + fin
ack
t=488
t=228
tt(img3)=80ms

t=308

28/04/21 65
 Dados: RTT = 20 ms
6 Objectos à { html, img1, img2, img3, img4, img5 }
tt (html) = 8 ms tt(img) = 80 ms

c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo

t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 t=308
(simplificado!)
t=48 ack + GET img1 / GET Img2 / ... / GET img5
RTT
t=68 tt(img1)=80ms t=388
(simplificado!)

t=148 tt(img2)=80ms t=468 fin

RTT ack + fin
ack
t=488
t=228
tt(img3)=80ms

t=308
T.c.total = 468 ms (ou 488 ms contando com fecho conexão)
28/04/21 66
Cookies: informação de estado
A maioria dos sites Web usa cookies
Exemplo:
l Susana acede sempre à Internet
Quatro componentes:
a partir do seu PC
1) Linha com cookie no cabeçalho da
mensagem HTTP response l visita um site de comércio

2) Linha com cookie no cabeçalho da electrónico pela primeira vez

mensagem HTTP request l quando o primeiro pedido chega
3) Ficheiro com cookies mantido na ao servidor Web, o servidor
máquina do utilizador, gerido pelo gera:
seu browser
l Um Identificador (ID) único
4) Uma base de dados de suporte do
lado servidor Web l Uma entrada na base de
dados de suporte para esse
ID

28/04/21 Universidade do Minho 67

 Cookies: informação de estado
client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
28/04/21 usual http response
Universidade msg
do Minho action 68
Cookies: informação de estado
efeitos colaterias
O que os cookies permitem:
l autorização Os Cookies e a privacidade:
l cabaz de compras l os cookies ensinam muito aos
servidores a respeito dos
l sugestões ao utilizador
utilizadores e seus hábitos
l informação de sessão por
l o utilizador pode fornecer
utilizador (ex: Web e-mail)
nome e e-mail ao servidor

Como manter “estado”:

l entidades protocolares: guardam estado por
emissor/recetor entre transações distintas
l cookies: forma como as mensagens http
transportam a informação de estado

28/04/21 Universidade do Minho 69

Web caches (servidor proxy)
Objectivo: satisfazer o pedido do cliente sem envolver o servidor HTTP alvo

l O utilizador configura o cliente

HTTP (browser) para aceder à
Web através de um servidor
proxy proxy
HT
TP e st
l O browser enviar todas as req server r eq
u
HT ues T P e
HTTP request messages para o client TP t HT
r es ons p origin
es
servidor proxy pon
se T Pr server
HT
t
l Se o objeto requerido está na u es
cache do proxy o servidor proxy r eq se
P n
retorna o objeto TT po
H r es
T P
l Senão o servidor proxy contacta HT
o servidor HTTP alvo, reenvia-lhe
a HTTP request message, client origin
aguarda a resposta que retorna
server
ao browser

28/04/21 Universidade do Minho 70

Web caching
l o servidor proxy/cache tem de Porquê Web caching?
atuar simultaneamente como
cliente e como servidor l reduz o tempo de resposta para
l são tipicamente instalados pelos os pedidos dos clientes
ISP ou pelas próprias instituições l reduz o tráfego nos links de
(universidades, empresas, ISP acesso ao exterior (os mais
residenciais, etc)
problemáticos para a instituição).
l Internet está povoada de caches:
permitem que fornecedores de
conteúdos mais “pobres”
disponibilizem efetivamente os
seus conteúdos (mas isso
também as redes de partilha de
ficheiros P2P)

28/04/21 Universidade do Minho 71

Exemplo de Caching
Pressupostos

l Tamanho médio dos objetos = 100,000 bits origin

l Taxa média de pedidos efectuados pelos browsers servers
da instituição para servidores HTTP = 15/sec public
Internet
l Tempo médio de atraso desde o pedido HTTP até à
chegada da resposta = 2 sec

Consequências
1.54 Mbps
access link
l Utilização da LAN = 15%
(15 pedidos/sec).(100Kbits/pedido)/(10Mbps) institutional
network
l Utilização do Link de acesso = 99% 1 Gbps LAN
(15 pedidos/sec).(100Kbits/pedido)/(1.54Mbps)
l Total delay =
= Internet delay + access delay + LAN delay
= 2 sec + minutes + milliseconds
28/04/21 Universidade do Minho 72
Exemplo de Caching (cont)

Solução possível
l Aumentar a largura de banda do link origin
de acesso para 10 Mbps servers
public
Internet
Consequência
l Utilização da LAN = 15%
l Utilização do Link de Acesso = 15%
1.54 Mbps
154 Mbps
l Total delay = Internet delay + access access link
delay + LAN delay
institutional
= 2 sec + msecs + msecs network
1 Gbps LAN

l É habitualmente muito dispendioso

fazer o upgrade do link de acesso de
uma instituição

28/04/21 Universidade do Minho 73

Exemplo de Caching (cont)
Solução possivel: instalar o Web
Proxy
l Se a taxa de acerto for de 0.4 origin
servers
public
Consequências Internet
l 40% dos pedidos serão satisfeitos
imediatamente
l 60% dos pedidos terão que ser
redirecionados para o servidor HTTP 1.54 Mbps
respetivo access link
l A utilização do link de acesso será reduzida institutional
para 60% resultando em atrasos network
negligenciáveis (10 msec) 1 Gbps LAN
l total avg delay = local web
= Internet delay + access delay + LAN cache
delay
= .6*(2.01) secs + .4*10msec < 1.4
secs
28/04/21 Universidade do Minho 74
GET Condicional
l Objectivo: não enviar o objecto se cache servidor
a cópia mantida em cache está
actualizada HTTP request msg
If-modified-since:
l cache: inclui no cabeçalho do objecto
<date>
pedido HTTP, a data da cópia não foi
guardada na cache modificado
If-modified-since: HTTP response
HTTP/1.0
<date>
304 Not Modified
l servidor: resposta não contém
nenhum objecto se a cópia
mantida em cache estiver HTTP request msg
actualizada: If-modified-since:
objecto
HTTP/1.0 304 Not <date>
modificado
Modified
HTTP response
HTTP/1.0 200 OK
<data>
28/04/21 Universidade do Minho 75
Exercício
l Pretende-se estimar o atraso na recepção de um documento Web usando o
protocolo HTTP. Sabemos que o atraso de ida-e-volta entre cliente e servidor é 4
ms, que o débito do caminho que une o cliente ao servidor é 1024 Kbps e que
cada segmento TCP contém no máximo 128 bytes de dados. Desprezam-se os
tempos de transmissão dos cabeçalhos; em particular, despreza-se o tempo de
transmissão dos segmentos que não contêm dados pertencentes ao documento
Web. As respostas às alíneas seguintes devem ser ilustradas com diagramas
espaço-tempo
l Se o documento consistir num único objecto base com 2048 bytes, a memória de
recepção TCP for ilimitada e o TCP utilizar o mecanismo de arranque lento ("slow-start"),
mudando para a fase de "congestion avoidance" quando a janela atinge os 4 segmentos,
determine o atraso na recepção do documento, desde o instante em que o cliente
estabelece contacto com o servidor até que o documento é recebido na totalidade.
l Assuma, agora, que o documento Web contém 4 imagens que são referenciadas no
objecto base. Cada imagem contém 1024 bytes e a versão de HTTP usada é não-
persistente (1.0) suportando um máximo de 2 sessões paralelas. Determine o atraso até
à recepção do documento, considerando que a largura de banda disponível é repartida
equitativamente entre sessões paralelas.
l Considere agora que usa a versão 1.1 do protocolo HTTP primeiro sem possibilidade de
pedidos em sequência (“pipelining”) e depois com pipelining.

28/04/21 Universidade do Minho 76

 HTTP2
Comunicações por Computador
Mestrado Integrado em Engenharia Informática
3º ano/2º semestre
2017/2018

Disponível online (grátis):hpbn.co/http2

Slides: bit.ly/http2-opt
28/04/21 Universidade do Minho 77
Desempenho HTTP/1.*
l Como melhorar o desempenho do HTTP/1.*?
l Quais as melhores práticas, simples e eficazes, que têm sido
usadas com regularidade?
l Reduzir o número de consultas ao DNS (DNS Lookups)

l Reutilizar conexões TCP

l Utilizar CDNs (Content Delivery Network)

l Minimizar o número de redireccionamentos HTTP (HTTP Redirects)

l Eliminar bytes desnecessários nos pedidos HTTP (cabeçalhos)

l Comprimir os artefactos na transmissão (compressão corpo)

l Cache dos recursos do lado do cliente

l Eliminar o envio de recursos desnecessários

Problemas de desempenho do HTTP/1.*

Application Paralelismo limitado

● O paralelismo está limitado ao número de conexões
HTTP/1.x ● Na prática, mais ou menos 6 conexões por origem
TCP UDP

Link layer
Head-of-line blocking
● Bloqueio do cabeça de fila, acumula pedidos em queue e atrasa
a solicitação por parte do cliente
● Servidor obrigado a responder pela ordem (ordem restrita)

Overhead protocolar é elevado

● Metadados do cabeçalho não são compactados
● Aproximadamente 800 bytes de metadados por pedido, mais os
cookies
Problemas de desempenho do HTTP/1.*
l Paralelismo é limitado pelo número de conexões...

~6 parallel downloads per origin

l Cada conexão implica overhead de handshake inicial

l Se for HTTPS, ainda tem mais um overhead do handshake TLS
l Cada conexão gasta recursos do lado do servidor
l As conexões competem umas com as outras
HTTP/1.* - Truques do lado do servidor
l Porque não subdividir em N sub-domínios, em vez de um
único domínio por servidor? (domain sharding)
l Aumenta o paralelismos --- passamos a ter 6 conexões por subdomínio
l Aumenta as consultas ao DNS...
l Mais servidores, competição nas conexões, complexidade nas aplicações
l Reduzir pedidos à concatenar objetos (concatenated assets)
l Vários CSS ou vários JS num único objeto! Resulta...
l Atrasa o processamento no cliente, pode dificultar o uso da cache

l Incluir recursos em linha no HTML (inline objects)

l Os mesmos objetivos do anterior: reduzir pedidos, antecipar conteúdos...

l Os mesmos problemas: atrasa processamento no cliente, dificulta o uso da

cache
HTTP2
l Em meados de 2009, a Google inicia o seu projeto SPDY!
l Objetivo nº1: reduzir em 50% o tempo de carregamento de página
(PLT Page Load Time)
l Outros objetivos:
l Evitar que os autores Web tenham de mexer nos conteúdos
l Minimizar o tempo de implantação e as alterações na infraestrutura
l Desenvolver em parceria com a comunidade Open Source
l Teste com dados reais que validem ou invalidem o protocolo
l Clientes: Firefox, Opera e Chrome aderiram rapidamente...
l Servidores: Twitter, Facebook, e Google, claro!...
l E o IETF (Internet Engineering Task Force)?
l Teve de ir atrás, a reboque, e formar um grupo de trabalho HTTP/2
 HTTP2
l Normalizado em menos de 3 anos!! Muita pressão...

CALL FOR DRAFT

PROPOSALS 17
DRAFT
00

2009 2011 2013 2015

Mid 2009: SPDY introduced as an experiment by google

Mar, 2012: Firefox 11 had support, turned on by default in version 13
Mar, 2012: Call for proposals for HTTP/2 – resulted in 3 proposals but SPDY was chosen as the basis for H/2
Nov, 2012: First draft of HTTP/2 (based on SPDY)
Aug, 2014: HTTP/2 draft-17 and HPACK draft-12 are published
Aug, 2014: Working Group last call for HTTP/2
Feb, 2015: (IESG) Internet Engineering Steering Group approved HTTP/2
©2015 AKAMAI | FASTER FORWARDTM
HTTP2
l HTTP2 é uma extensão e não uma substituição do HTTP/1.1
l Não se mexe nos métodos, URLs, headers, códigos de resposta, etc.

l Semântica – para a aplicação – deve é a mesma!

l Não há alterações na API aplicacional...

l Alvo à as limitações de desempenho das versões anteriores

l Primeiras versões do HTTP foram desenhadas para serem de fácil
implementação!
l Clientes HTTP/1.* obrigados a lançar várias conexões em paralelo
para baixar a latência.
l Não há compressão nem prioridades

l Mau uso da conexão TCP de suporte!...

HTTP2 – Tudo num único slide!
1. Uma única conexão TCP!

2. Request → Stream
o Streams são multiplexadas!
o Streams são priorizadas!

3. Camada de “framing”
binário
o Priorização
o Controlo de Fluxo
o Server push

4. Compressão do cabeçalho
(HPACK)
HTTP2 – “Framing” binário

= Mensagens HTTP são divididas em

uma ou mais frames
o HEADERS para metadados
o DATA para dados (payload)
o RST_STREAM para cancelar
o ...

= Cada frame tem um cabeçalho

comum
o 9-byte, com tamanho à cabeça
o De parsing fácil e eficiente
HTTP2 – “Framing” binário
l Terminologia HTTP2
l Stream – um fluxo bidirecional de dados, dentro de uma conexão, que pode carregar uma ou mais mensagens
l Mensagem - Uma sequência completa de frames que mapeiam num pedido ou numa resposta HTTP
l Frame – A unidade de comunicação mais pequena no HTTP2, contendo um cabeçalho que no mínimo identifica a
Stream a que pertence
HTTP2 – fluxo de dados
l Fluxo de dados numa conexão HTTP2

As streams são multiplexadas porque as frames pode ser intercaladas

umas com as outras!
= Todas as frames (ex: HEADERS, DATA, etc.) são enviadas numa única conexão TCP
= A frames são entregues por prioridades, tendo em conta os pesos das streams e as
dependências entre elas!
= As frames DATA estão sujeitas a um controlo de fluxo por stream e por conexão
HTTP2 – Tipos de frames
l As frames definidas no RFC7540 são:
l HEADERS -- headers de um pedido ou de uma resposta

l DATA – corpo dos objetos (dados)

l PRIORITY – define a prioridade da stream para o originador

l RST_STREAM – permite o término imediato da stream

l SETTINGS – para definir parâmetros de configuração

SETTINGS_HEADER_TABLE_SIZE, SETTINGS_ENABLE_PUSH,
SETTINGS_MAX_CONCURRENT_STREAMS, SETTINGS_INITIAL_WINDOW_SIZE,
SETTINGS_MAX_FRAME_SIZE, SETTINGS_MAX_HEADER_LIST

l PUSH_PROMISE – permite o push de conteúdos

l WINDOW_UPDATE – permite reajuste da janela de fluxo da stream
l CONTINUATION – para prolongar frames como HEADERS ou outros
l
28/04/21
PING, GOAWAY... Universidade do Minho 89
HTTP2 – Compressão do cabeçalho
l HPACK

l Valores literais (texto) são codificados com código de Huffman estático

l Tabela indexação estática à por ex: “2” corresponde a “method: GET”
l Tabela indexação dinâmica à Valores enviados anteriormente pode ser indexados!
HTTP2 – Server “push”

GET /product/123
Server: “You asked for /product/123, but
/product/123 you’ll need app.js, product-photo-1.jpg, as
well… I promise to deliver these to you. That
/app.js
is, unless you decline or cancel.”
/product-photo-1.jpg

l Maior granularidade no envio de recursos

l Evita o inlining e permite caching eficiente dos recursos
l Permite multiplexar e definir prioridades no envio dos recursos
l Precisa de controlo de fluxo, para o cliente dizer basta/quero mais
HTTP2 – Server “push”
l Há espaço para estratégias de “Server push” inteligente
l Ex: implementação Jetty

1. Servidor observa o tráfego de entrada

a. Constrói um modelo de dependências baseado no campo
Referer do cabeçalho (ou outras):
i. e.g. index.html → {style.css, app.js}

2. Servidor inicia um push inteligente de acordo com

as dependências que aprendeu
a. client → GET index.html
b. server → push style.css, app.js, index.html
HTTP2 – Controlo de fluxo
I want image geometry and preview, and I’ll
fetch the rest later...

GET /product-photo.jpg ➔ Client: “I want first 20KB of photo.jpg”

/product-photo.jpg ➔ Server: “Ok, 20KB… pausing stream
WINDOW_UPDATE
until you tell me to send more.”
➔ Client: “Send me the rest now.”
/product-photo.jpg

l Permite ao cliente fazer uma pausa na stream e retomar o envio mais tarde
l Controlo de fluxo baseado num sistema de créditos (janela):
l Cada frame do tipo DATA decrementa o valor
l Cada frame do tipo WINDOW_UPDATE atualiza o valor
HTTP2 – priorização
l Priorização é fundamental para um rendering eficiente!
l Com HTTP2, o cliente define as prioridade e faz logo os pedidos;
cabe ao servidor entregar os conteúdos com a prioridade certa

time
GET index.html
High
Priority
GET style.css

Low GET hero.jpg Requests are initiated as soon as each

Priority resource is discovered
GET other.jpg
Responsibility is on the server to
deliver the bytes in the right order!
HTTP2 – pesos e dependências
l Exemplo: stream A deve ter 12/16 e a B 4/16 dos recursos totais
l Exemplo: stream D deve ser entregue antes da stream C

= Cada stream pode ter um peso

o [1-256] integer value

= Cada stream pode ter uma

dependência
o … uma outra stream ID
HTTP2 – pesos e dependências
l Ex: Pesos e dependências definidos na biblioteca “nghttp2”
l 5 PRIORITY frames para criar
5 streams adormecidas 3, 5, 7, 9 e 11
e respetivas dependências
Id=0
l A stream 0 não existe (apenas raíz) 1
201
l O HTML base à stream 11 101

l CSS, JS referenciados no Id=3 Id=5 Id=7

<head> à stream 3, peso 2
1 1
l CSS,JS referenciados no
<body> à stream 5, peso 2 Id=11 Id=9
l Images à stream 11, peso 12

l Outros à stream 11, peso 2

28/04/21 Universidade do Minho 96
HTTP2 – Negociação protocolar
l Três formas que o cliente tem para usar HTTP2 (não podendo
assumir que todos os servidores são HTTP2):

1. Começando em HTTP/1.* e pedido ”upgrade” da conexão

l Semelhante ao mecanismo usado para os WebSockets
2. Usando HTTPS e negociando o protocolo HTTP2 durante o
handshake TLS inicial
3. Sabendo que o servidor é HTTP2 – envia sequencia inicial HTTP2

NOTA: A Google e outros defendiam que destes três mecanismos só

se deveria usar sempre o 2 (HTTPS). Foi o IETF que impôs os
restantes...
28/04/21 Universidade do Minho 97
HTTP2 – Negociação protocolar
l http:// pode ser servido tanto em HTTP/1.* como em HTTP2
l Mecanismo de Upgrade de uma conexão HTTP/1.*:

1. Cliente começa em HTTP1.1 e

pede upgrade para HTTP2

2. Settings codificados em BASE64

3. Servidor declina pedido,

respondendo em HTTP/1.1

4. Servidor aceita pedido para HTTP2

e começa Framing binário
HTTP2 – Negociação protocolar
l https:// pode ser servido quer em HTTP/1.* ou HTTP2
l Com HTTPS, negoceia-se o protocolo na fase de Handshake do
TLS, ao mesmo tempo que se migra para conexão segura:
HTTP2 – Negociação protocolar
l É possível começar logo em HTTP2 se e só se o cliente souber
que o servidor fala HTTP2:

l Enviar a sequência de 24 octetos:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

l Que corresponde a “"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n")”, logo

seguido de uma frame de SETTINGS para definer os parâmetros da
conexão HTTP2
HTTP2 – Testes
l Fazer demo!

l Experimentar URLs:
l https://http2.akamai.com/demo
l http://www.http2demo.io/
l https://http2.golang.org/serverpush

l Usar o magnífico nghttp2 (http://nghttp2.org/)

Exemplo:
$ nghttp -vv -a -n -y -s https://http2.golang.org/serverpush
Relembrar o exercício HTTP
c) HTTP/1.1 persistente, com pipeline, sem conexões em paralelo
t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT
tt(html)=8ms
t=40 t=308
(simplificado!)
t=48 ack + GET img1 / GET Img2 / ... / GET img5
RTT
t=68 tt(img1)=80ms t=388
(simplificado!)

t=148 tt(img2)=80ms t=468 fin

RTT ack + fin
ack
t=488
t=228
tt(img3)=80ms

t=308
T.c.total = 468 ms (ou 488 ms contando com fecho conexão)
28/04/21 102
Relembrar o exercício HTTP
d) HTTP2 múltiplas streams numa mesma conexão com Server Push
t=0 syn
RTT ack + syn
t=20 ack + GET html
RTT Servidor antecipa necessidade e faz PUSH PROMISE
t=40 de GET img1 / GET Img2 / ... / GET img5

Os vários objetos a enviar são

multiplexados na mesma conexão, fin
em múltiplas streams, ack + fin
partidos em pedaços, ack
designados por frames

28/04/21 103
QUIC
l Controlo de congestão, cifragem e parte do HTTP2 muda-se
para o QUIC que vai correr sobre UDP...
l Nasce o HTTP/3

HTTP/2 QUIC

HTTP/2 HTTP/2

TLS QUIC
TCP UDP
IP IP
 HTTP

Aplicações Web:
Suporte HTTP para Web Services
Conceitos práticos

28/04/21 Universidade do Minho 105

Aplicações Web: conceitos
l Protocolo HTTP - Hypertext Transfer Protocol
l É stateless por concepção!… Só com Cookies se ultrapassa isso!…
l Passa por firewalls ou por servidores intermediários Proxy/Cache…

HTTP Request
Browser Web Server Acesso via
HTTP Reply
Sistema
INTERNET /var/www/cgi-bin/… Operativo

/var/www/html/…

/var/www/icons/…
Web Pages

Páginas HTML,
l Cliente HTTP (Browser) faz “rendering” de HTML com imagens… Imagens,
l Servidor HTTP (Web Server) base serve apenas conteúdos estáticos… Exec. output,
28/04/21 Universidade do Minho etc 106
Aplicações Web: conceitos
l Web Applications
Como construir aplicações mais interactivas (tipo Desktop) sobre este modelo?
– Extensões do lado do cliente: External Viewers Plug-Ins Client Side Scripting
– Extensões do lado do servidor: Server Side Includes, Server Side Scripting

HTTP Request
Browser Web Server
HTTP Reply
HTML5/CSS3 INTERNET Files: HTML, IMG…
JavaScript
Microsoft Silverlight PHP (*.php) (mod_php)
Adobe Flash Java Server Pages (*.jsp *.jsf)
JavaFX
ASP/ASP.NET (*.asp *.aspx)
PDF Viewer
Python (*.py)
…….
Ruby (*.rb *.rbw)
…….
28/04/21 Universidade do Minho 107
Aplicações Web: REST API Design
l Lista de operações sobre um RECURSO (ex: livros) é definida
aproveitando a semântica dos métodos do protocolo HTTP:
POST GET PUT DELETE
Recurso (Create) (Read) (Update) (Delete)
/livros Cria um novo Lista todos os Atualiza um Apaga todos os
livro; livros; conjunto de livros livros;
Pedido: objeto Pedido: vazio; passados no Pedido: vazio;
“livro” no corpo Resposta: corpo do pedido Resposta:
do HTTP listagem de HTTP sucesso ou
Request! livros; insucesso;
/livros/01 Normalmente Devolve o objeto Se existe livro 01 Se existe livro 01
não é usado! que representa o então atualiza-o; apaga-o;
Erro! livro com id 01 Senão dá erro!

CRUD (Create / Read / Update / Delete)

[email protected] GCOM – DI – Universidade do Minho 108
Ferramentas úteis

$ curl ... $ http ...

(command line) (command line)

POSTMAN WireShark

Google Chrome PlugIn Packet Sniffer (just in case)

https://curl.haxx.se
https://httpie.org
https://www.getpostman.com/docs/introduction
https://www.wireshark.org
28/04/21 Universidade do Minho 109
Teste
l Teste com “Developer Tools” do browser

28/04/21 Universidade do Minho 110

Teste
l Teste com o Plug In POSTMAN do Google Chrome!

Resultado!

28/04/21 Universidade do Minho 111

REST API: GET (read all)
$ http GET http://ec2-54-175-51-193.compute-1.amazonaws.com/PHPWebServices/biblioteca.php/livros -v
GET /PHPWebServices/biblioteca.php/livros HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: ec2-54-175-51-193.compute-1.amazonaws.com
User-Agent: HTTPie/0.9.4

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 53
Content-Type: application/json
Date: Mon, 28 Nov 2016 13:34:09 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.23 (Amazon) OpenSSL/1.0.1k-fips PHP/5.6.28
X-Powered-By: PHP/5.6.28

[
{
"autor": "Camoes",
"id": "01",
"titulo": "Os Lusiadas"
}
]
28/04/21 Universidade do Minho 112
API REST: GET (read one)
$ http GET http://ec2-54-175-51-193.compute-1.amazonaws.com/PHPWebServices/biblioteca.php/livros/01 -v
GET /PHPWebServices/biblioteca.php/livros/01 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: ec2-54-175-51-193.compute-1.amazonaws.com
User-Agent: HTTPie/0.9.4

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 51
Content-Type: application/json
Date: Mon, 28 Nov 2016 13:39:20 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.23 (Amazon) OpenSSL/1.0.1k-fips PHP/5.6.28
X-Powered-By: PHP/5.6.28

{
"autor": "Camoes",
"id": "01",
"titulo": "Os Lusiadas"
}

28/04/21 Universidade do Minho 113

API REST: POST (create new)
$ http POST http://ec2-54-175-51-193.compute-1.amazonaws.com/PHPWebServices/biblioteca.php/livros id=02
autor="Eça de Queirós" titulo="Os Maias" -v
POST /PHPWebServices/biblioteca.php/livros HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 71
Content-Type: application/json
Host: ec2-54-175-51-193.compute-1.amazonaws.com
User-Agent: HTTPie/0.9.4

{
"autor": "Eça de Queirós",
"id": "02",
"titulo": "Os Maias"
}

HTTP/1.1 201 Created

Connection: Keep-Alive
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Mon, 28 Nov 2016 13:42:23 GMT
Keep-Alive: timeout=5, max=100
Location:
Server: Apache/2.4.23 (Amazon) OpenSSL/1.0.1k-fips PHP/5.6.28
X-Powered-By: PHP/5.6.28
28/04/21 Universidade do Minho 114
API REST: PUT (modify one)
$ http PUT http://ec2-54-175-51-193.compute-1.amazonaws.com/PHPWebServices/biblioteca.php/livros/02
id=02 autor="Eca de Queiros" titulo="Os Maias" -v
PUT /PHPWebServices/biblioteca.php/livros/02 HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 61
Content-Type: application/json
Host: ec2-54-175-51-193.compute-1.amazonaws.com
User-Agent: HTTPie/0.9.4

{
"autor": "Eca de Queiros",
"id": "02",
"titulo": "Os Maias"
}

HTTP/1.0 500 Internal Server Error

Connection: close
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Mon, 28 Nov 2016 13:50:27 GMT
Server: Apache/2.4.23 (Amazon) OpenSSL/1.0.1k-fips PHP/5.6.28
X-Powered-By: PHP/5.6.28

28/04/21 Universidade do Minho 115