Le service lance soudainement SocketException sans modifications apparentes

Question

Le 17 janvier 09:32, un de nos services a soudainement lancé 500 erreurs. C'est un service d'adaptateur à un service tiers et nous utilisons un HttpClient pour faire un POST (Nous faisons un GET à notre service avec des paramètres de chaîne de requête et nous transférons cela à l'application tierce en utilisant un POST et des paramètres dans le corps). Quand je poste manuellement au service de tiers en utilisant un postier ou une boucle, il a bien répondu. Donc c'était un problème avec notre service. C'est le service .NET qui utilise le middleware OWIN, semblable à la façon dont je travaille. Le problème était qu'il y a quelque temps, le framework .NET a été mis à niveau de 4.5.2 à 4.6 et quand il le fait en VS, il ajoute un élément <httpRuntime targetFramework="4.5.2"/> au web.config. Il s'agit de faire un effort pour préserver le comportement existant de l'application au cas où il y aurait des changements de rupture entre les versions du framework. La personne qui a mis à jour n'a pas réalisé et laissé dans l'élément dans le web.config. Il a bien fonctionné pendant des siècles, puis soudainement dans tous les environnements en même temps (y compris localement) s'est brisé. Je pensais que ça devait être quelque chose de temporel dans le framework .NET mais rouler l'horloge de mon système ne le résout pas! Que puis-je rechercher, des idées sur ce mystère? Il suffit de faire passer le web.config à 4.6 pour le corriger, mais j'ai été chargé de l'étudier.

Voici l'erreur sous-jacente:

System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host 
    at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult) 
    at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult) 

et c'est le code, il jette à _client.PostAsync avec ce qui précède que le InnerException. _client est un System.Net.Http.HttpClient

public async Task<CalculateResponse> Calculate(CalculateRequest request) 
{ 
    var env = new RequestEnvelope { Body = { RblsCalculate = request } }; 
    request.LoginId = _username; 
    request.Password = _password; 

    var body = XmlConvert.SerializeObject(env); 

    var content = new StringContent(body, Encoding.UTF8, "application/soap+xml"); 
    var httpResponse = await _client.PostAsync(_endpointPath, content); 

    var response = XmlConvert.ToObject<ResponseEnvelope>(await httpResponse.Content.ReadAsStreamAsync()); 

    return response?.Body?.RblsCalculateResponse; 
} 

Le tiers n'a pas fait de changements, des mises à jour de Windows n'a pas couru (cela effectué simultanément 5 environnements différents). Nous n'avons fait aucun changement. Lorsque nous déployons, nous déployons à une nouvelle instance à chaque fois, le web.config n'a pas changé sur les serveurs et le déploiement précédent était des semaines auparavant.

J'ai passé en revue certaines des modifications à 4.6 et il y a quelques changements potentiellement cassants autour de HttpClient si n'utilisant pas TLSv1.0 + comme protocole, j'ai vérifié using Wireshark sur un des serveurs et nous employons TLSv1.2 . Mais cela n'explique pas pourquoi il s'est soudainement arrêté.

Mise à jour - Sortie de trace.log pour le traçage SSL/TLS selon la suggestion @Trumpi

System.Net.Sockets Verbose: 0 : [16292] Data from Socket#52088480::PostCompletion 
System.Net.Sockets Verbose: 0 : [16292] 00000000 : 16 03 01 00 88 01 00 00-84 03 01 58 A4 49 35 01 : ...........X.I5. 

Mise à jour 2 - Suppression des journaux inutiles ^^

Answer 1

Fait intéressant, j'ai rencontré un problème très similaire la semaine dernière (même si ce n'était pas avec .NET Core). J'avais appelé un point de terminaison API pendant des mois via un travail quotidien et tout à coup, je recevais la même erreur. Il m'a fallu plusieurs jours pour trouver un correctif, mais pour moi, l'ajout de la ligne de code suivante a corrigé le problème. Vous pourriez probablement l'ajouter à la première ligne de votre méthode.

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; 

Answer 2

Mon premier instinct est que C'est un problème avec l'établissement de liaison TLS et le fait que le service tiers abandonne la connexion parce qu'il n'a pas réussi à établir une liaison. La version de TLS pourrait être un problème, comme vous l'avez noté. Ne pas être capable de trouver un chiffrement compatible pourrait être un autre problème.

Je suis tombé sur this blog post qui décrit comment écrire les informations de prise de contact sur le fichier de trace. Voici la section qu'il ajoute au fichier web.config:

<system.diagnostics> <trace autoflush="true"/> <sources> <source name="System.Net" maxdatasize="1024"> <listeners> <add name="TraceFile"/> </listeners> </source> <source name="System.Net.Sockets" maxdatasize="1024"> <listeners> <add name="TraceFile"/> </listeners> </source> </sources> <sharedListeners> <add name="TraceFile" type="System.Diagnostics.TextWriterTraceListener" initializeData="trace.log"/> </sharedListeners> <switches> <add name="System.Net" value="Verbose" /> <add name="System.Net.Sockets" value="Verbose" /> </switches> </system.diagnostics>

C'est le meilleur que je peux faire avec les informations contenues dans la question et j'espère que cela aide.

EDIT: Après la publication des résultats, il semble que l'appel tente de négocier une connexion TLS 1.0, que le serveur ne prend plus en charge. J'ai mis les détails dans un commentaire ci-dessous.