🦔

学習備忘録〜「Webを支える技術」第6章〜

に公開
web基礎
tech

はじめに

この備忘録は、新卒2年目の初学者バックエンドエンジニアの学習記録のためにつけているものです。
解釈違いや、誤情報がある可能性があります。見つけた際にはご指摘をお願いします。
新規プロジェクトにアサインしてもらうことも増えてきて、基礎知識から定着させていきたいと思い学習備忘録第二弾が始まります。

第6章〜HTTPの基本〜

HTTPの重要性

  • HTTPとはRFC2616で規定されたプロトコル
  • HTTPが取り扱えるデータ
    • HTML、XML
    • 静止画
    • 音声
    • 動画
    • JavaScriptプログラム
    • PDFや各種オフィスドキュメントファイル
    • その他コンピュータで扱えるあらゆるデータ
  • Webの基盤となるプロトコル
    • 以下の要素を実現している
      • 統一インタフェース
      • ステートレスサーバ
      • キャッシュ

RFC2616とは？

プロトコルとは？

TCP/IPとは何か

HTTPは、TCP/IPをベースにしている。
TCP/IPは、インターネトの基盤を構成する重要なネットワークプロトコルである。

階層型プロトコル

  • インターネットのネットワークプロトコルは階層型
  • 層ごとに抽象化していけば、階層の具体的なことに左右されることなく、上位層を実装可能
階層型プロトコル 主なプロトコル
アプリケーション層 HTTP,NTP,SSH,SMTP,DNS
トランスポート層 UDP,TCP
インターネット層 IP
ネットワークインタフェース層 イーサネット

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

  • 物理的なケーブルやネットワークアダプタに相当する部分

インターネット層

  • ネットワークインタフェース層の上に位置する
  • ネットワークでデータを実際にやり取りする部分
  • IPが相当する
  • IPではデータの基本的な通信単位を「バケット」と呼ぶ
  • 指定したIPアドレスを送り先として、バケット単位でデータをやり取りする
  • IPでは、自分のネットワークインタフェースでデータを送り出すことのみを保証する
  • 送り出したデータが、多数のルータを経由して最終的な送り先魔d届くかどうかは保証しない

トランスポート層

  • IPが保証しなかったデータの転送を保証する役割
  • TCPが相当
  • 接続先の相手に対してコネクションを張る
  • コネクションを用いてデータの漏れを確認し、データの到達を保証する
  • TCP接続で転送するデータが、どのアプリケーションに渡るのか決定するのがポート番号

ポート番号とは？
HTTPは通常80番

アプリケーション層

  • 具体的なアプリケーションのHTTPや、メール、DNSを実現する層
  • TCPでプログラムを作るときは、ソケットと呼ばれるライブラリを使うのが一般的
  • 基本的なプログラミング言語にはHTTPを実装したライブラリが標準でついている
  • ソケットを使ってHTTPを独自に実装することはほとんどない

ソケットとは？
ネットワークでのデータのやり取りを抽象化したAPI
接続、送信、受信、切断等の基本的な機能を備えている

クライアントとサーバ

  • Webはアーキテクチャスタイルにクライアント/サーバスタイルを採用

クライアント/サーバスタイル
クライアント（Webブラウザ）が情報を提供するサーバ（Webサーバ）に接続し、各種のリクエストを出してレスポンスを受け取る

リクエストとレスポンス

  • リクエスト/レスポンス型のプロトコルとは、HTTPではクライアントが出したリクエストをサーバで処理してレスポンスを返すプロトコルのことである
  • HTTPが同期型のプロトコルであるため、サーバでの処理に時間がかかる場合でも、リクエストを出したクライアントはレスポンスが返るまで待機する

クライアントで行われること

  1. リクエストメッセージの構築
  2. リクエストメッセージの送信
  3. レスポンスが返るまで待機
  4. レスポンスメッセージの受信
  5. レスポンスメッセージの解析
  6. クライアントの目的を達成するために必要な処理

サーバで行われること

  1. （リクエストの待機）
  2. リクエストメッセージの受信
  3. リクエストメッセージの解析
  4. 適切なアプリケーションプログラムへの処理移譲
  5. アプリケーションプログラムから結果を取得
  6. レスポンスメッセージの構築
  7. レスポンスメッセージの送信

HTTPメッセージ

リクエストメッセージ

最も簡易的なリクエストメッセージ

GET /test HTTP/1.1
Host: example.jp

リクエストライン

  • 1行目のことを「リクエストライン」と呼ぶ
  • メソッド、リクエストURI、プロトコルバージョンから成る

他にも以下の様なリクエストメッセージもある
クエリパラメータ

GET /test?type=normal HTTP/1.1
Host: example.jp:8080

絶対URI

GET http:example.jp/test HTTP/1.1
Host: example.jp

ヘッダ

  • リクストメッセージの2行目以降はヘッダが続く
  • ヘッダはメッセージのメタデータ
  • 1つのメッセージは複数のヘッダを持てる
  • 各ヘッダは「名前：値」という構成をしている
Host: example.jp:8080

ボディ

  • ヘッダの後にボディが続くこともある
  • ボディには、そのメッセージを表す本質的な情報が入る

レスポンスメッセージ

HTTP/1.1 200 OK
Content-type: aoolication/xhtml+xml; charset=uft-8

<html xmls="http://www.w3.org/1999/xhtml">
...
</html>

ステータスライン

  • レスポンスメッセージの1行目を「ステータスライン」と呼ぶ
  • プロトコルバージョン、ステータスコード、テキストフレーズから成る

ヘッダ

  • レスポンスメッセージの2行目以降

ボディ

  • ヘッダの後に続く部分
  • ヘッダとボディは空行で区切られる

HTTPのステートレス性

  • ステートレスとは「サバーがクライアントのアプリケーション状態を保存しない」制約のこと
  • ステートフルなやり取りは簡潔
  • ステートレスなやり取りは冗長

アプリケーション状態

  • アプリケーション状態とは別名「セッション状態」とも呼ばれる
  • システムにログインしてからログアウトするまでの一連の操作をまとめて「セッション」と呼ぶ

ステートフルの欠点

  • ステートフルなアーキテクチャでは、クライアントの数が増えた場合にスケールアウトさせにくくなる

ステートレスの利点

  • クライアントがリクエストメッセージに必要な情報を全て含める「自己記述的メッセージ」
  • ステートレスなサーバはアプリケーション状態を覚える必要がないため、サーバ側のシステムは単純になる
  • サーバは新しく送られてくるリクエストの処理にのみ集中すれば良くなる

ステートレスの欠点

パフォーマンスの低下

  • クライアントは毎回必要な情報を全て送信しなければならず、パフォーマンスが低下する恐れがある
  • パフォーマンス低下理由
    • 送信データ量が多くなる
    • 認証等、サーバに負荷がかかる処理を繰り返す

通信障害に対する対応

  • ステートフルな場合、通信障害によりリクエストが再送された場合に二重リクエストを感知できる
  • ステートレスな場合、通信障害によりリクエストが再送された場合に二重リクエストを感知できない

Discussion