No entiendo bien si publico datos de formulario http desde el navegador al servidor, ¿el protocolo aún necesita hacer un enlace de tres vías (syn-ack-data) o solo funciona para las solicitudes GET http?
No entiendo bien si publico datos de formulario http desde el navegador al servidor, ¿el protocolo aún necesita hacer un enlace de tres vías (syn-ack-data) o solo funciona para las solicitudes GET http?
Respuestas:
Tanto HTTP GET como HTTP POSTS usan TCP. Si está preguntando si un POST también requiere un protocolo de enlace TCP de 3 vías (syn-synack-ack), es como cualquier otra conexión TCP. El protocolo de enlace TCP es necesario antes de que cualquier protocolo de aplicación (como HTTP) comience a funcionar.
Para su información, su apretón de manos de tres vías es incorrecto; debería ser "syn-synack-ack"
AÑADIR:
Si el navegador utiliza el protocolo QUIC (Quick UDP Internet Connections, pronunciado rápido. Propuesto por Google) para HTTP, es posible evitar el protocolo de enlace TCP de 3 vías. Pero AFAIK lo soportó en Chrome y Google.
La mayoría del software prefiere HTTP / 2, que sigue siendo TCP, pero con muchas características, utiliza una conexión persistente y luego un protocolo de enlace de 3 vías una vez para cada servidor de servidor.
Si se utiliza este protocolo, cualquier solicitud, incluso GET, puede evitar el hanshake de 3 vías.
Si está preguntando en un sentido general, entonces la respuesta es definitivamente "sí", cualquier método HTTP (como POST) requiere una conexión TCP, y la única forma de iniciar una conexión TCP es usar el protocolo de enlace de tres vías.
Sin embargo, si está preguntando en un caso específico, tal vez si está capturando su propio tráfico y no ve el apretón de manos de 3 vías después de enviar contenido a un sitio web, entonces la respuesta es un poco menos simple. Tendremos que discutir algunos conceptos relacionados con HTTP antes de que podamos responder adecuadamente ...
En la versión original de HTTP1.0, cada objeto que solicitaba desde una página web requería que se formara una nueva conexión TCP para cada objeto. Tome el siguiente sitio web simplista que incluye texto y dos imágenes:
<HTML>
<HEAD>
<TITLE>My Title</TITLE>
</HEAD>
<BODY>
Stack Exchange Rules!
<IMG SRC="a.gif">
<IMG SRC="b.gif">
</BODY>
</HTML>
En HTTP1.0 tradicional, cargar este sitio web en su navegador requeriría tres conexiones TCP (cada una con su propio protocolo de enlace de 3 vías y cierre de 4 vías).
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
Tenga en cuenta que hay 27 paquetes arriba, solo para descargar tres elementos: la página HTML en sí (index.html), imagen a.gif e imagen b.gif. (en realidad habría más de 27 paquetes, pero para ahorrar espacio vertical, solo incluí los ACK en el apretón de manos de 3 vías y el cierre de 4 vías, y omití los ACK dentro del flujo de datos)
Para mejorar la eficiencia de HTTP, se introdujo una característica llamada "Connection Keepalive", que permite que HTTP reutilice la misma conexión TCP para solicitar múltiples objetos. La transferencia anterior se reduciría a lo siguiente:
HTTP 1.1 con conexión Keepalive
--> 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 solo se usó una única conexión TCP para solicitar los tres objetos. Esta vez, solo tomó 13 paquetes, una gran mejora de los 27 de antes.
La última mejora a HTTP que debemos analizar es una característica llamada Canalización. Esta característica aumentó aún más la eficiencia de HTTP, al hacer que el Cliente pueda solicitar múltiples opciones a la vez, sin esperar a recibir el objeto solicitado anteriormente. Deja que te enseñe:
HTTP1.1 con canalización
--> SYN
SYN ACK <--
--> ACK
--> GET /index.html
--> GET /a.gif
--> GET /b.gif
<index.html> <--
<a.gif> <--
<b.gif> <--
--> FIN
ACK <--
FIN <--
--> ACK
Todavía estamos usando solo una conexión TCP, y todavía solo estamos usando 9 paquetes. Sin embargo, no tenemos que esperar el Tiempo de ida y vuelta (RTT) que toma entre el Cliente y el Servidor entre pedir y recibir cada objeto. Si necesita una analogía, imagine que está en un restaurante y necesita sal, pimienta y salsa de tomate. ¿Es más eficiente pedirle a su mesero / a los tres artículos a la vez, o pedirlos de uno en uno y esperar a que vuelvan antes de hacer la siguiente solicitud?
(La canalización no está directamente relacionada con su pregunta, pero a menudo se describe junto con Keepalives y otras características de eficiencia HTTP, por lo que decidí incluirla en esta respuesta para completarla)
Ahora finalmente podemos volver a su pregunta:
¿Se requiere un protocolo de enlace de tres vías TCP para una POST HTTP?
Si abre una conexión a un servidor web y descarga una página web utilizando el método GET, y ese servidor web admite la conexión de keepalive. Las solicitudes posteriores a ese servidor web, incluido el método POST, podrían simplemente reutilizar la conexión TCP ya existente. Por lo tanto, esa POST particular no requeriría un nuevo protocolo de enlace de 3 vías, ya que los datos se transferirían en una conexión TCP ya existente.
Connection Keepalive, sin embargo, no tiene una duración infinita. Entonces, si después de descargar la página web, esperó un tiempo antes de enviar su POST, es posible que la conexión TCP original ya se haya cerrado y, en este caso, su navegador tendría que abrir una nueva conexión TCP para PUBLICAR sus datos, lo que obviamente requeriría comenzar con el apretón de manos de 3 vías.
Dado que muchos navegadores y servidores web usan diferentes temporizadores durante cuánto tiempo desean que su función "keepalive de conexión" mantenga las conexiones activas, no podría proporcionarle números confiables sobre cuánto tiempo suele pedir.