Servlet 4.0 at GeekOut 2015

HTTP/2 Comes to Java
What Servlet 4.0 Means to You
Ed Burns
@edburns
Java EE Specification Team
Oracle
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

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

Why HTTP/2?
HTTP/2 Big Features
1
2
3
4
5
4

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
.
.
.

Why HTTP/2?
• Head-of-Line blocking
Problems in HTTP/1.1

Why HTTP/2?
• HTTP Pipelining
style1.css
style2.css
Client Server
index.html
index.html
style1.css
style2.css
script1.js
.
.
.
script2.js
.
.
.
script1.js
script2.js

Why HTTP/2?
• Inefficient use of TCP sockets
Client ServerClient Server
Client Server
Client Server
Client Server
Client Server

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

File Concatenation and Image Sprites
TCP Efficiency Improves with Larger Files
10

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
.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;
}

Domain Sharding
Split page resources across several hosts to work around browser limits
13

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

Why HTTP/2?
HTTP/2 Big Features
1
2
3
4
5
15

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

Standing on the Shoulders
17

18

19

20

21

22

23

24

• 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
25
Credit: chrisjstanley flickr
The Socket Angle

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
The Socket Angle
• It would be like if we took the
existing Servlet specification

28
The Socket Angle
• It would be like if we took the
existing Servlet specification
and added a new layer underneath
it

The Socket Angle
Client ServerClient Server
Client Server
Client Server
Client Server
Client Server

Solution in HTTP/2
Client Server

• 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

• 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

• HTTP/2 is much more complicated
to implement
– No more
telnet host 80
GET /somepage.html rnrn
33
The Adoption Angle

• HTTP/2 is much more complicated
to implement
– No more
telnet host 80
GET /somepage.html rnrn
34
The Adoption Angle

• Request/Response multiplexing
• Binary Framing
• Stream Prioritization
• Server Push
• Header Compression
• Upgrade from HTTP/1.1
• ALPN
• 101 Switching Protocols
35
HTTP/2 Big Ticket Feature Review

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | 36
HTTP/2 Big Ticket Feature Review

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
Connections, Streams, Messages, Frames

• 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'

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 …)

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.
41
Known as HPACK

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
42
Example 1
HEADERS
+ END_STREAM
+ END_HEADERS
:method: GET
:scheme: http
:path: /index.html
:authority: example.org
accept: text/html

HTTP/1.1 200 OK
Content-Length: 11
Content-Type: text/html
Hello World
43
Example 2
HEADERS
- END_STREAM
+ END_HEADERS
:status: 200
content-length: 11
content-type: text/html
DATA
+ END_STREAM
Hello World

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
44
S
A
B C
4 12
A
B CD
4 16 12
exclusive = 0
A
B C
D
4 12
16
exclusive = 1

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).
45
E

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
– Application Layer Protocol Negotiation (ALPN)
46
Secure or not-secure?

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
47

Criticism of HTTP/2
• Poul Henning-Kamp's rant just before WGLC
– http://queue.acm.org/detail.cfm?id=2716278
48

Criticism of HTTP/2
49

Criticism of HTTP/2
50

Criticism of HTTP/2
51
Credit: Michael Fritz

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
52

53

54

Aside
Servlet and Reactive
Programming
55

Reactive Programming
56
Responsive
Message Driven
ResilientElastic
image credit: reactivemanifesto.org

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
57

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
58

Why HTTP/2?
HTTP/2 Big Features
1
2
3
4
5
59

Why HTTP/2?
HTTP/2 Big Features
1
2
3
4
5
60

• Allow server to understand client
supplied stream priorities
• Allow server to set priority of
responses
• Allow frameworks to effectively
leverage server push
– flexible strategies for leveraging push
• Leverage ALPN
Abstractions Endure
61
Servlet API is Well Positioned to Enable HTTP/2 Optimizations

• 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

• Binary Framing
• Server Push
– ALPN
– 101 Switching Protocols
63
HTTP/2 Features

• Binary Framing
• Server Push
– ALPN
– 101 Switching Protocols
64
HTTP/2 Features Potentially Exposed in Servlet API

• Add method HttpServletRequest and HttpServletResponse
– int getStreamId()
65
Request/Response Multiplexing

• Add a new class Priority
– boolean exclusive
– int streamId
– int weight
– Priority dependency
• Add method to HttpServletRequest
– Priority getPriority()
• Add methods to HttpServletResponse
– Priority getPriority()
– void setPriority(Priority p)
66
Stream Prioritization

