Não entendo muito bem se eu postar dados de formulário http do navegador no servidor, o protocolo ainda precisa fazer handshake de três vias (syn-ack-data) ou funciona apenas para solicitações HTTP GET?
Não entendo muito bem se eu postar dados de formulário http do navegador no servidor, o protocolo ainda precisa fazer handshake de três vias (syn-ack-data) ou funciona apenas para solicitações HTTP GET?
Respostas:
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.
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.