javax.net.le protocole ssl.SSLException: erreur de Lecture: ssl=0x9524b800: I/O erreur pendant l'appel système, Connection reset by peer

nos clients commencent à voir des centaines de ces" Sslexception error - Connection reset by peer " au cours des deux dernières semaines et je ne peux pas comprendre pourquoi

  1. nous utilisons le Retrofit avec okhttp, pas de configuration spéciale

    public class OkHttpClientProvider implements IOkHttpClientProvider {

    OkHttpClient okHttpClient;

    public OkHttpClientProvider() {
        this.okHttpClient = createClient();
    }

    public OkHttpClient getOkHttpClient() {
        return this.okHttpClient;
    }

    private OkHttpClient createClient() {
        return new OkHttpClient();
    }
}

le fournisseur de services ci-dessus est un fournisseur unique. Le RestAdapter est construit en utilisant ce client injecté (nous utilisons dagger) -

RestAdapter.Builder restAdapterBuilder = new RestAdapter.Builder()
                                        .setConverter(converter)
                                        .setEndpoint(networkRequestDetails.getServerUrl())
                                        .setClient(new OkClient(okHttpClientProvider.getOkHttpClient()))
                                        .setErrorHandler(new NetworkSynchronousErrorHandler(eventBus))
                                        );

basé sur les solutions de débordement de la pile ce que j'ai trouvé -

  1. la durée de maintien en vie sur le serveur est de 180 secondes, OkHttp a un défaut de 300 secondes

  2. le serveur renvoie "Connection: close" dans son en-tête mais la requête client envoie "Connection: keepAlive"

  3. le serveur supporte TLS 1.0 / 1.1 / 1.2 et utilise Open SSL

  4. nos serveurs ont déménagé à un autre fournisseur d'hébergement récemment dans une autre géographie donc je ne sais pas si ce sont des DNS les échecs ou pas

  5. nous avons essayé de modifier des choses comme keepAlive, OpenSSL reconfiguré sur le serveur mais pour une raison ou une autre le client Android continue d'obtenir cette erreur

  6. cela se produit immédiatement et sans délai lorsque vous essayez d'utiliser l'application pour poster quelque chose ou tirer pour rafraîchir (elle ne va même pas sur le réseau ou a un délai avant que cette exception ne se produise, ce qui impliquerait que la connexion est déjà rompue). Mais l'essayer plusieurs fois d'une façon ou d'une autre "correctifs" et nous obtenons un succès. Il arrive encore plus tard

  7. nous avons invalidé nos entrées DNS sur le serveur pour voir si c'est ce qui l'a causé mais qui n'a pas aidé

  8. Il arrive le plus souvent sur la technologie LTE, mais je l'ai vu sur Wifi

Je ne veux pas désactiver keep alive parce que la plupart des clients modernes ne le font pas. Aussi, nous utilisons OkHttp 2.4 et c'est un problème sur les appareils post sandwich à la crème glacée donc je l'espère devrait s'occuper de ces questions sous-jacentes de réseautage. Le client iOS obtient également ces exceptions, mais près de 100 fois moins (le client iOS utilise AFNetworking 2.0). Je me bats pour trouver de nouvelles choses à essayer à ce point, de l'aide / des idées?

