HTTPの教科書 9章

HTTPの教科書

HTTPのボトルネック

HTTPは以下の使用からボトルネックとなっている。 * 1つのコネクションで一つのリクエストしか、送ることができない。 * リクエストはクライアントからしか開始することができない。 * リクエスト、レスポンスヘッダーが圧縮されずに送られる。 * 冗長なヘッダーを送る。 * データの圧縮が強制でない。

様々なボトルネックの解消方法

Ajaxによる解決

XMLHttpRequestと呼ばれるAPIで、JavaScriptなどのスクリプト言語でサーバーとの通信を行うことができる。この技術を使うことでWebページの一部だけのデータを読むことができる。

Cometによる解決方法

Cometはサーバーのコンテンツに更新があった場合、クライアントからのリクエストを待たずにクライアント側にデータを送信するぎじゅつ。コンテンツをリアルタイムで更新することができる。

プロトコルレベルでの解決方法

Ajaxなどの技術はあるが、HTTPの制約を払おうとするとプロトコルレベルでの改善が必要。SPDYは現在のWebの速度を50%削減するすることを目標として開発が進められているプロトコルである。HTTPを完全に置き換えるのではなく、セッション層を新たに追加する。SPDYを使うことで、次のような機能をつけることができる。

多重化ストリーム

単一のTCPで、複数のHTTPリクエストを無制限に処理することができる。

リクエストの優先順位づけ

SPDYは無制限に並列に処理を行うことができるが、優先順位を割り当てることもできる。帯域幅が狭い処理がおそっくなることを防ぐためのもの。

HTTPヘッダの圧縮

リクエストとレスポンスのヘッダーを圧縮することができる

サーバープッシュ

サーバー側からクライアントにデータをプッシュする機能をサポート

サーバーヒント

サーバー側からクライアントに対して、リクエストすべきリソースを提案できる。

WebSocket

ブラウザーとサーバーの双方向の通信規格。一度コネクションを確立した後その後のすべての通信を専用プロトコルで行う。

# HTTPの教科書　8章

HTTPの教科書　8章

認証

コンピューターはディスプレイのまえに座っているのが誰かはわからない。本人であるかを確認するためには以下のような「本人しか知らない情報」もしくは、「本人しか持たない情報」を用いるしかない。

  • パスワード：本人だけが知っている情報
  • ワンタイムトークン：本人だけが持ってる機器等に表示された使い捨てパスワードなどの情報
  • 電子証明書：本人だけが持っている情報
  • バイオメトリクス：指紋や虹彩などの本人の身体情報
  • ICカードなど：本人だけが持っている情報

HTTPで使う認証方式

  • BASIC認証
  • DIGEST認証
  • SSLクライアント認証
  • フォームベースの認証

BASIC認証

HTTP1.0から実装されている認証方式で、現在でも一部で使われている。リクエストがあった場合には401(Authorization )ステータスコードを返す。ユーザーが入力したパスワードとユーザーIDは：でつながれBase64と呼ばれる形式でエンコードしてサーバーに送る。簡単にデコードでき、セキュリティの観点からよわいためにあまり使われない。

DIGEST認証

チャレンジレスポンス方式が使われている。チャレンジコードを使ってレスポンスコードを計算する。これでもまだセキュリティのリスクが有るためあまり使われていない。

SSLクライアント認証

HTTPSのクライアント証明書を利用した認証。予め登録されたクライアントからのアクセスかどうか確かめることができる。

フォームベース認証

クライアントが資格情報を送信し検証結果によって認証を行う方式。基本的には安価で安全だが、実装によってはセキュリティリスクが生じうる。サーバーはステートレスであるため、状態管理ができない。そこでセッション管理とCookieを使ってHTTPにない状態管理の機能を補う。資格情報はメッセージボディに格納されHTTPSで送信される。

HTTPの教科書まとめ（七章）

HTTTPの教科書まとめ　7章

HTTPの弱点

HTTP通信には次のような弱点がある。

  • 通信が平文なので盗聴可能
  • 通信相手をたしかめないのでなりすましが可能
  • 完全性を確かめないので改竄が可能

盗聴に関して

暗号化して身を守る方法

  • 通信の暗号化 SSLなどで通信そのものを暗号化する。これはHTTPSはやHTTP over SSLと呼ばれる。

  • コンテンツの暗号化 HTTPメッセージの中身だけ暗号化。改竄やなりすましの可能性が残る。

なりすましに関して

HTTP通信では相手を確かめない

リクエストもレスポンスも相手を確かめずに行う。

相手を確かめるために証明書を使うことができる。

信頼できる第三者機関が発行する証明書で通信相手を判断することができる。

完全性を確かめないことに関して

受け取った内容が改ざんされているかもしれない。

通常、HTTP通信では発行されたリクエストやレポンスが同じかどうかを確認していない。

改竄防ぐためには

HTTPでも完全性を高める方法はあるが確実で便利な方法は今のところない。確実に防ぐためにはHTTPSを用いる必要がある。

