# Implementation and Evaluation of HTTP/3 Connectivity Check Using Happy Eyeballs Algorithm
## 3 Proposed Method  
We propose a method for the application of the Happy Eyeballs algorithm to HTTP/3. However, as mentioned in Section 2.3, it cannot be applied immediately and several changes are required. Furthermore, this method offers several medium- and long-term benefits that will arise later, in addition to the short-term speedup until communication starts, owing to features such as QUIC congestion control, retransmission control, and HTTP priority control. We assume that QUIC encrypts the communications with the TLS so that the http schema indicating unencrypted communications is not used, and URLs are presented in the https schema. Moreover, we assume that the HTTP/3 acceptance port number is fixed to 443. Subsequently, the connection start delay discussed in Section 5 of the Happy Eyeballs specification [11]; i.e., the time between starting HTTP/3 and the old HTTP in this method, is fixed to 10 ms, which is defined as the minimum line. Other recommendations include a range of 100 ms-2 s depending on the congestion, with a default of 250 ms; however, this study is an application to a problem other than IPv4/IPv6. This means that the recommended value cannot be used as is. Moreover, there is no scientific basis for the original value, and it only indicates that the one round trip time (RTT) is a guideline. The IPv6 value is also not used as is. Furthermore, although the new protocol is given priority in this study, the old protocol should be similarly explored with little delay because the share of QUIC-enabled sites on the Internet is not high. After considering the intent of the specification to the extent applicable to this study, a fixed delay of 10 ms was selected to avoid computational problems. Moreover, the 0-RTT (this method sends application data from the beginning, skipping the TLS or other handshake for the communication destination that is obtained from the previous connection information. Originally proposed in RFC8446 [7], which defines TLS1.3, it was also incorporated into QUIC as a specification) function of QUIC is not used. This is because it assumes that the QUIC connection is available, which is beyond the scope of this study, and that the control for secure communication is complicated. In the Happy Eyeballs evaluation experiment on IPv4/IPv6 that was conducted by [PERSON] et al. [12], the authors compared the timings of the end of the TCP handshakes. However, in this context, the new protocol and old protocol have different transport layers, so the timing must be considered to compare the connectivity. This method compares the point in time when the QUIC-aggregated handshake ends in the new protocol with the point in time when both the TCP and TLS overlapping handshakes end in the old protocol. There are several reasons for this: the above are aligned in timing, application data are  
Figure 2: Happy Eyeballs. sent and received, and end users strongly prefer a final conclusion and not an intermediate result of the connection. The specific logic is presented in Figure 3.  
After a 10 ms connection start delay, HTTP/3 and old HTTP connection attempts are started in succession. If the QUIC handshake ends first, HTTP/3 is adopted and the other process is terminated immediately. Otherwise, the old HTTP is adopted and the HTTP request proceeds. If QUIC fails to connect following a delay, the site in question is assumed to be unsupported by HTTP/3 and the information is stored in the client. If QUIC completes the connection after a delay, the first HTTP request scheduled on QUIC is cancelled to eliminate duplication, but the fact that the connection is possible via HTTP/3 is saved to the client. This allows all requests for a period during which a connection does not need to be reestablished to select the appropriate protocol by simply referring to the correspondence information that is stored on the client.