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 une application serveur et parfois, lorsque le client tente de se connecter, j'obtiens le message d'erreur suivant:
NOTE: le message "ne peut pas obtenir le flux du client ou la connexion a échoué" est un texte que j'ai ajouté dans une déclaration catch
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();
Quelle peut être la cause de ce problème? Notez que ça n'arrive pas tout le temps
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. (S’il s’est arrêté, s’est écrasé ou est occupé par une autre demande.)
En anglais: La connexion à la machine (hôte/serveur/PC distant sur lequel le service s'exécute) a été établie mais, comme le service n'était pas disponible sur cette machine, la savoir quoi faire avec la demande.
Si la connexion à la machine n'était pas disponible, une erreur différente serait affichée. J'oublie ce que c'est, mais c'est dans les lignes de "Service inaccessible" ou "Indisponible".
Modifier - ajouté
Il est IS possible que cela soit causé par un pare-feu bloquant le port, mais étant donné que vous dites que c'est intermittent ("parfois lorsque le client tente de se connecter"), c'est très peu probable. Je n’avais pas inclus cela à l’origine car j’avais éliminé cela 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 du transport. Je pourrais appeler le service Web via un projet de site Web, mais si je réutilisais le même code dans un projet de test, je recevais une exception WebException contenant ce message. L'ajout de la ligne suivante avant de passer 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 utilisant le fichier Schéma HTTPS (Secure Hypertext Transfer Protocol) uniquement; existant les connexions ne sont pas modifiées.
Je pense que la configuration SecurityProtocol est importante lors de l'établissement de la liaison TLS lors de la sélection de la version du protocole.
TLS Handshake - Ce protocole permet d'échanger toutes les informations requises par les deux côtés pour l'échange des 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 par un message ServerHello, contenant la version de protocole choisie ... La version de protocole choisie doit être la version la plus élevée prise en charge par le client et le serveur. Par exemple, si le client prend en charge la version 1.1 de TLS et que le serveur prend en charge la version 1.2, la version 1.1 doit être sélectionnée. la version 1.2 ne devrait pas être sélectionnée.
Mon scénario spécifique était que la version minimale de TLS du service d’application Azure avait été remplacée par la version 1.2.
Je ne sais pas si c'est désormais la valeur par défaut, mais le remettre à la version 1.0 l'a fait fonctionner.
Vous pouvez accéder au paramètre dans "Paramètres SSL".
Je ne sais pas lequel des correctifs de ces articles de blog a aidé, mais l'un d'entre eux a réglé ce problème pour moi ...
L'astuce qui m'a aidé était de cesser d'utiliser un WebRequest et d'utiliser un HttpWebRequest. HttpWebRequest me permet de jouer avec 3 paramètres importants:
et
http://briancaos.wordpress.com/2012/06/15/an-exex-connection-was-forcibly-closed-by-the-remote-Host/
- ETAPE 1: Désactivez KeepAlive
- STEP 2: Définissez ProtocolVersion sur Version10
- ETAPE 3: Limiter le nombre de points de service
Les appels aux services HTTPS depuis l’un de nos serveurs lançaient également 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é. Wireshark utilisé pour voir que c'était un échec de négociation TLS. Finalement, la suite de chiffrement sur le serveur devait être mise à jour.
Cela ne va pas aider pour les problèmes intermittents, mais peut être utile pour d'autres personnes ayant un problème similaire.
J'avais cloné un VM et l'avais démarré sur un autre réseau avec une nouvelle adresse IP, mais je n'avais pas modifié 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 Paramètres avancés" . Changer la liaison à la nouvelle adresse IP l'a résolu pour moi.
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 perdu la connexion.
C'est peut-être le code serveur qui est à l'origine du problème, mais ce n'est peut-être pas le cas. Si vous avez accès au code du serveur, vous pouvez y mettre un peu de débogage pour vous dire quand les connexions client sont fermées. Cela pourrait vous donner une idée du moment et de la raison pour lesquels les connexions sont abandonnées.
Sur le client, vous devez écrire votre code pour prendre en compte la possibilité d’une défaillance du serveur à tout moment. C'est comme ça: les connexions réseau sont intrinsèquement peu fiables.
J'ai ce problème dans le passé. J'utilise PostgreSQL et quand j'exécute mon programme, il se connecte parfois et parfois il génère une erreur comme celle-ci.
Lorsque j'expérimente avec mon code, je place 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());
}
À PRÉSENT:
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 mes recherches, ce n'est pas un problème de code - cela vient en fait de la machine elle-même.
Bon codage!
Cela a résolu mon problème. J'ai ajouté cette ligne avant la demande est faite:
System.Net.ServicePointManager.Expect100Continue = false;
Il semblait y avoir un proxy dans la manière du serveur qui ne supportait pas le comportement 100-continue.
System.Net.ServicePointManager.Expect100Continue = false;
Ce problème survient parfois en raison de la mise en œuvre du serveur proxy sur le serveur Web. Pour contourner le serveur proxy en mettant cette ligne avant d'appeler le service d'envoi.
Essayez de vérifier si vous pouvez établir une poignée de main en premier lieu. J'avais déjà eu ce problème lors du téléchargement d'un fichier et j'ai seulement compris que le problème était la route inexistante lorsque j'ai supprimé le téléchargement et vérifié s'il pouvait se connecter en fonction des paramètres.
J'ai eu une application tierce (Fiddler) en cours d'exécution pour essayer de voir les demandes envoyées. Fermeture de cette application corrigé pour moi
Nous avions un problème très similaire: le site Web d'un client essayait de se connecter à notre service API Web et de recevoir le même message. Cela a commencé à se produire de manière totalement anarchique alors qu'il n'y avait eu aucun changement de code ou aucune mise à jour Windows sur le serveur sur lequel 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 ne prenant en charge que TLS 1.0. Pour une raison quelconque, le serveur sur lequel notre IIS était arrêté semblait avoir cessé d’accepter les 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 clés 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 les entrées:
NOTE: Activer les anciens protocoles de sécurité n'est pas une bonne idée. Dans notre cas, la bonne solution consistait à demander au site Web du client de mettre à jour son code pour utiliser TLS 1.2, mais les entrées de registre ci-dessus peuvent aider à diagnostiquer le problème dans le premier. endroit.
Si vous avez un certificat https sur le domaine, assurez-vous que la liaison https est liée au nom de domaine dans IIS. Dans IIS -> Sélectionnez votre domaine -> Cliquez sur Liaisons La fenêtre de liaisons de sites s'ouvre. Ajouter une liaison pour https.
Avait un problème similaire et obtenait les erreurs suivantes en fonction de l'application que j'ai utilisé et si nous avons contourné le pare-feu/équilibreur de charge ou non:
La liaison HTTPS vers [bla] (pour le n ° 136) a échoué. System.IO.IOException 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
ReadResponse () a échoué: le serveur n'a pas renvoyé de réponse complète pour cette demande. Le serveur a renvoyé 0 octet.
Le problème s'est avéré que le certificat de serveur SSL a été oublié et n'a pas été installé sur plusieurs serveurs.
La raison pour laquelle cela m'arrivait était que j'avais une dépendance récursive dans mon fournisseur de DI. Dans mon cas j'avais:
services.AddScoped(provider => new CfDbContext(builder.Options));
services.AddScoped(provider => provider.GetService<CfDbContext>());
Le correctif consistait simplement à supprimer le deuxième enregistrement de service limité
services.AddScoped(provider => new CfDbContext(builder.Options));