mise à jour-Ajout de la trace complète de la pile via okhttp

      retrofit.RetrofitError: Read error: ssl=0x9dd07200: I/O error during system call, Connection reset by peer
              at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:390)
              at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:240)
              at java.lang.reflect.Proxy.invoke(Proxy.java:397)
              at $Proxy15.getAccessTokenUsingResourceOwnerPasswordCredentials(Unknown Source)
              at com.company.droid.repository.network.NetworkRepository.getAccessTokenUsingResourceOwnerPasswordCredentials(NetworkRepository.java:76)
              at com.company.droid.ui.login.LoginTask.doInBackground(LoginTask.java:88)
              at com.company.droid.ui.login.LoginTask.doInBackground(LoginTask.java:23)
              at android.os.AsyncTask.call(AsyncTask.java:292)
              at java.util.concurrent.FutureTask.run(FutureTask.java:237)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
              at java.lang.Thread.run(Thread.java:818)
       Caused by: javax.net.ssl.SSLException: Read error: ssl=0x9dd07200: I/O error during system call, Connection reset by peer
              at com.android.org.conscrypt.NativeCrypto.SSL_read(Native Method)
              at com.android.org.conscrypt.OpenSSLSocketImpl$SSLInputStream.read(OpenSSLSocketImpl.java:699)
              at okio.Okio.read(Okio.java:137)
              at okio.AsyncTimeout.read(AsyncTimeout.java:211)
              at okio.RealBufferedSource.indexOf(RealBufferedSource.java:306)
              at okio.RealBufferedSource.indexOf(RealBufferedSource.java:300)
              at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:196)
              at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:191)
              at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
              at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:917)
              at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:793)
              at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:439)
              at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:384)
              at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:497)
              at com.squareup.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
              at com.squareup.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:25)
              at retrofit.client.UrlConnectionClient.readResponse(UrlConnectionClient.java:73)
              at retrofit.client.UrlConnectionClient.execute(UrlConnectionClient.java:38)
              at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:321)
              at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:240)
              at java.lang.reflect.Proxy.invoke(Proxy.java:397)
              at $Proxy15.getAccessTokenUsingResourceOwnerPasswordCredentials(Unknown Source)
              at com.company.droid.repository.network.NetworkRepository.getAccessTokenUsingResourceOwnerPasswordCredentials(NetworkRepository.java:76)
              at com.company.droid.ui.login.LoginTask.doInBackground(LoginTask.java:88)
              at com.company.droid.ui.login.LoginTask.doInBackground(LoginTask.java:23)
              at android.os.AsyncTask.call(AsyncTask.java:292)
              at java.util.concurrent.FutureTask.run(FutureTask.java:237)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
              at java.lang.Thread.run(Thread.java:818)
      ]}
36
demandé sur Rickster 2015-05-29 23:37:50

4 réponses

récemment, j'ai affronté le problème en travaillant sur un ancien code. Après googling j'ai constaté que le problème est partout, mais sans aucune résolution concrète. J'ai travaillé sur diverses parties du message d'exception et analysé ci-dessous.

Analyse:

  1. SSLException: exception avec le SSL (Secure Socket Layer), qui est implémenté dans javax.net.ssl paquet du JDK (openJDK/oracleJDK/AndroidSDK)
  2. Read error ssl=# I/O error during system call: erreur survenue lors de la lecture de le Secure socket. Cela s'est produit en utilisant les bibliothèques système natives/driver. Veuillez noter que toutes les plateformes solaris, Windows, etc. ont leurs propres bibliothèques de socket qui est utilisé par le SSL. Windows utilise la bibliothèque WINSOCK.
  3. Connection reset by peer: ce message est rapporté par la bibliothèque du système (rapports Solaris ECONNRESET, Windows rapports WSAECONNRESET), que la socket utilisée dans le transfert de données n'est plus utilisable parce qu'une connexion existante a été fermée de force par l'hôte distant. On a besoin de créer un nouveau chemin entre l'hôte et le client

Raison:

pour comprendre le problème, j'essaie de trouver la raison de la réinitialisation de la connexion et j'ai trouvé ci-dessous les raisons:

  • l'application Pair sur l'hôte distant est soudainement arrêtée, l'hôte est redémarré, l'interface réseau hôte ou distant est désactivée, ou l'hôte distant utilise une fermeture dure.
  • Cette erreur peut également se produire lorsque une connexion a été brisée en raison d'une activité de maintien en vie détectant une défaillance alors qu'une ou plusieurs opérations sont en cours. Les opérations en cours échouent avec Network dropped connection on reset(On Windows(WSAENETRESET)) et les opérations suivantes échouent avecConnection reset by peer(On Windows(WSAECONNRESET)).
  • si le serveur cible est protégé par un pare-feu, ce qui est vrai dans la plupart des cas, le temps de vie (TTL) ou le délai associé au port ferme de force le idle connexion à un temps d'arrêt donné. c'est quelque chose de notre l'intérêt