HTTPSは暗号化と認証と完全性保護を兼ね備えたHTTP

HTTPのソケット部分をSSLやTLSに置き換えている。HTTPSはハイブリッド暗号システムである。ハイブリッド暗号システムでは、共通暗号鍵を公開暗号鍵を用いて交換しその後の通信はお互いの共通暗号鍵を用いて通信を行う。公開鍵が本物であることは認証局によって証明される。またクライアント認証もできるが、ユーザーにクライアント証明書を発行してもらう必要がある。

HTTPまとめ

webとhttpの歴史

  • そもそもは学者の知識共有のためのツールとしてwebのもととなる仕組みが考案された。
  • そしてそのWWWを支える仕組みとしてHTTPとHTMLが考案されている。

TCPとIP

それぞれの層での役割

アプリケーション層

  • ユーザーに提供するアプリケーションで使う通信の動きを決めている。
  • FTPやDNS、そしてHTTPはこの層のプロトコルに含まれる。

トランスポート層

  • ネットワークで接続されているコンピューター間でのデータの流れのルールを決める層
  • 流れのルール、プロトコルにはTCP、UDPがある。

ネットワーク層

  • パケットの移動（その経路）を取り扱う層
  • ネットワークでは相手にパケットを届けるまでいくつもの経路がありますがその中から1つを決定します。

リンク層

  • ネットワークに接続するハードウェア的な部分を扱う
  • OSがハードウェアを操作するためのドライバやNIC、そしてケーブルなどの物理的に見える部分がこの層で取り扱う。

以上の4層はデータを送信する際にはユーザもしくはサーバー側から見てアプリケーション層、トランスポート層、ネットワーク層、リンク層の順番で処理されていきます。受信する際はその逆です。

TCP/IPでの通信の流れ

TCP/IP通信をする際の流れをいかに示す。

1.クライアント側のアプリケーション層でどのwebページを見たいかというHTTPリクエストを指示する。

2.次にトランスポート層で通信をしやすいようにばらばらにして通し番号とポート番号をつけてネットワーク層に渡します。

3.ネットワーク層では宛先としてMACアドレスを追加してリンク層に渡します。

4.リンク層でハードウェアの取り決めが行われます。

5.受け取り側は逆にリンク層からたとどってアプリケーション層までたどり着きます。

また、上記のようにそれぞれの層をたどっていく際に層ごとに必要なヘッダが着脱されます。

IP

信頼性が高いTCP

  • TCPはトランスポート層にあたるプロトコルで、スリーウェイハンドシェイクと呼ばれる手法によって信頼性の高いデータ通信を行っている。
  • スリーウェイハンドシェイクでは【SYN】と【ACK】というTCPフラグが使われる。

フラグを使った通信の流れを以下に示します。

  1. 【SYK】で相手に接続するとともパケットを送ります。
  2. 受信側は【SYK/ACK】とともにパケットを受け取った胸を伝えます。
  3. 最後に送信側が【ACK】のフラグを返すことで通信が終了したことを示します。

上記の過程がどこかで途絶えた場合TCPはパケットを再送して同じ手順を行います。

URI

  • URIとはスキームで表すことができるリソースを識別するための識別子である。
    • スキームとはリソースを得るための手段の名前付け方法のことです。
  • URIは「スキーム名」、「資格情報（クレデンシャル）」、「サーバーのアドレス」、「サーバーのポート」、「階層的なファイルパス」、「クエリー文字列」、「フラグメント修飾子」などから成り立ちます。

http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1の場合の

http =「スキーム名」

user:pass =「資格情報(クレデンシャル)」

www.example.jp = サーバーのアドレス

80 =「ポート番号」

/dir/index.htm = 階層的なファイルパス

uid=1 =「クエリー文字列」

ch1 =「修飾子」

スキーマ名

  • リソースを取得するために使うプロトコルを指示する。
  • "data"や"javascript"のようにプログラムを指定することもできる。
資格情報（オプション）
  • サーバーからリソースを取得するのに必要な資格情報。
  • オプション扱い。

サーバーのポート番号（オプション）

  • サーバーの接続先となるポート番号。
  • オプション扱い。

階層的なファイルパス

  • リソースを識別するためのサーバー上のファイルパス

クエリー文字列（オプション）

  • ファイルパスで指定されたリソースに任意のパラメーターを渡すためのもの。
  • オプション扱い

フラグメント修飾子（オプション）

  • 取得したリソースのサブリソースを示すのに使われる。
  • サブリソースとはドキュメント内の途中の位置などをさす。

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

  • HTTPはリクエストごとに新しいレスポンスが生まれ、過去のリクエストやレスポンスの状態は一切保持しない。
  • 別ページに行ってもログイン状態を維持したい場合はCookkieという技術（後述）でその課題が解決される。

HTTPメソッド

  • HTTPメソッドはサーバーに支持を与えるためのものである。

メソッドの種類

