You probably noticed that the website looks different. It not only looks different, but the whole machinery is different. We use the website as dogfooding for Tempesta FW, i.e. we test all the new features in Tempesta FW on the website. This article describes some new Tempesta FW features, which were recently released and which are in testing with the new website.
WordPress
WordPress requires some additional settings on a web accelerator side and we collected the tips & tricks for Tempesta FW. The tips & tricks link is the link to our wiki, which is updated on the GitHub repo and is converted to HTML and directly inserted into the MySQL database by a special Python script without any interactions with the WordPress PHP code. This means that Tempesta FW is also unaware about the changes in the wiki. An extensional HTTP request PURGE can be used to purge invalid content from a web accelerator cache and replace it with a new one. Traditional web accelerators (like Nginx) just evicts the purged resources. There is a problem with the approach.
A pretty “hot” content could be purged, and moreover, it can be purged frequently, so the first hit to the already not-cached resource is proxied to an upstream server producing more client requests with high latencies.
Tempesta FW extends the PURGE requests with X-Tempesta-Cache: get
header. Once Tempesta FW receives the request, following machinery happens:
- Tempesta FW purges the resource from the cache and sends a
GET
request to the upstream. - When Tempesta FW receives a response for the request, it caches it and any following client request will be serviced immediately right from the cache.
- Replying to a PURGE request (sent by a WordPress plugin in this case), Tempesta FW does not include the response body for the PURGE response to not to overload the client and the network.
- Actually, Tempesta FW just rewrites the method (from PURGE to GET) in the request, so you can add any other headers, which you need to pass to the upstream.
HTTP/2
The new website is services by HTTP/2 – just check this with the small blue lightening on the right in the address bar or in a Web Developer Tools for your browser.
HTTP/2 is a robust protocol and is provided by all modern HTTP servers and clients, but there are still issues with the streams (one of the killer feature for HTTP/2 over HTTP/1) scheduling in both the server (not fair or too slow scheduling) and client (browsers could do better work in assignment of the streams’ weights).
We researched the state of the art of HTTP/2 streams scheduling in Chromium, Firefox and Opera browsers and the streams scheduling implementations in Nginx, H2O, Envoy, Apache HTTPD (the last two, like curl, use the nghttp2 library to provide HTTP/2). You can find the details of the research in our wiki page HTTP/2 streams prioritization.
We started our research with intent to borrow streams scheduling from some open source project with compatible license, but we ended up with our own implementation, which can reduce an average download time for progressive JPEGs like Cloudflare does it (surely not in open source).
Super-fast TLS handshakes and more
We announced the benchamarks of our TLS handshakes back in 2021 on Mathematics and development of fast TLS handshakes FOSDEM talk. During the live demo on the talk we demonstrated that Tempesta TLS can establish 2-3 times more handshakes per second than Nginx with OpenSSL or WolfSSL and up to x5 lower 95% latency. Tempesta FW 0.7 is the first release, which employs the handshakes implementation.
Besides all these exciting things 0.7 delivers bunch of new exciting features:
- Websockets
- Custom HTTP redirects
- Sticky cookies load balancing
- and many web cache and TLS extensions, which make operation easier (even for us managing this website!)
You can download Tempesta FW in source code or binary release on our GitHub page. We appreciate any feedback on the project testing!
We are hiring! Take a look at our opportunities
Share the article