Wir befassen uns derzeit mit Leistungsproblemen in unserer App, und wir glauben, dass einige dieser Probleme mit der Tatsache zusammenhängen könnten, dass die App und der zugrunde liegende Netzwerkstapel von AFNetworking zu funktionieren scheinen Ignoriere keep-alive auf HTTP 1.1.AFNetworking/NSURLConnection HTTPS bleibt am Leben und zeigt merkwürdiges Verhalten
Wir haben Informationen von Apple, dass dauerhafte Verbindungen nach 3, 6 oder 30 Sekunden, je nach iOS-Version und WiFi/WWAN-Konnektivität, unabhängig von serverseitigen Keep-Alive-Informationen gelöscht werden.
Beim Überwachen der Verbindungs-Handshakes auf unseren Servern haben wir das seltsame Verhalten bemerkt, dass eine SSL-Verbindung von unserer App auf einem iOS-Gerät offen gelassen und nicht mit einem FIN-Paket geschlossen wurde. Sobald eine neue Anfrage von der App gemacht wird, wird die verbleibende Verbindung von der vorherigen Anfrage THEN mit einem FIN-Paket geschlossen und eine neue Verbindung wird erstellt.
Während wir verstehen, dass iOS die Verbindungen löscht, um den Batterieverbrauch niedrig zu halten, wundern wir uns, dass es die bestehende Verbindung nicht ordnungsgemäß beendet und diese Beendigung auf den Beginn einer neuen Anfrage verschiebt.
Kann jemand dieses Verhalten erklären und Lösungen vorschlagen, um teure SSL-Handshakes in Verbindungen zu vermeiden, die durch Keep-Alive unter normalen Bedingungen abgedeckt sind?
Welche iOS-Versionen sind betroffen? – Adam
Welche WWDC-Sitzung? Die dauerhafte Verbindung wird übrigens von der CFNetwork-Schicht gehandhabt. Und soweit ich weiß, gibt es keine API, um das Verhalten zu ändern. Sie können sich ansehen, wie die ASIHttpRequest-Unterstützung die Verbindung fortsetzt. Dies hängt nicht mit AFNetworking oder NSURLConnection zusammen. Und wahrscheinlich haben wir nichts zu tun. –
@Adam - So weit ich weiß von iOS 8 seine betroffen.Hier ist eine andere Frage, die etwas mit http://stackoverflow.com/q/29063803/730807 –