Java Day Tokyo 2017 ダウンロード資料

Servlet 4.0 で始めるHTTP/2

日本オラクル株式会社

クラウド・テクノロジー事業統括

Fusion Middleware事業本部

セールスコンサルタント

柳原 伸弥

Java Day Tokyo 2017

2017

年

₅

月

₁₇

日

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.

アジェンダ

Servlet 振り返り

Servlet 4.0 概要

Servlet 4.0 Server Push API

Server Push 利用時のネットワーク状況

Server Push ユースケース

1

2

3

4

5

アジェンダ

Servlet 振り返り

Servlet 4.0 概要

Servlet 4.0 Server Push API

Server Push 利用時のネットワーク状況

Server Push ユースケース

1

2

3

4

5

Servletの基本

Servlet

•

サーバサイドで動作するJava

–

Webコンテナにより呼び出されるクラス

•

javax.servlet.http.HttpServlet

–

HTTPリクエストにより処理を実施

•

（GET/POST/・・・）

•

Controller としての役割

–

計算処理やデータベースアクセス等

–

画面描画用のデータを生成

GET/POST/

GET/POST/・・・

HTTPリクエスト

HTML/XML/

HTML/XML/・・・

HTTPレスポンス

サーバサイドJava

Servlet

Servlet History

バージョン リリース

プラットフォーム

内容

2.3

2001/8

J2EE 1.3

Filter 機能

2.4

2003/11

J2EE 1.4

web.xml への XML Schema利用

2.5

2005/9

JavaEE 5

Annotation サポート(リソース注入)

3.0

2009/12

JavaEE 6

非同期 Servlet, Annotation 利用によるEoD,

プラガビリティ

3.1

2013/5

JavaEE 7

ノンブロッキング I/O API,

プロトコルアップグレード(WebSocket)

4.0

2017/7予定

*

JavaEE 8

HTTP/2 対応

Servlet の機能拡張の変遷

* Servlet 4.0 現状

2017/4/20 – 5/20 : パブリックレビュー

2017/5/23 – 6/5 : パブリックレビュー投票

[JSR-000369 Java Servlet 4.0 Specification]

通信効率を向上するHTTPの新規格

HTTP/2 概要

リリース

バージョン

内容

1991年

HTTP/0.9 GETのみ。ヘッダ/レスポンスコードの規定もなし

1996年

HTTP/1.0 RFC1945: POST等のメソッド追加。レスポンスヘッダの追加

1999年

HTTP/1.1 RFC2068: Keep-Aliveやパイプライン化をサポート

2015年

HTTP/2.0

RFC7540

: HTTP/1.1との互換性保持。通信効率向上の機能サポート

リクエスト

レスポンス

TCPコネクション

TCPコネクション

ストリーム

•

HTTP/1.1

•

HTTP/2

Web高速化のための機能

HTTP/1.1の欠点とHTTP/2の特長

•

HTTP/1.1 の欠点

–

原則として１つのリクエストの完了を

待ってから、次のリクエストを送信

–

HTTPパイプラインを使用する場合の、

Head-of-Line Blocking の発生

•

HTTP/1.1のWeb高速化の取り組み

–

CSS スプライト

–

インライン・イメージ

–

ドメイン・シャーディング

Blo

cking

•

HTTP/2 の特長

–

ストリーム(リクエスト/レスポンス)の

多重化

–

ストリーム優先度

–

Server Push

–

ヘッダー圧縮

–

バイナリー・フレーム

push

1 TCP

接続

HTTP/2 対応

Servlet 4.0

GET/POST/

GET/POST/・・・

HTTPリクエスト

HTML/XML/

HTML/XML/・・・

HTTPレスポンス

Servlet 4.0

•

Server Push

–

クライアント・リクエストを待たない

サーバ・レスポンス

•

プロトコルネゴシエーション

–

ALPN

(Application-Layer Protocol Negotiation)

–

JDK 8 による ALPN サポート

Push

Push

Push

Push

Push

Push

アジェンダ

Servlet 振り返り

Servlet 4.0 概要

