How to set cache server certificate for nsurlsession？

I’m not sure what you mean by “cached certificates”. That’s not a thing in TLS.

I suspect that you’re asking about the abbreviated handshake protocol, as illustrated by Figure 2 in RFC 5246. If so, this requires cooperation behalf of both the client and the server:

• The client saves the SessionID from the server’s ServerHello and then, when it goes to connect again, presents that in its ClientHello.

• The server checks that and decides whether it do an abbreviated handshake.

You should look in your packet trace to see which side is blocking that handshake, that is:

• Is the client not presenting the session ID?

• Or is the server not accepting the session ID?

Oh, wait, are you using TLS 1.3? If so, similar logic applies but the details are very different. See Figure 3 of RFC 8446.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

“cached certificates” means “Server Hello” package here. We are trying bandwidth optimization. Want to reduce the traffic occupied by “Server Hello” package, or other ways to reduce bandwidth . On the Android client, the second short interval request for “Server Hello” package will be smaller, so there is a problem with the method of narrowing the “Server Hello” package ，because the package size will not change during IOS testing.

I’m not super familiar with this is TLS 1.3 but I believe similar logic applies. When you look at the packet trace, do you see the ClientHello offer a key_share parameter in the first connection and key_share and pre_shared_key parameters in subsequent ones?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

the second short interval request for “Server Hello” package will be smaller, so there is a problem with the method of narrowing the “Server Hello” package 

If you are looking to take advantage of Early Data in TLS 1.3, then Quinn is correct that you must have an pre_shared_key and early_data extension in your client hello packet, so that your server and the client can use a previous PSK's to send data when reconnecting for a second time. This is described in section 4.2.10 of the TLS spec for Early Data Indication.. Now... having said that, just because the client sends these two extension in the client hello packet doesn't mean that the server will respect them. The server has the ability to deny this and continue on with the normal negotiation process. So when testing this, take a look at why your server is making these decisions.

If TLS 1.2 also has this, how to explain it?

If TLS 1.2 also has this, how to explain it?

Early data in the client hello packet is a TLS 1.3 feature. TLS 1.2 uses pre-shared keys (PSKs) differently and a 1-RTT handshake re-establishment can be done with session tickets or ids. (Ask Quinn mentioned above).

We used in UNNotificationServiceExtension ,code like ： NSURLSessionConfiguration *config = [NSURLSessionConfiguration defaultSessionConfiguration];     self->uploadTask = [[NSURLSession sessionWithConfiguration:config                              delegate:self                            delegateQueue:[NSOperationQueue currentQueue]] dataTaskWithRequest:request];     [self->uploadTask resume];

Through Wireshark packet capturing, We found that each request for Session ID is different： Handshake Protocol: Server Hello Session ID: 825a5a052f3c90115e2e7aab61b32858d53ec361111ddaaa70fcc55c53fab014 Session ID: 16aff82cdc84c8698847d97616cf7a1ac5267eb625707b2aed75e67a6cfd0a1a How to keep Session ID constant? @eskimo @meaton

By reusing the nsurlsession, I can see the same Session ID in ServerHello.

The problem has been solved. Thank you for your support.@eskimo @meaton