We have an iOS app (Alamofire 5.9+, backed by URLSession) that talks to a LAN dashcam:
HTTP/1.1 TLS 1.2 The device runs an embedded C HTTPS server Responses commonly include Connection: close (a new TCP connection is opened for each request) From Wireshark, looking at Client Hello, we observe:
First connection: full handshake; a Session ID is negotiated Next new TCP connection: Client Hello carries that Session ID and completes an abbreviated handshake (resumption succeeds) After that: the same Session ID is not reused again Questions we want to confirm
For TLS 1.2 Session ID resumption (RFC 5246), does iOS / URLSession intentionally allow a cached session to be resumed at most once? Or can the same Session ID be resumed multiple times until it expires / is evicted from the cache?
Without changing the overall LAN dashcam product model, how should the server be configured—e.g. moving to TLS 1.3 and/or HTTP/2—so that iOS clients can resume via Session Ticket and/or Session ID multiple times?
What we have already ruled out / observed
The client already uses a shared long-lived URLSession / Alamofire Session (we do not create a new session per request) The server often returns Connection: close, so each request uses a new TCP connection; we are discussing TLS session resumption across connections, not HTTP keep-alive We occasionally see TLS time of only ~10–20 ms, which suggests at least one successful session resumption has occurred
At the URLSession level, the only control you have over this is the session itself. To maximise the chances of session reuse, you should issue all of your requests in the same session.
we do not create a new session per request
Cool.
Unfortunately that’s all you can do here. This allows the session to reuse the session ID, but it doesn’t require it. The session decides whether to do that based on its own internal logic.
The pattern you’ve described — first connection does the full handshake, second connection resumes the session, third connection does the full handshake, and so on — is something I’ve seen before. I’ve never got to the bottom of why URLSession works this way. Historically it was happy to reuse a session ID multiple times.
IMO your best option here is to move to a more modern HTTP protocol, so HTTP/2 or HTTP/3. Both of those run multiple requests over the same underlying (TCP or QUIC) connection. This will avoid this problem and yield other benefits, most notably better performance overall.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"