Avec une application .NET / C # J'essaie de télécharger des données à partir d'une API HTTP. Même si le délai d'attente de l'instance HTTPCLIENT est défini sur 30 minutes, la demande sera extrêmement plus rapide. Aujourd'hui, j'ai appris que cela est dû au fait que le .NET httpClient n'envoie aucun TCP Garder des paquets vivants. (C'est pourquoi je peux télécharger des données à partir de cette API à Chrome, comme prouvé avec Wireshark, chrome envoie ces paquets tandis que httpClient ne le fait pas.)
Voici comment j'avais espéré obtenir les données JSON de l'API: P>
this.httpclient = new HttpClient(); [...] result = await this.httpclient.GetAsync(url);
3 Réponses :
http (contrairement à WebSockets) ne prend pas en charge les messages Keepalive, donc je suppose que vous faites référence à Même si le délai d'attente de l'instance httpClient est défini sur 30 minutes, la demande sera extrêmement plus rapide. Aujourd'hui, j'ai appris que cela est dû au fait que le .NET httpClient n'envoie aucun TCP Garder des paquets vivants.
Je ne pense pas que ce soit correct. L'envoi de paquets Keepalive n'aurait aucun effet sur le comportement du délai d'attente. En particulier, lorsque le service Keepalive atteint le serveur et qu'elle envoie la réponse ACK, aucune application n'est même notifiée - en effet, ils ne peuvent pas être informés, car il n'y a pas de données dans un TCP Keepalive ou ACK.
Maintenant, j'ai fait des recherches, mais je ne pouvais pas savoir comment envoyer ces pings vivants.
Les paquets Keepalive TCP sont problématiques pour deux raisons: elles ont des valeurs défectueuses maladroites et elles peuvent être abandonnées par des routeurs intermédiaires. Les défaillances maladroites incluent un Minimum minimum de 2 heures et aucune garantie de la capacité de changer cela; Heureusement, les versions de Windows modernes permettent de définir une minuterie de maintenance par connexion et permettent de la définir à une valeur bien inférieure.
Cela dit, je ne connais pas un moyen d'accéder au socket SO_KEEKEALIVE -Style TCP Keekalive Paquet.
sous-jacent pour un httpclient . Le httpclient a un pipeline de gestionnaires qui se terminent (ces jours-ci) dans un sockethtttphandler , qui est en fait responsable de la connexion de socket. Mais je ne vois aucune API sur ce type qui vous permettra d'atteindre directement pour manipuler la prise ou fournir une prise déjà configurée pendant la construction.
Merci d'avoir souligné cela, j'aurais attendu qu'il existe un moyen d'ajuster les paramètres de la prise en quelque sorte. En ce qui concerne l'effet sur le comportement du délai d'attente, je peux clairement voir que l'utilisation de ces paquets conservés a une incidence sur la question de savoir si les demandes fonctionnent ou échouent. (J'ai mis à jour ma question avec une capture d'écran)
C'est ce que je vais supposer se produire:
Vous appelez Je devinerais que la quantité de traitement prend plus de 2 minutes puis décède autour de cette marque, correcte? Si vous ne configurez pas votre serveur pour permettre des réponses qui prennent plus de 2 minutes, le serveur va déposer votre connexion ... et pour une bonne raison.
Les prises sont extrêmement chères. Vos points d'extrémité doivent renvoyer les données le plus rapidement possible, car s'ils ne pouvaient pas exécuter dans des problèmes de sabre de socket.
Par exemple, le délai d'attente par défaut pour une application ASP.NET CORE est de 2 minutes. Vous pouvez trouver cela dans le web.config par défaut situé ici:
Tout ce que ces choses à propos de "TCP continuent en vie" vous parlez n'a rien à voir avec ce que vous vivez. Aucun n'est-ce jamais. attendre ceci.httpclient.getaSync (URL); et le point final à URL fait une quantité massive de traitement ... non seulement télécharger un fichier ou données tout le temps, mais simplement traiter des données ne renvoyant rien jusqu'à ce qu'il soit fini.
Oui en effet, le point final fait beaucoup de traitement. Malheureusement, je n'ai aucun contrôle sur le serveur, je ne peux rien changer là-bas et je doute que ma demande d'augmentation du délai d'attente a-t-il entendu (le donnera si). Cependant, je peux difficilement croire que cela n'a rien à voir avec ce que je ressens car je peux clairement voir que je reçois des données lorsque le client envoie des paquets vivants de TCP, et qu'il n'y a pas de réponse au tout quand ils ne sont pas là . Cela peut être reproduit avec divers clients.
Ok alors - mais juste pour que vous sachiez, le problème n'est pas avec httpclient , c'est avec autre chose. Que ce soit votre ordinateur, votre réseau ou votre serveur. Mon argent est toujours sur le serveur. Bonne chance!
Alors maintenant, je finis par répondre à ma propre question car je viens de trouver une solution super simple qui fonctionne réellement: en fait, j'ai utilisé où la baseurl est la racine du document commun de toutes mes demandes que j'envoie à travers A pour boucle.