0
219
VistasConfundido sobre el envío de solicitudes en HTTP1 y HTTP2
Aprendí que bajo HTTP1.1, la cantidad máxima de conexiones persistentes simultáneas predeterminadas por nombre de host (¿origen?) Será 6, al menos para Chrome. No estoy preguntando sobre el número exacto del límite, ya que sé que varía de un navegador a otro. Tengo más curiosidad acerca de cuándo abriremos una nueva conexión para nuevas solicitudes: ¿el navegador reutiliza la misma conexión TCP de alguna manera o siempre inicia una nueva conexión TCP a menos que no haya alcanzado el límite de solicitudes simultáneas?
Digamos que estamos usando HTTP1.1 y tenemos Connection: Keep-Alive si en el html tenemos
<script src="https://foo/foo1.js"></script> <script src="https://foo/foo2.js"></script> <script src="https://foo/foo3.js"></script> <script src="https://foo/foo4.js"></script> <script src="https://foo/foo5.js"></script> <script src="https://foo/foo6.js"></script> <script src="https://foo/foo7.js"></script>¿Cada uno de los scripts dará como resultado una nueva conexión TCP establecida o todas las solicitudes posteriores reutilizarán la primera conexión TCP establecida por la primera pestaña del script? Y si cada uno de estos scripts da como resultado una nueva conexión TCP establecida, dado que el límite del navegador para solicitudes simultáneas es de 6, ¿la séptima solicitud tiene que esperar hasta que finalice la sexta solicitud para establecer la conexión?
El ejemplo anterior se trata de iniciar solicitudes desde etiquetas HTML. ¿Qué pasa con las llamadas API hechas desde JavaScript? Vamos en nuestro javascript que tenemos
const result1 = apiCall1() const result2 = apiCall2() const result3 = apiCall3() const result4 = apiCall4() const result5 = apiCall5() const result6 = apiCall6() const result7 = apiCall7() Y supongamos que el punto final al que llegan esas llamadas API es todo api.foo.com/v1/tasks , mis preguntas son, nuevamente: cada una de las llamadas API resultará en una nueva conexión TCP establecida o todas las solicitudes posteriores reutilizarán el primera conexión TCP establecida por la primera llamada api? Y si cada una de estas llamadas api da como resultado una nueva conexión TCP establecida, dado que el límite del navegador para solicitudes simultáneas es 6, ¿la séptima solicitud tiene que esperar hasta que finalice la sexta solicitud para establecer la conexión?
Mi última pregunta es, en comparación con http1.1, ¿http2 soluciona este problema al permitir enviar muchas solicitudes al mismo tiempo a través de una sola conexión TCP?
2 Respuestas
Responde la pregunta0
¿Cada uno de los scripts dará como resultado una nueva conexión TCP establecida o todas las solicitudes posteriores reutilizarán la primera conexión TCP establecida por la primera pestaña del script?
Sí, los descargaría uno por uno y comenzaría a abrir más conexiones TCP para hacerlo, hasta un máximo de 6. La séptima solicitud tendría que esperar a que una de las conexiones se liberara antes de que pudiera descargarse.
Pero la realidad es que la primera solicitud puede haber finalizado cuando se abren las conexiones TCP posteriores, por lo que es posible que no alcance el límite de 6 para solo 6 o 7 solicitudes.
¿Qué pasa con las llamadas API hechas desde JavaScript? Vamos en nuestro javascript
Exactamente lo mismo. Límite de 6 por origen. Aunque una cosa a tener en cuenta es que ciertas solicitudes de CORS enviadas sin credenciales cuentan efectivamente como otro origen (aunque es el mismo origen real) y, por lo tanto, obtienen otras 6 conexiones.
Mi última pregunta es, en comparación con http1.1, ¿http2 soluciona este problema al permitir enviar muchas solicitudes al mismo tiempo a través de una sola conexión TCP?
Básicamente sí. No del todo al mismo tiempo debido a la forma en que funciona TCP, pero lo más cerca posible. Vea mi respuesta aquí: ¿Qué significa multiplexación en HTTP/2?
0
El proceso es simple, si asigna keep-alive, la conexión se recuerda para un apretón de manos más rápido para que un usuario pueda realizar muchas solicitudes sin tener que volver a abrir una conexión segura costosa.
Ahora siempre existirá el proceso de sincronización/reconocimiento para realizar solicitudes con el servidor. Para que el servidor responda a cada elemento que su usuario solicitó, se necesita una nueva conexión. Se omite esto un poco con caché para ayudar a su ancho de banda y disminuir las solicitudes al servidor. Todas las conexiones se terminan a pedido servido.
Entonces, en un escenario, 100 navegadores quieren acceder a su sitio, cada solicitud se ve como 1.js 2.js... La salida debe estar en orden, pero esto puede depender en gran medida de muchas cosas. Su idioma en el que está codificando en el lado del servidor, cómo se maneja, sirve y si administra alguna cola. Si realiza una solicitud que requiere un procesamiento más prolongado (se comunicará con usted en el futuro), otras solicitudes podrían continuar siempre que no esté bloqueando el ciclo de eventos (se reduce a su servidor).
A continuación puede ver el proceso para establecer una conexión con el servidor, este se dedica a todas y cada una de las solicitudes. El costo de TLS se puede mejorar, pero la solicitud inicial es costosa. 