1. Introduction
Satellite networks have become an important component of the Internet due to their wide coverage, high bandwidth and broadcasting capabilities. However, satellite communication links suffer from several limitations. The first primary limitation is the large propagation delay which is especially notable in geostationary (GEO) satellites that are located around 36,000 km above earth. The second limitation is the high bit error rate (BER) which is caused by the significant path loss in the satellite propagation channel. In modern satellite systems employing Adaptive Modulation and Coding (AMC), the link bit rate, and hence the frame size, varies with the channel conditions resulting in excessive segmentation and reassembly at higher layers. Another problem is the bandwidth asymmetry that exists between the hub gateway and satellite terminals which is caused by the nature of the shared return channel [
1]. These problems at the link level greatly affect the performance of many Internet services running over satellite networks.
Over the years, there have been continuous efforts to overcome these problems at different layers of the Internet protocol stack which is illustrated in
Figure 1.
At the transport layer, various TCP congestion control algorithms were designed to address the high latency problem of satellite links [
2]. Also, performance enhancement proxies (PEPs) were widely used to improve TCP connection throughput using various, mostly proprietary solutions. At the application layer, newer forms of Internet protocols such as HTTP/2 over TCP and HTTP/3 over Quick UDP Internet Connection (QUIC) have been designed to address many of the shortcomings of legacy HTTP and TCP protocols [
3].
Since satellite networks are usually deployed for long-term service often spanning many years, it is important to provide a cost-effective means for evaluating new and evolving Internet protocols over these networks. In this research work, we investigated the behavior of the modern HTTP variants such as HTTP/2 over TCP and HTTP/3 over QUIC running in modern satellite networks using a realistic emulation testbed. The testbed was built using state-of-the-art web browsers and web servers to mimic the true behavior of Internet protocols. The testbed can be used for optimizing the performance of these protocols as well as devising new algorithms to enhance their performance. Also, it will provide guidelines for different configurations of the protocol stacks and congestion control algorithms that could be used to improve Internet performance over future satellite networks.
In this paper, we present the findings of a detailed investigation of HTTP/3 over QUIC and HTTP/2 over TCP in GEO satellite links with modern congestion control algorithms and various web page structures. Specifically, the paper provides the following contributions:
A testbed for GEO satellite links, with full DVB-S2/RCS emulation, running state of the art web servers and clients with complex web page structures that are otherwise extremely difficult to achieve via simulation;
A performance comparison of HTTP/2 and HTTP/3 over GEO satellite links when using modern congestion algorithms such as Cubic and BBR;
A web-level performance comparison of HTTP/2 and HTTP/3 when using complex web page structures with varying objects sizes and distribution. Here we employ First Contentful Paint (FCP) and Largest Contentful Paint (LCP) in addition to the page load time (Time) as our web-level user-perceived performance metrics.
The rest of the paper is organized as follows. A literature review of related work on evaluating Internet protocols in satellite networks is presented in
Section 2. Next,
Section 3 explains the details of the modern Internet protocols such as QUIC and HTTP/2. The evaluation testbed with its hardware and software components is described in
Section 4. The evaluation scenarios and the results are presented in
Section 5 and
Section 6, respectively. Finally, we summarize our main findings and conclusions at the end of the paper.
2. Related Work
The performance of TCP and QUIC protocols over satellite networks has been studied in numerous recent papers. The authors of [
4] studied the QUIC protocol in a virtual testbed and recommended using Performance Enhancement Proxy (PEP) to enhance its performance in satellite networks. However, their results are sensitive to the CPU limitation of a single machine hosting a virtual testbed. On the other hand, the authors of [
5] compared PEP for both QUIC and TCP in terrestrial and satellite networks, and found that the performance of both TCP and QUIC is enhanced by using PEP.
Furthermore, the authors of [
6] compared the performance of QUIC with TCP-PEP in satellite networks by using an experimental testbed. Using the throughput as a performance measurement, they found that the enhanced TCP-PEP outperforms QUIC in a lossy satellite link. They claim that QUIC needs a better loss recovery mechanism in the higher RTT and lossy networks. However, they did not specify which congestion control algorithm was used in their QUIC configuration.
In [
7], the authors examined the performance of TCP-PEP and different QUIC implementations (QUIC Chromimum, QUIC Apache, QUICKLY and NGTCP) over an experimental satellite testbed. The congestion control algorithms were Reno and Cubic. They found that QUICKLY outperforms the other QUIC implementations over satellite networks but the performance of all QUIC implementations is degraded with packet losses.
The performance of QUIC with a recent congestion control algorithm called Bottleneck Bandwidth and Round-trip time (BBR) has been evaluated in [
8], using an emulation testbed of satellite networks. Their preliminary evaluation indicated better results for QUIC with BBR compared to QUIC with Cubic. However, these papers did not investigate the perceived user-experience indicators which we are going to study in this paper.
Also, the effects of acknowledgment overheads in QUIC over satellite networks have been evaluated using an emulated satellite testbed in [
9]. It compared TCP with two different implementations of QUIC: QUICKLY-IETF-27 and Chromium- IETF -26. It found that the return link traffic on QUIC is larger than TCP due to the overhead of acknowledgments in QUIC. However, the congestion controls used in the experiments are different since Chromium used BBR, while TCP and QUICKLY used New Reno. This had a significant effect on performance.
The authors of [
10] evaluated, by simulation, the performance of HTTP/1.1 over TCP wave and standard TCP in terms of page load time with different web page sizes. They found that TCP wave performs better than standard TCP because it uses a burst-transmission paradigm instead of a window-based paradigm. Also, the performance of HTTP/2 over QUIC and TCP with Explicit Congestion Notification (ECN) was studied in [
11] using an experimental testbed for an integrated space–terrestrial network. They evaluated the performance based on the page load time and the number of blocked messages. In their experiments, they found that HTTP/2 over QUIC with Cubic congestion control performed better than HTTP/2 over TCP with Cubic even with ECN enabled.
The authors of [
12] examined the performance of multiple satellite operators (Avanti, Astra and Tooway) in an experimental testbed with multiple HTTP protocols. They studied HTTP/1.1 and HTTP/2 over TCP, HTTP/1.1 and HTTP/2 over UDP, and HTTP/3 over QUIC with Cubic as the congestion control. They found that HTTP/1.1 outperforms other HTTP protocols. They also concluded that Performance Enhancement Proxies (PEPs) are necessary in satellite networks to enhance performance. However, the authors used Chromium to test the HTTP protocols which creates six fixed connections by default for HTTP/1.1 over TCP. As a result, HTTP/1.1 over TCP outperformed the other HTTP protocols in that paper.
The authors of [
13] addressed the challenges of using QUIC over satellite networks. The experiments were performed on an emulated satellite platform, where they tested HTTP/2 over TCP and HTTP/3 over QUIC with two web page sizes (11 KB and 5 MB). They found that QUIC with the default congestion control (Cubic) degrades the performance when web page size is increased because of the lack of PEP proxy supports in QUIC. However, they did not test TCP without PEP proxy to be compared with QUIC to ensure fairness in comparison.
Finally, the authors of [
14] evaluated the performance of TCP-PEP and Google QUIC (GQUIC) with Cubic congestion control over satellite networks. They found that TCP-PEP outperforms GQUIC in terms of web page load time due to the splitting feature on TCP PEP proxies. However, they did not mention their network architecture and evaluation methodology. Also, the feature of multiplexing on HTTP is absent here since their web page profiles consisted of one object only (one stream).
On different, but related, developments, micro satellites with Small Optical Transponder (SoTA) have been developed and tested to provide low-orbit optical communication link to a ground station [
15]. Optical LEO satellite links are considered a potential solution to overcome the limited spectrum and data rates of RF satellite links. Preliminary experimental results have been reported in [
16] while a comprehensive simulation platform for LEO optical communication was developed in [
17] which also reports the effect of many system configurations and parameters on link performance. However, as the technology is being developed most of the focus is currently on perfecting and evaluating the optical link itself and, hence, higher layer protocols such as HTTP are not yet considered.
All of the papers discussed above did not evaluate the performance of HTTP traffic with different web page structures over QUIC and TCP transport protocol with different congestion control algorithms. In this paper, we will evaluate the performance of HTTP/3 over QUIC, and HTTP/1.1 and HTTP/2 over TCP with recent congestion algorithms and various web page structures. Also, we will provide important user-level performance metrics which are not considered in the above papers. Moreover, we will analyze the behavior of HTTP traffic based on objects’ size distribution within the web page.
4. Evaluation Testbed
For a realistic evaluation of modern Internet protocols, we built a testbed running on dedicated computers and hosting the full stack software implementation of HTTP/2, HTTP/3 with Cubic and BBR congestion control algorithms. The testbed was realized using the OpenSAND Emulation platform which is an open-source project developed by Thales Alenia Space to provide demonstration, validation and performance evaluation of satellite network applications [
27]. The emulator implements most of the new satellite transmission standards such as DVB-RCS2 and DVB-S2 including the protocol stacks as well as the DVB physical layer blocks for each uplink and downlink. It also supports the Adaptive Modulation and Coding (AMC) loop which is used by DVB-RCS2 transmitters to match the transmission rate with the channel quality. In addition, the emulator provides multiple attenuation profiles that depends on the orbit characteristics of the satellite [
27].
The testbed consists of five computers deployed as the network depicted in
Figure 5. Three machines host the three primary components of OpenSAND: terminal, satellite and gateway. We added a machine at the terminal side to run the client software and control the experiments, and another machine at the gateway side to host the web server. The specifications of all software and hardware are summarized in
Table 1.
There are two direct point-to-point links and a switched subnet in this setup. The first direct link is from client to terminal and the other is from server to gateway. The switched subnet consists of a bridge that connects the terminal, the gateway and the satellite via IP tunnels when the emulation is enabled. All traffic arriving at the terminal will be received and processed by the satellite emulator node. Then, the traffic will be transferred and processed by the corresponding blocks of the gateway. Therefore, we can produce a realistic satellite channel by adjusting the emulator link characteristics as needed in each experiment. The satellite link parameters used in the testbed are listed in
Table 2.
For the server machine, we deployed the Open LiteSpeed v1.7 which is a free web server provided by LiteSpeed technologies [
28]. We chose this web server because it implements different HTTP protocols (HTTP/1.1, HTTP/2 and HTTP/3) and supports TCP and QUIC with various congestion control algorithms such as Cubic and BBR. On the client machine, we used Firefox Nightly v90.0 which was, at the time of evaluation, the most recent development version of Firefox because it supports HTTP/3 as well as HTTP/2 [
29]. Also, it has been chosen among other browsers such as Opera, Chromium, etc. since it allows controlling the number of parallel TCP connections to the server. This is necessary in our testbed to ensure fair comparisons to QUIC in the experiments.
5. Experiments’ Setup
The testbed experiments were carefully designed to examine the interaction of the new HTTP protocols with congestion control over a typical satellite link. As explained in
Section 3, one of the important features of HTTP/2 and HTTP/3 is the use of parallel streams over one transport connection. This can only be evaluated using web pages of complex structures and can only be measured using detailed application-level performance metrics. Therefore, we developed three HTML-based templates consisting of multiple embedded objects with different distributions of sizes and organization within the main HTML file. For the embedded objects, we produced eight JPEG images with varying sizes adapted in each HTML page to produce the desired total size of the web page. The distribution of objects in each page structure is listed in
Table 3 and illustrated in
Figure 6.
The first template is a single-object web page which consists of only one embedded object whose size is matched to the required size of the web page. The second template is a uniform multi-object web page which contains eight objects of identical size such that their aggregate size is equal to the total web page size. The third one is a triangular multi-object web page where the eight objects are organized inside the page according to a special order of their size. The first four objects are ordered in increasing size up to the middle of the web page then the four remaining object are ordered in decreasing size down to the end of the web page. The reason for this arrangement is to investigate the effect of parallel streams in HTTP/2 and HTTP/3 on the visual rendering of complex web pages. With parallel fetching of the embedded objects in such complex web pages, the user’s perceived browsing performance of the web page will depend on the position of the largest objects in the page. If the largest object is embedded at the end of the web page, then the page would seem to load faster than if it was embedded at the beginning of the page because the smaller objects will load faster with parallel streams. The behavior will depend on the distribution of the embedded objects within the page; hence, we designed the above templates as a simplified representation of more realistic complex web pages.
The testbed allows many evaluation scenarios each considering an HTTP variant running with a transport congestion algorithm. Each scenario can be run for different web page structures with varying sizes and organization. In this paper, we report the results of three main experiments that were designed to examine specific aspects of the protocol stack’s configuration. The first experiment studies the behavior of parallel streaming in HTTP/2 and HTTP/3 protocols in a satellite link. The second experiment examines the effect of Cubic and BBR congestion control algorithms on HTTP while the third one focuses on the effect of the web page structure on HTTP/2 and HTTP/3 in a satellite link. In all cases, we set all links’ speeds to 10 Mbps and the satellite link RTT to 500 ms. Furthermore, the same scenarios were conducted over a direct LAN link between the client and server in order to provide some baseline for our evaluation. All experiments are summarized in
Table 4. It should be noted here that one must take careful consideration of the default operating behavior of the web client and server, and their host computers to ensure isolated, controlled experimentation of HTTP protocols. Issues of web browser caching, server disk delays, network ARP delays and DNS lookup delays need to be isolated first before recording any statistics.
6. Results and Discussion
In this section, we will present and discuss the results of the three experiments described in the previous section. Every evaluation scenario was run three times resetting all testbed components after each iteration to ensure an identical operating environment. The results were then collected and averaged using client-side scripts that were developed specifically for the testbed. In the following, we first define the performance metrics that were collected in the evaluation and then discuss the results of each experiment.
6.1. Performance Metrics
In HTTP evaluation, the page load time (PLT) has been used as the primary indicator of layer-7 protocol performance. It summarizes many of the factors that are contributed by the network, transport and application protocols. However, due to the complex interaction and intrinsic features of the modern protocols such as HTTP/2, HTTP/3 and QUIC, the PLT does not always provide a sensible performance measure. Therefore, we need other performance metrics to study the interaction between clients and web servers as seen by the end user.
To assess the relative user experience, we used two additional user-level performance measures: the First Contentful Paint (FCP) and the Largest Contentful Paint (LCP) [
29]. The FCP indicates the first response from the server and reveals what the user perceives first from the web page. The LCP expresses the perceived load speed as the arrival time of the most significant object (largest object). All the key performance metrics used in the evaluation are defined in
Table 5.
6.2. The Effect of Parallel Streams in HTTP
The number of parallel streams used to fetch the objects in a web page can affect the load time significantly. Thus, we tested the download of multi-object web pages and compared it to single-object web pages of the same total size. The uniform structure was used for the multi-object web page and the total size of all web pages was set according to
Table 3. The test used BBR congestion control for both the direct LAN link and the satellite link.
The average page load times (PLTs) of uniform multi-object web pages and of single-object web pages are shown in
Figure 7 and
Figure 8, respectively. In multi-object web pages, depicted in
Figure 7, we can see that HTTP/1.1 has the longest PLT compared to HTTP/2 and HTTP/3 because it operates with one stream only. This is because of the head of line (HoL) blocking at the application layer where one object blocks the transmission of the other objects until it is fully received. Thus, the multiple objects are transmitted sequentially in HTTP/1.1 over a single TCP connection. To overcome the HoL issue, HTTP/2 uses multiple streams, one stream per object, where all objects are transmitted in parallel to prevent HoL blocking at application layer. This significantly reduces the PLT compared to HTTP/1.1 but it still suffers from HoL blocking at the transport layer because all HTTP/2 streams are multiplexed into a single TCP connection. On the other hand, HTTP/3, which relies on QUIC non-blocking multiplexing at the transport layer, produces much smaller PLTs, about 55% less than HTTP/1.1 and 30% less than HTTP/2.
The situation is almost reversed when the page consists of a single object only where HTTP/2 performed worse than HTTP/1.1 as shown in
Figure 8. This is because stream multiplexing is not applicable in this scenario and we are left with the bigger protocol overhead of HTTP/2, e.g., from TLS security and bigger header size, which increase the page load time. However, HTTP/3 still outperforms HTTP/1.1 and HTTP/2 in this scenario because of the nature of QUIC which reduces the initial connection setup time.
The protocol overhead in HTTP/2 and HTTP/3 becomes the dominant factor in the performance over small RTT links such as the direct link scenarios shown in
Figure 7a and
Figure 8a. With multi-object pages, the gain obtained from stream multiplexing helps offset the protocol overhead produced in HTTP/2 and HTTP/3 compared to HTTP/1.1. However, with single-object web pages, HTTP/1.1 performs better over small RTT links. We can conclude that the stream multiplexing provides the highest gain when operating over high RTT links such as satellite links.
6.3. The Effect of the Congestion Control Algorithm
The congestion control algorithm used in the transport protocol plays a major role in the performance of HTTP protocols. For this, we evaluated the performance of HTTP with the Cubic and BBR algorithms with multi-object web pages in the satellite link. The web page structure was fixed to the uniform multi-object where the total page size was set according to
Table 3.
The average PLT of multi-object web pages downloaded with HTTP over the direct LAN link and the satellite link is shown in
Figure 9. The solid lines are for Cubic while the dashed lines represent BBR. The results indicate that BBR outperforms Cubic regardless of the type of HTTP protocol. This is because BBR allows up to
packets in-flight during its start-up phase in addition to
packets queued in the buffer. As a result, the number of packets in-flight particularly in satellite link will be large enough, due the large RTT, to produce better channel utilization than Cubic. Although Cubic manages to utilize the channel in the direct LAN link, it fails to do so in the larger RTT satellite link because it only updates its transmission rate every RTT, implying slower growth in such high latency links.
Moreover, the evaluation results revealed that Cubic with HTTP/3 also suffers in the direct LAN link. This is because HTTP/3 is able to transfer many more packets compared to HTTP/1.1 and HTTP/2 hence producing more protocol overhead in the link.
Table 6 shows the overhead percentage generated from transmitting different web pages in the three HTTP protocols. This is not a problem with BBR since it quickly utilizes the channel as discussed earlier, thus overcoming the effect of the HTTP/3 overhead.
6.4. The Effect of the Web Page Structure
The perceived user-level performance of downloading multi-object web pages is affected by the number of embedded objects, their sizes and how they are arranged in the web page. We assess this effect using the First Contentful Paint (FCP) and the Largest Contentful Paint (LCP), defined in
Table 5, in addition to the average PLT. The two web page structures considered here are the uniform multi-object page, with equal objects’ sizes, and the triangular multi-object page, where the objects are arranged in increasing-then-decreasing order as described in the previous section. The test used HTTP/2 and HTTP/3 over TCP, and QUIC while fixing the congestion control algorithm as BBR because it can fully utilize the channel.
Figure 10 shows the average First Contentful Paint (FCP) of downloading multi-object web pages over HTTP/2 and HTTP/3 in the satellite link. Here, we observe that HTTP/2 needs more time to get the first object from the server compared to HTTP/3. The reason is that HTTP/2 uses TCP which requires a three-way handshake for connection setup and another handshake for TLS security. HTTP/3, on the other hand, uses QUIC which requires only one RTT (1-RTT handshake) for the combined connection setup with TLS security. In addition, all HTTP protocols need at least two RTTs to complete a page request: one RTT to request the main web page (index page) and another RTT to request the first object within the page after the browser parses the main page as illustrated in
Figure 11. The triangular multi-object web page structure yields smaller FCP than the uniform in both HTTP/2 and HTTP/3. This is because the first object in the triangular structure is the smallest among the eight objects embedded in the web page. So, it will finish earlier than the first object in the uniform web page structure.
Next, we look at the second user-experience metric which is the time from the web request until the most significant (largest) object within the web page is loaded successfully. The average Largest Contentful Paint (LCP) of multi-object web pages in the satellite link is shown in
Figure 12. Here, HTTP/3 also outperforms HTTP/2 for the same reasons described earlier. However, the results clearly show the effect of the object size distribution and order within the web page itself. The triangular web page has smaller LCP than the uniform web page in both HTTP/2 and HTTP/3. Because the largest object in the triangular structure is located in the middle of the web page, it loads faster when parallel streams are used as in HTTP/2 and HTTP/3. This has a clear improvement on the perceived visual rendering of the web page as seen by the user.
Finally, the average page load time (PLT) of downloading uniform and triangular web pages is shown in
Figure 13. Clearly, the object distribution within the web page does not affect the PLT because it is determined by the total time needed to fetch all objects in the page successfully regardless of the size or location of each object.
6.5. Summary of Main Findings
In general, there is a significant advantage of HTTP/3 compared to either HTTP/2 or HTTP/1.1 in many network environments especially in large RTT satellite links. The results of our investigation can be summarized in the following.
Most of the performance gain of HTTP/2 and HTTP/3 compared to HTTP/1.1 comes from stream multiplexing of complex web pages. However, this comes at the cost of much larger protocol overhead due to mandatory TLS connection handshake and encryption. We can conclude that the stream multiplexing provides the highest gain when downloading multi-object pages over large RTT links such as satellite links.
The protocol overhead can dominate the performance of both HTTP/2 and HTTP/3 especially in low RTT links. HTTP/1.1 performs similar to HTTP/2 and HTTP/3 over very low RTT even when it fetches the web page sequentially, because it does not suffer from the overhead of connection handshake and encryption as in HTTP/2 and HTTP/3.
HTTP/3 further benefits from reducing the initial TLS connection handshake and the non-blocking feature of QUIC. The gains here are large enough to offset the protocol overhead when operating over large RTT links.
The effect of stream multiplexing is clearly visible when using complex web pages of multiple objects with varying sizes. From our investigation, we found that the perceived visual rendering of web pages will be better in HTTP/2 and HTTP/3 depending on the position of the most significant object within the HTML web page. This is especially notable in HTTP/3 since it does not suffer from HoL blocking at the transport layer.
BBR congestion control outperforms Cubic regardless of the type of HTTP protocol because it is able to quickly fill the pipe achieving higher utilization of the satellite link. Cubic fails to utilize the satellite link because it only updates its transmission rate every RTT, implying slower growth in these large RTT links.