Servlet 4.0 Server Push API

Server Push 利用時のネットワーク状況

Server Push ユースケース

1

2

3

4

5

PushBuilder インターフェース

Server Push 処理 API

<interface>

HttpServletRequest

+ newPushBuilder(): PushBuilder

:

<interface>

PushBuilder

+ method(String method): PushBuilder

+ queryString(String queryString): PushBuilder

+ sessionId(String sessionId): PushBuilder

+ setHeader(String name, String value): PushBuilder

+ addHeader(String name, String value): PushBuilder

+ removeHeader(String name): PushBuilder

+ path(String path): PushBuilder

+ push(): void

+ getMethod(): String

+ getQueryString(): String

+ getSessionId(): String

+ getHeaderNames(): Set

+ getHeader(String name): String

+ getPath(): String

PushBuilder pushBuilder

一般的な処理フロー

Server Push 基本シーケンス

GET /index

request.newPushBuilder()

:PushBuilder

Servlet

Client

path(“bootstrap.css”)

path(“bootstrap.js”)

push()

push()

bootstrap.css

bootstrap.js

Index.html

1.

ServletPathへリクエスト

2.

HTTP リクエストから

PushBuilderを取得

3.

index.html が参照するリソース

を

PushBuilderに設定

4.

pushを起動

5.

3.と4. を必要に応じて繰り返す

6.

HTTP レスポンスを返す

1

2

3

4

5

6

Servlet 4.0 Server Push コードサンプル (1/3)

基本的な Server Push 実装例

@WebServlet(name = "ServerPush", urlPatterns = {"/index"})

public class ServerPush extends HttpServlet {

@Override

protected void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

PushBuilder pushBuilder = request.newPushBuilder();

Server Push の宛先対象となるリクエストから

PushBuilder

オブジェクトを取得

Servlet 4.0 Server Push コードサンプル (2/3)

基本的な Server Push 実装例

if (pushBuilder != null) {

pushBuilder

.path("bootstrap/css/bootstrap.min.css")

.push();

pushBuilder

:

.push();

}

Server Push 対象の

リソースを示すURIを指定

Server Push を invoke

PushBuilder オブジェクトは

Servlet 4.0 Server Push コードサンプル (3/3)

基本的な Server Push 実装例

response.setContentType("text/html;charset=UTF-8");

RequestDispatcher disp = request.getRequestDispatcher("index.html");

disp.forward(request, response);

}

_{Server Pushとは非同期に}

アジェンダ

Servlet 振り返り

Servlet 4.0 概要

Servlet 4.0 Server Push API

Server Push 利用時のネットワーク状況

Server Push ユースケース

1

2

3

4

5

Servlet 4.0 Server Push API 説明

PushBuilder

説明

事前リクエストに関連するレスポンスを先行送信する予約リクエスト を作成する

PUSH_PROMISE: Pushするための予約リクエストヘッダと、レスポンスのためのストリームを予約

予約リクエストは

「キャッシュ可能」

かつ

「安全」

なメソッドとして定義

「RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2) – 8.2. Server Push」

初期化時は以下の状態となり「キャッシュ可能」かつ「安全」な状態

メソッド: GET

リクエストヘッダから以下を除去

Conditional headers : [If-Match, If-Modified-Since, If-None-Match , If-Unmodified-Since],

Range headers, Expect headers, Authorization headers, Referrer headers

Servlet 4.0 Server Push API 説明

newPushBuilder

default PushBuilder newPushBuilder()

説明

HTTPリクエストからPushBuilder インスタンスを生成

次のServer Push を利用できない場合に null を返す

現在のコネクションがServer Push をサポートしていない場合

クライアントがHTTP/2 SETTINGS フレームでSETTINGS_ENABLE_PUSH の値を0で設定している場合

リターン

PushBuilder オブジェクト 又は、null

Servlet 4.0 Server Push API 説明

path

PushBuilder path(String path)

説明

Pushする対象のURIを設定する

パラメータ

path: push 対象のリソースを示すURI

“/” から始めた場合は、絶対パスとして処理

