É necessário um handshake de três vias TCP para um POST HTTP?


Respostas:


12

HTTP GET e HTTP POSTS usam TCP. Se você está perguntando se um POST também requer um handshake TCP de três vias (syn-synack-ack), ele é como qualquer outra conexão TCP. O handshake TCP é necessário antes que qualquer protocolo de aplicativo (como HTTP) comece a funcionar.

Para sua informação, seu aperto de mão de três direções está incorreto; deve ser "syn-synack-ack"

ADICIONAR:

Se o navegador usar o protocolo QUIC (Quick UDP Internet Connections, pronunciado rápido. Proposto pelo Google) para HTTP, é possível evitar o handshake TCP de três vias. Mas o AFAIK é compatível com Chrome e Google.

A maioria dos softwares prefere o HTTP / 2, que ainda é o TCP, mas com muitos recursos, ele usa conexão persistente e o handshake de três vias, feito uma vez para cada servidor servidor.

Se esse protocolo for usado, o hanshake de 3 vias pode ser evitado por qualquer solicitação, incluindo GET.


24

Se você está perguntando em um sentido geral, a resposta é definitivamente "sim", qualquer método HTTP (como POST) requer uma conexão TCP, e a única maneira de iniciar uma conexão TCP é usar o handshake de três vias.

Se, no entanto, você estiver perguntando em um caso específico, talvez se você está capturando seu próprio tráfego e não vê o handshake de três vias após enviar o conteúdo para um site, a resposta é um pouco menos simples. Teremos que discutir alguns conceitos relacionados ao HTTP antes de podermos respondê-lo adequadamente ...


Na versão original do HTTP1.0, todos os objetos solicitados em uma página da Web exigiam a formação de uma nova conexão TCP para cada objeto. Veja o site simplista a seguir, que inclui algum texto e duas imagens:

<HTML>
  <HEAD>
    <TITLE>My Title</TITLE>
  </HEAD>
  <BODY>
    Stack Exchange Rules!
    <IMG SRC="a.gif">
    <IMG SRC="b.gif">
  </BODY>
</HTML>

No HTTP1.0 tradicional, para carregar este site em seu navegador, seriam necessárias três conexões TCP (cada uma com seu próprio handshake de 3 vias e fechamento de 4 vias).

HTTP 1.0:

--> SYN
                SYN ACK <--
--> ACK

--> GET /index.html
           <index.html> <--

--> FIN
                    ACK <--
                    FIN <--
--> ACK

.

--> SYN
                SYN ACK <--
--> ACK

--> GET /a.gif
                <a.gif> <--

--> FIN
                    ACK <--
                    FIN <--
--> ACK

.

--> SYN
                SYN ACK <--
--> ACK

--> GET /b.gif
                <b.gif> <--

--> FIN
                    ACK <--
                    FIN <--
--> ACK

Observe que há 27 pacotes acima, apenas para fazer o download de três itens: a própria página HTML (index.html), imagem a.gif e imagem b.gif. (na verdade, haveria mais de 27 pacotes, mas para economizar espaço vertical, incluí apenas os ACKs no handshake de 3 vias e no fechamento de 4 vias e omiti os ACKs no fluxo de dados)

Para melhorar a eficiência do HTTP, foi introduzido um recurso chamado "Connection Keepalive", que permite ao HTTP reutilizar a mesma conexão TCP para solicitar vários objetos. A transferência acima seria reduzida para o seguinte:

HTTP 1.1 com o Keepalive de Conexão

--> SYN
                SYN ACK <--
--> ACK

--> GET /index.html
           <index.html> <--
--> GET /a.gif
                <a.gif> <--
--> GET /b.gif
                <b.gif> <--

--> FIN
                    ACK <--
                    FIN <--
--> ACK

Observe que apenas uma única conexão TCP foi usada para solicitar os três objetos. Desta vez, foram necessários apenas 13 pacotes, uma grande melhoria em relação aos 27 anteriores.

A última melhoria no HTTP que devemos discutir é um recurso chamado Pipelining. Esse recurso aumentou ainda mais a eficiência do HTTP, permitindo que o Cliente solicite várias opções ao mesmo tempo, sem esperar para receber o objeto solicitado anteriormente. Deixe-me te mostrar:

HTTP1.1 com Pipelining

--> SYN
                SYN ACK <--
--> ACK

--> GET /index.html
--> GET /a.gif
--> GET /b.gif
           <index.html> <--
                <a.gif> <--
                <b.gif> <--

--> FIN
                    ACK <--
                    FIN <--
--> ACK

Ainda estamos usando apenas uma conexão TCP e ainda usando apenas 9 pacotes. No entanto, não precisamos esperar o tempo de ida e volta (RTT) necessário entre o cliente e o servidor entre solicitar e receber cada objeto. Se você precisar de uma analogia, imagine que está em um restaurante e precisa de sal, pimenta e ketchup. É mais eficiente pedir ao garçom / garçonete todos os três itens de uma só vez ou pedir um por vez e esperar que eles voltem antes de fazer a próxima solicitação?

(O pipelining não está diretamente relacionado à sua pergunta, mas geralmente é descrito em conjunto com o Keepalives e outros recursos de eficiência HTTP, então decidi incluí-lo nesta resposta para garantir a integridade)


Agora, finalmente, podemos voltar à sua pergunta:

É necessário um handshake de três vias TCP para um POST HTTP?

Se você abrir uma conexão com um servidor da Web e baixar uma página da Web usando o método GET, e esse servidor da Web oferecer suporte à manutenção da conexão. Solicitações subsequentes para esse servidor da Web, incluindo o método POST, podem simplesmente reutilizar a conexão TCP já existente. Portanto, esse POST específico não exigiria um novo handshake de três vias, pois os dados seriam transferidos em uma conexão TCP já existente.

O Keepalive de conexão, no entanto, não tem uma duração infinita. Portanto, se depois de baixar a página da Web, você esperou um pouco antes de enviar o POST, a conexão TCP original já pode ter sido fechada e, nesse caso, seu navegador precisaria abrir uma nova conexão TCP para POST seus dados, o que obviamente exigiria o início com o aperto de mão de três vias.

Como muitos navegadores e servidores da Web usam cronômetros diferentes por quanto tempo eles desejam que o recurso "manutenção da conexão" mantenha as conexões ativas, não seria possível fornecer números confiáveis ​​sobre quanto tempo normalmente é solicitado.


11
Esta é uma resposta mais completa. Muito obrigado. Definitivamente vale a pena ser votado.
Manikandan Sigamani

11
Que tal ilustrar HTTP / 2: p?
animaacija 25/01

Na verdade, o handshake de três vias não é a única maneira de abrir conexões TCP. Para mencionar as outras formas, há pelo menos conexão simultânea de abertura e aperto de mão dividido.
21717 juhist

11
O mundo seria um lugar melhor se toda a resposta fosse detalhada como esta! Bem feito, muito bem explicado.
Dawez

Com um roteador ou proxy de otimização de TCP, o navegador pode começar a enviar dados HTTP ao ver um estabelecimento de conexão TCP falso do agente local quando o servidor ainda está estabelecendo a conexão com a parte mais externa do ambiente do cliente. E vamos pensar um minuto se um otimizador de TCP for executado no meio ou no ambiente do servidor!
enguia ghEEz

0

De fato. De qualquer forma, ainda há uma maneira de torná-lo mais eficiente - os dados podem ser colocados em pacotes SYN-SYNACK-ACK, embora até que o handshake seja concluído, os dados não possam ser usados.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.