GET : リソースの取得

  • リクエストURIで識別されるリソースの習得を要求する。
  • サーバーがリソースを解釈しその結果をレスポンスとして返す。
    • テキストならそのまま、プログラムであれば実行結果がレスポンスになる。

POST : エンティティボディの転送

  • GETメソッドと類似しているが、エンティティボディー転送の目的で使用される。
  • GETでもエンティティボディーは送信は可能であるが、POSTが一般的に使われる。
  • POSTメソッドの目的はレスポンスによるエンティティの取得ではない。

PUT : ファイルの転送

  • ファイルを転送するために使われる。
  • このPUTメソッドそのものに認証機能がないため、セキュリティ上に問題がある。
    • Webアプリケーションなどによる認証機能の組み合わせや、RWST（Representational State Trancefer）という設計様式を使う場合に利用される。

HEAD : メッセージヘッダーの取得

  • HEADメソッドはGETと同様の機能ですが、URLの有効性やリソースの更新時間を確かめる目的などで使われる。

DELEATE : ファイルの削除

  • ファイルの削除を行うためのメソッド。
  • PUT同様メソッドそのものに認証機能はない。
    • PUTと同様な場面で使われる。

OPTION : サポートしているメソッドの問い合わせ

タイトル通り

TARANCE : 経路の調査

  • Webサーバーに接続して自分に通信を折り返してもらうループバックを起す。
  • リクエスト送信の際"Max-Forwards"という数値をヘッダーフィールドに定め、サーバーを通過するごとにその数を減らしていきます。
  • 0になったところを最後とし、最後にリクエストを受け取ったサーバーはステータスコード200のokを返す。
  • XSTという攻撃に利用されることによって現在では使われていません。

CONNECT : プロキシへのトンネリング要求

  • プロキシサーバーにトンネル接続の確立を要求して、TCP通信をトンネリングさせるために使う。
  • SSLやTLSなどのプロトコルで暗号化されたものをトンネルさせるために使われる。

持続的な接続で通信量を節約

  • 受信されるデータ量が年々増え,TCP接続をつなげっぱなしにしておくという方法が考えられた。
  • TCPコネクション接続を何度も行うオーバーヘッドを減らすことができ、その分通信が早くなる。

パイプライン化

  • 複数のリクエストを並列して発行でき、リクエストに対してレスポンスを待つ必要がない
  • 持続的な接続により可能になる

Cokkieを使った状態管理

  • ステートレスなHTTP通信で、クライアント側に以前までのやり取りの状態を保存してもらうためCokkieを使う。
  • HTTPヘッダのSet-Cokkieでクッキーをクライアントに送る。
  • 保存したCokkieをクライアントはサーバーに送り、サーバーはそのCokkie情報から以前までの状態を認識する。

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

HTTPメッセージ

  • HTTPリクエストとHTTPレスポンス
  • 大きくメッセージヘッダとメッセージボディから成り立つ

リクエストメッセージとレスポンスメッセージの構造

リクエストメッセージ

  • メッセージヘッダー
    • リクエストライン
      • リクエストURIとHTTPのバージョン
    • リクエストヘッダフィールド
      • リクエストの諸条件や属性を表す各種ヘッダ
    • 一般ヘッダフィールド
    • エンティティヘッダフィールド
  • メッセージボディ

レスポンスメッセージ

  • メッセージヘッダー
    • ステータスライン
    • レスポンスヘッダフィールド
      • レスポンスの諸条件や属性を表す各種ヘッダ
    • 一般ヘッダフィールド
  • メッセージボディ

　エンコーディングで転送効率を上げる

メッセージボディとエンティティボディの違い

メッセージとエンティティとは
  • メッセージ
    • HTTP通信での基本単位
    • オクテットシーケンス（8bit）からなり、通信を介して転送
  • エンティティ
    • リクエストやレスポンスのペイロード（不可物）
    • エンティティヘッダーフィールドとボディから成り立つ
違い
  • メッセージボディの役割はリクエストやレスポンスに関するエンティティボディを運ぶこと
  • 基本的には「メッセージボディ＝エンティティボディ」
  • 転送コーディングで送る場合はエンティティボディの内容が変わるため≠

圧縮して送るコンテンツコーディング

主なコンテンツコーディングの種類

分解して送るチャンクエンコーディング

  • HTTP通信ではリクエストしたリソースのすべてのエンティティボディの転送が完了しないとブラウザー表示されない。
  • 大きなデータを転送する場合はデータをいくつかに分けることで少しずつ表示できる。
  • エンティティボディを分割する機能をチャンク転送コーディングと呼ぶ
    • チャンク転送コーディングでは区切りのサインとして次のチャンクサイズを16進数で示したものを使う
    • エンティティボディの最後には”０（CR＋LF）”を書いている
使われてるところ
  • Webページとか開く際に画像が部分部分で表示されているのはチャンクエンコーディングで分割して送られるから

