On Fri, 21 Jun 2024 08:15:42 GMT, John Jiang <jji...@openjdk.org> wrote:
> > The application calls `getSession()` from the same SSLContext of the > > original connection. > > ... > > The remaining tickets sit on the client if they need them. Some > > applications may choose to resume multiple times to download data/images. > > I might miss something. The client can connect to the server in parallel, and > these new connections can share the SSLContext from a previous connection. > And the new connections automatically pick the cached sessions in that > SSLContext one by one. Right? Let me start from the beginning and hopefully it will clear things up. Today, each Finished connection gets one resumption ticket. That session's SSLContext contains the cache. When someone wants to resume, they use the same SSLContext to make a new session. That new session will look into the cache, find the resumption ticket, and take it out to use. Tickets are one-time use. On completion of the resumed session, a new ticket is placed into cache under the same entry as the previous one. Clients that want to open parallel sessions are unable to use resumption effectively. The current client cache can only hold one ticket, throwing away any other tickets the server may have sent it. Additionally, the time between taking the resumption ticket and receiving a new ticket is too slow for parallel connecting clients. The first resumption session takes that ticket, while the second resumption session sees no ticket and has to do a full handshake. This change allows multiple tickets to be stored on the client cache, solving the parallel clients problem, without the application having to change. If the application uses new SSLContext instances for each connection, it does not have access to the same cache. This change does not modify that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2182982688
