HTTPのお話

HTTPのお話HTTPのお話
NASA9084NASA9084
HTTPのお話 file:///mnt/A2C043EDC043C66F/Users/owner/Dropbox/digi-poro/#3/...
1 / 54 2016年01月15日 20:07

準備準備
2 / 54 2016年01月15日 20:07

URIとURL,URNURIとURL,URN
URL
Uniform Resource Locator
URN
Uniform Resource Name
↓
URI
Uniform Resource Identi�er (RFC2396→RFC3986)
3 / 54 2016年01月15日 20:07

URIの形式URIの形式
scheme://user:password@domain:port/resource
scheme
http, ftp, mailto, …
domain
hogehoge.com
port
TCP/IP Port
resource
/path/to/resource.extension
4 / 54 2016年01月15日 20:07

TCP/IPPORTTCP/IPPORT
TCP/IPで使用する番号
情報の出入り口や港のようなもの
→これでどのアプリケーションの通信なのか判断できる
5 / 54 2016年01月15日 20:07

WELL-KNOWNPORTWELL-KNOWNPORT
慣例的に、用途が固定化しているTCP/IPポート番号
ポート番号サービス/プロトコル
20 FTP
22 SSH
80 HTTP
110 POP3
443 HTTP over SSL/TLS
465 SMTP over SSL/TLS
993 IMAP over SSL/TLS
6 / 54 2016年01月15日 20:07

TLSTLS
Transport Layer Security
通信相手の認証
通信内容の暗号化
改竄の検出
トランスポート層とアプリケーション層の間
7 / 54 2016年01月15日 20:07

TCP/IP4階層モデルTCP/IP4階層モデル
現在のインターネット通信で最も利用されている通信プロトコル
群
8 / 54 2016年01月15日 20:07

9 / 54 2016年01月15日 20:07

TCP/IPモデルの流れTCP/IPモデルの流れ
送信側は上層から下層へ、受信側は下層から上層へ
送信時は順に情報を付加する
受信時は順に情報を外していく
10 / 54 2016年01月15日 20:07

11 / 54 2016年01月15日 20:07

今回のベース今回のベース
12 / 54 2016年01月15日 20:07

HTTPHTTP
Hypertext Transfer Protocol
ネットワークで情報をやり取りするための決めごと
サーバーとクライアントという２つの「役割」がある
よく使われるのはHTTP/1.1 (RFC2616, RFC7230 -
RFC7235)
今後はHTTP/2 (RFC7540)
トランスポートプロトコルとしてTCPを利用
リクエスト - レスポンス型プロトコル
URIでリソースを指定
13 / 54 2016年01月15日 20:07

具体的には・・・具体的には・・・
14 / 54 2016年01月15日 20:07

15 / 54 2016年01月15日 20:07

16 / 54 2016年01月15日 20:07

HTTP通信の基本的な流れHTTP通信の基本的な流れ
17 / 54 2016年01月15日 20:07

18 / 54 2016年01月15日 20:07

19 / 54 2016年01月15日 20:07

20 / 54 2016年01月15日 20:07

21 / 54 2016年01月15日 20:07

REQUESTとRESPONSEREQUESTとRESPONSE
HTTPとは要求を送って、その返答を返してもらう仕組み
要求をRequest, 返答をResponseという
要求・返答の時に送るメッセージをそれぞれ、Request
Message, Response Messageという
これらのメッセージをまとめてHTTP Messageという
22 / 54 2016年01月15日 20:07

23 / 54 2016年01月15日 20:07

24 / 54 2016年01月15日 20:07

REQUESTMETHODの種類REQUESTMETHODの種類
主に使うのは2つ
Method 用途
GET データの取得要求
POST データの送信要求
25 / 54 2016年01月15日 20:07

26 / 54 2016年01月15日 20:07

