Server-Side UDP Redirection Bypassing NAT Latency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing client-server communication systems face high latency due to server-side redirects, especially when traversing client-side Network Address Translation (NAT) firewalls, as they require multiple Internet Round-Trip Times (RTTs) for establishing connections and securing data transfers.
Innovation Solution
The system employs low latency server-side redirection of User Datagram Protocol (UDP)-based transport protocols by pre-establishing preparatory data and cryptographic materials, allowing direct connection and data transfer from a secondary server closer to the client, thereby bypassing the need for multiple RTTs and reducing latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If traditional server-side redirect is used, then the client can be directed to a more appropriate server, but the latency increases due to multiple Internet RTTs required for connection establishment and SSL/TLS handshake
Solution Approach 1:
The patent applies preliminary action by pre-establishing cryptographic materials and connection parameters before the actual data transfer needs to occur. The system performs SSL/TLS handshake and connection setup in advance during server selection, so that when redirection is needed, the client can immediately connect to the new server using pre-shared cryptographic context, eliminating the need for multiple RTTs for connection establishment and SSL/TLS handshake.
2Reliability
If multiple RTTs are performed for connection establishment and SSL/TLS handshake, then secure connection is established, but the overall communication latency increases significantly
Solution Approach 1:
The patent performs SSL/TLS handshake and cryptographic context establishment in advance during the initial server connection, before redirection is needed. This preliminary action ensures that when the client needs to redirect to a different server, the secure connection can be rapidly re-established using pre-shared cryptographic materials, thus maintaining reliability while reducing the time penalty.
Solution Approach 2:
The patent introduces an intermediary mechanism where the initial server acts as a mediator that helps establish cryptographic context that can be transferred to the target server. This intermediary role allows the client to leverage the initial secure connection setup when connecting to the redirected server, reducing the need for complete re-handshaking and thereby reducing latency while maintaining security.
3Ease of operation
If the client establishes a new connection to the second server, then the client can access the requested resource, but the process requires additional RTTs for HELLO exchange and SSL/TLS message completion
Solution Approach 1:
The patent applies preliminary action by pre-establishing cryptographic materials and connection parameters before the actual data transfer needs to occur. The system performs SSL/TLS handshake and connection setup in advance during server selection, so that when redirection is needed, the client can immediately connect to the new server using pre-shared cryptographic context, eliminating the need for multiple RTTs for connection establishment and SSL/TLS handshake.
Data Source
Figure 1
Figure 2
Figure 3~4
AI summary
Systems, methods, and machine-readable media for low latency server-side redirection of User Datagram Protocol (UDP)-based transport protocols traversing a client-side Network Address Translation (NAT) are provided. At a first server, a request for directing a data resource to a client may be received. The request may be received from the client or a back-end server trying to push the data resource to the client. The first server may lack the data resource or the resources to provide the data resource to the client. A second server may be determined for responding to the request. The request may be redirected to the second server. The first server may provide for the second server to connect to the client and directly respond to the request. The second server may have not been previously connected to the client.