Replify Accelerator performs a number of different types of optimization to improve the throughput of your network.
Often the focus is on the benefits Replify brings through it’s cross protocol de-duplication and compression. These optimization techniques can be easily measured and therefore the benefits can be easily conveyed. For example, downloading a 100 megabyte file with Replify might only use 1 megabyte of bandwidth on the WAN. In this case we know that we’ve offloaded 99% of the data and the customer can easily view this on the Replify GUI.
However, Replify Accelerator also performs TCP optimization. This can have significant benefits for the user-experience but because these are not easy for us to measure and display on a GUI, they can often get overlooked.
There are two main techniques that we use for TCP optimization, both of which are worth understanding if you are trying to accelerate traffic on a poor quality network.
The TCP Handshake
Every time you connect to a server using a TCP-based protocol such as HTTP, HTTPS, HTTP2, SMB2, MAPI etc, a handshake is performed. This is basically the client and server exchanging the following information:
- Hello, I’d like to connect to you. Is that ok. (SYN)
- Yes, that’s fine. Go ahead (SYN-ACK)
- Thanks, I’ll send you some data now (ACK)
If you connect to a website, this might initiate a number of TCP conversations, each of which will require the same handshake to take place at the start of the connection.
Let’s consider what this looks like when someone makes an HTTP request to a web server over a high latency connection with a round trip time (RTT) of 500ms.
A 500ms RTT means that the client has to wait for one second to get any data from the web server and half of this time is spent performing the TCP handshake. If downloading a complex web page, it will be many seconds before the page with all its resources, such as stylesheets and images, gets fully loaded.
WAN Connection Pooling
Replify Accelerator’s WAN Connection Pooling functionality assists with this issue by creating a number of WAN connections that can be used at a later date.
This means that the 500ms TCP handshake takes place before the user opens their browser and the above exchange is changed to the following:
Replify’s WAN Connection Pooling feature reduces the time to the first server packet by 500ms on this 500ms latency link.
You can see from this example that the client waits for a little over 500ms to get a response from the web server, effectively halving the response time!
For users making frequent connections over a high latency connection, such as a satellite link, this is a big deal. They will see a noticeable improvement in response times for most applications.
Read more about another key Replify TCP optimization: congestion control in part 2.
If you want to know more about how Replify Accelerator’s TCP optimization can improve your network’s performance, please get in touch with us at sales@replify.com.