Impossible de lire les données de la connexion de transport: une connexion existante a été fermée de force par l'hôte distant
J'ai un serveur d'application et parfois, lorsque le client essaie de se connecter, j'obtiens l'erreur suivante:
NOTE: le "couldn't get stream from client or login failed" est un texte que j'ai ajouté dans catch statement
Et la ligne à laquelle il s'arrête ( sThread : ligne 96 ) est :
tcpClient = (TcpClient)client;
clientStream = tcpClient.GetStream();
sr = new StreamReader(clientStream);
sw = new StreamWriter(clientStream);
// line 96:
a = sr.ReadLine();
Qu'est-ce qui peut causer ce problème? Notez que cela n'arrive pas tout le temps
12 réponses
Cette erreur signifie généralement que la machine cible est en cours d'exécution, mais que le service auquel vous essayez de vous connecter n'est pas disponible. (Soit il s'est arrêté, s'est écrasé, ou est occupé avec une autre demande.)
En Anglais: La connexion à la machine (hôte distant/serveur/PC sur lequel le service s'exécute) a été effectuée mais comme le service n'était pas disponible sur Cette machine, la machine ne savait pas quoi faire avec la requête.
Si la connexion à la machine n'était pas disponible, vous verriez une erreur différente. J'oublie ce que c'est, mais c'est le long des lignes de "Service inaccessible" ou "indisponible".
Modifier-ajouté
Il est possible que cela soit causé par un pare-feu bloquant le port, mais étant donné que vous dites que c'est intermittent ("parfois quand le client essaie de se connecter"), c'est très peu probable. Je n'ai pas inclus cela à l'origine parce que je l'avais exclu mentalement avant de répondre.
J'ai reçu cette erreur lors de l'appel d'un service web. La question était également liée à la sécurité au niveau des transports. Je pourrais appeler le service web via un projet de site Web, mais en réutilisant le même code dans un projet de test, j'obtiendrais une WebException contenant ce message. L'ajout de la ligne suivante avant d'effectuer l'appel a résolu le problème:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
Modifier
System. Net. ServicePointManager. SecurityProtocol - Cette propriété sélectionne la version de Secure Sockets Layer (SSL) ou de Transport Protocole TLS (Layer Security) à utiliser pour les nouvelles connexions qui utilisent Protocole HTTPS (Secure Hypertext Transfer Protocol) uniquement; existant les connexions ne sont pas modifiées.
Je crois que la configuration SecurityProtocol est importante lors de la prise de contact TLS lors de la sélection de la version du protocole.
Poignée de main TLS - ce protocole est utilisé pour échanger toutes les informations requises par les deux parties pour l'échange de la données d'application réelles par TLS.
ClientHello - un client envoie un message ClientHello spécifiant la version de protocole TLS la plus élevée qu'il prend en charge ...
ServerHello - le serveur répond avec un message ServerHello, contenant la version de protocole choisie ... La version de protocole choisie doit être la plus élevée prise en charge par le client et le serveur. Par exemple, si le client prend en charge TLS version 1.1 et le serveur prend en charge la version 1.2, la version 1.1 devrait la version 1.2 ne doit pas être sélectionnée.
Je ne sais pas lequel des correctifs dans ces articles de blog a aidé, mais l'un d'eux a trié ce problème pour moi ...
Et
Mon scénario spécifique était que le service D'application Azure avait la version minimale de TLS changée en 1.2
Je ne sais pas si c'est la valeur par défaut à partir de maintenant, mais le changer à 1.0 l'a fait fonctionner.
Vous pouvez accéder au paramètre dans "Paramètres SSL".
Les appels aux services HTTPS de l'un de nos serveurs ont également lancé l'exception" Impossible de lire les données de la connexion de transport : une connexion existante a été fermée de Force ". Le service HTTP, cependant, a bien fonctionné. Utilisé Wireshark pour voir qu'il s'agissait d'un échec de la poignée de main TLS. Finalement, la suite de chiffrement sur le serveur devait être mise à jour.
Pour une raison quelconque, la connexion au serveur a été perdue. Il se peut que le serveur ait explicitement fermé la connexion ou qu'un bogue sur le serveur ait provoqué sa fermeture inattendue. Ou quelque chose entre le client et le serveur (un commutateur ou un routeur) a laissé tomber la connexion.
C'est peut-être le code du serveur qui a causé le problème, et ce n'est peut-être pas le cas. Si vous avez accès au Code du serveur, vous pouvez y mettre du débogage pour vous indiquer quand les connexions client sont fermées. Cela pourrait donner vous une indication de quand et pourquoi les connexions sont abandonnées.
Sur le client, vous devez écrire votre code pour prendre en compte la possibilité que le serveur échoue à tout moment. C'est comme ça: les connexions réseau sont intrinsèquement peu fiables.
Cela n'aidera pas pour les problèmes intermittents, mais peut être utile pour d'autres personnes ayant un problème similaire.
J'avais cloné une machine virtuelle et l'avais démarrée sur un réseau différent avec une nouvelle adresse IP mais je n'avais pas changé les liaisons dans IIS. Fiddler me montrait "impossible de lire les données de la connexion de transport: une connexion existante a été fermée de force par l'hôte distant" et IE me disait "activer TLS 1.0, TLS 1.1 et TLS 1.2 dans les paramètres avancés". Modification de la liaison à la nouvelle adresse IP adresse résolu pour moi.
J'ai eu ce problème dans le passé. J'utilise PostgreSQL et quand j'exécute mon programme, Parfois il se connecte et parfois il jette une erreur comme ça.
Lorsque j'expérimente mon code, je mets mon code de connexion à la toute première ligne sous le formulaire public. Voici un exemple:
Avant:
public Form1()
{
//HERE LIES SOME CODES FOR RESIZING MY CONTROLS DURING RUNTIME
//CODE
//CODE AGAIN
//ANOTHER CODE
//CODE NA NAMAN
//CODE PA RIN!
//Connect to Database to generate auto number
NpgsqlConnection iConnect = new NpgsqlConnection("Server=localhost;Port=5432;User ID=postgres;Password=pass;Database=DB");
iConnect.Open();
NpgsqlCommand iQuery = new NpgsqlCommand("Select * from table1", iConnect);
NpgsqlDataReader iRead = iQuery.ExecuteReader();
NpgsqlDataAdapter iAdapter = new NpgsqlDataAdapter(iQuery);
DataSet iDataSet = new DataSet();
iAdapter.Fill(iDataSet, "ID");
MessageBox.Show(iDataSet.Tables["ID"].Rows.Count.ToString());
}
Maintenant:
public Form1()
{
//Connect to Database to generate auto number
NpgsqlConnection iConnect = new NpgsqlConnection("Server=localhost;Port=5432;User ID=postgres;Password=pass;Database=DB");
iConnect.Open();
NpgsqlCommand iQuery = new NpgsqlCommand("Select * from table1", iConnect);
NpgsqlDataReader iRead = iQuery.ExecuteReader();
NpgsqlDataAdapter iAdapter = new NpgsqlDataAdapter(iQuery);
DataSet iDataSet = new DataSet();
iAdapter.Fill(iDataSet, "ID");
MessageBox.Show(iDataSet.Tables["ID"].Rows.Count.ToString());
//HERE LIES SOME CODES FOR RESIZING MY CONTROLS DURING RUNTIME
//CODE
//CODE AGAIN
//ANOTHER CODE
//CODE NA NAMAN
//CODE PA RIN!
}
Je pense que le programme doit d'abord lire la connexion avant de faire quoi que ce soit, je ne sais pas, corrigez-moi si je me trompe. Mais selon mon recherche, ce n'est pas un problème de code - c'était en fait de la machine elle-même.
Bon Codage!
J'ai eu une application tierce (Fiddler) en cours d'exécution pour essayer de voir les demandes envoyées. La fermeture de cette application l'a corrigé pour moi
Cela a résolu mon problème. J'ai ajouté cette ligne avant que la demande soit faite:
System.Net.ServicePointManager.Expect100Continue = false;
Il semblait qu'il y avait un proxy dans le chemin du serveur qui ne supportait pas le comportement 100-continue.
System.Net.ServicePointManager.Expect100Continue = false;
Ce problème se produit parfois en raison du serveur proxy implémenté sur le serveur web. Pour contourner le serveur proxy en mettant cette ligne avant d'appeler l'envoyer service.
Nous avons eu un problème très similaire où le site web d'un client essayait de se connecter à notre service API Web et d'obtenir le même message. Cela a commencé à se produire complètement à l'improviste quand il n'y avait pas eu de changements de code ou de mises à jour Windows sur le serveur où IIS était en cours d'exécution.
Dans notre cas, il s'est avéré que le site web appelant utilisait une version de. Net qui ne supportait que TLS 1.0 et que, pour une raison quelconque, le serveur sur lequel notre IIS s'exécutait s'est arrêté semblait avoir cessé d'accepter Appels TLS 1.0. Pour diagnostiquer que nous devions activer explicitement TLS via le Registre sur le serveur IIS, puis redémarrer ce serveur. Ce sont les touches reg:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
If that doesn't do it, you could also experiment with adding the entry for SSL 2.0:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
Ma réponse à une autre question ici a ce script powershell que nous avons utilisé pour ajouter des entrées:
Remarque: activer les anciens protocoles de sécurité n'est pas une bonne idée, la bonne réponse dans notre cas était d'amener le site Web client à mettre à jour son code pour utiliser TLS 1.2, mais les entrées de Registre ci-dessus peuvent aider diagnostiquer le problème en premier lieu.