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:

[Link]

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/[Link] HTTP/1.1 Linha do pedido

Host: [Link]
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.
[Link]/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)

costa@[Link] 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 [Link]
GET / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: [Link]
User-Agent: HTTPie/2.0.0
....
(ver os últimos 4 slides, para mais exemplos com API REST,
eo site do HTTPie [Link] )

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 [Link]/DI/[Link]
(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 [Link]
executado no sistema [Link] 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/[Link] 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

[Link] = 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

[Link] = 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
[Link] = 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):[Link]/http2

Slides: [Link]/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 [Link], [Link], as
well… I promise to deliver these to you. That
/[Link]
is, unless you decline or cancel.”
/[Link]

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. [Link] → {[Link], [Link]}

2. Servidor inicia um push inteligente de acordo com

as dependências que aprendeu
a. client → GET [Link]
b. server → push [Link], [Link], [Link]
HTTP2 – Controlo de fluxo
I want image geometry and preview, and I’ll
fetch the rest later...

GET /[Link] ➔ Client: “I want first 20KB of [Link]”

/[Link] ➔ Server: “Ok, 20KB… pausing stream
WINDOW_UPDATE
until you tell me to send more.”
➔ Client: “Send me the rest now.”
/[Link]

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 [Link]
High
Priority
GET [Link]

Low GET [Link] Requests are initiated as soon as each

Priority resource is discovered
GET [Link]
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 [Link]
l [Link]
l [Link]

l Usar o magnífico nghttp2 ([Link]

Exemplo:
$ nghttp -vv -a -n -y -s [Link]
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
[Link] = 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/[Link] (*.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)

costa@[Link] GCOM – DI – Universidade do Minho 108
Ferramentas úteis

$ curl ... $ http ...

(command line) (command line)

POSTMAN WireShark

Google Chrome PlugIn Packet Sniffer (just in case)

[Link]
[Link]
[Link]
[Link]
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 [Link] -v
GET /PHPWebServices/[Link]/livros HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: [Link]
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 [Link] -v
GET /PHPWebServices/[Link]/livros/01 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: [Link]
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 [Link] id=02
autor="Eça de Queirós" titulo="Os Maias" -v
POST /PHPWebServices/[Link]/livros HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 71
Content-Type: application/json
Host: [Link]
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 [Link]
id=02 autor="Eca de Queiros" titulo="Os Maias" -v
PUT /PHPWebServices/[Link]/livros/02 HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 61
Content-Type: application/json
Host: [Link]
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