Otrzymuję komunikat "NSURLErrorDomain Code = -1004" z wywołaniami Alamofire API,
ale tylko przez kilka sekund po uruchomieniu aplikacji (lub odpoczęło przez kilka minut, gdy aplikacja się otworzyła i po niej zadzwonić)
Jeśli spróbuję wykonać to samo połączenie po kilku sekundach, wszystko działa poprawnie.
Przeszukałem wszystkie pytania dotyczące przepełnienia stosu i sprawdziłem wszystkie możliwe przyczyny poniżej:
- Nie ma problemu z połączeniem z Internetem
- "Ustawienia zabezpieczeń transportu aplikacji" są poprawne, a serwer używa protokołu https (próbowałem też "NSAllowsArbitraryLoads = true", ale to nie pomogło)
- Interfejsy API działają poprawnie
Mam przeczucie, że uzyskanie ustawień sieciowych zajmuje kilka sekund, a kiedy wykonuję połączenie API, zanim to zrobię, po prostu natychmiast się nie powiedzie. LUB .. Używam Websocket w tle, który może być powiązany?
FAILURE: Error Domain = NSURLErrorDomain Code = -1004 "Nie można połączyć się z serwerem." UserInfo = {NSUnderlyingError = 0x137d39380 {Domena błędu = kCFErrorDomainCFNetwork Code = -1004 "(null)" UserInfo = {NSErrorPeerAddressKey = {długość = 16, pojemność = 16, bajty = 0x100201bb341a9f540000000000000000}, _kCFStreamErrorCodeKey = -2200, _kCFStreamErrorDomainKey = 4}}, NSErrorFailingURLStringKey = [FILTERED], NSErrorFailingURLKey = [FILTERED], _kCFStreamErrorDomainKey = 4, _kCFStreamErrorCodeKey = -2200, NSLocalizedDescription = Nie można połączyć się z serwerem.}
Jakieś sugestie?
ZAKTUALIZOWANE
Zauważyłem, że aplikacja uruchamia 4 żądania, a 1 lub 2 z nich losowo kończy się niepowodzeniem, a ja sprawdziłem dostęp Nginx i logi błędów, a w ogóle nie było rejestru dla nieudanych połączeń.
Mamy ten sam problem tutaj z Nginx 1.10.0 (i 1.9.15), iOS 9.3.1 z wykorzystaniem HTTP / 2 z TLS 1.2.
Problem znika z HTTP / 1.1 i działa również z HTTP / 2 w wersji Nginx do 1.9.14.
Nginx 1.11.0 Mainline jest już dostępny z dołączoną poprawką wspomnianą wcześniej w tym temacie;
Zmień: klienci HTTP / 2 mogą teraz rozpocząć wysyłanie treści żądania
natychmiast; dyrektywa "http2_body_preread_size" kontroluje rozmiar pliku
bufor użyty przed nginx rozpocznie czytanie treści żądania klienta.
Przetestowałem to i dla mnie to wydanie działa teraz poprawnie.
Wygląda to jak potwierdzony błąd w Nginx 1.10. Problem dotyczący tego można znaleźć na temat śledzenia błędów nginx at https://trac.nginx.org/nginx/ticket/979. Rzeczywisty problem można znaleźć na stronie https://trac.nginx.org/nginx/ticket/959
Możesz rozważyć przejście do gałęzi 1.9, która ma wydania, które działają. Mam nadzieję, że nginx wyda wkrótce wersję 1.10.1, która nie ma tego błędu.
Problem faktycznie występuje tylko w systemie iOS; Android, Windows i OSX nie mają problemów z negocjowaniem poprawnego połączenia http2.
Mogę również potwierdzić, że nginx 1.9.15 nie działa poprawnie. Niektóre połączenia zawsze mają "Nie można połączyć się z serwerem", a po powrocie do wersji nginx 1.9.12 wszystko działa poprawnie.
Oto kroki, które chciałbym wykonać:
- 1) przetestuj moją aplikację w symulatorze i urządzeniu
- 2) sprawdź, czy protokół HTTPS jest rzeczywiście potrzebny, zamiast http
3) skonfigurować menedżera alamofire i zmienić limit czasu (dla tego kroku i
napisz trochę kodu):
var alamofireManager = Alamofire.Manager.sharedInstance
let configuration = NSURLSessionConfiguration.defaultSessionConfiguration()
configuration.HTTPMaximumConnectionsPerHost = 10
configuration.timeoutIntervalForRequest = 30
configuration.timeoutIntervalForResource = 30
alamofireManager.delegate.taskWillPerformHTTPRedirection = nil
(więc zrób ten ostatni krok następnymi wywołaniami alamofire może być na przykład: alamofireManager.request(etc....
)
- 4) testuj z twardym łączem jak http://www.google.com, jeśli to samo
nic się nie dzieje wokół twojego szybkiego kodu są nieprawidłowe, spróbuj
ustaw parametry serwera sieciowego.
Problem rozwiązany!!!
wersje:
1. Nginx version: 1.10.2
2. IOS version: 9.3.2
Gdy konfiguracja taka jak ta:
listen 443 ssl;
Mają ten sam problem jak ty.
Ale !!!
Gdy konfiguracja taka jak ta:
listen 443 ssl http2;
Problem rozwiązany!!