Errore di rete casuale e occasionale (NSURLErrorDomain Code = -1001 e NSURLErrorDomain Code = -1005)

Question

L'ultimo paio di giorni che ho provato a eseguire il debug di un errore di rete da d00m. Sto iniziando a rimanere senza idee/lead e la mia speranza è che altri utenti SO abbiano esperienza preziosa che potrebbe essere utile. Spero di essere in grado di fornire tutte le informazioni pertinenti, ma non ho personalmente il controllo degli ambienti server.

Il tutto è iniziato dagli utenti che hanno notato un paio di "errori di rete" nella nostra app. L'errore sembrava verificarsi in modo casuale, senza alcun modello evidente relativo alla connettività Internet, alla versione iOS o agli aggiornamenti del backend. I due errori che si verifica dietro le quinte sono:

Error Domain=NSURLErrorDomain Code=-1001 "The request timed out."

più spesso:

Error Domain=kCFErrorDomainCFNetwork Code=-1005 "The network connection was lost.

dopo il debug per un paio di giorni, sono riuscito a riprodurre questi errori (si verificano a caso) sparando ca. 10 richieste casuali (GET e POST) verso il nostro back-end con un timer di sospensione casuale tra ogni richiesta (impostata su 1-20 secondi). Tuttavia, si verifica solo nei periodi. Quello che ho vissuto negli ultimi due giorni è che quando inizia un "periodo di errore", ottengo uno dei due errori ogni volta che eseguo il codice (ovvero un tasso di errore di 1/10 o 1/20 richieste). Questo tasso di errore continua per un paio d'ore e poi l'errore scompare per un paio d'ore e poi inizia dappertutto.

Alcuni fatti rapidi circa la messa a punto:

• accade sul dispositivo e simulatore
• accade su iOS 8.4 e iOS 7.1 - anche se v 8.4 è quello principale che uso per il test..
• Per le richieste di rete utilizziamo NSURLSession. Abbiamo incluso anche AFNetworking (aggiornato alla versione più recente), ma utilizziamo solo la parte Security per SSL Pinning. Anche con il blocco SSL completamente disattivato, l'errore si verifica ancora.

Alcuni risultati che ho scritto giù durante l'ultimo paio di giorni:

• sembra accadere solo sulle nostre ambienti di produzione che ha un po 'diversa configurazione come i nostri ambienti di staging. Questo mi porta a pensare che potrebbe essere correlato al bug keep-alive come discusso here e here. Tuttavia, il nostro reparto operativo ha creato un nuovo ambiente di staging inviando la stessa intestazione keep-alive come ambienti di produzione, ma ciò non ha provocato l'errore nell'ambiente di staging.
• La nostra versione Android dell'app non è stata in grado di riprodurre l'errore utilizzando la stessa impostazione delle richieste. Inoltre, non abbiamo ricevuto alcun problema con il cliente su "errori di rete" nell'app per Android.

Il mio istinto dice che è correlato all'ambiente server e all'implementazione HTTP in iOS. Sono comunque in grado di rintracciare un modello convincente che dimostra tutto. Ho eseguito la stessa configurazione utilizzando un semplice script Rails e quando si verifica il successivo "periodo di errore", sarò pronto a provare a riprodurlo al di fuori della terra di iOS. Aggiornerò la domanda quando questo accadrà.

Non sono in cerca di soluzioni che comportino la reimpostazione delle impostazioni Wi-Fi, l'arresto del simulatore o simili in quanto non lo vedo come soluzione fattibile in un ambiente di produzione.Ho anche preso in considerazione l'idea di creare il retry-loop-fix come menzionato nel problema GitHub, ma vedo questa come ultima risorsa.

Per favore fatemi sapere se avete bisogno di ulteriori informazioni.

Answer 1

Nella mia esperienza, questi tipi di problemi di solito indicano una perdita di pacchetti massiccia, in particolare su una rete cellulare, dove variazioni minori nell'interferenza del multipath e altri problemi possono fare la differenza tra il traffico in transito affidabile e non.

Un'altra possibilità che viene in mente sono le implementazioni NAT di scarsa qualità, nell'improbabile caso in cui l'intervallo di timeout del server sia sufficientemente lungo da provocare il NAT di rinunciare alla connessione TCP.

In entrambi i casi, l'unico modo per sapere con certezza cosa sta succedendo è prendere una traccia di pacchetti. Per fare ciò, collega un Mac a Internet tramite una connessione cablata, abilita la condivisione di rete tramite Wi-Fi e collega il dispositivo iOS a quella rete Wi-Fi. Quindi lanciare Wireshark e dirgli di monitorare l'interfaccia del bridge. Istruzioni qui:

http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/

Da lì, si dovrebbe essere in grado di vedere esattamente ciò che viene inviato e quando. Questo probabilmente farà molto per capire perché sta fallendo.