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

HTTPの教科書

ーー 第1章 Web とネットワークの基本を知ろう ーー

 

TCP / IP 

アプリケーション層。HTTPやFTP

トランスポート層TCPが信頼性を担当。データ(HTTPメッセージ)を通信しやすいようにバラバラにしたり、スリーウェイハンドシェイクで確実に相手に送信する。

ネットワーク層。IPが配送を担当。宛先としてMACアドレスを追加。

 

URI(Uniform resource Identifier)のフォーマット

http://user:pass@www.example.jp:80/dir/index.html?uid=1#ch1

・「スキーム名」リソース取得に用いるプロトコルの指示(ex)https. http, ftp

・「資格情報」サーバーからリソースを取得するのに必要なアイパスなど(オプション)

・サーバーアドレス、ポート番号、ファイルバス、クエリー文字列、フラグメント識別子

 

 

ーー 第2章 シンプルなプロトコルHTTP ーー

 

■HTTPは状態を保持しないステートレスなプロトコル

・状態の保持には Cookie を用いる。

・あるサーバーへの1度目のリクエストに対するレスポンスの際に、Set-Cookie というヘッダーフィールドでCookieをクライアントに保存するよう指示。同一サーバーへの2回目以降のリクエストの際には、Cookieをヘッダーフィールドに付加することで同一のクライアントであると認識される。

 

■HTTPメソッド

・「GET」リソースの取得

・「POST」エンティティボディの転送

・「PUT」ファイルの転送。セキュリティ上の問題があるので、Webアプリケーションの認証機能やWeb同士が連携するRESTという設計様式を利用する場合に利用されることが多い。

・「HEAD」メッセージヘッダーの取得。URIの有効性やリソースの更新時間を確かめる目的で使われる。

・「DELETE」ファイルの削除。PUTと同様セキュリティ上の問題。

・「OPTIONS」サポートしているメソッドの問い合わせ。

・「TRACE」経路の調査。

・「CONNECT」プロキシへのトンネリング要求。

 

■通信量の節約

・「持続的接続」クライアントとサーバーいずれかが明示的に接続を切断しない限り、TCP接続を持続する。リクエスト毎の前にTCP接続を行う必要がなくなる。

・「パイプライン化」レスポンスを待たずにリクエストを発行できる。

 

 

ーー 第3章 HTTPの情報はHTTPメッセージにある ーー

 

■メッセージの転送

・「コンテンツエンコーディング」圧縮して送る。gzip, compress, deflate, など

・「チャンク転送コーディング」大きなサイズのデータの時分解して送る

・「マルチパート」MIMEの仕組みを使って、テキストや画像など異なるデータを送信できる。MIME・・画像などのバイナリデータをASCII文字列にエンコードする方法や、データの種類を表す方法を規定している。

・「レンジリクエスト」エンティティの範囲を指定してリクエストを行う。

・「コンテンツネゴシエーション」言語や文字セット、エンコーディング方式毎に最適なリソースを提供する仕組み。サーバー、クライアント、両方が駆動するタイプがある。

 

 

ーー 第4章 結果を伝えるHTTPステータスコード ーー

 

ステータスコードのクラス

・1XX リクエストが受け付けられて処理中

・2XX リクエストが正常に処理を完了した。

・3XX リクエストが完了するには追加動作が必要(リダイレクトとか)

・4XX クライアントエラー

・5XX サーバーエラー

 

 

ーー 第5章 HTTPと連携するWebサーバー ーー

 

■バーチャルホスト

・1台のサーバーで複数ドメインを実現する。

・同じIPアドレスで異なるホスト名やドメイン名を持った複数のWebサイトが稼働しているバーチャルホストの仕組みがあるため、FQDN( Fully Qualified Domain Name )かHostヘッダーフィールドでの指定が必要。

 

■通信を中継するプログラム

・「プロキシ」サーバーとクライアントの両方の役割をする中継プログラム。キャッシングプロキシと透過型プロキシがある。

・「ゲートウェイ」HTTPサーバー以外のサーバーへの中継。データベースへの接続やクレジットカードの決済など。

・「トンネル」クライアントとサーバーが安全に通信を行うための通信路を確立する。HTTPリクエストを解釈しない。

 

・キャッシュはクライアントとサーバーの双方に存在する。

 

 

ーー 第6章 HTTPヘッダー ーー

 

・HTTPヘッダーフィールドは、HTTPメッセージを構成する要素の1つで、HTTPプロトコルの中で、メッセージボディのサイズや、使用している言語、認証情報などをブラウザやサーバーに伝える。

 

■4種類のHTTPヘッダーフィールド

・「一般ヘッダーフィールド」リクエスト、レスポンス両方で用いられる。

・「リクエストヘッダーフィールド」

・「レスポンスヘッダーフィールド」

・「エンティティヘッダーフィールド」

 

 

ーー 第7章 Webを安全にするHTTPS ーー

 

■HTTPの弱点

・通信が平文(暗号化しない)なので盗聴可能

・通信相手を確かめないのでなりすまし可能

・完全性を証明できないので改竄可能。

 

HTTPS = HTTP + 暗号化 + 認証 + 完全性保護

公開鍵暗号方式共通鍵暗号方式を併用して暗号化。

・ネットワークに負荷がかかることから通信が遅くなる。

・暗号化や復号化の必要があるのでCPUやメモリを使い処理が遅くなる。

 

 

ーー 第8章 誰がアクセスしているかを確かめる認証 --

 

■HTTP/1.1 で利用できる認証方式

BASIC認証

・DIGEST認証

SSLクライアント認証 - HTTPSのクライアント認証を利用した証明方式で、利用するのにコストがかかる。

・フォームベース認証 - 認証の大半はフォームベース認証が用いられ、セッション管理とCookie による実装が行われている。

 

 

ーー 第9章 HTTPに機能を追加するプロトコル --

 

■HTTPのボトルネック

・1コネクションで1リクエストしか送れない。

・リクエストをクライアントからしか開始できない。レスポンスだけを受け取れない。

・ヘッダーが圧縮されずに送られる。ヘッダーが冗長。

・データの圧縮は任意だが、圧縮して送られることが強制ではない。

 

■解決方法

・「Ajax

・「Comet」サーバーに更新があるまでレスポンスを保留。(疑似的サーバープッシュ)

・「SPDY」多重化ストリーム、リクエストの優先順位付け、HTTPヘッダーの圧縮、サーバープッシュ機能、サーバーヒント機能

・「WebSocket」ブラウザで双方向通信を行う。通信料削減

 

WebDAV(Web-based Distributed Authoring and Versioning)

 Webサーバー上のファイル管理を行う。

 

 

ーー 第10章 Webコンテンツで使う技術 --

 

・「CGI」リクエストのたびにプログラムを起動するので、大量にアクセスがあるとWebサーバーに負担がかかる。

・「サーブレット」Webサーバーと同じプロセスの中で動作するので、負荷を軽減できる。

XMLAtomRSSJSON

 

 

ーー 第11章 Webへの攻撃技術 --

 

・出力値の不備による脆弱性

・設定や設計の不備による脆弱性

・セッション管理の不備による脆弱性

など

 

 

ーー 感想 --

 

・基本情報を取った人には重複した内容も多く、簡単すぎるかもしれない。とはいえ、HTTPヘッダーの各ステータスやHTTPSなど、中身については知らないものも少なくはなかった。

・最初に入るには悪くはないかもしれないがオススメはしない。難易度がとても半端で、もう少し解説があったらという用語がいきなり出てきたりする。