Een Chrome-verzoek zegt "Voorlopige headers worden getoond":
De eerste keer dat de browser dit verzoek verstuurt, wordt het verzoek geblokkeerd en wordt er geen reactie ontvangen. Wanneer de browser opnieuw wordt gevraagd dit verzoek te versturen, zal de browser deze waarschuwing rapporteren als op hetzelfde vorige verzoek niet is beantwoord, dus waar ligt het probleem?
Ik ben het meerdere keren tegengekomen in het project, en ik zal respectievelijk verschillende scenario's introduceren:
1. Voorlopige headers verschijnen bij het openen van de browser van alle clients:
Hoe hiermee om te gaan: Controleer de pagina waar het verzoek is geactiveerd om te zien of het indienen van het formulier en het ajax-verzoek tegelijkertijd worden geactiveerd.
Definieer bijvoorbeeld een knop, typ is submit, en definieer een ajax-event voor de knop;
Dit scenario is een van die scenario's die zich voordeden in ons eerdere ontwikkelingsproces
2. Sommige clientbrowsers verschijnen
Hoe hiermee om te gaan: Bel de chrome://net-internals/#events van Chrome, activeer het verzoek opnieuw en controleer vervolgens het logboek van verzoeken waar Provisorische headers worden weergegeven;
Kijk of delegate_blocked_by trefwoorden bestaan; Dit komt meestal doordat de browserplug-in of de software van de client het verzoek onderschept; De situatie die we hebben wordt onderschept door WebSense Endpoint;
Als dat het geval is, kan het in feite genegeerd worden, het probleem van de cliënt zelf; Je kunt overwegen de plugin of software te verwijderen en het opnieuw proberen om te zien of het nog steeds verschijnt; Als het nog steeds voorkomt, kijk dan of het onder de volgende voorwaarden valt
3. Alle clients hebben deze fout willekeurig en af en toe gehad, en als dit het geval is, is het vaak een server-side probleem
Afhandelingsmethode: Probleemoplossing op basis van de implementatiearchitectuur. Een paar belangrijke processen in onze deployment-architectuur zijn bijvoorbeeld nginx----> gatewayapplicatie----> F5 load balancer----> applicatieserver (docker)
Je kunt laag voor laag troubleshooten; de eenvoudige manier is om direct een for loop curl-verzoek te schrijven met het server shell-commando, en eerst de laagste applicatieserver aan te roepen (als je bang bent dat de druk niet genoeg is, kun je hem met meerdere threads indrukken); Druk op zijn beurt omhoog; Tijdens het stresstesten kun je in realtime zien of het verzoek blijft hangen; Als het wordt gevonden, is het zeer waarschijnlijk dat dit het probleem is:
Op dit moment zijn we twee situaties tegengekomen: één op F5-niveau, waarbij sommige verzoeken onsuccesvol worden gebalanceerd naar de applicatieserver; Er is ook een situatie waarin het vastzit op het nginx-niveau;
Oplossing: De load balancing-strategie op F5-niveau is veranderd van performance L4 naar standaard.
Nginx-niveau vastzittend situatieafhandelingsplan: Ik heb hier eigenlijk niet aan deelgenomen, en ik begrijp dat het aanpassen van veel configuraties van nginx geen effect heeft, en uiteindelijk gewoon doden en opnieuw installeren, dus ik heb het belangrijkste punt niet gevonden
Mijn eigen oplossing, omdat de Fiddler 4 die ik gebruik niet normaal gesloten is, dus opende ik Fiddler 4 opnieuw, probeerde de website aan te vragen en die keerde terug naar normaal, op dat moment sloot ik Fiddler 4 weer.
|
Geplaatst op 22-05-2018 22:57:55
|
|
|
|
