944 views
HTTPの基本
HTTPとは
HTTPとは、TCP/IPをベースとした、プロトコル。
HTTPの重要性
バージョンは、現在1.1。
HTTPは、ハイパーテキストの転送用プロトコルだが、実際はHTML,XML,静止画,音声,動画,JavaScriptプログラム,PDF等PCで扱えるデータであれば、なんでも転送できる。
HTTPはRESTで重要な特徴である、「統一インタフェース」「ステートレスサーバ」「キャッシュ」等を実現している。
TCP/IPとは
TCP/IPとは、インターネットの基盤を構成するネットワークプロトコル。
階層型プロトコル
ネットワークプロトコルは、「階層型」になっている。
ネットワークインタフェース層
物理歴なケーブルやネットワークアダプタを指す
インターネット層
ネットワークでデータを実際にやり取りする箇所。
TCP/IPのIP担当。データやり取りの通信単位は「パケット」と呼ぶ。
指定したIPアドレスを送り先として、パケット単位でデータをやり取り通信する。
※ 送ることだけを保証。本当に届いたかは保証しない。
トランスポート層
ネットワーク層で保証していなかったデータの転送を保証する。
接続先の相手に対して、コネクションを貼り、データの抜け漏れをチェック。到着を保証する。
TCPで接続したコネクションで、転送するデータがどのアプリケーションに渡るかを決めるのが「ポート番号」
アプリケーション層
メールやDNS(名前とIP紐づけ),HTTPを実現する層。
TCPでプログラムを作成するとき、ソケットと呼ばれるライブラリを使用する。
ソケットは、ネットワークのデータやり取りを抽象化したAPI。
具体的には、下のようなことができる。
- 接続
- 送信
- 受信
- 切断
HTTPサーバやブラウザはソケットを用いて実装する。
※ ほとんどのプログラミング言語で、ソケットは標準でついている
HTTPのバージョン
HTTP1.0：HTTPの最初の標準化
HTTP1.1：HTTPの完成
クライアントとサーバー
本項では、Webアーキテクチャスタイルの「クライアント/サーバ」を採用し、HTTPの具体的な仕組みについ手解説する。
リクエストとレスポンス
下画像のように、クライアントが「リクエスト」を出し、サーバーが「レスポンス」を返すプロトコルのことを、
「リクエスト/レスポンス型プロトコル」と呼ぶ
HTTPは「同期型」のプロトコル。
例えば、「リクエスト」後、サーバー処理に時間がかかる場合でも、クライアントは待機する。
クライアントで行われること
- リクエストメッセージの構築
- リクエストメッセージの送信
- レスポンスが車で待機
- レスポンスの受信
- レスポンスの解析
- クライアントの目的を達成するのに必要な処理。
※解析の結果、再度リクエストが必要になることもある。
サーバーで行われること
- リクエストの待機
- リクエストメッセージの受信
- リクエストメッセージの解析
- 適切なアプリケーションプログラムへの処理移譲
- アプリケーションプログラムから結果を取得
- レスポンスメッセージの構築
- レスポンスメッセージの送信
※適切なヘッダを付加してレスポンスメッセージを構築。クライアントへ送信する。
HTTPメッセージ
リクエストメッセージとレスポンスメッセージをまとめて「HTTPメッセージ」と呼ぶ。
それぞれ、構成を確認する。
基本的には、下のような構成をとっている。
リクエストメッセージ
(例)
GET /test HTTP/1.1
Host: test.jp
リクエストライン
リクエストメッセージの一行目は「リクエストライン」と呼ぶ。
リクエストラインでは、以下のような構成がされる。
- メソッド(GET)
- リクエストURI(test)
- プロトコルのバージョン(HTTP/1.1)
ヘッダ
リクエストメッセージ2行目以降は「ヘッダ」が続く。
ヘッダは、メッセージのメタデータ(データについてのデータのこと)。
各ヘッダは、「名前：値」という構成をしている。
上の例では、「Host」の値が「test.jp」であると示している。
ボディ
ヘッダの下に続く。
ボディには、そのメッセージを表す本質的な情報が入る。
例えば、リソースを新しく作成したり、更新したりするときは、ボディにリソース表現が入る。
レスポンスメッセージ
(例)
HTTP/1.1 200OK
Content-Type:application/xhtml+xml;charset=utf-8
<html xmls = "http://www.org/sample/test">
</html>
ステータスライン
レスポンスメッセージの一行目は、「ステータスライン」と呼ぶ。
プロトコルのバージョン(HTTP/1.1)とステータスコード(200)テキストフレーズ(OK)から成る。
ヘッダ
レスポンスメッセージ2行目以降は、リクエストメッセージと同様にヘッダ。
この行では、Content-TypeヘッダでHTMLのMIMEとメディアタイプとエンコーディングを指定する。
ボディ
例でいうところの< html >～< /html >まで
HTTPのステートレス性
HTTPは、ステートレス(サーバーがクライアントのアプリケーションの状態を保存しない)プロトコル。
ここでは、そもそも「アプリケーションの状態ってナニ？」という話をする。
※ ステートフル代表は「FTPプロトコル」等
アプリケーションの状態
基本的に、「ステートフルのやり取りのほうが簡潔」になる。(差分でOK)。
「ステートレス」の場合、すべて送信する必要がある。
(例：ピザや)
- ステートレス：ピザをXLサイズで注文する。この時ポテトの追加等あるたびに、「ピザXLとポテト...」と情報を更新して送信する
- ステートフル：ピザをXLサイズで注文する。この情報をサーバで保持するので、差分でOK。
この時の「ピザをXLサイズで注文する」情報のことを「クライアントのアプリケーション状態」と呼ぶ。
別名「セッション状態」
ステートフルの欠点
上の話だけ見ると、クライアントがアプリケーションの状態を覚えることはよいことのように見える。
が、クライアントの数が増えると、一気に難しくなる。
逆に「絶対50人しか使わない」とかなら使えるかもしれないけど。
ステートレスの長所
ステートレスでは、「クライアントが、リクエストメッセージに必要な情報を含める」。
それに対して、サーバーは対応するだけになるので、処理が楽になる。
不特定多数が使用する場合、こちらの方が向いている。
この時のメッセージを、「事故記述的メッセージ」と呼ぶ。
ステートレスの欠点
- パフォーマンスの低下(データの送信量が増えるため)
- 通信エラーへの対処(例えば、クリック=>通信エラー=>もう一度クリックをした時の処理)
Page 6 of 18.
[添付ファイル]
お問い合わせ
owl
自己紹介
駆け出しエンジニア
だいたいweb系をかじってる
最近ちょとブロックチェーンに興味出てきた
