I notice that OkHttp support h2 over ALPN in Android 5.0+.
From some article,I learned that we can use NPN Negotiation for http/2 request.
Can I send http/2 request with OkHttp over NPN Negotiation?
So that it's possible to support h2 on android 4.1+ with better network performance :-D
We dropped NPN support. ALPN is the future.
Related
I know, that if we talk about non secured connection, it is possible to establish connection via http/2 protocol without ALPN.
But what about TLS connection? In RFC said:
A client MUST send the connection preface (Section 3.5) and then MAY
immediately send HTTP/2 frames to such a server; servers can identify
these connections by the presence of the connection preface. This
only affects the establishment of HTTP/2 connections over cleartext
TCP; **implementations that support HTTP/2 over TLS MUST use protocol
negotiation in TLS [TLS-ALPN]**.
Does it mean that both server and client must use ALPN to establish connection via TLS and http2? Or there are workarounds and other options?
A compliant HTTP/2 client must send the ALPN extension for HTTP/2 over TLS.
However, what would a server do if the ALPN extension is not present?
This may happen with old clients, or non-compliant clients, or attackers.
The server could be legitimately configured to speak only HTTP/2 (for example, https://h2.domain.com), so it may assume that the protocol being spoken is h2 without the need of negotiating it via ALPN. This is an implementation/configuration choice. (Another valid choice could be to just close the connection if ALPN is absent).
The RFC also discusses the role of ALPN for cross-protocol attacks, see this section.
I think the intent of the RFC is to mandate the use of ALPN; however, a server should be prepared to receive connection attempts without ALPN, and at that point it can be configured to either close the connection or assume a default protocol, which is typically http/1.1, but could as well be h2.
Keep in mind that you may always use TLS without ALPN and perform an HTTP/1.1 to HTTP/2 upgrade request (where, like in ALPN, you declare what protocol you want to upgrade to), which would typically succeed as servers should support HTTP/1.1 to HTTP/2 upgrade.
So you would be able to speak HTTP/2 to such servers, after the upgrade, even without ALPN.
A server may assume that if ALPN is missing, the client wants to try with an HTTP/1.1 to HTTP/2 upgrade. If the server does not see the upgrade (but directly the HTTP/2 client preface), it may reply with 426 Upgrade Required (see here).
I am trying to connect to a server that defaults to HTTP/2 with Apach Http-Components 3.4, which is not HTTP/2 compatible. I see here that a client can request HTTP/2 from the server via the Upgrade header. Is there a way to request HTTP/1.1 from the server?
Yes, it should be the default. A server should only HTTP/2 to a client if it was previously negotiated.
Either:
through an upgrade from HTTP/1 through the HTTP Upgrade header
through protocol negotiation (ALPN) during the TLS handshake
It is theoretically possible to force HTTP/2 on both sides without negotation. This is called HTTP/2 with prior-knowledge. However that mode shouldn't be used on public servers, since it exactly causes the problems that you are having.
I would try to speak to the developers/maintainers of the server if the HTTP/2 only behavior is intended.
The new HTTP/2 protocol comes with some promising features. Some of them:
Multiplexing - a single TCP connection can be used to make multiple HTTP/2 requests and receive multiple responses (to a single origin)
HTTP/2 Server Push - sending server responses to the client without receiving requests, i.e. initiated by the server
Bidirectional connection - HTTP/2 spec - Streams and Multiplexing:
A "stream" is an independent, bidirectional sequence of frames
exchanged between the client and server within an HTTP/2 connection.
The motivation behind HTTP/2 is explained here HTTP/2 FAQ:
HTTP/1.1 has served the Web well for more than fifteen years, but its
age is starting to show.
and
The goal of the Working Group is that typical uses of HTTP/1.x can use HTTP/2 and see some benefit.
So HTTP/2 is nice and comes to replace HTTP/1.x. Unfortunately, HTTP/2 does not support WebSockets. In this question Does HTTP/2 make websockets obsolete? it is made clear that the HTTP/2 Server Push is not an alternative, neither are Server-Sent Events.
Now to the question: What do we use if we want WebSockts functionality over HTTP/2?
Current forms of HTTP/2 Protocol Negotiation:
HTTP/2 connections start in one of three ways:
In an encrypted connection (TLS/SSL) using ALPN (Application Layer Protocol Negotiation). Most browsers require TLS/SSL for HTTP/2 and use this method for HTTP/2 connection establishment.
In clear text, using the HTTP/1.1 Upgrade header (same as Websockets). Most browsers require TLS/SSL for HTTP/2, so this is limited in it's support.
In clear text, using a special string at the beginning of an HTTP/1.1 connection (which could allow HTTP/2 servers in clear text to disable HTTP/1.1 support). Limited client support.
Negotiating the Websocket Protocol, present tense:
Negotiating Websocket connections, at the moment, requires HTTP/1.1 support and makes use of the HTTP/1.1 Upgrade header.
This is often performed by the same application server that listens to the HTTP/1.1 and HTTP/2 connections. Web applications that support concurrency (whether evented or thread based) are usually protocol agnostic (as long as HTTP semantics are preserved) and work well enough on both protocols.
This allows HTTP data to be used during connection establishment (and perhaps effect the Websocket connection state/authentication procedure).
Once the Websocket connection is established, it's totally independent from the HTTP semantics / layer.
Negotiating the Websocket Protocol in an HTTP/2 world:
In an HTTP/2 (only) world, which might be a while into the future, there could be a number of possible approaches to Websocket protocol negotiation: an ALPN based approach and an HTTP/2 "tunnel" (or "stream") approach.
The ALPN approach preserves protocol independence at the expense of the pre-upgrade (HTTP) stage, while the "stream" approach provides the HTTP pre-"upgrade" (or Connect) stage at the expense of high coupling and complexity.
The ALPN Approach:
One possible future approach will simply add the Websocket protocol to the ALPN negotiation table.
At the moment, ALPN is used to select (or default to) the "http/1.1" protocol and the Upgrade request is handled by the HTTP/1.1 server. Which means that Websocket still provides us with the HTTP header data during protocol negotiation (while using it's own TCP/IP connection)
In the future, ALPN might simply add "wss" as an available choice.
Using this approach, the Websocket (which is currently established using the HTTP/1.1 Upgrade header, both in encrypted and clear text forms) could easily be negotiated using the ALPN extension to the TLS/SSL layer.
This will keep the Websocket protocol independent from the HTTP/2 protocol and allow it's use even when HTTP isn't supported.
However, this will come with the downside that cookies and other HTTP headers might be no longer available as part of the protocol negotiation. Another difference (both good and bad) is that this approach will require a separate TCP/IP connection.
The HTTP/2 "tunnel" / "stream" approach
Another possible future approach, which is reflected in this proposed draft, will dispose of the HTTP/1.1 variation of the Websocket protocol in favor of an HTTP/2 "stream" approach.
HTTP/2 "streams" are the way HTTP/2 implements multiplexing and allows multiple requests to be handled concurrently. Each request receives a stream number ID and any data pertaining to this request (headers, responses etc') is identified using the same numerical stream ID.
Under this approach, "Websocket" data will be contain within the HTTP/2 wrapper and the stream ID will be used to identify the "Websocket" stream.
Although this might provide some benefits (HTTP headers and cookies could be provided as part of the Websocket negotiation), it's not without its downfalls.
Higher complexity and tighter protocol coupling are just two examples, both of which are very serious downfalls.
Conclusion:
At the time of this writing, HTTP/1.1 Upgrade semantics are required for Websocket connections, both when using clear text (ws) and encrypted (wss) connections.
The future is, as of yet, undecided and it will probably take a long time before the current Upgrade process (using HTTP/1.1) is phased out
Well your timing is rather apt!
A new version of the internet standards draft was literally just published:
Bootstrapping WebSockets with HTTP/2
Additional information here:
https://github.com/mcmanus/draft-h2ws/blob/master/README.md
And you can follow the discussion in it here:
https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0032.html
Until this is approved, and then implemented by browsers and servers, I would say that Daniel Haxx’s post that you included in your question represents a very good summary of the current status.
One of your links actually has one answer: you can just use SSE.
Semantically, you can achieve the same things with either websockets or (SSE + POST ). The view that the two technologies address different use cases is, roughly speaking, bikeshedding around "this syntax works better for this".
There are ongoing efforts to port something similar to websockets to HTTP/2, but unless those technologies make possible new uses cases or efficiencies, I see no point.
If I type out https://http2.golang.org/ the chrome browser will automatically send the HTTP/2 request. How is this done?
Take stackoverflow for example, when the browser sends a request to stackoverflow.com, it has to do the following steps:
DNS lookup. find the ip address of stackoverflow.
TCP/IP handshake
TLS handshake.
HTTP request/response (Application Protocol).
....
TLS handshake
Regarding step3 TLS handshake, there is an nice explanation by #Oleg.
In order to inspect the detail of TCP/IP packet, You may need use some tools to capture packets. e.g. Wireshark.
Client sends ClientHello to server, which carries several things
supported cipher suite. which cipher suites do you like?
supported TLS version.
a random number.
the supported Application Protocols. e.g. HTTP/2, HTTP 1.1/ Spdy/..
...
Server responds SeverHello, which carries
chosen cipher suite.
chosen TLS version.
a random generated number
And, chosen application protocols in TLS application-layer protocol negotiation (ALPN), e.g. HTTP/2
Conclusion
HTTP2 request/response happens in step4. Before that, browser has already know whether sever support HTTP/2 through TLS handshake.
The chrome browser will only send a HTTP/1.1 Request to the website. As the website is HTTP/2 Enabled, it will send a message to the browser that it supports HTTP/2. The server upgrades the communication protocol between it and the server to HTTP/2 if it finds the browser capable of recognizing HTTP/2.
So, it is generally the server which converts a request to the HTTP/2 Connection. The browser just complies with the upgrade policy of the server.
The chrome browser displays that you have a HTTP/2 connection with the server or website, only after the server upgrades the communication protocol.
The string "h2" identifies the protocol where HTTP/2 uses Transport Layer >Security (TLS) [TLS12].
This identifier is used in the TLS application-layer protocol negotiation (ALPN) >extension [TLS-ALPN] field and in any place where HTTP/2 over TLS is identified.
If server support http2.0 browser will find that server is support http2.0 in TLS application-layer protocol negotiation.
refer link!
In this way, the client can connect the server without ALPN and use http/2 default.
Is that possible？
Yes it is possible, but the conditions are strict.
Browsers, as of now, do not implement clear-text communication for HTTP/2, so if you use a browser the answer to your question is no: you have to deploy your server with ALPN support if you want browsers to be able to connect.
On the other hand, other clients such as Java clients may be able to connect to a server using clear-text HTTP/2, so for those type of clients the answer to your question is yes: you can deploy a HTTP/2 server without ALPN support.
The Jetty Project [disclaimer, I am a committer] implements a web server and servlet container that support both scenarios: you can enable ALPN for TLS (SSL) HTTP/2 communication so that browsers will be able to connect, and you can also enable clear-text HTTP/2 communication as explained here. See also the Jetty HTTP/2 documentation.