A significant part of the services provided by Qrator Labs are based on the reverse proxy technology. This means that requests destined for your server go to the reverse proxy first, which then forwards them to your server, acting as a client. The same goes for the responses: the server sends them not directly to the user, but to the reverse proxy, and it forwards them to the user.

The server that the reverse proxy accesses is called the upstream.

This architecture allows Qrator Labs to solve the following challenges:

• Detect and stop DDoS attacks;
• Block known malicious requests;
• Block requests from bots;
• Perform balancing, distributing load between several upstreams that serves the same service;
• Establish persistent connections with upstream to save resources.

Reverse HTTP proxy works both with incoming unencrypted traffic via HTTP and with encrypted traffic via HTTPS. Upstream connections can also be made using both HTTP and HTTPS.

See also: How to connect reverse HTTP proxy.

HTTP proxyingHTTP proxying

If the site uses HTTP, then in order for the reverse proxy to start handling traffic, you only need to change the DNS A records for the domain.

The user's device contacts the DNS server and gets the IP address of the reverse proxy. After this, direct interaction of the user goes only with Qrator Labs servers. Requests that are not part of a DDoS attack are forwarded to the upstream, with the X-Forwarded-For header added to them.

The following situations are an exception:

• If you have added IP addresses to the blacklist, then requests from users from such addresses will not be forwarded to upstream. You can manage the blacklist from your Qrator Labs dashboard.

• If you have configured HTTP redirects, the Qrator Labs reverse proxy will return a response to the corresponding requests on its own, without forwarding the request to the upstream.

HTTPS proxyingHTTPS proxying

For HTTPS sites, the technology works on the same principles as for HTTP sites: each request from a user is analyzed, and if it came from a legitimate user, the reverse proxy forwards it to the upstream.

But since HTTPS traffic is encrypted, the reverse proxy must decrypt it before processing the request. This requires an SSL certificate and the associated chain of trust and private key. This data is placed in the certificate storage and is used to establish encrypted connections between users and the reverse proxy. Connections between the reverse proxy and the upstream can be set up using both HTTPS and HTTP.

You can add data to the certificate storage in two ways:

• Configuring automatic certificate issuance and renewal.
• Manually uploading files via the dashboard or API.

Automatic certificate issuanceAutomatic certificate issuance

Qrator Labs uses a free service Let's Encrypt to automatically issue certificates. You can order this certificate via your dashboard, specifying the list of domain names for which the certificate should be issued.

Each Let's Encrypt certificate is valid for 90 days after issuance. A few days before this period expires, Qrator Labs automatically sends a certificate reissue request and installs it instead of the outdated one. If automatic renewal is not possible, Qrator Labs will notify you.

To verify domain ownership for Let's Encrypt, the reverse proxy returns a specific token at a specific URL (HTTP-01 challenge). Note that the Let's Encrypt service will only be able to verify the presence of this token when the DNS A records already point to the reverse proxy's IP address. It is not possible to automatically issue a certificate before changing DNS records. So, after changing DNS records and before the certificate is issued, your resource will not be available to users via HTTPS. If you need it to be available immediately after changing DNS records and updating caches, it is recommended that you obtain and manually upload the certificate to the storage in advance.

Manually adding files to the certificate storageManually adding files to the certificate storage

You can manually add the certificate and its associated files to the certificate store by first issuing the certificate in any way. For example, you can add the same certificate that was used for the domain before connecting to Qrator Labs.

Each certificate must be accompanied by a chain of trust and a private key.

Data can be added either via dashboard or via API certrequest_upload, certrequest_install and sni_link_add. X.509 certificates in PEM format are supported. Supported container formats are pem, cer, crt, der, p7b, p7c, p12.

HTTP/2 proxyingHTTP/2 proxying

By default, the Qrator Labs reverse proxy only works over HTTP/1.1, but on your request, technical support specialists can enable support for HTTP/2 to connect to users. This version of the protocol can in some cases greatly speed up resource loading for users whose browsers also support HTTP/2. The use of HTTP/2 is only possible when using HTTPS.

One of the key differences between HTTP/1.1 and HTTP/2 is the ability to load multiple resources simultaneously. When using HTTP/1.1, to request a new resource, you either need to wait until the previous one is finished loading or create a new TCP session. Creating each new TCP session incurs certain costs, and the total number of such sessions in the browser is usually limited. With HTTP/2, the browser can send new requests within an already created TCP session; this approach is called multiplexing.

The connection between the Qrator Labs reverse proxy and the upstream is in any case over HTTP/1.1, but due to the large connection pool, the reverse proxy is capable of sending requests in parallel. See Persistent connections with upstream section below.

The Qrator Labs reverse HTTP proxy also supports HTTP/2 Server Push to proactively send resources that the browser might need later. See HTTP/2 Server Push below for details.

Establishing an encrypted connectionEstablishing an encrypted connection

When dealing with HTTPS traffic, reverse proxy:

• Supports the following encryption algorithms (cipher suites) for connections to users:

  TLS versions	Cipher suites
  TLS 1.0, 1.1, 1.2	ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 AES128-GCM-SHA256 AES128-SHA256 AES128-SHA DES-CBC3-SHA
  TLS 1.3	TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256

  Note

  Qrator Labs technical support can change the list of allowed algorithms at your request.

• Supports all possible algorithms and all versions of TLS for upstream connections. The upstream's authenticity is not verified.

Speed optimizationSpeed optimization

Qrator Labs reverse HTTP proxy allows you to optimize your connection performance through several techniques:

• Persistent connections with upstream
• TLS offloading
• HTTP/2 Server Push

Persistent connections with upstreamPersistent connections with upstream

When processing an HTTP request from a website visitor, significant time is spent establishing a TCP transport session. If HTTPS is used, each new TCP session is followed by a TLS handshake and generation of session key which also takes considerable time.

A reverse proxy can establish TCP sessions and perform TLS handshakes in advance, forming a dynamic pool of sessions ready for instant payloads. The reverse proxy uses a session from this pool to process each request. One session can be sequentially used to process many requests.

When a user connection is made via HTTP/2 and the user requests multiple resources within the same connection, the Qrator Labs reverse proxy directs those requests to the upstream through different connections from the pool. This way the user can effectively use the HTTP/2 capabilities without having to configure full-fledged HTTP/2 support from the upstream side.

TLS offloadingTLS offloading

Using HTTPS implies encrypting all traffic with a session key, which can lead to slower processing of each request than in HTTP protocol. This is especially noticeable on sites with high traffic.

Reverse proxy can work in TLS offloading mode. This means that a connection with the upstream can use HTTP, even if the user accesses the resource via HTTPS. The reverse proxy takes all the load associated with TLS and the upstream consumes fewer resources to process each request. This configuration often results in faster resource performance.

HTTP/2 Server PushHTTP/2 Server Push

The HTTP/2 protocol allows you to send a user resources that have not yet been requested but may be needed later, such as stylesheets and images related to the page being downloaded. This technology is called Server Push. When properly configured, Server Push can speed up site loading.

However, because the reverse proxy and the upstream connect using HTTP/1.1, the upstream cannot initiate Server Push directly. To take advantage of Server Push, configure your web server so that its responses contain Link HTTP headers (RFC 5988) with the rel=preload parameter. Multiple Link headers can be added to a single server response.

Header example:

Link: </style.css>; as=style; rel=preload

On detecting such a header in the response, Qrator Labs reverse proxy will request the specified resource (in this example, styles file /style.css) from the upstream and send it to the user via HTTP/2 Server Push.