-
1.
HTTP/2 Comes to Java
What Servlet 4.0 Means to You
Ed Burns
Java EE Specification Team
Oracle
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
-
2.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2
-
3.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Our Plan for Your Time Investment
Why HTTP/2?
HTTP/2 Big Features
How Servlet Might Expose These Features
Java SE 9 Support for HTTP/2
Summary and Current Status
1
2
3
4
5
3
-
4.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Our Plan for Your Time Investment
Why HTTP/2?
HTTP/2 Big Features
How Servlet Might Expose These Features
Java SE 9 Support for HTTP/2
Summary and Current Status
1
2
3
4
5
4
-
5.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Why HTTP/2?
A Real Life Example
index.html
style1.css
style2.css
.
.
.
script1.js
script9.js
pic1.jpg
pic8.jpg
.
.
.
photo1.png
photo2.png
.
.
.
-
6.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Why HTTP/2?
• Head-of-Line blocking
Problems in HTTP/1.1
-
7.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Why HTTP/2?
• HTTP Pipelining
• Head-of-Line blocking
Problems in HTTP/1.1
style1.css
style2.css
Client Server
index.html
index.html
style1.css
style2.css
script1.js
.
.
.
script2.js
.
.
.
script1.js
script2.js
-
8.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Why HTTP/2?
• Inefficient use of TCP sockets
Problems in HTTP/1.1
Client ServerClient Server
Client Server
Client Server
Client Server
Client Server
-
9.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Why HTTP/2?
• Much of what we do in web-apps is a hack to work around shortcomings in
HTTP/1.1
– File concatenation and image sprites
– Domain sharding
– Inlined assets
What is an optimization?
9
-
10.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
File Concatenation and Image Sprites
TCP Efficiency Improves with Larger Files
10
-
11.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
File Concatenation and Image Sprites
TCP Efficiency Improves with Larger Files
11
• Modern web page now consists of more than 90 resources fetched from 15
distinct hosts
• Solution:
– Just work around it by shoving more than one logical file into one physical file.
– Seminal article: A List Apart http://alistapart.com/article/sprites
– Useful tool: SpritePad http://spritepad.wearekiss.com/
-
12.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
File Concatenation and Image Sprites
TCP Efficiency Improves with Larger Files
12
.ic-AerospaceAndDefense-wht-on-gray, .ic-AerospaceAndDefense-wht-on-
red, .ic-Airline-wht-on-gray, .ic-Airline-wht-on-red{
background: url(sprites.png) no-repeat;
}
.ic-AerospaceAndDefense-wht-on-gray{
background-position: 0 0;
width: 80px;
height: 80px;
}
.ic-AerospaceAndDefense-wht-on-red{
background-position: -81px 0;
width: 80px;
height: 80px;
}
.ic-Airline-wht-on-gray{
background-position: 0 -80px ;
width: 80px;
height: 80px;
}
.ic-Airline-wht-on-red{
background-position: -81px -79px ;
width: 80px;
height: 80px;
}
-
13.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Domain Sharding
Split page resources across several hosts to work around browser limits
13
-
14.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Inlined Assets
• data URLs
• <img
src="data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jv
b29t/f3//Ub/
/ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4…" />
Base64 Encoding Will Never Die
14
-
15.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Our Plan for Your Time Investment
Why HTTP/2?
HTTP/2 Big Features
How Servlet Might Expose These Features
Java SE 9 Support for HTTP/2
Summary and Current Status
1
2
3
4
5
15
-
16.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 is really just a new transport
layer underneath HTTP/1.1
– same request/response model
– no new methods
– no new headers
– no new usage patterns from
application layer
– no new usage of URL spec and other
lower level specs
Network Programming Review
16
-
17.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Standing on the Shoulders
17
-
18.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
18
-
19.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
19
-
20.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
20
-
21.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
21
-
22.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
22
-
23.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
23
-
24.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
24
-
25.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• HTTP/1.0
– Sockets are a throwaway resource
– Specification says very little about how
sockets are to be used
– Browsers free to open many sockets to
the same server
Network Programming Review
25
Credit: chrisjstanley flickr
The Socket Angle
-
26.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
26
The Socket Angle
• HTTP/2
– Sockets seen as a scarce resource
– Specification says much about how
they are to be used
– Only one open per server
-
27.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
27
The Socket Angle
• It would be like if we took the
existing Servlet specification
-
28.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
28
The Socket Angle
• It would be like if we took the
existing Servlet specification
and added a new layer underneath
it
-
29.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
Problems in HTTP/1.1
Client ServerClient Server
Client Server
Client Server
Client Server
Client Server
-
30.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
Solution in HTTP/2
Client Server
-
31.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
• HTTP/1.0 was designed to be easy to implement with contemporary
development practices of 1991
– text based protocol
– leaves flow control to the TCP layer
– easy to write a parser
– simple socket lifecycle
The Adoption Angle
31
-
32.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Network Programming Review
• HTTP/2 is much more complicated to implement
– state machine
– header compression
– binary framing (arguably easier than text based for parsing)
The Adoption Angle
32
-
33.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• HTTP/2 is much more complicated
to implement
– No more
telnet host 80
GET /somepage.html rnrn
33
Network Programming Review
The Adoption Angle
-
34.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• HTTP/2 is much more complicated
to implement
– No more
telnet host 80
GET /somepage.html rnrn
34
Network Programming Review
The Adoption Angle
-
35.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• Request/Response multiplexing
• Binary Framing
• Stream Prioritization
• Server Push
• Header Compression
• Upgrade from HTTP/1.1
• ALPN (or NPN)
• 101 Switching Protocols
35
HTTP/2 Big Ticket Feature Review
-
36.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | 36
HTTP/2 Big Ticket Feature Review
-
37.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Request Response Multiplexing
• Fully bi-directional
• Enabled by defining some terms
– Connection
A TCP socket
– Stream
A “channel” within a connection
– Message
A logical message, such as a request or a response
– Frame
The smallest unit of communication in HTTP/2.
37
Lets you do more things with a single TCP connection
-
38.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Request Response Multiplexing
38
Connections, Streams, Messages, Frames
-
39.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Request Response Multiplexing
• Once you break the communication down into frames, you can interweave
the logical streams over a single TCP connection.
• Yet another idea from the 1960s is new again.
39
Connections, Streams, Messages, Frames
Browser
ServerSingle TCP connection for HTTP 2
STREAM'4'
HEADERS'
STREAM'9'
HEADERS'
STREAM'7'
DATA'
STREAM'7'
HEADERS'
STREAM'2'
HEADERS'
STREAM'2'
DATA'
-
40.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Binary Framing
• Solves Head-Of-Line (HOL) blocking problem
• Type field can be DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS,
PUSH_PROMISE, PING, GOAWAY, WINDOW_UPDATE, CONTINUATION
40
Enabled by dumping newline delimited ASCII
Length (24)
Type (8) Flags (8)
R Stream Identifier (31)
Frame Payload (0 …)
-
41.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Binary Framing
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
41
Example 1
HEADERS
+ END_STREAM
+ END_HEADERS
:method: GET
:scheme: http
:path: /index.html
:authority: example.org
accept: text/html
-
42.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Binary Framing
HTTP/1.1 200 OK
Content-Length: 11
Content-Type: text/html
Hello World
42
Example 2
HEADERS
- END_STREAM
+ END_HEADERS
:status: 200
content-length: 11
content-type: text/html
DATA
+ END_STREAM
Hello World
-
43.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Stream Prioritization
• Stream Dependency in HEADERS Frame
• PRIORITY frame type
• An additional 40 bytes
– Stream id (31)
– Weight (8): [1, 256]
– Exclusive bit (1)
• Only a suggestion
43
S
A
B C
4 12
A
B CD
4 16 12
exclusive = 0
A
B C
D
4 12
16
exclusive = 1
-
44.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Server Push
• Eliminates the need for resource inlining.
• Lets the server populate the browser’s cache in advance of the browser
asking for the resource to put in the cache.
• No corresponding JavaScript API, but can be combined with SSE
– Server pushes stuff into the browser’s cache.
– Server uses SSE to tell the browser to go fetch it (but we know it’s already in the
browser’s cache).
44
E
-
45.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Header Compression
• Observation: most of the headers
are the same in a given stream
– Host: Accept: user-agent: etc.
• Why send them every time?
• Have the server and the client keep
tables of headers, then just send
references and updates to the
tables.
45
Known as HPACK
-
46.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Upgrade from HTTP/1.1
• Not secure
– We have to use port 80
– Use existing 101 Switching Protocols from HTTP/1.1
• Secure
– Next Protocol Negotiation (NPN)
– Application Layer Protocol Negotiation (ALPN)
46
Secure or not-secure?
-
47.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
HTTP/2 Upgrade from HTTP/1.1
• Not secure
– We have to use port 80
– Use existing 101 Switching Protocols from HTTP/1.1
• Secure
– Next Protocol Negotiation (NPN)
– Application Layer Protocol Negotiation (ALPN)
47
Secure or not-secure?
-
48.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Criticism of HTTP/2
• HOL blocking is still a problem, just shuffled around
– HOL blocking can still happen in HEADERS frames
• No h2c in Firefox or Chrome
– Mention the IETF RFC-7258
• Carbon footprint for all that HPACK encoding/decoding
• Numerous new DoS attack vectors
• HTTP/2 is orthogonal to WebSocket
Everybody's a Critic
48
-
49.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Criticism of HTTP/2
• Poul Henning-Kamp's rant just before WGLC
– http://queue.acm.org/detail.cfm?id=2716278
Everybody's a Critic
49
-
50.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Criticism of HTTP/2
• Poul Henning-Kamp's rant just before WGLC
– http://queue.acm.org/detail.cfm?id=2716278
Everybody's a Critic
50
-
51.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Criticism of HTTP/2
• Poul Henning-Kamp's rant just before WGLC
– http://queue.acm.org/detail.cfm?id=2716278
Everybody's a Critic
51
-
52.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Criticism of HTTP/2
• Poul Henning-Kamp's rant just before WGLC
– http://queue.acm.org/detail.cfm?id=2716278
Everybody's a Critic
52
Credit: Michael Fritz
-
53.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Don't take my word for it
• HTTP/2 isn't one spec, it's two specs
– HTTP/2 protocol
– HPACK
• Built on top of many other specs
53
-
54.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Don't take my word for it
54
-
55.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Don't take my word for it
55
-
56.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Aside
Servlet and Reactive
Programming
56
-
57.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Reactive Programming
57
Responsive
Message Driven
ResilientElastic
image credit: reactivemanifesto.org
-
58.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Servlet 4.0 and Reactive Programming
• Non-blocking IO in Servlet 3.1
– ServletInputStream
• #setReadListener, #isReady
– ServletOutputStream
• #setWriteListener, #isReady
– ReadListener
• #onDataAvailable, #onAllDataRead, #onError
– WriteListener
• #onWritePossible, #onError
58
-
59.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Servlet 4.0 and Reactive Programming
• Asynchronous in Servlet 3.0
– ServletRequest#startAsync
– AsyncContext
• #addListener, #dispatch, #complete
– AsyncListener
• #onComplete, #onError, #onStartAsync, #onTimeout
• Event-driven
– Server-Sent Events
59
-
60.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Our Plan for Your Time Investment
Why HTTP/2?
HTTP/2 Big Features
How Servlet Might Expose These Features
Java SE 9 Support for HTTP/2
Summary and Current Status
1
2
3
4
5
60
-
61.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Our Plan for Your Time Investment
Why HTTP/2?
HTTP/2 Big Features
How Servlet Might Expose These Features
Java SE 9 Support for HTTP/2
Summary and Current Status
1
2
3
4
5
61
-
62.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• Existing API is designed for One Request == One Response.
• HTTP/2 destroys this assumption.
• It will be challenging to do justice to the new reality of One Request == One
or More Responses.
• We must not simply bolt the “One or More Responses” concept onto some
convenient part of the existing API.
62
Challenges in Exposing HTTP/2 Features in Servlet API
Servlet 4.0 Big Ticket New Features
-
63.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• Request/Response multiplexing
• Binary Framing
• Stream Prioritization
• Server Push
• Header Compression
• Upgrade from HTTP/1.1
– ALPN or (NPN)
– 101 Switching Protocols
63
HTTP/2 Features
Servlet 4.0 Big Ticket New Features
-
64.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• Request/Response multiplexing
• Binary Framing
• Stream Prioritization
• Server Push
• Header Compression
• Upgrade from HTTP/1.1
– ALPN or (NPN)
– 101 Switching Protocols
64
HTTP/2 Features Potentially Exposed in Servlet API
Servlet 4.0 Big Ticket New Features
-
65.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• Add method HttpServletRequest and HttpServletResponse
– int getStreamId()
65
Request/Response Multiplexing
Servlet 4.0 Big Ticket New Features
-
66.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• Add a new class Priority
– boolean exclusive
– int streamId
– int weight
• Add method to HttpServletRequest
– Priority getPriority()
• Add methods to HttpServletResponse
– Priority getPriority()
– void setPriority(Priority p)
66
Stream Prioritization
Servlet 4.0 Big Ticket New Features
-
67.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
• Push resource to client for a given url and headers
• May add callback for completion or error of a push
• Not at all a replacement for WebSocket
• Really useful for frameworks that build on Servlet, such as JSF
67
Server Push
Servlet 4.0 Big Ticket New Features
-
68.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | 68
Server Push
Servlet 4.0
Big Ticket
New Features
Browser
Server Thread A
servlet.service()
GET /index.html
Server
discovers
browser will
need style.css
and script.js
request.dispatchPushRequest("style.css")
request.dispatchPushRequest("script.js")
Server Thread B
servlet.service()
synthetic GET /style.css
synthetic GET /script.js
Server Thread C
servlet.service()
style.css
script.js
index.html
-
69.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Server Push
public class FacesServlet implements Servlet {
public void service(ServletRequest req,
ServletResponse resp) throws IOException, ServletException {
//..
HttpServletRequest request = (HttpServletRequest) req;
try {
ResourceHandler handler =
context.getApplication().getResourceHandler();
if (handler.isResourceRequest(context)) {
handler.handleResourceRequest(context);
} else {
lifecycle.attachWindow(context);
lifecycle.execute(context);
lifecycle.render(context);
}
}
}
Example of Potential Use from JSF
69
-
70.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Server Push
public class ExternalContextImpl extends ExternalContext {
//…
public String encodeResourceURL(String url) {
if (null == url) {
String message = MessageUtils.getExceptionMessageString
(MessageUtils.NULL_PARAMETERS_ERROR_MESSAGE_ID, "url");
throw new NullPointerException(message);
}
Map attrs = getResourceAttrs();
((HttpServletRequest) request).dispatchPushRequest(url, attrs);
return ((HttpServletResponse) response).encodeURL(url);
}
//…
}
Example of Potential Use from JSF
70
-
71.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Our Plan for Your Time Investment
Why HTTP/2?
HTTP/2 Big Features
How Servlet Might Expose These Features
Java SE 9 Support for HTTP/2
Summary and Current Status
1
2
3
4
5
71
-
72.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Java SE 9 Support for HTTP/2
• JEP 110 http://openjdk.java.net/jeps/110
• Easy to use API
• Covers only the most common use cases
• Supports both HTTP/1.1 and 2
• Builds on Java API classes going back to Java 1.2!
72
-
73.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Java SE 9 Support for HTTP/2
73
HttpClientHttpClient.Builder
HttpRequest.Builder
HttpRequestHttpRequest
-
74.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Java SE 9 Support for HTTP/2
• A handful of classes
– HttpClient, built by HttpClient.Builder
• Holds information for creating one or more HttpRequests
– HttpRequest, built by HttpRequest.Builder
• one request/response interaction
– HttpResponse
– Body Processors
• HttpRequestBodyProcessor
• HttpResponseBodyProcessor
Small footprint
74
-
75.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Java SE 9 Support for HTTP/2
• Blocking mode: one thread per request/response
– send request
– get response
• Non-blocking mode
– Using ExecutorService and CompletableFuture
– Full support for HTTP/2 Server Push
Small footprint
75
-
76.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Java SE 9 Support for HTTP/2
• Negotiation of HTTP/2 from 1.1
– ALPN or plaintext
• Server Push
– Support for PUSH_PROMISE frames
• HPACK parameters
HTTP/2 features
76
-
77.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Our Plan for Your Time Investment
Why HTTP/2?
HTTP/2 Big Features
How Servlet Might Expose These Features
Java SE 9 Support for HTTP/2
Summary and Current Status
1
2
3
4
5
77
-
78.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Summary and Current Status
• Servlet 4.0 brings HTTP/2 to Java EE
– 100% compliant implementation of HTTP/2
– Expose key features to the API
• Server Push
• Stream Prioritization
• Request/Response multiplexing
78
-
79.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Summary and Current Status: HTTP/2
• December 2015 Submit HTTP/2 to IESG for consideration as a Proposed
Standard DONE
• January 2015 Submit HTTP/2 to RFC Editor DONE
• February 2015 Publish HTTP/2 as an RFC
79
-
80.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Summary and Current Status
• JSR-369 just formed on 22 September
• Tentative Delivery Schedule
– Q3 2015: expert group formed
– Q2 2015: early draft
– Q3 2015: public review
– Q4 2015: proposed final draft
– Q3 2016: final release
80
-
81.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
How to Get Involved
• Adopt a JSR
– http://glassfish.org/adoptajsr/
• The Aquarium
– http://blogs.oracle.com/theaquarium/
• Java EE 8 Reference Implementation
– http://glasfish.org
81
-
82.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The preceding is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
82
out additional information/disclaimers required depending on your audience.
Know your audience
They already think they know everything about Servlet
They already think they know everything about HTTP/1.1
They’ve heard about HTTP/2.0
They are looking for what’s new. They’re looking for a reason to stick with Servlet over node.js
They like lots of code, they are suspicious of slideware.
Show of hands questions:
using Servlet 3.0, 3.1
heard something substantial about h2?
This section of the talk can follow the narrative arc and foreshadowing patterns to build to the climax of how Servlet 4.0 will provide answers to these problems.
If HTTP/1.1 was good enough for the last 15 years, why do we need something new?
30 resources
2 styelsheets
9 java scripts
8 jpg images
2 pngs
With HTTP/1.1 pipelineing, you can send each request in order, the server is required to respond in the same order.
Lets say style1 and style2 are returned quickly, but script1 seems to take some time. Because of HOL blocking, none of the other
resources can be delivered until script1 is completely delivered.
With HTTP/1.1 pipelineing, you can send each request in order, the server is required to respond in the same order.
Lets say style1 and style2 are returned quickly, but script1 seems to take some time. Because of HOL blocking, none of the other
resources can be delivered until script1 is completely delivered.
Can we work around HOL blocking in HTTP/1.1?
Sort of, just open up more sockets to the same server! Most browsers support 6 – 8 simultaneous sockets.
We know that each socket is expensive. Particularly on servers!
Well, if the protocol itself has these performance problems, what can we do at the application level to workplu around them?
This is where the problem began. Prior to this, there was no concept of an inlined asset
This technique works around the HOL blocking problem by concatenating many logical resources into a single physical resource.
Leverages the benefits of the TCP congestion algorithm, that the efficiency of the socket improves with larger files over time.
This concept also works with css and js. And don't forget compression. That really helps as well.
You play a stupid DNS trick to get more parallel access.
Lets you work around the browser imposed limitation on how many parallel connections to a single host
Goes back to the way it was before Mosaic came along.
Those are the big problems that are out there in the world.
This is important because HTTP/2 is essentially a new transport layer underneath the existing HTTP/1.1 semantics + a header compression specification.
Same request/response model
No new HTTP methods (except for PRI but that's just for the protocol)
No new headers (but new names/concepts for old headers)
No new usage pattern from application level
Same usage of URL spec and TCP ports
Care has been taken to avoid the "not invented here" syndrome, and to re-use concepts already proven successful.
Can we work around HOL blocking in HTTP/1.1?
Sort of, just open up more sockets to the same server! Most browsers support 6 – 8 simultaneous sockets.
We know that each socket is expensive. Particularly on servers!
Well, if the protocol itself has these performance problems, what can we do at the application level to work around them?
Can we work around HOL blocking in HTTP/1.1?
Sort of, just open up more sockets to the same server! Most browsers support 6 – 8 simultaneous sockets.
We know that each socket is expensive. Particularly on servers!
Well, if the protocol itself has these performance problems, what can we do at the application level to work around them?
Plug ACM
Plug ACM
Fully bi-directional at the protocol level, no HOL blocking.
Message, not just request and response, there are also control messages.
httpbis draft 14.
Length shows how long the entire frame is.
Flags are used for several purposes, one of which is to indicate that this is the end of the header, or the end of the stream.
DATA is request or response body
HEADERS is the request or response header
RST_STREAM corresponds to an error
SETTINGS allows you to send configuration data for a given stream.
PUSH_PROMISE: related to server push
PING if the connection is still alive. This is necessary because the impact of closing down and opening a new socket is a bigger deal. In h1, if there was a problem on a socket, just close it
and open up another one. In h2, sockets are treated with more respect.
GOAWAY allows graceful closing of the socket.
WINDOW_UPDATE is for flow control. If the server is sending more data than the client can handle, the client can tell the server to send less.
CONTINUATION when one frame is a continuation of another one.
httpbis draft 14.
The + means "add this header to the table". The – means "remove this header from the table".
:method:, :scheme: etc are "Pseudo-Header Fields". These are special header fields defined by the HTTP/2 spec. They were defined to hold information that formerly was on the request line, or for other "must have" HTTP headers, and must start and end with a ":".
They must bee in lower case or the request is treated as malformed, but the strings must be compared in a case-insensitive fashion.
httpbis draft 14.
Two ways to specify priority: in headers or in a separate frame. Make sure people understand that this is not just an integer. It's not just like, "a bigger integer means it is more important."
B and C depend on A. This information is included as a header in the HEADERS frame.
These numbers are weights that correspond to the priority.
If A is stuck, you can't do anything on A, you would like to do the things that are lower priority, which is B and C in this case. You would distribute the resources in the ratio of 4 to 12.
An exclusive flag allows for the insertion of a new level of dependencies. The exclusive flag causes the stream to become the sole dependency of its parent stream, causing other dependencies to become dependent on the prioritized stream.
Patterns: Foreshadow use of Server Push with JSF later
It's a facility to allow the server to pre-populate the browser's cache with data it knows the browser will need anyway.
Here is where you mention that this is not a replacement for WebSocket. It can be used in concert with SSE
The designers of HTTP/2 observed that a lot of bytes of H1 are just headers. Furthermore, there is a lot of repetition.
Because we have the concept of stream ID within a channel, we can now have headers that correspond to that stream ID, and therefore
keep track of these header tables that correspond to that stream.
This is a lot harder to implement than h1! Let’s rewind the clock to 1993. These standards were designed to be easy to implement. This fact
was crucially important to the growth of the web. Remember, back then, the web was not the only game in town. There was archie, WAIS and
gopher. If they came out of the gate with such a complex protocol, http would not have caught on as fast as it did.
There is something to be said for simplicity of implementation. But there is also something to be said for a judicious use of complexity to
increase performance where it is appropriate.
HTTP RFC
7230 HTTP/1.1 messaging
7231 HTTP/1/1 semantics and content
7232 h1 conditional requests
7233 range requests
7234 Caching
7235 authentication
4648 base64 encoding
7323 TCP extensions for high performance
3986 URI spec
2046 MIME
6265 Cookies
HTTP RFC
7230 HTTP/1.1 messaging
7231 HTTP/1/1 semantics and content
7232 h1 conditional requests
7233 range requests
7234 Caching
7235 authentication
4648 base64 encoding
7323 TCP extensions for high performance
3986 URI spec
2046 MIME
6265 Cookies
Responsive: responds to user needs in a timely manner
Resilient: can withstand outages with graceful degradation
Elastic: system response is not too heavily degraded when demand is high, resource utilization is not to heavy when demand is low.
Message Driven: allows the parts of the system to be loosely coupled and interact with eachother in an asynchronous manner.
Servlet only concentrates on two of these concerns: responsive and message driven. The other parts are outside of the domain of Servlet.
One problem with being able to proudly sport the "We Are Reactive" banner is that the instant you have to block for IO, you are no longer reactive. The main purpose of
these new APIs in Servlet 3.1 is to make it so you can entirely avoid blocking if you are really careful.
Uses a listener approach to solve the non-blocking IO problem.
Introduced an API to query if the streams can be read from or written to without blocking.
Servlet started on the path of reactivity in 3.0.
SSE is where we handle the "Event Driven" concern of reactive.
Mention the discussion about SSE: conclusion: no additional API needed.
Use this is a segue to mention how new features at the protocol layer
may or may not be exposed to higher layers in the stack.
Request reliability mechanism in h2 8.1.4
The features in gray are deemed too low level to expose in Servlet, an application level abstraction.
We are not trying to obsolete Apache HTTP client.
Mention how long it's been since we've done anything on the level of HttpUrlConnection in JDK.