"N'osez pas douter du Code, vous devez douter du Code" notez une analyse de délai de demande réseau

Résumé：Ce positionnement,C'est assez compliqué,Et parfois les gens ne pensent pas,Parce que la même interface,C'est bon de changer d'environnement,J'ai peur de douter du Code;Mais les circonstances problématiques,Un autre connecteur serait parfait,Je dois encore douter du Code

Cet article est partagé par Huawei Cloud Community《Analyse du temps d'arrêt d'une demande de réseau》,Auteur：xiewenci .

Phénomène problématique

LancementhttpDemande,Interface de service arrière/v5/iot/11c9c88e6fb26bead43b75514dc380eb/routing-rule/rules?limit=10&marker=ffffffffffffffffffffffff&offset=0,J'ai attendu.,Retour à la réponse dans une minute,Et le Code chinois est affiché

Processus d'analyse

1.Délimitez d'abord,Changer le même Code de version dans un environnement normal et anormal,Tester la même interface,Mais l'environnement normal est normal,Environnement anormal ou attente1Minutes,Donc je pense que c'est un problème environnemental,Et ensuite,Prends le sac.

2.Capturer des paquets dans des environnements anormaux et normaux respectivement,Voir la figure ci - dessous pour plus de détails sur le flux：

Informations sur le flux pour un environnement anormal

Informations sur le flux dans un environnement normal

D'après le graphique, l'environnement normal est , Une fois la réponse envoyée par le serveur terminée , Retour normal du client ACK, Ensuite, il est initié par le client FINDemande de rupture de chaîne. L'environnement d'exception est une fois que le serveur a envoyé la réponse , Le client a aussi répondu ACK, Mais il n'y a pas eu de demande active de rupture de chaîne ,Jusqu'àkeep-aliveAprès le temps, Demande de rupture de chaîne initiée par le serveur （ Parce que le temps de rupture active de la chaîne ）. Le phénomène est que le client attend que le serveur envoie une réponse （ Il n'a peut - être pas fini d'envoyer ）, Donc suspectez le serveur d'avoir un cache ou quelque chose comme ça , Le flux de réponse n'a pas été envoyé à temps , Alors continuez à regarder le Code

3.Voir le Code, En revenant au client ,Non.flushEtcloseFonctionnement,Les codes sont les suivants:

Et j'ai pensé que j'avais trouvé la cause du problème , Essayez de modifier le Code ,Comme suit：

AjoutéflushFonctionnement etcloseFonctionnement（C'est parti.try Vite! ）, Test final effectué , Toujours en accord avec le phénomène initial , Toujours attendre 1 La réponse ne sera pas retournée avant quelques minutes . C'est un peu déroutant , Et une analyse plus approfondie de l'obscénité , En fait, ça se voit dans le courant. , La réponse du serveur a été immédiatement retournée au client ,Comme le montre la figure ci - dessous:

Maintenant qu'on a répondu , Alors pourquoi le client continue d'attendre ？ Voici quelques points d'interrogation sur le graphique , C'est en fait un caractère chinois mal codé , Donc ici encore, on se demande si le format d'encodage a conduit le client à recevoir Content-Length La longueur ne correspond pas à la longueur de la réponse reçue , C'est - à - dire que la longueur réelle de la réponse reçue par le client est inférieure à Content-LengthLongueur, Et j'ai attendu , Alors continuez à modifier le Code

4.Modifier le Code,Le format d'encodage spécifié estUTF-8,Les codes sont les suivants:：

Remplacer la version environnementale ,Exécution des essais, La réponse est revenue immédiatement , C'est le pot de ce format de codage

Examen des causes

1. Une incohérence dans le format de codage peut entraîner une incohérence dans la longueur réelle du flux de réponse ？La réponse est certaine,Format de codage incohérent, La longueur réelle serait incohérente ,Les résultats des essais sont les suivants:：

2. Pourquoi ce problème n'est - il pas apparu avant ？ Quelle est la cause de la perte du format de codage

Voir les services d'arrière - plan jarSac,DécouvertespringLa version a été mise à jour vers5.2.21.RELEASE, Le format d'encodage par défaut n'est pas spécifié dans cette version comme UTF-8

Un service d'arrière - plan est donc nécessaire pour spécifier le format d'encodage , Ou le Service de passerelle est unifié

Résumé et réflexion

Ce positionnement,C'est assez compliqué,Et parfois les gens ne pensent pas,Parce que la même interface,C'est bon de changer d'environnement,J'ai peur de douter du Code;Mais les circonstances problématiques,Un autre connecteur serait parfait,Je dois encore douter du Code; Il y a aussi l'interface d'appel dans le conteneur ,C'est le même problème., Ça n'a rien à voir avec Internet . En fait, je devrais me calmer et réfléchir à pourquoi Le client a attendu , Pas de rupture active de la chaîne , C'est toujours vrai HTTPDétails de l'Accord, Pas assez compétent , Ce n'est qu'au milieu qu'il y a eu quelques erreurs , Besoin de consolider et d'approfondir httpInterprétation de l'accord.

Cliquez sur suivre,Pour la première fois, découvrez la nouvelle technologie Huawei Cloud~