résolution:

  1. les événements du côté du serveur tels que l'interruption de service soudaine, redémarré, interface réseau désactivée ne peuvent être gérés par aucun moyen.
  2. côté serveur, configurez le pare-feu pour le port donné avec les valeurs plus élevées de temps de vie (TTL) ou de temps mort comme 3600 secondes.
  3. les Clients peuvent "essayer" maintenir le réseau actif pour éviter ou réduire les Connection reset by peer.
  4. Normalement sur le trafic réseau maintient en vie et problème/exception n'est pas vu souvent. Forte Wifi a moins de chances de Connection reset by peer.
  5. avec les réseaux mobiles 2G, 3G et 4G lorsque la livraison de données par paquets est intermittente et dépend de la disponibilité du réseau mobile, elle ne peut pas réinitialiser le timer TTL côté serveur et les résultats dans le Connection reset by peer.

Voici les Termes suggérés sur les différents forums pour résoudre le problème

  • ConnectionTimeout: utilisé seulement au moment de la connexion. Si l'hôte prend le temps de connecter une valeur plus élevée de ceci fait attendre le client pour la connexion.
  • SoTimeout: Socket timeout-indique le temps maximum pendant lequel le paquet de données a est reçu pour considérer la connexion comme active.Si aucune donnée reçue dans les temps, la connexion est considéré comme Bloqué / cassé.
  • Linger: Jusqu'à quelle heure la socket ne doit pas être fermée lorsque les données sont en attente d'envoi et que la fonction de fermeture de la socket est appelée sur la socket.
  • TcpNoDelay: voulez-vous désactiver le tampon qui contient et accumule les paquets TCP et les envoyer une fois qu'un seuil est atteint? Le paramétrage à true sautera le tampon TCP pour que chaque requête soit envoyée immédiatement. Les ralentissements dans le réseau peuvent être causés par une augmentation du réseau trafic dû à une transmission de paquets plus petite et plus fréquente.

donc aucun des paramètres ci-dessus n'aide à maintenir le réseau en vie et donc inefficace.

j'ai trouvé un réglage qui peuvent aider à la résolution de la question qui est-ce fonctions

setKeepAlive(true)
setSoKeepalive(HttpParams params, enableKeepalive="true")

Comment ai-je résolu mon problème?

  • mettez le HttpConnectionParams.setSoKeepAlive(params, true)
  • Catch SSLException et vérifiez le message d'exception pour Connection reset by peer
  • si exception est trouvée, stocker le téléchargement / lire la progression et créer une nouvelle connexion.
  • Si possible de reprendre le téléchargement/lu ailleurs de relancer le téléchargement

j'espère que les détails vous aideront. Heureux De Codage...

69
répondu Devendra Vaja 2017-01-24 11:03:21

Si vous utilisez Nginx et l'obtention d'un problème similaire, cela peut aider:

Scannez votre domaine sur ce sslTesturl, et de voir si la connexion est autorisée pour votre version du dispositif.

si les périphériques de version inférieure (comme < Android 4.4.2 etc) ne sont pas capables de se connecter en raison du support TLS, alors essayez d'ajouter ceci à votre fichier de configuration Nginx,

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
10
répondu jayiitb 2017-11-18 01:39:03

nous avons eu ce même problème à partir de ce matin et goti il résolu... espérons que cette aide...

SSL on IIS 8

  1. tout fonctionnait bien hier et hier soir notre SSL a été mis à jour sur le site IIS.
  2. en vérifiant les fixations du site sur le SSL a remarqué que IIS8 a une nouvelle case à cocher Exiger L'Indication Du Nom Du Serveur, il n'a pas été vérifiée de sorte précédé pour l'activer.
  3. qui a déclenché le problème.
  4. retour à IIS, désactivé la case à cocher.... Problème Résolu!!!!

Espérons que cette aide!!!

3
répondu Jorge Navarro 2016-08-02 16:38:08

une autre cause possible de ce message d'erreur est si la méthode HTTP est bloquée par le serveur ou load balancer.

Il semble être norme de pratique de sécurité pour bloquer les méthodes HTTP inutilisées. Nous nous sommes heurtés à cela parce que HEAD était bloqué par l'équilibreur de charge (mais, curieusement, pas tous les serveurs équilibrés de charge, ce qui a provoqué une défaillance seulement une partie du temps). J'ai pu tester que la demande elle-même a bien fonctionné en changeant temporairement à utiliser la méthode.

le code d'erreur sur iOS était: Error requesting App Code: Error Domain=Nslerrordomain Code = -1005 "the network connection was lost."

0
répondu Mykaelos 2017-12-15 15:47:55