複数の形式のデータを送れるマルチパート

  • メールにはMIMEと呼ばれる複数種のデータを扱うための仕組みがあり、マルチパートと呼ばれる複数の形式のデータを格納する方式を使っている。
  • HTTPにもこのマルチパートに対応しており、1つのメッセージボディの中に複数のエンティティを含めて転送することができる。
  • マルチパートの区切り文字列はHTTPヘッダのContent-Typeヘッダーフィールドのboundaryに指定する。
  • 実際の区切りは区切り文字列プラス”--”になる
 COntent-Type:Multipart/formdata; boundary=AaB03x

  (改行)

  --AaB03x

  Content-Type:application/pdf

  Content-Renge:byte 7000-7999/8000

　(改行) 

  （データ）

  --AaB03x

  Content-Type:application/pdf

  Content-Renge:byte...

  (改行) 

  (別のデータ)

  --AaB03x--
マルチパートの種類
  • Multipart/form-data
    • webフォームからファイルアップロードに使用される
  • Multipart/byteranges
  • ステータスこーでお206(Partial COntent)レスポンスメッセージが複数の内容を含むときに使用される。

一部だけもらえるレンジリクエスト

  • インターネットが普及する以前は大きなデータを送ってもらっている最中にコネクションが切断されると最初からやり直しになっていた。
  • 現在はレジュームと呼ばれる機能でダウンロードしたところから再開できる。
  • レジュームを行うためには部分的に送ってもらう範囲を指定することが必要であり、その範囲指定したリクエストをレンジリクエストという。
  • レンジリクエストに対するレスポンスのステータスコードは206（Partial Content）
  • サーバーがレンジリクエストに対応していない場合は200 OKのステータスコードが返され、完全なエンティティが返される。

最適なコンテンツを返すコンテンツネゴシエーション

  • 異なる言語を主とするブランざーが同じURIにアクセスしたときにそれぞれに対応した言語のWebページを返すような仕組みをコンテンツネゴシエーションと呼ぶ。
    • コンテンツネゴシエーションとはクライアントとサーバーが提供するソースの内容について交渉すること。
    • コンテンツネゴシエーションでは言語、文字セット、エンコーディング方式などをリクエストメッセージのヘッダーフィールドから判断する.
      • Accept
      • Acceot-Charaset
      • Accept-Encoding
      • Accept-Language
      • Content-Language
コンテンツネゴシエーションの種類
サーバー駆動型ネゴシエーション
  • サーバー側でネゴシエーションを行う方式
  • リクエストヘッダーフィールドを参考に自動的に処理を行う
  • ブラウザーが送る情報を基にするため、ユーザーに最適かものが送られるとは限らない。
エージェント駆動型ネゴシエーション
  • クライアント側でコンテンツネゴシエーションを行う方式
  • ブラウザーに表示された選択肢からユーザーが主導で選択する。
  • JavaScriptで自動的に行うものもある。
    • たとえば、PC用とスマフォ用のWebページを切り替えるなど。
トランスペアレントネゴシエーション

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

ステータスコードはサーバーからのリクエスト結果を伝える。

  • クライアントからのリクエストに対して、結果を示すのがステータスコードである。
  • ステータスコードは200 OKのように3ケタの数字と説明から成り立つ。
  • 最初の1桁（百の位の部分）でレスポンスの種類を表している。
ステータスコード クラス 説明
1XX Infomational ステータスが受け入れられて処理中
2XX Success リクエストされた処理が正常に完了した
3XX Redirection リクエストが完了するには追加動作が必要
4XX Client Error サーバーがリクエストを理解できなかった
5XX Server Error サーバーがリクエストの処理に失敗した

2XX 成功（Success）

2XXのレスポンスはリクエストが正常に処理されたことを示す。

200 OK

  • リクエストをサーバーが正常に処理したことを表す。

204 NO Content

  • リクエストに対する処理は成功しているが、レスポンスにエンティティボディが含まれない。
  • クライアントからサーバーに情報が送られるだけでよく、クライアントに新たな情報を送る必要がない場合に使われる

206 Partial Content

  • Rangeによって指定されたリクエストによって、サーバーが指定された部分的GETリクエストを受け付けたことを表す。
  • レスポンスはContent－Rangeで指定された範囲のエンティティが含まれる。

3XX リダイレクト(Redirection)

  • 3XXレスポンスは、リクエストが正常に処理を終了するためにブラウザー側で処理が必要な場合のレスポンス

301 Moved Permanently

  • リクエストされたリソースに新しいURIが割り当てられている場合のレスポンス
  • Locationヘッダーフィールドに新しいURIが指定される。

302 Found

  • リクエストされたリソースが一時的に新しいURIが割り当てられている場合のレスポンス

303 SeeOther

  • リクエストに対するリソールが別のURIにあり、GETメソッドで再取得を行ってほしい場合のレスポンス
  • 基本的には302 Foundと同じであるが、リダイレクト先をGETメソッドで取得することが明確になっている。