“/” から始めない場合は、事前リクエストのコンテキストパスに対する相対パスとして処理

リターン

この PushBuilder オブジェクト

Servlet 4.0 Server Push API 説明

addHeader

PushBuilder addHeader(String name, String value)

説明

Pushする対象のリクエストヘッダを追加する

パラメータ

name: ヘッダ名

value: ヘッダ値

リターン

この PushBuilder オブジェクト

PushBuilder.addHeader

Servlet 4.0 Server Push API 説明

push

void push()

説明

設定されたリソースをPushする

• クライアントがHTTP/2 によるPush配信を拒否できるため、リソースが実際にPushされるかは保証しない

•

push メソッド実行後、設定したリソースのURIと、Conditional Header はクリアされる。

それ以外の設定は 維持されるため、別のPush実行に再利用できる。

•

path() によるURI設定は、push メソッド実行前に必須である。

設定のない場合、IllegalStateException が発生する。

Servlet 4.0 Server Push API 説明

method

PushBuilder method(String method)

説明

Pushする際のHTTP メソッドを設定する

パラメータ

method: HTTP メソッド

PushBuilder生成時にGETが設定されているため、特に設定する必要はない

また、キャッシュ不可かつ非安全なメソッド[POST, PUT, DELETE, CONNECT, OPTION, TRACE] を

設定したり、空設定の場合は IllegalArgumentException が発生する

リターン

この PushBuilder オブジェクト

Servlet 4.0 Server Push API 説明

queryString

PushBuilder queryString(String queryString)

説明

path(String) で設定したURIに対してクエリ文字列を追加する

•

path(String) でクエリ文字列を追加したURIを設定している場合は実施しなくてもよい。

•

Push対象のリソースがCache Busting 対応されているような場合などに利用

パラメータ

queryString: push対象のリソースURIに対して追加するクエリ文字列

リターン

この PushBuilder オブジェクト

PushBuilder.queryString

アジェンダ

Servlet 振り返り

Servlet 4.0 概要

Servlet 4.0 Server Push API

Server Push 利用時のネットワーク状況

Server Push ユースケース

1

2

3

4

5

一般的なコンテンツアクセス時のネットワーク

HTTP/1.1 及び HTTP/2 のネットワーク状況確認

HTML

CSS

JS

リクエスト

レスポンス

クライアント

サーバ

ネットワーク状況確認 (HTTP/1.1)

従来 (HTTP/1.1) の一般的なページ表示

オレンジ色

の箇所は

TCP接続の確立

複数個所で

TCP接続フェーズが発生

ネットワーク状況確認 (HTTP/2)

Server Push なしのHTTP/2 アクセス

オレンジ色

の箇所は

TCP接続の確立

紫色

の箇所は

SSLの確立

同時にリソース要求が発生

ネットワーク状況確認 (HTTP/2)

Server Push を実施したHTTP/2 アクセス

非同期に指定リソースが

一般的なコンテンツアクセス時のネットワーク

HTTP/1.1 及び HTTP/2 のネットワーク状況確認

HTML

CSS

JS

バックエンド

処理

リクエスト

レスポンス

リクエスト

レスポンス

クライアント

フロントサーバ

バックエンドサーバ

ネットワーク状況確認 (HTTP/1.1)

サーバ内処理時間: 1000ms

•

バックエンド処理実施中が終了した後に、リソース要求が発生

•

ページのレンダリングに遅延が発生する

バックエンド処理終了後に

受信したレスポンスから

リソース取得要求

ネットワーク状況確認 (HTTP/2)

サーバ内処理時間: 1000ms

•

バックエンド処理実施中に指定したリソースがServer Pushされている

•

ページのレンダリングを行う際にはリソース取得済みの状態

DOMツリー組み立て前に

リソース取得済み

アジェンダ

Servlet 振り返り

Servlet 4.0 概要

Servlet 4.0 Server Push API

Server Push 利用時のネットワーク状況

Server Push ユースケース

1

2

3

4

5

CSS や JavaScript の連結ファイル準備の軽減

スタイルシート/JavaScript

