Zero Round Trip Time TLS Session Anticipatory Request Buffering
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current TLS protocols face inefficiencies in communication latency, particularly for large requests made by clients, as transmission latency remains a significant factor due to the need for servers to retrieve data from remote locations during TLS sessions, leading to increased overhead and scalability issues with concurrent connections.
Innovation Solution
The anticipatory request message system buffers early request messages from clients during TLS sessions, using session tickets to enable immediate data transmission upon TLS session resumption, thereby mitigating transmission latency by pre-retrieving and storing requested data locally.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If the server retrieves data from remote locations during TLS sessions, then the data can be transmitted to clients, but the transmission latency increases and communication efficiency decreases
Solution Approach 1:
The patent applies preliminary action by having the server pre-retrieve data from remote locations during the TLS handshake phase (0-RTT) before the client actually needs it. The server anticipates client requests and fetches data in advance, storing it in a buffer. When the client resumes the TLS session, the pre-retrieved data is already available for immediate transmission, eliminating the need for subsequent data retrieval operations and reducing transmission latency.
2Adaptability or versatility
If the server processes multiple concurrent TLS connections, then client coverage increases, but system overhead and complexity increase
Solution Approach 1:
The patent reduces system overhead by performing data retrieval operations during the initial TLS handshake (0-RTT phase) before full connection establishment. By anticipating and pre-fetching data during this preliminary phase, the server avoids the need to perform expensive data retrieval operations for each individual client request, thereby reducing per-connection overhead while maintaining concurrent connection capabilities.
Solution Approach 2:
The patent creates buffered copies of data during the TLS handshake phase. Instead of retrieving original data from remote locations for each client request, the server creates local copies in a buffer during the preliminary 0-RTT phase. These copied data can then be rapidly transmitted to multiple clients without repeated remote retrieval operations, reducing system overhead while maintaining adaptability to concurrent connections.
3Reliability
If the server waits for TLS session resumption before transmitting data, then security is maintained, but transmission latency increases
Solution Approach 1:
The patent resolves this contradiction by performing data retrieval during the preliminary TLS handshake phase (0-RTT) before the client needs the data. The server anticipates client requests and pre-fetches data while the TLS session is being established. When the client resumes the TLS session, the data is already retrieved and buffered, ready for immediate transmission. This maintains security by ensuring data is only transmitted after proper TLS authentication while eliminating post-resumption retrieval delays.
Data Source
AI summary
Provided is a method, a computer program product, and a system for providing request messages with zero round trip time in a Transport Layer Security (TLS) session. The method includes establishing a TLS session between a server and a client by performing a TLS handshake between the server and the client. The method further includes generating a session ticket associated to the client. The method also includes transmitting the session ticket to the client and receiving an early request message from the client during the TLS session. The early request message includes a request message that is to be sent to the client upon resuming the TLS session with the client. The method further includes associating the early request message with the session ticket and processing the early request message. The data related to the early request message can be sent upon resumption of the TLS session.