devdevdevReports

dev系開発開発者の開発日記

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)

HTTPとは

  • RFC2616で規定されたプロトコル
  • 最新バージョンは1.1
  • 様々なデータを転送可能
    • ハイパーテキスト(html、xmljsonなど)
    • 画像(img、pngjpeg、gifなど)
    • 動画(mp3、movなど)
    • 音声(asf、asxなど)
    • ドキュメントファイル(pdf、ppx、doc、xlsなど)
  • RESTを実現するWEB基盤
    • 統一インターフェース
    • ステートレスサーバー
    • キャッシュ

TCP/IPとは

階層型プロトコル

アプリケーション層

  • HTTP、NTP、SSHSMTPDNS
  • アプリケーション単位で通信

トランスポート層

  • UDPTCP
  • ポート番号単位で通信

インターネット層

ネットワークインターフェース層

HTTPの歴史

初期(HTTP 0.9)

  • 1990年に発明
  • 仕様書なし
  • ヘッダーなし
  • HTTPメソッドはGETのみ

統一期(HTTP 1.0)

  • 1993年~1996年に発表
  • Netscape、InternetExploreのブラウザ戦争の時期
  • ヘッダーの導入
  • GET以外のHTTPメソッドの導入

完成期(HTTP 1.1)

  • 1997年~1999年に発表
  • チャンク転送の導入
  • Acceptヘッダーによるコンテントネゴシエーションの導入
  • 複雑なキャッシュコントロール機能の追加
  • 持続的接続機能の追加

拡張期

クライアント/サーバー方式

クライアントの役割

  • リクエストメッセージの構築
  • リクエストメッセージの送信
  • レスポンスの待機
  • レスポンスメッセージの受信
  • レスポンスメッセージの解析
  • クライアントの目的に応じた処理(画面表示など)

サーバーの役割

  • リクエストの待機
  • リクエストメッセージの受信
  • リクエストメッセージの解析
  • アプリケーションプログラムへの処理委譲
  • アプリケーションプログラムからの結果を取得
  • レスポンスメッセージの構築
  • レスポンスメッセージの送信

HTTPメッセージ

リクエストメッセージ

  • リクエストライン
    • メソッド
      • リソースに対しての操作
      • 例)GET、POST、PUT、DELETEなど
    • リクエスURI
    • プロトコルバージョン
      • 使用するHTTPのバージョン
      • 例)HTTP/1.1
  • ヘッダー
  • ボディ
    • アプリケーションに渡すデータ(パラメータ)

レスポンスメッセージ

  • ステータスライン
    • アプリケーションが返す処理結果
    • 例)200:成功、403:権限エラー、500:サーバー内エラー
  • ヘッダー
  • ボディ
    • クライアントが目的を果たすために渡すデータ
    • 例)HTML(画面表示)

HTTPメッセージの構成要素

構成要素 リクエス レスポンス
スタートライン リクエストライン ステータスライン
ヘッダー リクエストヘッダ レスポンスヘッダ
空行
ボディ リクエストボディ レスポンスボディ

HTTPのステートレス性

アプリケーション状態

  • システムにログインしてからログアウトするまでの一連の操作の間の状態
  • セッション状態ともいう
  • アプリケーション状態を保存しないのがステートレス

ステートフルの例

ステートフルの欠点

  • クライアントの数が増えた場合にスケールアウトさせにくい
  • 大規模サービスには適用できない
    • 1台のサーバで管理できるクライアントの数には限界がある
    • 不特定多数のクライアントを相手にするとクライアントとサーバを固定できない
    • アプリケーション状態を同期させる必要がある
    • データを同期するとパフォーマンスが低下する

ステートレスの利点

  • システムをスケールアウトしやすい
    • クライアントがアプリケーション状態を都度伝えるため、サーバーで管理しない
    • クライアントが増加した場合はサーバーの増設で対応できる
    • クライアントはどのサーバーにリクエストしてもいい

ステートレスの欠点

  • パフォーマンスの低下
    • データ通信量が多くなる
      • クライアントから冗長的なメッセージを送信するため
      • 認証処理などサーバ負荷が高い処理も冗長的に行うため
    • 通信エラーへの対処が難しい
      • リクエストの途中でエラーとなるとデータの不整合が起きやすい
      • サーバーはアプリケーション状態に関係なく、リクエストを受け付けるため

【WEBを支える技術】を読む理由 - devdevdevReports

【WEBを支える技術】REST編 - devdevdevReports

【WEBを支える技術】URI仕様編 - devdevdevReports

【WEBを支える技術】URI設計編~良いURI設計とは~ - devdevdevReports

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~ - devdevdevReports

【WEBを支える技術】HTTPメソッド編~名は体を表す~ - devdevdevReports

【WEBを支える技術】HTTPステータス編~名は体を表す~ - devdevdevReports