RESPONSECODEの大まかな種類RESPONSECODEの大まかな種類
三桁の数字で大まかな情報がわかる
コード種別意味
1xx 情報処理継続
2xx 成功理解、受理済み
3xx リダイレクション追加処理が必要
4xx クライアントエラーリクエストに誤り
5xx サーバーエラー処理に失敗
27 / 54 2016年01月15日 20:07

RESPONSECODEの例RESPONSECODEの例
code メッセージ意味
200 OK リクエスト成功
301 Moved Permanently 恒久的に移動した
401 Unauthorized 認証が必要
403 Forbidden 禁止
404 Not Found 未検出
451 Unavailable For Legal
Reasons
政治的検閲による閲
覧禁止
500 Internal Server Error サーバ内部エラー
503 Service Unavailable サービス利用不可
28 / 54 2016年01月15日 20:07

HTTPの歴史HTTPの歴史
29 / 54 2016年01月15日 20:07

HTTP/0.9HTTP/0.9
最初のHTTP
1991年に最初にドキュメント化されたHTTP
非常にシンプルで、紙一枚で済む程度
メソッドはGETのみ
ヘッダもなし
HTMLのみが使われることを想定
GET /index.html
30 / 54 2016年01月15日 20:07

HTTP/1.0HTTP/1.0
1995年にRFC1945として初版が発行
メソッドが増えた
レスポンスにヘッダがつくように
ステータスコード
リクエストにバージョンをつけることに
GET /index.html HTTP/1.0
31 / 54 2016年01月15日 20:07

HTTP/1.1HTTP/1.1
1997年にRFC2068として初版が発表
その後二回改定
RFC2616
RFC7230 - 7235
バーチャルホストのサポート
Hostヘッダの登場
持続的接続のサポート
GET /index.html HTTP/1.1
Host: hoge.fuga.com
32 / 54 2016年01月15日 20:07

SPDYSPDY
Google発の通信プロトコル
HTTPを基にして高速化を行ったプロトコル
TLS接続の上にセッション層を追加
単一のSPDYセッションで複数のリクエストを送受信
データの先読み機能
HTTPS必須
33 / 54 2016年01月15日 20:07

HTTP/2HTTP/2
16年ぶりHTTPバージョンアップ
SPDYをベースに策定
2015年にRFC7540として文書化
HTTP/1.1との後方互換性を維持
非同期接続の多重化
ヘッダ圧縮
リクエスト・レスポンスのパイプライン化
34 / 54 2016年01月15日 20:07

HTTPの問題HTTPの問題
HTTPにはいくつかの問題点がある
認証問題
セッションステートレス問題
35 / 54 2016年01月15日 20:07

(セッション)ステートレス問題(セッション)ステートレス問題
HTTPは非常に簡単な仕組み
声をかけて返事してもらうだけ
返事が終わったら会話(session)は終わり
→状態(state)を記憶できない(less)
36 / 54 2016年01月15日 20:07

ステートフルとステートレスステートフルとステートレス
ハンバーガー店を例に
参考 : http://yohei-y.blogspot.jp/2007/10/blog-post.html
37 / 54 2016年01月15日 20:07

ステートフルなセッションステートフルなセッション
客「こんにちは」
店員「いらっしゃいませ。○○バーガーへようこそ」
客「ハンバーガーセットをお願いします」
店員「サイドメニューは何になさいますか?」
客「ポテトで」
店員「ドリンクは何になさいますか?」
客「ジンジャーエールで」
店員「+50円でドリンクをLサイズにできますがいかがですか?」
客「Mでいいです」
店員「以上でよろしいですか?」
客「はい」
店員「かしこまりました」
38 / 54 2016年01月15日 20:07

