La solicitud de Chrome dice "Se muestran cabeceras provisionales":
La primera vez que el navegador envía esta solicitud, esta se bloquea y no se recibe respuesta. Cuando se pide al navegador que envíe esta solicitud de nuevo, informará de esta advertencia si no se ha respondido a la misma solicitud anterior, ¿dónde estará el problema?
Me lo he encontrado varias veces en el proyecto, y voy a presentar diferentes escenarios respectivamente:
1. Los encabezados provisionales se muestran al acceder al navegador de todos los clientes:
Cómo gestionarlo: Revisa la página donde se activó la solicitud para ver si la presentación del formulario y la solicitud de ajax se activan al mismo tiempo.
Por ejemplo, definir un botón, tipificar es submit, y definir un evento ajax para el botón;
Este escenario es uno de los que ha surgido en nuestro proceso de desarrollo anterior
2. Aparecen algunos navegadores cliente
Cómo gestionarlo: llama a la chrome://net-internals/#events de Chrome, luego reactiva la solicitud y después revisa el registro de solicitudes donde aparecen los encabezados provisionales;
Mira si existen delegate_blocked_by palabras clave; Esto se debe generalmente a que el complemento del navegador o el software del cliente interceptan la solicitud; La situación que tenemos es interceptada por WebSense Endpoint;
Si este es el caso, básicamente puede ignorarse, el problema del propio cliente; Puedes considerar desinstalar el plugin o software y probar de nuevo para ver si sigue apareciendo; Si sigue ocurriendo, por favor comprueba si entra en las siguientes condiciones
3. Todos los clientes han tenido este error de forma aleatoria y ocasional, y si es así, a menudo es un problema del lado del servidor
Método de manejo: Solucionar problemas según la arquitectura de despliegue. Por ejemplo, algunos procesos clave en nuestra arquitectura de despliegue son nginx----> aplicación de pasarela----> balanceador de carga F5----> servidor de aplicaciones (docker)
Puedes solucionar problemas capa por capa; la forma sencilla es escribir directamente una solicitud de curl for loop con el comando del servidor shell, y primero llamar al servidor de aplicación más bajo (si temes que la presión no sea suficiente, puedes presionarlo con varios hilos); Presiona hacia arriba a turnos; En el proceso de pruebas de estrés, puedes ver en tiempo real si la solicitud se quedará atascada; Si se encuentra, es muy probable que este sea el problema:
Actualmente, nos hemos encontrado con dos situaciones: una es a nivel F5, algunas solicitudes se balancean sin éxito en el servidor de aplicaciones; También hay una situación en la que se queda atascado en el nivel nginx;
Solución: La estrategia de balanceo de carga a nivel F5 ha cambiado de L4 de rendimiento a estándar.
Plan de manejo de situación atascada a nivel nginx: En realidad no he participado en esta situación, y entiendo que modificar muchas configuraciones de nginx no tiene efecto, y al final simplemente matar y reinstalar, así que no encontré el punto clave
Mi propia solución, como el Fiddler 4 que uso no está cerrado normalmente, así que volví a abrir Fiddler 4, intenté solicitar la web y volvió a la normalidad, en ese momento volví a cerrar Fiddler 4.
|
Publicado en 22/5/2018 22:57:55
|
|
|
|
