Por alguna especulación de Firefox CP

fondo

Etéreo, aparte estudiado con Chrom-sincronización y firefox-tiempo. Abrir Baidu cuando lo encuentra,
200 https://www.baidu.com/ toma 238 milisegundos
200 https://www.baidu.com/img/superlogo_c4d7df0a003d3db9b65e9ef0fe6da1ec.png?where=super toma 38 milisegundos
200 HTTPS: // www.baidu.com/img/superlogo_c4d7df0a003d3db9b65e9ef0fe6da1ec.png?qua=high&where=super toma 107 milisegundos
dos solicitudes después del mismo se puede decir de por qué el último es mucho tiempo 2,8 veces tanto de él?
Echar un vistazo a la primera petición:

Mira la segunda petición:

Análisis de la segunda solicitud

1. el bloqueo de 36 ms, porque la agrupación de conexiones Firefox agota, para esperar una liberación de la conexión de inactividad
2. DNS 1 milisegundo de tiempo, tan poco tiempo para establecer una conexión TCP no es suficiente, por lo que el juez leyó la caché de Firefox del DNS (por defecto), o leer la caché del sistema operativo
3. Procesados ​​conector de 9 ms, lean la siguiente petición de cabecera, Cache-Control: no-cache, se Wayward CDN. Conexión: keep-alive, parece que no hay keep-alive
4. TLS establecimiento de 21 milisegundos, el costo de la seguridad, TLS apretón de manos es muy frustrante, esta actuación ha sido muy bueno
5. Enviar, espere a recibir todos los derechos de HTTP, y una petición de no ampliar la brecha

¿Por mantenimiento de conexión no tenga efecto

Antes de comenzar la segunda solicitud, la primera petición recibida no se ha completado, por lo que no keep-alive.
Pero me encontré con la parte posterior de otra nueva solicitud de conexión TCP reconstruido, supongo grupo de subprocesos navegador no es lo suficientemente grande como para reciclar algún tipo de conexión para acceder a otros sitios.

Referencia

[1] el control del navegador Firefox, DNS tiempo de caché
[2] documentos monitor de red Firefox
[3] TLS de Microsoft Office
[4] HTTPS protocolo detallado