読者です 読者をやめる 読者になる 読者になる

Webを支える技術を研修で読んでる まとめ2

この記事について

技術研修で読み進めているWebを支える技術について、各章のまとめを順次上げていく。

前 Webを支える技術1~5章

次 

HTTPの概要

HTTPはTCP/IPをベースにしている。 TCP(Transmission Control Protocol) IP(Internet Protocol) 現在のHTTPはバージョン1.1が主流として使われており、10年以上更新されていない。 現代の開発スタイルでは、HTTP1.1を有効に使っていこうという流れになっている。^1 ネットワーク・プロトコルは階層毎にわかれている。

各階層は次のようになっている。

  • ネットワークインターフェース層
  • インターネット層
    • IPを使ってパケット単位でネットワークで実際にやり取りする部分
      • この時、最終的にたどり着くかは保証していない
    • IP
  • トランスポート層
    • IPでのデータ転送の届け先を保証する部分
      • ここで初めて相手に対してコネクションを張る
    • UDPTCP
      • どちらも通信用の標準規格
      • UDPは、届いているかどうかを確認せず、データを送りっぱなしにする。信頼性は低いが転送効率が高く遅延しにくい。
      • TCPは、再送制御やデータ欠落の検知など信頼性を確保する仕組みが整っているため、転送効率より確実性が高い
    • ポートを利用するが、1〜65535の数値
  • アプリケーション層
    • 実際のメールやHTTPを実現する部分
    • TCPでプログラムを作る時は、ソケットを使うのが一般的
    • HTTP、NTP、SSHSMTPDNS

階層にすることの特徴は

  • 抽象度別に分けることが出来る
    • ネットワークインターフェース層のほうが抽象度が低い
  • 各階層の実装が独立している
    • 下位層の実装に依存しない
    • 障害発生時などの問題を各層毎に区切ることが出来る

HTTPの仕組みについて

HTTPはアーキテクチャスタイルに クライアント/サーバ を採用している。 クライアント(Webブラウザ)が情報を提供するサーバ(Webサーバ)に接続し、各種リクエストを出してレスポンスを受け取る。 このようなプロトコルリクエスト/レスポンス型(Request-Response Style) と呼ぶ。

クライアント/サーバそれぞれの役割

クライアントでは、リクエストの送信から受信する際、次のことを行う。

  1. リクエストメッセージの構築
  2. リクエストメッセージの送信
  3. (レスポンスが返るまで待機)
  4. レスポンスメッセージの受信
  5. レスポンスメッセージの解析
  6. クライアントの目的を達成するために必要な処理
    • ブラウザであれば、HTMLのレンダリング処理
    • 検索エンジン用にデータを集めるロボットプログラムであれば、HTMLの解析結果をDBに格納する処理

次に、サーバでは次のことを行う

  1. (リクエストの待機)
  2. リクエストメッセージの受信
  3. リクエストメッセージの解析
  4. 適切なアプリケーション・プログラムへの処理の委譲
    • DBから最新記事を取得処理
    • 広告へのリンク作成処理
  5. アプリケーション・プログラムから結果を取得
  6. レスポンスメッセージの構築
  7. レスポンスメッセージの送信

HTTPメッセージ

先述した、リクエストメッセージとレスポンスメッセージはまとめて、 HTTPメッセージ と呼ぶ。

リクエストメッセージの構造

リクエストメッセージの構造は以下の図のようになっている。 名称未設定 2.001.jpeg

リクエスト行のURIには、http://example.jp:8080/search?q=test&debug=true#n10のようなURIフラグメントは、リクエストメッセージには含めない。この場合のリクエスト行は、URIフラグメントを除いた、パス以降の文字列が入る。具体的には/search?q=test&debug=trueが入る。

また、リクエストURIは基本絶対URIでも相対URIでも使用出来る。^2 しかし、プロキシへのリクエストの場合必ず 絶対URI となる。

レスポンスメッセージの構造

レスポンスメッセージの構造は以下のずのようになっている。 名称未設定 2.002.jpeg

参考:ネットワークエンジニアとして TCP/IP - HTTP

HTTPのステートレス性

HTTPはステートレスなプロトコルとして設計されている。 これは、サーバがアプリケーション状態を保存しないということである。

アプリケーション状態とは?

アプリケーション状態は、別名セッション状態とも言う。 システムにログインしてから、ログアウトするまでの一連の操作間の状態をアプリケーション状態と呼ぶ。

もしステートフルなプロトコルだと、アプリケーション毎のやり取りをサーバが記憶する必要がある。 反対にステートレスなプロトコルだと、アプリケーション自身でやり取りを全て記憶する必要がある。

それぞれの概要は次のようになる。

  • やり取りについて
    • ステートフル:簡潔(サーバが記憶しているから)である。
    • ステートレス:冗長(今までの状態を話す必要があるから)である。
  • 利点
    • ステートフル:送信するデータ量が少なくて済む。
    • ステートレス:クライアント数が増えた際にシステムをスケールさせるのが楽になる。
  • 欠点
    • ステートフル:クライアント数が増えると、サーバが記憶しなければならないデータ量が増えるため負担が増える。
    • ステートレス:送信データ量が増える。認証など、サーバに負担がかかる処理を繰り返す。通信エラーの際にリクエストが処理出来ているか分からない。