• 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
• Two implementation strategies
– dispatch synthetic request
– builder API
67
Server Push

Server Push via dispatch of
synthetic request
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

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

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

Server Push via Builder API
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.getPushBuilder()
PushBuilder 1 in
Thread A
setPath("/style.css")
setPath("/script.js")
PushBuilder 2 in
Thread B
style.css
script.js
index.html
request.getPushBuilder()
push()
push()

Why HTTP/2?
HTTP/2 Big Features
1
2
3
4
5
72

• 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!
73

74
HttpClientHttpClient.Builder
HttpRequest.Builder
HttpRequestHttpRequest

• 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
75

• 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
76

HttpResponse response = HttpRequest
.create(new URI("http://www.foo.com"))
.send(HttpRequest.noBody());
String responseBody =
response.body(HttpResponse.asString());
77

//Simple blocking -- all execution from calling thread
HttpResponse r1 = HttpRequest.create(new URI("http://www.foo.com/"))
.method("GET")
int responseCode = r1.responseCode());
String body = r1.body(HttpResponse.asString());
HttpResponse r2 = HttpRequest.create(new URI("http://www.foo.com/"))
.method("GET")
System.out.println("Response was " + r1.responseCode());
File body = r2.body(HttpResponse.asFile("/tmp/response.txt));
// Content stored in /tmp/response.txt
HttpResponse<Void> r3 = HttpRequest.create(new URI("http://www.foo.com/"))
.method("POST")
.send(HttpRequest.fromString("param1=1, param2=2"));
Void body = r3.body(HttpResponse.ignoreBody()); // body is Void in this case
78

// Async support, fully leverages SE 8 features
// Fetch three resources asynchronously. If all fetch ok
// send a further request to confirm work done
// Set up initial three requests
String[] filenames = {"foo.txt", "bar.txt", "blah.txt"};
CompletableFuture<File> futures[] = new CompletableFuture[filenames.length];
URI base = new URI("http://foo.com/resources")
URI finalResult = new URI("http://foo.com/confirm");
for (int i=0; i<filenames.length; i++) {
String filename = filenames[i];
URI uri = base.resolve(filename);
futures[i] = HttpRequest.create(uri)
.method("GET")
.sendAsync(HttpRequest.noBody())
.thenApply((HttpResponse resp) -> {
return resp.body(HttpResponse.asFile("/tmp/" + filename));
});
}
79

// Set up dependent request upon completion of all of the above
CompletableFuture<String>; last =
CompletableFuture.allOf(futures)
.thenCompose((Void v) -> {
return HttpRequest.create(finalResult)
.method("POST")
.build()
.sendAsync(HttpRequest.noBody())
.thenApply((HttpResponse resp) -> {
return resp.body(HttpResponse.asString());
});
});
// when we get to this point, no blocking has occurred and the
// initial requests are in progress
String lastResponse = last.join(); // -- wait for all work to complete
System.out.println(lastResponse);
80

• Negotiation of HTTP/2 from 1.1
– ALPN or plaintext
• Server Push
– Support for PUSH_PROMISE frames
• HPACK parameters
HTTP/2 features
81

Why HTTP/2?
HTTP/2 Big Features
1
2
3
4
5
82

• Servlet 4.0 brings HTTP/2 to Java EE
– 100% compliant implementation of HTTP/2
– Expose key features to the API
• Server Push
83

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
• May 2015 Publish HTTP/2 as an RFC 7540/7541 DONE
84

• JSR-369 formed on 22 September 2014
• Tentative Delivery Schedule, revised as of 2015-06-05!
– Q3 2014: expert group formed
– Q3 2015: early draft
– Q4 2015: public review
– Q2 2016: proposed final draft
– Q1-2 2017: final release
https://blogs.oracle.com/theaquarium/entry/java_ee_8_roadmap_update
85

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
86

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.
87

Servlet 4.0 at GeekOut 2015

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Viewers also liked

Viewers also liked (20)

Similar to Servlet 4.0 at GeekOut 2015

Similar to Servlet 4.0 at GeekOut 2015 (20)

More from Edward Burns

More from Edward Burns (20)

Recently uploaded

Recently uploaded (20)

Servlet 4.0 at GeekOut 2015

Editor's Notes