304 Not Modified

  • クライアントが条件付きリクエスト(GETメソッドによるリクエストメッセージにIF-Match, If-Modified, IF-None-Match, If-Range, If-Unmodiged-Sinceのいずれかがヘッダーフィールドを含んでいる場合のリクエスト)を行ったときアクセスは許可されたが、条件が満たされなかった場合のレスポンス
  • 3XXに部類されるがリダイレクトとは毛色が違う。

307　Temporary Redirect

  • 302 Foundと同じ意味を持つが？

4XX クライアントエラー

  • 4XXレスポンスは、クライアントが原因でエラーが発生していることを示す。

400 Bad Request

  • リクエストの構文が間違えていることを示している。
  • ブラウザーはこれを200 OKと同様に扱う（？）

401 Unauthoried

  • 送信されたリクエストには認証が必要であることを示す。
  • 2度目以降の401 Unautoriedのレスポンスは認証失敗を表す。
  • 401を含んだレスポンスを返す場合にはリクエストされたリソースに適用できるWWW-Authenticateヘッダーフィールドを含む必要がある。
  • ブラウザで最初に401レスポンスを受け取った場合は認証のためのダイアログが表示される。

403 Forbidden

  • リクエストされたリソースへのアクセスが拒否されたことを表す。
  • サーバー側は拒否の理由を明らかにする必要はない。
    • 明らかにする場合はエンティティボディに記載し、ユーザー側に表示する。
  • ファイルシステムのパーみんしょんが与えられていない場合や、アクセス権限の何らかの問題がある場合がある

5XX サーバーエラー

  • 5XXレスポンスはサーバーが原因でエラーが発生していることを示す。

500 Internal Server Error

  • サーバーがリクエストを実行する際にエラーが起きたことを示している。
  • Webアプリケーションにエラーがある場合や一時的な状態のこともある。

503 Service Unavailable

  • サーバーが一時的な過負荷、もしくはメンテナンスのため現在リクエストを処理できないことを表す。
  • 解消時間がわかっている場合はRetry-Afterヘッダーフィールドにその時間を記載し、クライアントに伝えることが望ましい。

HTTPと連携するWebサーバー

  • Webサーバーは1つのサーバーで複数のドメインを立ち上げることができる。
  • 通信の中継サーバーとして、通信効率を上げることができる。

1台で複数ドメインを実現するバーチャルホスト

  • HTTP/1.1では1つのサーバーに複数のWebサイトを立ち上げることができる。
  • バーチャルホストという機能を使いサーバー1台に対し仮想的に複数台あるように扱うことができる。
  • バーチャルホストの仕組みがあるため、HTTPリクエストを送る場合は、ホスト名、ドメイン名を完全に含んだURIの指定か、Hostヘッダーフィールドでの指定が必ず必要となる（DNSより、ドメイン名がIPアドレスに変換されてアクセスされるから）。（？）

通信を中継するプログラム : プロキシ、ゲートウェイ、トンネル

  • HTTPではクライアントとサーバー以外にプロキシ(Proxy)、ゲートウェイ(Geteway)、トンネル(Tunnel)といった通信を中継するプログラムやサーバーが存在する。
プロキシ(Proxy)
  • サーバーとクライアントの両方の役割をする中継プログラム
  • クライアントからのリクエストをサーバーに、サーバーからのレスポンスをクライアントに渡す。
ゲートウェイ(Geteway)
  • ほかのサーバーを中継するサーバーで、クライアントから受け取ったリクエストをリソースを持っているサーバーであるかのようにふるまう。
  • クライアントがゲートウェイであることを気が付かない場合がある。
トンネル(Tunnel)
  • 2つの離れたクライアントとサーバーの間で中継することで、2台の接続を取り持つ中継プログラム

プロキシ

  • 基本的なプロキシサーバーの動作はクライアントから受け取ったリクエストをURIを変更せずに別のサーバーに転送すること。
  • リソースを持ったサーバーのことをオリジンサーバーと呼び、オリジンサーバーからのレスポンスはまたプロキシサーバーを経由してクライアントに受け渡される。
  • HTTP通信においてプロキシサーバーは複数台経由することもできる。
  • 中継の際にはViaヘッダーフィールドにホストの情報を追加してゆく。
  • プロキシサーバーの役割
    • キャッシュを用いてネットワーク帯域などの効率をよくする。
    • 組織で特定のWebサイトに対してアクセス制限をかけたりログをとったりして、ポリシーをっ徹底させる目的として使用される。
キャッシングプロキシ
  • プロキシでレスポンスを中継する際に、プロキシサーバー上にリソースのコピーをキャッシュしておくタイプのプロキシ
透過型プロキシ
  • プロキシでリクエストやレスポンスを中継する際にメッセージに何も変更を加えないプロキシ
  • 逆にメッセージに何らかの変更を加えるタイプのプロキシを非透過型プロキシ

ゲートウェイ

  • 動作はプロキシによく似ている。
  • ゲートウェイの場合にはその先にあるサーバーはHTTPサーバー以外のサービスを提供するサーバーである。
