現在、アプリのパフォーマンスの問題に取り組んでおり、これらの問題のいくつかは、アプリと基盤となる AFNetworking ネットワーク スタックが HTTP 1.1 でキープアライブを無視しているように見えるという事実に関連している可能性があると考えています。
サーバー側のキープアライブ情報に関係なく、iOS のバージョンと WiFi/WWAN 接続に応じて、永続的な接続がそれぞれ 3、6、または 30 秒後にパージされるという情報を Apple から入手しました。
サーバーで接続ハンドシェイクを監視しているときに、iOS デバイス上のアプリからの SSL 接続が開いたままになり、FIN パケットで閉じられないという奇妙な動作に気付きました。アプリから新しいリクエストが行われるとすぐに、前のリクエストからの残りの接続が FIN パケットで閉じられ、新しい接続が作成されます。
iOS がバッテリー消費を低く抑えるために接続をパージすることは理解していますが、既存の接続を適切に終了せず、その終了を新しい要求の開始まで延期することに疑問を抱いています。
誰かがこの動作を説明し、通常の条件下でキープアライブによってカバーされる接続で高価な SSL ハンドシェイクを回避するための解決策を提案できますか?