CSS

_CSS

CSS

CSS

JS

_JS

JS

JS

CSS

_CSS

CSS

JS

_JS

JS

PUSH

PUSH

PUSH

PUSH

• 連結ファイルの準備が必要

HTTP/2

•

Webページ要求時にプッシュ

•

HTTP/1.1

–

CSS/JavaScriptファイル数削減による

HTTPリクエスト数の削減

•

複数のスタイルシートを単一ファイル化

•

複数のJavaScriptを単一ファイル化

–

課題

•

単一ファイル化に要する作業

•

モノリシック化による再利用性の低下

•

HTTP/2

–

複数のCSS / JavaScript をプッシュ

CSS スプライトからの代用

画像ファイル

CSS

.item a {

display: block;

width: 240px;

height: 40px;

background-image: url('sprite.png');}

.item01 a {background-position:

0px 0px;}

.item01 a:hover {background-position: 0px -40px;}

.item01 a:active {background-position: 0px -80px;}

.item01.current a {background-position: 0px -120px;}

：

連結した画像ファイル

HTTP/2

PUSH

PUSH

PUSH

PUSH

•

CSSスプライトの工夫が必要

• 個別ファイルをプッシュ

•

HTTP/1.1

–

画像ファイル数削減による

HTTPリクエスト数の削減

•

複数の画像ファイルを連結

•

CSSを利用した座標指定による表示

–

課題

•

画像ファイルの連結に要する作業

•

CSSによるPosition指定の複雑さ

•

画像ファイルの更新

•

HTTP/2

–

個別の画像ファイルをプッシュ

インラインイメージからの代用

画像ファイル

HTML

<img src=

"data:image/png;base64,iVBORw0KGgoAAAA

NSUhEUgAAAeAAAAHgCAIAAADytinCAAAAYX

pUWHRSYXcgcHJvZmlsZSB0eXBlIGlwdGMAAHj

aPYq7EYAwDMV6T8EI+cjPzjhcaOgo2P8IFEiNCtl

53dO2j57Wk8bgKCx……" />

•

HTML内にBase64エンコードした画像を埋め込み

HTTP/2

PUSH

PUSH

•

Server Push により画像ファイルのキャッシュ利用可

•

HTTP/1.1

–

画像ファイルインライン可による

HTTPリクエスト数の削減

•

data URI scheme (data:)による画像指定

•

Base64エンコードによる画像の文字列化

–

課題

•

data URI schemeの画像はキャッシュ不可

•

Base64エンコードによるサイズ増加

•

画像ファイルの変更時のデータ差し替え

•

HTTP/2

サーバ内処理時間中の Server Push

JSP

リクエスト

レスポンス

Servlet

JSP

RequestDispatcher

.forward()

Servlet変換

初期化

jspInit()

PUSH

PUSH

PUSH

PUSH

PUSH

PUSH

バックエンド処理

サーバ内

処理時間

•

サーバ内処理時間

–

DBアクセスなどのバックエンド処理

–

プリコンパイルを行わない場合の

サーブレット変換及び初期化処理

•

待機時間を利用したServer Push

–

サーバ内処理中に表示対象の

JSPが利用するリソースをプッシュ

JSP でインクルードする部品の Server Push

JSP Include

HTML

CSS

JS

CSS

JS

JSP

<jsp:include page=“parts.jsp" flush="true" />

<jsp:include page=“parts.html" flush="true" />

Servlet

JSP

PUSH

PUSH

PUSH

PUSH

• インクルードしている部品が

参照するリソースを事前にプッシュ

•

JSP Include

–

JSPはInclude機能を利用した

部品の再利用が可能

•

インクルード対象のServer Push

–

親JSPがIncludeする対象のJSPや

HTMLが参照するリソースを事前に

プッシュ

複数 Servlet に共通するリソースの Server Push

Servlet Filter

Servlet

Filter

Servlet

Servlet

Servlet

PUSH

PUSH

@WebFilter(dispatcherTypes =

{ DispatcherType.REQUEST }, urlPatterns = { "/*" })

