iOS und Go - Keep-Alive mit NSURLSession

Ich glaube, Sie verwirren TCP Keep-Alive mit HTTP Keep-Alive (persistente Verbindungen). Dies sind nicht verwandte Konzepte. Von Ihrer Frage meinen Sie wahrscheinlich persistente HTTP-Verbindungen.

In HTTP / 1.1 sind persistente Verbindungen die Standardeinstellung und werden von NSURLSession und fast jedem HTTP / 1.1-Client verwendet. Sie müssen darum bitten, sie auszuschalten. Sie können im HTTP-Header nach einem Connection: close suchen, oder auf der Serverseite können Sie das Close -Feld von http.Request überprüfen. Aber ich bin sicher, dass Sie dauerhafte Verbindungen bekommen. Dies bedeutet, dass Sie den TLS-Tunnel (oder zumindest den TCP-Dreiwege-Handshake) nicht für jede Anforderung neu verhandeln müssen. (Wenn Sie jedoch parallele Anforderungen stellen, gibt es immer noch mehrere Verbindungen, die Sie aushandeln müssen. HTTP / 1.1 kann immer nur eine Sache gleichzeitig behandeln, und NSURLSession versucht, einen Pool von Verbindungen zu verwenden, um die Antwortzeiten zu verbessern.)

TCP keep-alives sind eine ganz andere Sache. Es sendet ein periodisches "Ping" an die andere Seite, um sicherzustellen, dass es immer noch erreichbar ist. Es gibt viele Möglichkeiten für Sie, die Netzwerkkonnektivität zu verlieren und es erst zu kennen, wenn Sie das nächste Mal versuchen, zu kommunizieren, und das normale Symptom ist, dass die Verbindung einfach hängen bleibt und Sie es abmelden müssen. Theoretisch ist TCP keep-alive nur das Werkzeug, um dies zu entdecken, aber ich habe es praktisch nie praktisch gefunden. Es ist schwierig, richtig zu konfigurieren (besonders in Cocoa). Sie müssen fast immer eine "Ping" -Funktionalität auf höherer Ebene für Ihre Anwendung erstellen, anstatt sich darauf zu verlassen.

Aber, um es zu Ihrem Problem zu bringen, ist HTTP / 1.1 wahrscheinlich für Sie in Ordnung, aber Sie müssen Ihre Antworten sorgfältig verwalten. Wenn Sie für jeden Brief eine neue Anfrage machen und eine massive Antwort zurücksenden, dann wird das schlecht funktionieren. Sie werden Ihren gesamten Verbindungspool damit beschäftigen, Dinge herunterzuladen, die Sie wegwerfen werden. Sie müssen sich zuerst auf gute Algorithmen konzentrieren. Zumindest möchten Sie wahrscheinlich nur einige Ergebnisse gleichzeitig senden und eine "Paging" -Anwendung in Ihrer API bereitstellen, um nach mehr Ergebnissen für die gleiche Suche zu fragen.

Um sicher zu sein, was TCP tut, können Sie CFNETWORK_DIAGNOSTICS aktivieren. Aus der Dokumentation:

  

Während der normalen Entwicklung können Sie diese Umgebungsvariable über den Xcode-Schema-Editor einstellen. Wenn Sie Probleme außerhalb von Xcode untersuchen müssen, können Sie sie programmgesteuert mit dem in Listing 1 gezeigten Code festlegen.

     

Listing 1 Programmgesteuertes Aktivieren der CFNetwork-Diagnoseprotokollierung

%Vor%      

Sie sollten dies gleich zu Beginn der Startsequenz der App tun. Normalerweise ist es ausreichend, dies an den Anfang von main zu setzen, aber wenn Sie statische C ++ - Initialisierer haben, die CFNetwork verwenden, müssen Sie es vor ihnen ausführen.

     

Die CFNetwork-Diagnoseprotokollierung wird gestartet, wenn Sie CFNetwork zum ersten Mal verwenden, oder ein Framework wie Foundation, das CFNetwork verwendet. An diesem Punkt wird eine Nachricht wie in Listing 2 angezeigt.

     

Listing 2 Ein Beispiel für die CFNetwork-Diagnoseprotokoll-Startmeldung

%Vor%