リクエスト時:
クライアント⇒HTTPリクエスト⇒ゲートウェイ⇒HTTP以外の通信⇒HTTP以外のサーバー

レスポンス時:
HTTP以外のサーバー⇒HTTP以外の通信ゲートウェイ⇒HTTPリクエスト⇒クライアント
  • クライアントとゲートウェイ間を暗号化でセキュアに通信することで通信の安全性を高める役割などをしている。
  • 利用例
    • ゲートウェイがデータベースにSQLクエリを使ってデータを取得する。
    • クレジットカードの決済システムを連携する。

トンネル

  • 要求に応じで別サーバーとの通信路を確立する。
  • SSLなどによる暗号化通信を施し、クライアントとサーバーが安全に通信を行う目的で用いられる。
  • トンネルそのものはHTTPリクエストを解釈せずにそのまま先のサーバーに中継する。

リソースを保管するキャッシュ

  • キャッシュはプロキシサーバーやクライアントのローカルディスクに保存されたリソースのコピーのことを指す。
  • キャッシュを使うことでリソースを持ったサーバーへのアクセスを減らすことができる。
  • キャッシュサーバーはプロキシサーバーの一種でキャッシングプロキシに部類される。
  • キャッシュサーバーはオリジンサーバーからのレスポンスを中継する際にそのリソースをコピーして保存しておく。

キャッシュには有効期限がある。

  • キャッシュサーバーにキャッシュがあるからと言って、同じリソースへのリクエストに対して常にキャッシュを返すとは限らない。
  • クライアントからの要求やキャッシュの有効期間などによってオリジンサーバーに有効性を確認しに行ったり、新たなリソースを再度取得しに行ったりする。

クライアント側にもキャッシュがある。

  • キャッシュはキャッシュサーバーだけではなくクライアントが使用しているブラウザーが持っている場合もある。
  • キャッシュサーバーと同じくリソースが古いと判断した場合はオリジンサーバーに有効性を確認しに行ったり、新たなリソースを再度取得しに行ったりすることがある。

6章 HTTPヘッダー

HTTPメッセージヘッダー

  • HTTPプロトコルのリクエストとレスポンスには、必ずメッセージヘッダーがある。
メッセージヘッダー
空行(CR+LF)
メッセージボディ
リクエストメッセージヘッダの構成
  • リクエストライン
    • メソッド
    • URI
    • HTTPバージョン
  • リクエストヘッダーフィールド
  • 一般ヘッダーフィールド
  • エンティティーヘッダーフィールド
  • その他
レスポンスメッセージヘッダの構成
  • ステータスライン
  • レスポンスヘッダーフィールド
  • エンティティヘッダーフィールド
  • その他

HTTPヘッダーフィールド

HTTPヘッダーフィールドは重要な情報を伝える

  • リクエストにもレスポンスにも使われており重要な情報を伝える役割を果たしている。
  • メッセージボディのサイズや、使用している言語、認証情報などをブラウザやサーバーに提供するために使用される。

HTTPヘッダーフィールドの構造

  • HTTPヘッダーフィールドはヘッダーフィールド名とフィールド値から構成されコロンで区切られている。
ex.
ヘッダーフィールド名：フィールド値
Content-Type:text/html
  • ヘッダーフィールド名はUS-ASCII文字で構成される。
  • フィールド値は1つのヘッダーフィールドに対して複数持つことができる。

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

  • HTTPヘッダーフィールドはその用途に合わせて4種類に分類される。
一般ヘッダーフィールド
  • HTTPヘッダーフィールドは、リクエストとレスポンスその両方で使用されるヘッダー
リクエストヘッダーフィールド
  • クライアント側からサーバー側に対して送信されるリクエストメッセージに使用されるヘッダー
  • リクエストの付加情報やクライアントの情報、レスポンスのコンテンツに関する優先度などを付加します。
レスポンスヘッダーフィールド
  • サーバーからクライアント側に対して送信されるレスポンスメッセージで使用されるヘッダー
  • レスポンスの付加情報やサーバーの情報、クライアントへの付加情報などの要求などを付加する。
エンティティヘッダー
  • リクエストメッセージとレスポンスメッセージに含まれるエンティティに使用されるヘッダー
  • コンテンツの更新時間などエンティティに関する情報を付加する。

エンドトゥエンドヘッダーとホップバイホップヘッダー

エンドトゥエンドヘッダー＊
ポップバイポップヘッダー＊

　HTTTP/1.1ヘッダーフィールド

  • リクエストとレスポンスどちらでも利用されるヘッダー

Chashe-Control

  • ディレクティブと呼ばれるコマンドを指定することでキャッシュの動作を指定する。
  • 指定するディレクティブにはパラメーターがある元のないものがある
  • 複数のディレクティブを指定する場合はカンマ","で区切る

Chashe-Control