public class ServerPushFilter extends Filter {

@Override

protected void doFilter(HttpServletRequest request,

HttpServletResponse response, FilterChain chain)

throws ServletException, IOException {

PushBuilder pushBuilder

= request.newPushBuilder();

•

Servlet Filter

–

Servlet リクエスト時の事前処理として

利用

–

複数の Servlet へのマッピング可能

•

複数 Servlet に共通のリソースを

Server Push

–

Servlet Filter を経由して呼び出される

Servlet に共通するリソースをプッシュ

–

Fliter で実装する事で

Server Push 処理の共通化が可能

フレームワーク内部でのServer Push

JSF

•

ExternalContextの拡張

–

ExternalContext.encodeResourceURL()

によるマークアップ処理を拡張

•

<h:outputStyleSheet>

•

<h:outputScript>

•

<h:outputLink>

–

ExternalContextFactory及び

ExternalContextWrapperの拡張

–

faces-config.xmlへの設定追加

•

JSFタグによる外部リソース参照を

Server Push

JSF

<h:outputStyleSheet>

<h:outputScript>

CSS

JS

External

Context

encodeResourceURL()

<link href=“…” />

<script src=“…” />

リクエスト

レスポンス

PUSH

PUSH

externalContext.getRequest()

.newPushBuilder()

.push()

JSFを拡張したServer Push 実装イメージ

JSF – 実装例

Public class PushExternalContextFactory extends ExternalContextFactory {

private ExternalContextFactory externalContextFactory;

@Override

public ExternalContext getExternalContext(Object context, Object request, Object response) throws FacesException {

return PushExternalContext(externalContextFactory.getExternalContext(context, request, response));}}

Public class PushExternalContext extends ExternalContextWrapper {

private ExternalContext externalContext;

@Override

public String encodeResourceURL(String url) {

((HTTPServletRequest) externalContext.getRequest()).newPushBuilder().path(url).push();

return super. encodeResourceURL(url);}}

<factory>

<external-context-factory>

PushExternalContextFactory

</external-context-factory>

</factory>

ExternalContextFactory継承クラス

ExternalContext実装クラス

faces-config.xml

_{1. ExternalContext を生成するファクトリークラスを作成：}

ExtenalConextFactory を継承実装

2. ExternalContext を実装：

実装クラスであるExternalContextWrapperを継承実装

3. JSF設定ファイル(faces-config.xml) に登録

フレームワーク依存リソースのServer Push

フレームワーク

•

各種フレームワーク内部での利

用

–

自社開発フレームワークの内部で

Servletが利用されるもの多数存在

–

フレームワークで制御する画面は

依存する外部リソースが明確

•

クリティカル・レンダリングパスを

最適化するフレームワーク

–

画面描画の高速化を意識した

Server Push 利用をフレームワーク化

フレームワーク

Servlet

_CSS

_JS

リクエスト

レスポンス

PUSH

PUSH

リクエスト

ページ

ビルド

DOM

ビルド

CSS OM

実行

JS

レンダリング

ツリー

レイアウト/

ペイント

GET

html

レスポンス

リソース

PUSH

PUSH

• フレームワーク内での

Server Push

• クリティカル・レンダリングパスの最適化

Servlet 4.0 で始めるHTTP/2

Wrap up

HTTP/2 時代のWebページ高速化

Server Pushの活用のメリットと考慮点

• 標準化された 実装

によりWebページ高速化の取り組みの容易化

• 先行してロードさせるリソースのProgrammaticな制御が可能

適用効果

• Webページの構成に応じた適切な

プッシュ対象の選別

が必要

• ブラウザ毎の挙動の差異

考慮点

• Webサイト高速化

に関する技術の理解

• Servlet 4.0 – Server Push 利用の

ベスト・プラクティス

の検討

活用に向けて

参考: 動作検証環境

•

JDK

–

Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

•

GlassFish

–

glassfish-5.0-b06-05_03_2017.zip

•

Servlet

–

javax.servlet-api: 4.0.0-b05

•

Browser

–

Google Chrome: 59.0.3071.47