Подтвердить что ты не робот

Случайная и случайная сетевая ошибка (NSURLErrorDomain Code = -1001 и NSURLErrorDomain Code = -1005)

Последние пару дней я пытался отладить сетевую ошибку с d00m. У меня заканчиваются идеи/лидеры, и я надеюсь, что другие пользователи SO имеют ценный опыт, который может быть полезен. Я надеюсь, что смогу предоставить всю необходимую информацию, но я лично не контролирую серверные среды.

Все началось с того, что пользователи заметили пару "сетевых ошибок" в нашем приложении. Ошибка, как представляется, происходила случайным образом, без какой-либо заметной картины, связанной с подключением к Интернету, версией iOS или обновлениями бэкэнд. Две ошибки, которые происходят за кулисами:

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

и чаще:

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

После отладки в течение нескольких дней мне удалось воспроизвести эти ошибки (случайные), включив прибл. 10 случайных (GET и POST) запросов к нашему серверу со случайным таймером сна между каждым запросом (устанавливается на 1-20 секунд). Однако это происходит только в периоды. То, что я пережил последние пару дней, заключается в том, что, когда начинается "период ошибок", я получаю одну из двух ошибок каждый раз или два раза, когда я запускаю код (что означает частоту ошибок 1/10 или 1/20 запросов). Эта частота ошибок продолжается в течение нескольких часов, а затем ошибка исчезает в течение нескольких часов, а затем начинается все.

Некоторые быстрые факты о настройке:

  • Случается на устройстве и симуляторе
  • Случается на iOS 8.4 и iOS 7.1 - хотя v.8.4 является основным, который я использую для тестирования.
  • Мы используем NSURLSession для наших сетевых запросов. Мы также включили AFNetworking (обновлено до последней версии), но мы используем только часть безопасности для SSL-шифрования. Даже при полном отключении SSL ошибка все равно возникает.

Некоторые результаты, которые я записал за последние пару дней:

  • Кажется, что это происходит только в нашей производственной среде, которая имеет некоторую другую конфигурацию в качестве промежуточной среды. Это заставило меня подумать, что это может быть связано с ошибкой keep-alive, как обсуждалось здесь и здесь. Однако наш отдел ops создал новую промежуточную среду, отправляющую тот же заголовок keep-alive в качестве рабочей среды, но это не приводило к возникновению ошибки в промежуточной среде.
  • Наша версия Android-приложения не смогла воспроизвести ошибку, используя ту же настройку запросов. Кроме того, мы не получили никаких проблем с клиентами в отношении "сетевых ошибок" в приложении для Android.

У меня возникает ощущение, что это связано с серверной средой и реализацией HTTP в iOS. Однако я не могу найти убедительный образец, который доказывает что-либо. Я сделал ту же настройку, используя простой Rails script, и когда произойдет следующий "период ошибки", я буду готов попытаться воспроизвести его за пределами земли iOS. Я обновлю вопрос, когда это произойдет.

Я не ищу решения, связанные с сбросом настроек Wi-Fi, отключением симулятора или подобным, поскольку я не вижу в этом реальных решений в производственной среде. Я также рассмотрел возможность создания исправления петли, как упоминалось в проблеме GitHub, но я вижу это как последнее средство.

Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

4b9b3361

Ответ 1

По моему опыту, эти проблемы обычно указывают на массовую потерю пакетов, особенно по сети сотовой сети, где незначительные изменения в многолучевых помехах и другие проблемы могут сделать разницу между надежным прохождением трафика, а не.

Еще одна возможность, которая приходит на ум, - это некачественные реализации NAT, в маловероятном случае, если ваш интервал ожидания сервера достаточно длинный, чтобы заставить NAT отказаться от TCP-соединения.

В любом случае, единственный способ точно знать, что происходит, - это взять трассировку пакета. Для этого подключите Mac к Интернету через проводное соединение, включите сетевой доступ через Wi-Fi и подключите устройство iOS к этой сети Wi-Fi. Затем запустите Wireshark и скажите ему, чтобы он контролировал интерфейс моста. Инструкции здесь:

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

Оттуда вы сможете увидеть, что именно отправляется и когда. Это, вероятно, будет иметь большое значение для понимания того, почему он терпит неудачу.