キャッシュリクエストディレクティブ
ディレクティブ パラメーター 説明
no-chache なし オリジンサーバーへの強制的な再検証
no-store なし キャッシュはリクエスト、レスポンスの一部を保存してはいけない
max-age＝[秒] 必須 レスポンスの最大Age値
max-stale＝[秒] 省略可能 期限切れのレスポンスを受け入れる
min-fresh＝[秒] なし 指定した時間は新鮮さがあるレスポンスを望む
no-transform なし プロキシはメディアタイプを変換してはならない
only-if-chached なし キャッシュからリソースを取得
chach-extension - 新しいディレクティブのためのトークン
キャッシュレスポンスディレクティブ
ディレクティブ パラメーター　 説明
public なし どこかにレスポンスキャッシュが可能
private 省略可能 特定のユーザーに対してのみレスポンス
no-chach 省略可能 有効性の再確認なしではキャッシュは使用してはならない
no-store なし キャッシュはリクエスト、レスポンスの一部を保存してはならない
no-transform なし プロキシはメディアタイプを変更してはならない
must-revalidate なし キャッシュは可能だが、オリジンサーバーにリソースの再確認を要求する
proxy-revalidate なし 中間キャッシュサーバーに対し、キャッシュしたレスポンスの有効性を再確認を要請
max-age=[秒] 必須 レスポンスの最大Age値
s-maxage=[秒] 必須 共有キャッシュサーバーのレスポンス最大Age値
cache-extension - 新しいディレクティブのためのトークン(？)

Connection

  • Connectionヘッダーフィールドには2つの役割がある。
    • プロキシに対してそれ以上転送しないヘッダーフィールドの指定
      • Connection:"それ以上転送しないヘッダーフィールド名"
    • 持続的接続の管理
持続的接続の管理に使われるフィールド値
Connecitonのフィールド値 説明
Close HTTP/1.1で持続的接続がデフォルトになっているため、明示的に接続を閉じたい場合に使用する
Keep-Alive HTTP/1.1以前のバージョンで持続接続がデフォルトでないため、明示的に持続接続を行うためのフィールド値

Trailer

  • メッセージボディの後に記載されているヘッダーフィールドをあらかじめ伝えることができる。

Transfer-Encoding

Via

  • プロキシ、もしくはゲートウェイにおいて自サーバーの情報をViaヘッダーフィールドに追加する
  • 経路を知るために使用される。

Warning

  • レスポンスに関する追加情報を伝える
  • 基本的にはキャッシュに関する問題の警告をユーザーにつたえる。
  • Warning:[警告コード] [警告したホスト:ポート番号] "[警告文]" ([日時])
コード 警告文 説明
110 Response is stale プロキシが有効期限切れのリソースを返した
111 Revalidation failed プロキシがリソースの有効性の再確認に失敗した
112 Disconnection operation プロキシがネットワークから恋に切断されている
113 Heuristic Expriration レスポンスが24時間以上経過している場合（キャッシュの有効期限が24時間以上に設定している場合）
199 Miscellaneous waring 任意の警告文
214 Tranceform applied プロキシがエンコーディングやメディアタイプなどに対して何らかの処理を行った場合
Miscellaneous persistent waring 任意の警告文

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

  • クライアント側からサーバー側に対して送信される。
  • リクエストの付加情報やクライアントの情報、レスポンスのコンテンツに関する優先度などを付加します。

Accept

  • ユーザーエージェントが処理することができるメディアタイプと、メディアタイプの相対的な優先度を伝えるために使用される。
  • メディアタイプ一覧
    • テキストファイル
      • text/html, text/plain, test/css....
      • application/xhtml+xml,application/xml
    • 画像ファイル
    • 動画ファイル
    • アプリケーション用バイナリファイル
      • application/octet-stream....

Accept-Charset

  • ユーザーエージェントが処理することができる文字セットと、文字の相対的な優先度を伝えるために使用される。
  • 文字セットは一度に複数扱うことが可能
  • サーバー駆動型ネゴシエーションに利用される

Accept-Encoding

  • ユーザーエージェントが処理することができるコンテンツコーディングとコンテンツコーディングの相対的な優先度を伝えるために使用される。
  • コンテンツコーディングは一度に複数指定できる。
  • Acceptヘッダーフィールドと同じで品質係数によって相対的な優先度を指定する。
  • "＊" (ワイルドカード)を指定するとあらゆるエンコーディングフォーマットを示す。
  • コンテンツコーディングの例

Accept-language

  • ユーザーエージェントが処理することのできる自然言語セットと、自然言語の相対的な優先度を伝えるために使用される。
  • 自然言語の指定は一度に複数扱うことが可能

Authorization

  • ユーザーエージェントの認証情報を伝えるために使用される。
  • ステータスコード401レスポンスの後、リクエストにこのヘッダーフィールドを含める。

