Webを支える技術 第3部 まとめ
Webを支える技術 第3部のまとめ
第6章 HTTPの基本
HTTPとは
HTTPはハイパーテキストの転送用プロトコルであり、実際には静止画や動画、JavaScriptなどのコンピュータで扱えるデータなら何でも転送できる。
現在のWebでは、これのバージョン1.1が最も使用されている。
TCP/IP
TCP/IPはHTTPのベースになっており、インターネットの基盤を構成するネットワーク・プロトコルである。
ネットワークインターフェース層 物理的なケーブルやアダプタ
インターネット層 ネットワークで実際にデータをやりとりする部分。TCP/IPにおいてIPが相当する。 IPにおいて、データの基本的な通信単位をパケットと呼び、指定したアドレスに対してパケット単位で通信を行う。
トランスポート層 IPが保証しなかったデータの転送を保証する役割を持つ。TCP/IPにおいてTCPが相当する。 TCPでは、接続先に対してコネクションを張ることでデータの抜け漏れをチェックし、データの到達を保証する。 また、接続したコネクションがどのアプリケーションを渡るのかを決定するのがポート番号であり、HTTPではデフォルトの80番ポートが使用される。
アプリケーション層 メールやDNS、HTTPを実現する層。
TCPでは一般的に「ソケット」いうライブラリが使用される。 ソケットは接続、送信、受信、切断などといったネットワークでのデータのやりとりを抽象化したAPIであり、HTTPサーバやブラウザはソケットを用いて実装される。
リクエストとレスポンス
HTTPではクライアント-サーバ間でデータをやりとりする際に、以下のような一連の流れが行われる。
クライアント側
クライアント側
HTTPのステートレス性
HTTPはステートレスなプロトコルとして設計されている。
メリット
- クライアント側に自らのアプリケーション状態を覚えさせることで、サーバの負荷を減らすことに繋げられる
- クライアント側はどのサーバにリクエストを送っても問題ない
デメリット
- 送信するデータの量が多くなる
- 認証などのサーバーに負荷がかかる処理が繰り返される
- 通信エラーの対処
- ネットワークトラブルが起きたときにリクエストが処理されたかどうか分からない
第7章 HTTPメソッド
| メソッド | 意味 |
|---|---|
| GET | リソースの取得 |
| POST | 子リソースの作成、リソースへのデータ追加、その他処理 |
| PUT | リソースの更新、作成 |
| DELETE | リソースの削除 |
| HEAD | リソースのヘッダ(メタデータ)の取得 |
| OPTIONS | リソースがサポートしているメソッドの取得 |
| TRACE | 自分宛てにリソースを返す試験(ループバック) |
| CONNECT | プロキシ動作のトンネル接続への変更 |
尚、TRACEとCONNECTはほとんど使われていない。
POSTとPUTの使い分けについて
特別な理由が無い限り、サーバ側でURIを決定するPOSTを利用する方が望ましい。
第8章 ステータスコード
HTTPのステータスを表す番号
| コード番号 | 意味 |
|---|---|
| 1xx | 処理中 |
| 2xx | 成功 |
| 3xx | リダイレクト |
| 4xx | クライアントエラー |
| 5xx | サーバエラー |
よく使われるもの
| コード番号及びメッセージ | 意味 |
|---|---|
| 200 OK | リクエスト成功 |
| 201 Created | リソースの作成成功 |
| 301 Moved Permanently | リソースの恒久的な移動 |
| 303 See Other | 別URIの参照 |
| 400 Bad Request | リクエストの間違い |
| 401 Unauthorized | アクセス権不正 |
| 404 Not Found | リソースの不在 |
| 500 Internal Server Error | サーバ内部エラー |
| 503 Service Unavailable | サービス停止 |
現在の状態を正しいステータスコードで返さなければ、無駄なインデックス処理が行われてしまう可能性もあるため、設計時に注意しなければならない。
第9章 HTTPヘッダ
ヘッダはメッセージのボディに対する付加的な情報を示す。また、HTTPの機能はヘッダに設定されている情報を元に初めて実装される。
日時
Dateヘッダなどによって、日時のフォーマットを指定する。 例
Date : Tue, 28 Apr 2020 03:21:05 GMT
HTTPでは、日時は全てGMT(グリニッジ標準時)で記述することになっていため、サマータイムなどの問題を回避することが出来る。
MIMEメディアタイプ
Content-Type
Content-Typeヘッダは、メッセージの内容がどのような種類なのかメディアタイプで示す。 現状では、RFC2045及びRFC2046によって9つのタイプが定義されている。
| タイプ | 意味 |
|---|---|
| text | 人が読んで理解できるテキスト |
| image | 画像データ |
| audio | 音声データ |
| video | 映像データ |
| application | その他のデータ |
| multipart | 複数のデータからなる複合データ |
| message | 電子メールメッセージ |
| model | 複数次元で構成するモデルデータ |
| example | 例示用 |
charsetパラメータ
文字エンコーディング(文字コード)を指定するパラメータ。HTTPでは、デフォルトの文字エンコーディングはISO 8859-1と定義されているため、日本語文字列が含まれていると文字化けを起こしてしまう。 文字化けを防ぐには、予めcharsetパラメータでUTF-8などの日本語に対応している文字コードを指定しておく必要がある。
コンテントネゴシエーション
メディアタイプや文字エンコーディングを、サーバ側で一方的に決めるのではなく、クライアントと交渉して決める方式。
Accept 処理できるメディアタイプを伝える
Accept_Charset 処理できる文字エンコーディングを伝える
Accept Language 処理できる言語を伝える
Content-Lengthとチャンク転送
- Content-Length
メッセージがボディを持っている場合、その長さを10進数のbyteで示す。 Content-Lengthヘッダは、静的なファイルなどのあらかじめサイズが分かっているリソースで利用される。
- チャンク転送
動的にリソースが生成されるようなWebサービスの場合、あらかじめサイズが決まっておらず、レスポンスが低下してしまう。 こういった場合、Transfer-Encordingを利用することで、サイズが分からないリソースを少しずつ送ることができる。
認証
ユーザ名とパスワードをAuthorizationヘッダに入れてリクエストごとに送信する認証方式。 ほとんど平文のような形で情報をやりとりするため、SSL/TLSとの組み合わせや平文でもいいという環境などを検討しなければならない。
- Digest認証
ハッシュ関数を利用して、メッセージを不可逆な形式にしてやり取りする方法。 Basic認証よりセキュアな方式だが、メッセージ自体は暗号化されないため、暗号化したい場合はHTTPSを利用した方がよい。
HTTPS
HTTPSは、HTTPとSSL/TLSを組み合わせた通信の総称で、クライアント-サーバ間でのデータのやりとりを暗号化して盗聴を防ぐために利用される。
- 暗号化
- 認証
- 改ざん検知
キャッシュ
サーバから取得したリソースをローカルに保存しておき、再度アクセスしたときに再利用するというHTTPの機能。
Pragma キャッシュを抑制するヘッダ。リソースをキャッシュさせないように示す。
Expires キャッシュの有効期限を指定するヘッダ。指定された時間まではキャッシュを再利用する。リソースを変更しない場合でも、最長1年程度の保持に留めておくことが推奨されている。
Cache-Control 詳細なキャッシュ方式を指定するヘッダ。
条件付きGET
クライアントがキャッシュをそのまま利用できないと判断した場合でも、条件付きGETを利用することでリソースが変更されている検証する。
If-Modified-Since リソースの更新日時を条件にする。
If-None-Match リソースのEtagを条件にする。
If-Modified-SinceとIf-None-Matchの使い分け
サーバがEtagを利用している場合は「If-None-Match」、そうでない場合は「If-Modified-Since」を利用すべき。
持続的接続
HTTP1.1の新機能であり、クライアントとサーバ間でリクエストのたびに切断するのではなく、まとめて接続し続ける手法。HTTP1.0ではKeep-Aliveヘッダで実現するが、HTTP1.1ではデフォルトの動作になった。