ステートレスなセッションステートレスなセッション
店員「いらっしゃいませ。○○バーガーへようこそ」
店員「サイドメニューは何になさいますか?」
客「ハンバーガーセットをポテトでお願いします」
店員「ドリンクは何になさいますか?」
客「ハンバーガーセットをポテトとジンジャーエールでお願いします」
店員「+50円でドリンクをLサイズにできますがいかがですか?」
客「ハンバーガーセットをポテトとジンジャーエール(M)でお願いします」
店員「以上でよろしいですか?」
客「ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上」
店員「かしこまりました」
39 / 54 2016年01月15日 20:07

なぜステートレスなのかなぜステートレスなのか
HTTPの通信を考えると、ステートレスの利点が大きい
40 / 54 2016年01月15日 20:07

ステートレスの利点ステートレスの利点
スケーラビリティがある
41 / 54 2016年01月15日 20:07

同時受付対応のセッション同時受付対応のセッション
店員1「いらっしゃいませ。○○バーガーへようこそ」
店員2「サイドメニューは何になさいますか?」
客「ハンバーガーセットをポテトでお願いします」
店員3「ドリンクは何になさいますか?」
客「ハンバーガーセットをポテトとジンジャーエールでお願いします」
店員4「+50円でドリンクをLサイズにできますがいかがですか?」
客「ハンバーガーセットをポテトとジンジャーエール(M)でお願いします」
店員5「以上でよろしいですか?」
客「ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上」
店員6「かしこまりました」
42 / 54 2016年01月15日 20:07

HTTPCOOKIEHTTPCOOKIE
ウェブサーバとウェブブラウザ間で状態を管理するプロトコル
保存された情報そのものもCookieと呼ぶ
43 / 54 2016年01月15日 20:07

ステートレス問題の解決ステートレス問題の解決
HTTPだけではステートレス問題が存在
いくつかの解決策を考案
IPアドレスにより区別
プライベートネットワークからのアクセスを区別できない
状態をURLに含める
本来二度起きない状態が何度も発生してしまう
→ネットスケープ・ナビゲータがCookieを実装
44 / 54 2016年01月15日 20:07

45 / 54 2016年01月15日 20:07

RESTFULAPIRESTFULAPI
46 / 54 2016年01月15日 20:07

RESTREST
REpresentational State Transfer
分散システムで複数のソフトを連携させるのに適した設計原則
セッションなどの状態管理を行わない
情報を操作する命令の体型が予め定義・共有されている
すべての情報は汎用的な構文で一意に識別される
情報内に別の情報や状態へのリンクを含めることができる
→HTTPと非常に相性が良い
47 / 54 2016年01月15日 20:07

RESTをHTTPに対応付けると・・・RESTをHTTPに対応付けると・・・
セッションなどの状態管理を行わない
HTTPはステートレス
情報を操作する命令の体型が予め定義・共有されている
GET/POSTなど
すべての情報は汎用的な構文で一意に識別される
URI
情報内に別の情報や状態へのリンクを含めることができる
HTML,XMLなど
48 / 54 2016年01月15日 20:07

APIAPI
Application Programming Interface
プログラムの機能・情報を外部から利用するための規約
例えば・・・
File IO API(OSが提供)
49 / 54 2016年01月15日 20:07

WEBAPIWEBAPI
あるURIにHTTPリクエストを送信すると処理結果を返してくれる
50 / 54 2016年01月15日 20:07

RESTFULAPIRESTFULAPI
RESTに従って設計されたAPI
→一般にはweb APIにRESTを適用 = RESTful API
同じURIに対する呼び出しには常に同じ結果が返される
51 / 54 2016年01月15日 20:07

RESTFULAPIの例RESTFULAPIの例
twitter REST API
Github API
52 / 54 2016年01月15日 20:07

何が嬉しい?何が嬉しい?
HTTPの基本的な動作を理解していると、同じような操作で簡単
に取り扱える！
53 / 54 2016年01月15日 20:07

THANKYOU!THANKYOU!
54 / 54 2016年01月15日 20:07

HTTPのお話

More Related Content

Viewers also liked (7)

More from nasa9084 (14)

HTTPのお話