Expect

  • クライアントがサーバーに特定の振る舞いを要求していることを伝える。
    • 期待に応えられない場合は417 Expectation Failedを返す。
  • クライアントは希望する拡張をこのヘッダーフィールドで伝えることができる。
  • ステータスコード100レスポンスを待つクライアントは、リクエスト時にExpect 100-continueと指定する必要がある。

From

  • ユーザーエージェントを使っているユーザーのメールアドレスを伝える。
  • エージェントを使用する場合はなるべく使うべきである(？)
  • User-Agentヘッダーフィールドにメールアドレスを含んでいるものもある。

JJUG CCC fall 2017の感想

JJUG CCC 2017 Fall

　初めて、こういうような技術系のイベントに参加してきました。正直、Javaどころか、技術の知識もからっきしだったのでついていけるか不安だったんですが、初心者向けのセッションなどもあり楽しめました。
まぁ、それでもわからないことも多かったですが....
学ばなければいけないことが多いなぁ...とさらに実感しました。
　
　ところで、ブログを書くに至った経緯ですが、職場の大先輩に『こういうイベントは感想ブログをまで書いて参加したといえる』と教わり（正確には、その大先輩もそう教わったと言われ）今回ブログを書いてみることにしました。誰かに見てもらうというよりは自分の頭の中の整理に使うということを目的としてます。ただ、もし読んでくれる酔狂な人がいて、なんか間違っていることとか優しく指摘をしていただける方がいると泣いて喜びます。

今回は以下のセッションを見てきました。

明るい話口調で、強弱がありわかりやすい話し方をされている印象でした。お話の内容は『知る』と『出す』このサイクルが大切であるというもの。『知る』は『出す』につながり、また、『出す』ことで『知る』こともある。このサイクルを何度も繰り返すことが成長につながるというお話をされていました。そして、コミュニティはそのサイクルを回すのにうってつけの場所のようです。
個人的に印象に残った点は『知る』ことの1つに『自分を知る』ということを挙げていたこと、あまり、『自分を知る』ということを考えてなかったのですが、お話を聞いて改めで重要なことだなと思いました。
年齢も経験も関係ない！ステップアップするためのJavaコミュニティ活用術 // Speaker Deck

アサーションが書けるJavaライブラリであるAssertJの話をされていました。Junitやhamcrestにもまだあまり知識がなく、少しお話は難しく感じましたが。AssertJを使った場合とJunitのみの場合の比較で話を進めていて、『きれいにわかりやすく書ける』とことがAssertJのメリットだと強調されていました。知識があれば、もっとこのメリット感を理解できたに違いない...と少し悔しい思いをしながら話を聞いていました。
ユニットテストのアサーション 流れるようなインターフェースのAssertJを添えて 入門者仕立て

『作りたいものを作る』という呪縛。この方が発表で、おっしゃっていたことはまさに僕自身が無意識のうちにかかっていた呪縛でした。発表はまず『技術』とは『コードを読む力のことである』と、まずこの発表での『技術』を決めてしまい、ではその技術を上げるということのゴールとして『OCJP（Oracle Certified Java Programmer）』を挙げておられました。OCJPを受けるとどのようなことが勉強でき、だから『技術』が伸びるっという話がきれいにつながっていました。この方のセッションは本当にわかりやすく、スライドの作り方などの勉強にもなりました。あと、OCJPも機会があれば受けてみようと思います。値段が高いのが難点ですが....
JJUG CCC 2017 fallに登壇してきた - 無駄かもしれない足掻き

JavaのVersionのお話でした。どのバージョンでどんな機能が追加され、どのようにJavaは進化したのかという話を『CSVを読み込んで、標準出力に出す』という簡単なプログラムを用いてVersionが上がるごとにどこが書き換わるのかを示しながら話をされていました。とてもわかりやすかったです。最後にはJavaの今後の話もされていて勉強になりました。
Java9を迎えた今こそ！Java本格(再)入門

個人的に一番興味があったセッションでした。その理由がDocker個人的に今一番興味がある技術の1つです。まぁ、興味があるとはいえ何も知らないんですけどね....笑
ですので、このセッションでぜひとも勉強しようと考えていたのですが。デモでトラブルが起こってしまったみたいで、あまりきちんとお話を聞くことができなかったです。時間があるときに資料を見直してみようと思います。
Dockerで始める Java EE アプリケーション開発 for JJUG CCC 2017

Eclipse Collectionsか...そもそもStrem APIもつかいこなせてないからな...という感想です。もっと勉強していればメリットなどもきちんと理解できたのかもしれませんが....すみません。どうもStrem APIより効率がいいらしいのですが...
JJUG CCC 2017 Fall に参加した - nashcft's blog


  • G+H 『Javaが「書ける」から「できる」になれる！メモリ節約ノウハウ話』猪鼻哲也さん

細かい無駄を省いてメモリ消費を抑える。そういった話をされていましたが。正直、私には早すぎた気がします。お話の半分も理解できませんでした...精進します。



どのセッションも非常に勉強になりました。貴重なお話をありがとうございました。次のJJUG CCCも参加させてもらおうと考えてます。