I am starting to look into HTTP/2, running tests on Windows 10/IIS 10. From what I understand HTTP/2 is enabled there by default for secure connections. Yet when I am browsing a local site from Chrome 67.0.3396.99 - HTTP/2 seems slower, issuing more requests.
HTTP connection:
HTTPS connection:
Any idea why this is happening?
Your screenshot shows 8 additional requests being loaded over HTTPS so you are not comparing like for like. Investigate what those are and you'll likely have your answer.
Additionally while the latest version of IIS uses HTTP/2 by default you are better adding the protocol column to the network tab to confirm if this is being used. That way you know whether you are comparing HTTP to HTTPS or HTTP to HTTP/2 (over HTTPS).
HTTP/2 is primarily faster over high latency connections so you may not notice much difference over low latency connections (e.g. if testing with localhost) but it shouldn't really be any slower because of this (except for perhaps a small additional initial connection SSL/TLS negotiation time for HTTPS).
Related
source
In addition, the proliferation of incompletely-implemented
applications calling themselves "HTTP/1.0" has necessitated a
protocol version change in order for two communicating applications
to determine each other's true capabilities.
From the RFC:
HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet.
Rephrased:
Before HTTP was standardised there were differences in implementations that meant they couldn't always communicate with each other correctly (e.g. certain web-browsers couldn't work with certain web-servers). The RFC article refers to these pre-standardisation implementations as using HTTP/0.9.
HTTP/1.0, as defined by RFC 1945, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, and virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.
Rephrased:
After HTTP was standardised as HTTP/1.0 it certainly helped the interopability and compatibility problems, but version 1.0 of the protocol simply assumed all HTTP software would be able to use it for their existing application, but now that HTTP/1.0 has been in-use for a while the maintainers of the HTTP protocol specification saw that they need to extend HTTP to support these use-cases (e.g. proxies, caches, persistent connections, virtual-hosts) and while these things could be done using the built-in extension mechanisms in HTTP/1.0 they felt a need to increment the version number to HTTP/1.1 in order to prevent an implementation simply assuming the remote host supports a feature or not.
Example
A good example is the Host header in HTTP/1.1 that allows for a web-server serving from a single IP address and port number to serve-up different websites based on the Host header (as before HTTP/1.1 existed webservers could only serve one website per IP address, which is a problem). HTTP/1.0 does allow clients and servers to add their own custom headers, such as Host, however there is no way for the client or the server to know that the other end actually supports the Host header. But in HTTP/1.1 the Host header was formerly added to the specification so if both the client and server declare they use HTTP/1.1 then the other end knows that they'll recognize the Host header and handle it correctly.
So in the HTTP/1.0 days, with custom headers, this is how it would play out if a browser requests www.example.com if it were served from a Shared Webhost:
Browser (to DNS server): "Please give me the IP address for 'www.example.com'"
DNS Server (to browser): "www.example.com is 198.51.100.7"
Browser (to 198.51.100.7): "Hello, I speak HTTP/1.0, please send me index.html for Host: www.example.com
Server (to browser): "I also speak HTTP/1.0, here is index.html for 'not-actually-example.com'"
As you can see, the browser got not-actually-example.com even though it asked for www.example.com, because the Web-server was using HTTP/1.0 which does not recognize the Host header, even though the web-browser was sending the Host header (as an extension/experimental header). The browser software has no way of knowing if not-actually-example.com is what the user wanted or not.
In human terms, what they're saying is: so many people said they did HTTP 1.0 while they didn't, that nobody knew whether it really was HTTP 1.0 any more when someone said it.
To get out of that, they chose a new number.
What I did: I tweaked a Wordpress website so it will load within 2.3 seconds instead of the former 5 seconds. As a final step, I enabled HTTP/2 in the LAMP server (PHP7.0, Apache 2.4) and restarted Apache.
Issues: On doing this, the Time to First Byte jumped from 500ms to 9 seconds and the website PNG and JPEG images in the Speed Load Test (GTmetrix and Webpagetest.org) are now resulting in 404. Please, see screenshot here https://www.diigo.com/item/image/5pj5q/vt0g
Overall, the Speed Load Test is showing me that the website is loading at 20-30 seconds, instead of the former 2.3 seconds.
I am at a loss about how to solve those two issues caused by HTTP/2. Any advice is welcome.
I may have found the answer. It has to do with SSL Certs. At least for my situation. I use WHM/CPanel and the SSL certs get shared. HTTP2 detects that and sends a 421 error.
From Apache : https://httpd.apache.org/docs/2.4/mod/mod_http2.html
Multiple Hosts and Misdirected Requests
Many sites use the same TLS certificate for multiple virtual hosts.
The certificate either has a wildcard name, such as '*.example.org' or
carries several alternate names. Browsers using HTTP/2 will recognize
that and reuse an already opened connection for such hosts.
While this is great for performance, it comes at a price: such vhosts
need more care in their configuration. The problem is that you will
have multiple requests for multiple hosts on the same TLS connection.
And that makes renegotiation impossible, in face the HTTP/2 standard
forbids it.
So, if you have several virtual hosts using the same certificate and
want to use HTTP/2 for them, you need to make sure that all vhosts
have exactly the same SSL configuration. You need the same protocol,
ciphers and settings for client verification.
If you mix things, Apache httpd will detect it and return a special
response code, 421 Misdirected Request, to the client.
I disabled http2 and the 404/421 errors stopped.
As the title says,
I currently have a website with https on sensitive pages and cached http on the rest for speed.
I know HTTP2 is faster than HTTPS. What I don't know is whether HTTP2 is faster than regular un-encrypted HTTP?
Would I see performance improvements if I encrypted everything with SSL and enabled HTTP2, compared to using HTTP without encryption but with caching?
It completely depends on your site.
However, saying that, there is practically zero noticeable speed penalty for using HTTPS nowadays - unless you are on 20 year old hardware or serving huge content (e.g. you are a streaming site like Netflixs or YouTube). In fact even YouTube switched to HTTPS for practically all their users: https://youtube-eng.blogspot.ie/2016/08/youtubes-road-to-https.html?m=1
There is a small initial connection delay (typically 0.1 of a second) but after that there is practically no delay, and if on HTTP/2 then the gains that m will give to most sites will more than make up for tiny, unnoticeable, delay that HTTPS might add.
In fact, if you have some of your site on HTTPS already, then either you are using HTTPS resources on some of your site (e.g. common CSS that both HTTP and HTTPS pages use) and already experiencing this delay, as you need to connect over HTTPS to get those even when on HTTP, or you are making them available over both and making your HTTPS users download them again when they switch.
You can test the differences with a couple of sample sites on my blog here to give you some indication of differences: https://www.tunetheweb.com/blog/http-versus-https-versus-http2/ - which is a response to the https://www.httpvshttps.com website that I feel doesn't explain this as well as it should.
To implement HTTP/2 support on nginx/1.11.1, I'm going to redirect all HTTP Request to HTTPS.
In this case, how will Bot and Browsers, that don't support HTTP/2 protocol, behave and render the page?
Is there a way for me to simulate HTTP/1.1 browser behavior on Chrome Developer Tools?
You are mixing two concepts here that are somehow related, but they are largely different: HTTP to HTTPs redirect, and HTTP 1.1 vs HTTP/2 negotiation.
Redirecting HTTP to HTTPS requests is fine. Virtually every client (browser, bot, etc) available these days is capable of understanding HTTPS requests.
As for HTTP 1.1 vs HTTP/2, Nginx will fallback to HTTP 1.1 if the HTTP/2 connection fails because the client doesn't support it.
Last but not least, this question has very little to do with StackOverflow. It is more appropriate in ServerFault or SuperUser.
Potentially interesting
TCP retransmission will increase. This could lead on poorly configured devices for connection abort.
Question
If 2 HTTP requests are made to the same server at the same time from fresh, e.g. GET /image1.png HTTP/1.1 & GET /image2.png HTTP/1.1 with no previous connection to the server. Then should 1 TCP connection be made or 2?
Info
Persistent connections supported by default in HTTP 1.1. HTTP 1.0 uses the Connection: Keep-Alive.
It seems pretty clear from reading the RFC that if the above requests are made one after each other then the second request should reuse the connection.
HTTP Pipelining is sending multiple requests down the same connection without first waiting for a response. I am not sure where this fit into the answer tho.
If 2 HTTP requests are made to the same server at the same time from fresh, e.g. GET /image1.png
If the requests are made by the browser simultaneously (and there is no HTTP proxy server), then there will be two connections made to the server (unless http pipelining is enabled). Per the wikipedia article on pipelining,
Out of all the major browsers, only Opera based on Presto layout engine had a fully working implementation that was enabled by default. In all other browsers HTTP pipelining is disabled or not implemented.
Internet Explorer 8 does not pipeline requests, due to concerns regarding buggy proxies and head-of-line blocking.
Mozilla browsers (such as Mozilla Firefox, SeaMonkey and Camino) support pipelining, however it is disabled by default. Pipelining is disabled by default to avoid issues with misbehaving servers. When pipelining is enabled, Mozilla browsers use some heuristics, especially to turn pipelining off for older IIS servers.
Konqueror 2.0 supports pipelining, but it's disabled by default.
Google Chrome supports pipelining for HTTP in the stable release as a non-default option (starting with version 18). There is no support for pipelining HTTPS yet.[11] As of version 26, the flag to enable HTTP pipelining in Chrome has been disabled.
So, probably two connections.