1 / 64

情報処理 II www による情報発信とサービス提供 I

情報処理 II www による情報発信とサービス提供 I. 第 12 回 2014 年 7 月 3 日 大塚 智宏. 本日の予定. HTTP による Web サーバとの通信（１） TCP/IP ネットワーク入門 HTTP の基礎 Web サーバと通信してみよう 今回の課題. 前回 までの 課題について. 第 7 回課題 採点して返却しました 授業 支援でテキストファイルをダウンロードしてください ファイル先頭の学籍番号が間違っていないか確認してください 再提出の指示があった人は早めに再提出を 第 9 回 課題 採点中なのでもう少しお待ちください

tallulah-ross
Download Presentation

情報処理 II www による情報発信とサービス提供 I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 情報処理IIwwwによる情報発信とサービス提供I 第12回 2014年7月3日 大塚 智宏

  2. 本日の予定 • HTTPによるWebサーバとの通信（１） • TCP/IPネットワーク入門 • HTTPの基礎 • Webサーバと通信してみよう • 今回の課題

  3. 前回までの課題について 第7回課題 採点して返却しました 授業支援でテキストファイルをダウンロードしてください ファイル先頭の学籍番号が間違っていないか確認してください 再提出の指示があった人は早めに再提出を 第9回課題 採点中なのでもう少しお待ちください 第11回課題 7/11（金） 23:59 締切です

  4. チェックツールの使用（１） • 「miChecker」 をダウンロードして使ってみる • http://www.soumu.go.jp/main_sosiki/joho_tsusin/b_free/miChecker_download.html • 「4. miCheckerのダウンロード」 のところからZipファイルをダウンロードし，「マイ ドキュメント」 以下に展開 • 「miChecker」⇒「miChecker.exe」を実行 • チェックの実行 • 左上のアドレスバーにURIを入力して 「移動」 • 「アクセシビリティ検証・視覚化」 ⇒ 「アクセシビリティ検証・音声ユーザビリティ視覚化」 を実行 • 下部に検証結果が，右側には音声ユーザビリティの視覚化結果が表示される

  5. チェックツールの使用（２） • 「Check My Colours」 を利用してみる • http://www.checkmycolours.com/ • チェックの実行 • アドレスバーにURIを入力して 「Check」 • HTMLの要素ごとに背景色と文字色のコントラストを検証し，結果を表示してくれる

  6. チェックツール使用上の注意 • チェック対象の範囲に注意する • フレームを使っているページは，フレーム内の個々のページまでは対象にならない場合がある • そもそもフレームは使うべきではないが… • すべてのページを個別にチェックするのが望ましい • すべての問題点を指摘してくれるわけではない • 自動化されたツールでは発見困難なものもある • ツールだけで済まさず，人手でもチェックすることが重要

  7. TCP/IPネットワーク入門

  8. Webの基本的な構造 • Webの3要素 • URI： 情報の 「場所」 を表現 • HTML： 情報の 「中身」 を表現 • HTTP： 情報の 「交換方式」 を定義 ユーザエージェント （Webブラウザなど） HTMLファイル sample.html URI （URL） http://www.hoge.com/sample.html Hello! <html> <head> <title>Sample</title> </head> <body> <p>Hello!</p> </body> </html> HTTP (HyperText Transfer Protocol) Web サーバ www.hoge.com Web クライアント インターネット PC，携帯電話など

  9. 「インターネット」 とは？ • "internet" と "the Internet" は違う • internet • 複数のネットワークを相互接続するためのネットワークのこと • the Internet • "internet" のうち，地球規模で接続・運用されている世界最大のネットワークの呼称 （固有名詞的に使われる） • 日本語の 「インターネット」 は通常こちらを指す • 1990年代のWebの普及によって爆発的に利用が増加，規模拡大 • 接続している組織がそれぞれのネットワークを管理している （ことになっている） • IPアドレス，ドメイン名等の共用リソースの一部はICANN等の国際機関が管理している • 通信方式として 「TCP/IPプロトコルスイート」 が使われる

  10. インターネットができるまでの話（１） • 昔のネットワーク （1980年代以前） • 大型計算機用ネットワーク，パソコン通信のネットワーク • 各ネットワークは独立しており，互いに通信できなかった • 物理的に接続する機能がない • 通信の方式が違う • 通信相手を特定することができない 大型計算機 パソコン通信 ホストサーバ 独自の ネットワーク 電話回線 端末 端末 端末 PC PC PC

  11. インターネットができるまでの話（２） • 異なったネットワーク同士を接続するには？ • 共通の通信方式，および通信相手の指定方法が必要 • TCP，IPをはじめとする各種プロトコルの誕生 • 複数のネットワークを物理的に接続する装置が必要 • IPの 「パケット交換」 を行う装置 （ルータ） の登場 ？ 大型計算機 パソコン通信 ホストサーバ 独自の ネットワーク 電話回線 端末 端末 端末 PC PC PC

  12. インターネットの誕生 • ネットワークのネットワーク （the Internet） • 特定メーカの機器や接続方式に依存しないネットワーク • 「IPアドレス」 による通信先の指定方法の統一 • TCP，IPやその上位プロトコルによる通信方式の統一 • やがて，世界中の端末が互いに通信を行うことが可能に インターネット ルータ ルータ TCP/IP A社 ネットワーク B社 ネットワーク サーバ PC PC サーバ PC PC 192.168.1.2 172.16.3.4

  13. インターネットの普及 • インターネットの誕生による需要喚起 • 接続機器・方式に依存しない汎用ネットワーク • 国境を越えて成長する大規模ネットワーク • 各種アプリケーションの誕生 • 電子ニュース，電子メール，ファイル共有，情報検索 • Web （World Wide Web，WWW） の誕生 （1991年） • 誰もが世界中に情報を発信することが可能に • 1990年代の爆発的なWebの普及 • インターネット＝Webのような誤用が広まるまでになった • 2000年代以降のさらなる発展 • 各種Webサービスの普及，Web利用端末の多様化 • 誰もが双方向に情報をやり取りする時代へ

  14. TCP/IPとは • インターネットで使われる通信プロトコル群の総称 • 非常に多くのプロトコルが含まれるが，最初期に作られた最も重要なプロトコルであるTCPとIPにちなんで 「TCP/IP」 と呼ばれる • インターネットプロトコルスイート，などとも呼ばれる • TCP/IPの階層 • 上位のプロトコルは，相手先との通信を行うために下位のプロトコルを用いる アプリケーション層 HTTP，FTP，SMTP等 アプリケーション層 トランスポート層 TCP，UDP等 トランスポート層 インターネット層 IP等 インターネット層 リンク層 Ethernet，Wi-Fi等 リンク層

  15. IP （Internet Protocol） • インターネット上で，情報を通信相手に送信および受信する役割を担うプロトコル • 情報は，「パケット」（データグラム） と呼ばれる小さな単位に分割されて送信される • パケットは，発信者・受信者情報等を格納した 「IPヘッダ」 と，実際の通信内容を格納した 「ペイロード」 とで構成される • 情報の発信者（送信元），受信者（送信先）は，「IPアドレス」 によって識別される • 現在は IPv4 （IPバージョン4） と IPv6 （IPバージョン6）が主に利用されている • IPv4のIPアドレスは 「枯渇した」 ため，長期的にはIPv6へ移行することを前提にいろいろな対応策が考えられている • IPv6については今回は省略

  16. IPアドレス（１） • IPで用いられる，通信主体（発信者，受信者）を識別するための仮想的な番号 • インターネット上でユニーク（唯一）なIDとして使われる • 同じIPアドレスを持つ端末は存在しない，というのが前提 • ICANNを頂点とする 「インターネットレジストリ」 と呼ばれる組織が管理・割当てを行っている • IPアドレスのことを 「IP」 と呼ぶ場合があるが，正確ではない • IPv4のIPアドレスは32ビット（2進数32桁）の整数で表され，通常は以下のように8ビットずつ . で区切って表記する • 131.113.134.163 （16進数で表すと 837186ad） • 232 = 4,294,967,296 （約43億） 個の端末を識別できる • 同じネットワーク内の通信では，IPアドレスを物理アドレス（MACアドレス）に変換してから通信を行う • ARPというプロトコルを使う （詳細は略）

  17. IPアドレス（２） • IPアドレスは，ネットワーク部とホスト部に分かれる • ネットワーク部： ネットワークを識別 • ホスト部： ネットワーク内の個々の機器を識別 • 「サブネットマスク」 を用いてこれらを区別する • 例） 192.168.4.15 で，ネットワーク部が24ビットの場合 • IPアドレスやネットワークアドレスの表記では，/ で区切ってネットワークアドレス長を付加することも多い • 上記の例だと，192.168.4.15/24 や 192.168.4.0/24 となる 192.168.4.15 255.255.255.0 ネットワーク部 ホスト部 サブネットマスク（16進数： ffffff00） 192.168.4.0 0.0.0.15 ネットワークアドレス ホストアドレス

  18. IPアドレス（３） • その他にも以下の概念があるが，ここでの説明は省略 • アドレスクラス，CIDR • ブロードキャストとマルチキャスト • グローバルIPアドレスとプライベートIPアドレス

  19. ルーティングの概念 • ネットワークの交通整理を行うのがルーティング • 交差点の案内標識 ⇒ ルーティングテーブル 131.113.5.0 内部 131.113.215.0 C 131.113.11.0 B それ以外 D 上流ネットワークへ D ネットワーク 131.113.5.0 131.113.215.57 宛パケット C A B E ネットワーク 131.113.11.0 ネットワーク 131.113.215.0 131.113.11.0 内部 それ以外 A 131.113.215.0 内部 それ以外 E

  20. ルータとルーティング • 複数のネットワークを相互に接続し，ルーティングを行うのがルータと呼ばれる装置 131.113.5.0 131.113.5.1 131.113.215.0 131.113.5.3 131.113.11.0131.113.5.2 それ以外 131.113.4.1 131.113.4.1 上流ネットワークへ ルータ Y 131.113.5.1 ネットワーク 131.113.5.0 131.113.5.3 131.113.215.57 宛パケット ルータ X ルータ Z 131.113.11.1 131.113.215.1 131.113.5.2 ネットワーク 131.113.11.0 ネットワーク 131.113.215.0 131.113.11.0131.113.11.1 131.113.215.0 131.113.5.3 それ以外 131.113.5.1 131.113.215.0 131.113.215.1 それ以外 131.113.5.1

  21. IPでできないこと • 「機器間」 の通信しか定義されていない • 一般に，1台のコンピュータ上では複数のプログラムが動作しているが，それらを識別する方法がない • 送信したデータが相手に届いたかどうかが分からない • ネットワークの混雑等によって途中でパケットが失われたり，到着したとしても順序が入れ替わってしまう場合があるが，それを確認する手段がない • これらを解決するのが，上位層（トランスポート層）のプロトコルであるTCPおよびUDP

  22. ポート番号 • コンピュータ上で動いている特定のプログラムを通信相手として指定するための仮想的な番号 • プロトコルがTCPかUDPかによっても区別される • プログラムとポート番号との対応付けは，OSが行う • よく使われるプロトコルでは，例えばHTTPならTCPの80番ポート，というように一般的に利用される番号が決まっている • 「ウェルノウンポート」 と呼ばれる • サーバに対して通信を開始する際に便利 • 1023番以下に分布し，IANAという組織が管理している 79 プログラム httpd 80 172.16.3.2 の TCP/80番ポート 81 ネットワーク プログラム プログラム 82 83 172.16.3.2

  23. UDP （User Datagram Protocol） • IP上で動作し，ポート番号によって送信側，受信側の機器内のプログラムを指定できるようにしたプロトコル • TCPのように信頼性のある通信は提供しない • 送達確認や順序制御の機能はなく，IPと同様にパケットが失われたり順序が入れ替わってしまう可能性がある • しかし，（場合にもよるが）複雑な手順がない分だけ転送の効率が高まるため，効率を重視したり，多少データが抜け落ちても問題ないような上位プロトコルに利用されている • DNS，NTP，DHCP，SNMP等の一部機能 • 音声や動画のストリーミング配信 （VoIP，MPEG-TS 等） Internet プログラム P プログラム Q a b A.B.C.D E.F.G.H

  24. TCP （Transmission Control Protocol） • IP上で動作し，ポート番号による機器内のプログラム指定に加え，通信相手との信頼性のある通信を提供するプロトコル • 通信相手との間に仮想的な通信回線を作成する （「接続」） • プログラムからは，回線を占有しているように見える • 送達確認，順序制御などの複雑な処理を行っている • そのため，UDPに比べると転送効率の面では劣る（場合が多い） • 多くの一般的な上位プロトコルに利用されている • HTTP，FTP，SMTP，POP，IMAP，SSH，Telnet 等 仮想的な双方向通信回線 Internet プログラム P プログラム Q a b A.B.C.D E.F.G.H

  25. URI（復習） • インターネット上のリソースを特定するための識別子（Uniform Resource Identifier） • Webをはじめとするさまざまなサービスで使用される • Webで使われるURIは，以下の3つで構成される • スキーム （http, ftp, file等のプロトコル名が使われる場合が多い） • ホスト名 • パス名 http://www.keio.ac.jp/index.html httpwww.keio.ac.jp /index.html スキーム ホスト名 パス名

  26. ホスト名とドメイン名 • インターネットにおいて，個々のコンピュータを識別するための 「名前」 およびその一部 • 「ホスト名」 と 「ドメイン名」 は同じものと考えてよい場合が多いが，状況によって使い分けることもある . uk jp com net co ac ne keio www.keio.ac.jp www

  27. ドメイン名の割当てと登録 • ドメイン名は，ICANNをはじめとするさまざまな機関等によって統一的に管理されている • 例えば，ドメイン名 「keio.ac.jp」 は慶應義塾によって管理されているが，これは 「ac.jp」 を管理しているJPRSから管理権限を委譲されているためである • 同様に，JPRSはICANNから 「jp」 の管理を委譲されている • なお，この意味で使う場合 「ホスト名」 とは言わない . uk jp com net co ac ne keio

  28. DNS （Domain Name System） • インターネット上のコンピュータ（機器）の 「名前」 であるドメイン名（ホスト名）と，「番号」 であるIPアドレスの対応付けを管理するためのシステム • 世界に13個ある 「ルートサーバ」 を頂点とする階層的な分散型データベースとなっている • 各組織は，管理権を持つドメイン名に対応するデータベースを保持しており，それを 「ネームサーバ」 上で公開する • ルートサーバは，ネームサーバの親玉のようなもの • クライアント （情報を必要とするコンピュータ） は，ネームサーバに以下の問合せを行い，情報を取得する • ホスト名 ⇒ IPアドレス の変換 （正引き） • IPアドレス ⇒ ホスト名 の変換 （逆引き） • メールサーバの情報，ネームサーバ自体の情報，など

  29. ホスト名解決の仕組み • 実際には 「キャッシュ」 等の機構によってもう少し効率的に処理が行われる • ちなみに，DNSが登場する前の時代は，すべてのドメイン名とIPアドレスの対応を保持する 「すごいサーバ」 が全部処理していた ルート サーバ .担当 (2) www.keio.ac.jp? (1) www.keio.ac.jp? (3) .jp なら Aに聞いて 近場の ネーム サーバ (4) www.keio.ac.jp? クライアント ネーム サーバ A ac.jp なら Bに聞いて .jp担当 131.113.215.57 (10) (5) (9) www.keio.ac.jp? 131.113.215.57 www.keio.ac.jp? (6) (8) ネーム サーバ B .keio.ac.jp 担当 ネーム サーバ C .keio.ac.jp なら Cに聞いて .ac.jp担当 (7)

  30. HTTPの基礎

  31. Webページ閲覧時の処理の流れ（１） ユーザがWebブラウザに対し，閲覧したいページのURIを伝える URIを打ち込む，ブックマークを開く，リンクを辿る，等 例として http://www.keio.ac.jp/index.htmlを仮定 ブラウザは，ホスト www.keio.ac.jp のIPアドレスをDNSを参照（正引き）して取得する 実際のDNSの参照は，OSが補助する場合が多い 結果として 131.113.134.20 を得る ブラウザは，ホスト 131.113.134.20 の80番ポートに対してTCPの接続を確立する 特に指定がない場合，HTTPではTCPの80番ポートを使う サーバ側では，Webサーバプログラムが呼び出される

  32. Webページ閲覧時の処理の流れ（２） ブラウザとWebサーバは，確立されたTCP接続上でHTTPプロトコルのメッセージをやり取りする ブラウザが，取得したいリソースの絶対パス（/index.html）をリクエストメッセージとして送る サーバは，対応するリソース（HTMLファイル）をレスポンスメッセージとして送り返す ブラウザは受信したHTMLを解析し，追加で必要なリソース（外部CSSや画像ファイル等）があればさらにリクエストメッセージを送って取得する ブラウザは，取得したリソース群（HTML+CSS等）を解析し，レンダリングして画面に表示する 実際には，受信したリソース群はキャッシュとして一旦メモリやディスクに保存されるのが普通

  33. HTTP （HyperText Transfer Protocol） • Webにおいて，ブラウザとWebサーバの間でHTML等のコンテンツの送受信に用いられるプロトコル • リクエスト-レスポンス型（後述）のプロトコル • トランスポート層にはTCPを用い，サーバ側はデフォルトで80番ポートを使用する • HTTPのバージョン • HTTP/0.9 （1989年） • HTTP/1.0 （1996年，RFC 1945） • ヘッダの導入等，0.9から大幅に拡張された • HTTP/1.1 （1997年，RFC 2068） • キープアライブやバーチャルホスト機能等，1.0をさらに拡張 • その後改訂されてRFC 2616 （1999年） となっていたが，2014年6月に約15年ぶりに改訂され，RFC 7230～7235 となった

  34. クライアント-サーバモデル • 通信を行うコンピュータを 「サーバ」 と 「クライアント」 に分類し，クライアントがサーバに要求を送信してサーバがそれに応答を返す形で処理を行う通信方式 • この方式で処理が行われるプロトコルは 「リクエスト-レスポンス型」 のプロトコルと呼ばれる • HTTP，SMTP等，多くのプロトコルがこの方式を採用している • 他の方式としては，ピアツーピア（P2P）がある <html> <head> <title>Sample</title> </head> <body> <p>Hello!</p> </body> </html> Hello! 要求（HTTPリクエスト） Web サーバ Web クライアント 応答（HTTPレスポンス）

  35. HTTPリクエスト • クライアントからサーバに送信する要求メッセージ • リクエスト行，（複数の）ヘッダ，ボディで構成される • リクエスト行 = 「メソッド URI バージョン」 • リクエストの内容，および要求対象のリソース（ファイル）を示す • ヘッダ = 「ヘッダ名: 内容」 • リクエスト内容やクライアントに関する追加情報 • 改行で区切って複数（必要なだけ）記述できる • ボディは特定のメソッドでデータを送信するのに使われる リクエスト行 リクエスト行 GET /index.html HTTP/1.1 Host: www.keio.ac.jp ... ヘッダ（必要なだけ） ・・・ <空行> ヘッダ 空行 ボディ（必要な場合） ・・・

  36. メソッド • HTTPリクエストの種類を表す識別子 • GET： リソースの取得 • 最も頻繁に使用されるメソッド • URIに含める形でデータを送信することも可能 （クエリ文字列） • HEAD： ヘッダのみの取得 • GETと同様リソースを要求するが，ヘッダのみが返送される • ページの更新状況のみを確認したい場合などに使われる • POST： データの送信と処理要求 • ボディとしてデータを送信し，URIで指定したリソースに渡す • 入力データをCGIプログラム等に処理させる場合に使われる • その他 （詳細は略） • PUT，DELETE，OPTIONS，TRACE，CONNECT，PATCH • メソッドは全て大文字で書かなければならない点に注意

  37. HTTPレスポンス • サーバからクライアントに送信する応答メッセージ • ステータス行，（複数の）ヘッダ，ボディで構成される • ステータス行 = 「バージョン ステータスコード 説明句」 • レスポンスの意味 （成功，失敗，エラー等） を表す • ヘッダ = 「ヘッダ名: 内容」 • レスポンス内容やサーバに関する追加情報 • 改行で区切って複数（必要なだけ）記述できる • 要求されたリソースはボディ部分に格納される ステータス行 ステータス行 HTTP/1.1 200 OK Content-Type: text/html Content-Length: 795 ... <!DOCTYPE html> ... ヘッダ（必要なだけ） ・・・ <空行> ヘッダ 空行 ボディ（必要な場合） ・・・ ボディ

  38. ステータスコード（１） • HTTPレスポンスの意味を表す3桁の番号 • 対応する説明句とセットでステータス行に含められる • 「HTTP/1.1 404 Not Found」 等 • 100の位の値によって5種類に分類される • 1XX： 情報提供 • 2XX： 成功 • 3XX： 転送 • 4XX： クライアント側のエラー • 5XX： サーバ側のエラー

  39. ステータスコード（２） • 主なステータスコード • 200 OK • 「リクエストは成功した」 • 要求されたリソースがボディとして送信される • 301 Moved Permanently • 「リソースは恒久的に移動した」 • Locationヘッダで移動先が通知され，通常はブラウザが移動先を指定して再度リクエストを行う （ページは自動的に転送される） • 304 Not Modified • 「リソースは更新されていない」 • If-Modified-Sinceヘッダによる条件付きGETにおいて，リソースが更新されていない場合など

  40. ステータスコード（３） • 主なステータスコード（続き） • 401 Unauthorized • 「リソースの参照には認証が必要」 • 認証情報を付加して再度リクエストを行う必要がある • 403 Forbidden • 「サーバが実行を拒否した」 • 閲覧権限のないリソースを要求した場合など • 404 Not Found • 「リソースが存在しない」 • URIが間違っている場合など • 500 Internal Server Error • 「サーバの内部エラー」 • CGIプログラムの実行に失敗した場合など

  41. ヘッダ • HTTPリクエストやレスポンスにおいて，さまざまなメタ情報をやり取りするためのフィールド • 1行に1つずつ，「ヘッダ名: 内容」 の形で必要な数だけ記述 • ヘッダ群の後ろ（ボディの前）には空行を入れる • 以下の4種類に分類される • リクエストヘッダ • HTTPリクエストで使用され，リクエストやブラウザに関する情報を送る • レスポンスヘッダ • HTTPレスポンスで使用され，レスポンスやサーバに関する情報を送る • エンティティヘッダ • レスポンスやPOSTメソッドによるリクエストなどで使用され，転送されるリソース（ボディ）に関する情報を送る • 一般ヘッダ • リクエスト／レスポンスの両方で使用され，上記以外のさまざまな情報を送る

  42. 主なリクエストヘッダ（１） Host リクエストURIのホスト名（ポート番号が80以外の場合はそれも指定） 例： Host: www.keio.ac.jp 例： Host: proxy.example.com:8080 リクエストで唯一の 「必須」 ヘッダ User-Agent ユーザエージェント（UA，ブラウザ）の種類やバージョン 例： User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:30.0) Gecko/20100101 Firefox/30.0 UAによるページの振り分けやスタイルの切替え等に利用される Referer リクエストURIの参照元ページのURI （リンク元） 例： Referer: http://www.keio.ac.jp/ アクセス解析などに利用される

  43. 主なリクエストヘッダ（２） If-Modified-Since 条件付きリクエスト （指定時刻以降にリソースが更新されている場合のみリソースが返送される） 例： If-Modified-Since: Wed, 2 Jul 2014 07:23:31 GMT 更新されていない場合，304 Not Modified が返される Last-Modified との組合せでキャッシュの制御に利用される キャッシュ制御では，ETag と If-None-Match の組合せもよく使われる Range リソースの一部のみを要求 例： Range: bytes=512- （最初の512バイトを除いた残りの部分） Authorization 認証情報 （認証方式によって内容は異なる） 例： Authorization: Basic bmV0Om5ldDEyMwo=

  44. 主なレスポンスヘッダ Server Webサーバソフトウェアの種類やバージョン 例： Server: Apache/2.4.9 (Unix) Location 移動したリソース等の新しい場所を示す 例： Location: http://www-new.example.com/ 301 Moved Permanently 等に付随して送信される WWW-Authenticate 認証を要求し，認証方法とそのパラメータを指定 例： WWW-Authenticate: Basic realm="Member Only" 401 Unauthorized に付随して送信される

  45. 主なエンティティヘッダ Content-Type ボディとして送信されるリソースのメディアタイプを示す 例： Content-Type: text/html; charset=utf-8 Content-Length ボディ部分の長さ（サイズ）をバイト単位（10進数）で示す 例： Content-Length: 795 Last-Modified リソースの最終更新時刻（日時） 例： Last-Modified: Wed, 2 Jul 2014 07:23:31 GMT If-Modified-Since で時刻を指定する際などに利用される

  46. 主な一般ヘッダ Date メッセージが作成された日時 例： Date: Thu, 3 Jul 2014 16:43:46 GMT Connection TCP接続に関するオプションを指定 例： Connection: close HTTP/1.1 ではキープアライブ（次回説明）がデフォルトのため，明示的に接続を終了する際はリクエストで上記のように指定する Cache-Control クライアント側のキャッシュ制御に関するオプションを指定 例： Cache-Control: no-cache, no-store

  47. HTTP/2.0 （参考） • 現在，次世代のHTTPであるHTTP/2.0の開発がIETFで進められている • HTML 4.01等と同様，HTTP/1.1が現在のWebの進化に対応しきれなくなっているため • Googleが開発したHTTP互換のプロトコル 「SPDY」 をベースとしており，HTTP/1.1に対しさまざまな改良が加えられる予定 • 現在はドラフト（下書き）がいくつか公開されている状態で，2014年末頃の仕様策定を目指している

  48. TCP/IP，HTTPに関する参考サイト • RFC 7230～7235 （HTTP/1.1） • http://tools.ietf.org/html/rfc7230 • http://tools.ietf.org/html/rfc7231 • http://tools.ietf.org/html/rfc7232 • http://tools.ietf.org/html/rfc7233 • http://tools.ietf.org/html/rfc7234 • http://tools.ietf.org/html/rfc7235 • HTTP入門 • http://www.tohoho-web.com/ex/http.htm • 3 Minutes Networking • http://www5e.biglobe.ne.jp/%257Eaji/3min/

  49. Webサーバと通信してみよう

  50. WebサーバとHTTPで通信してみる HTTPの動作を理解するため，WebブラウザになったつもりでWebサーバと直接通信してみよう HTTPリクエストを手動で打ち込んで送信し，それに応じたHTTPレスポンスが返ってくることを確認する 「Telnetクライアント」 と呼ばれるソフトウェア （とインターネット接続環境） さえあれば，簡単に試すことができる Windowsであれば，コマンドプロンプト上のtelnetコマンドや，Tera Term，PuTTY 等のフリーソフトが使える Macでも 「ターミナル」 上のtelnetコマンド等が使える 例として，PuTTYを使って以下のURIのリソースを取得 http://user.keio.ac.jp/~aa202427/index.html Telnetクライアントで簡単に動作確認できるプロトコルには他にも SMTP，POP，FTP などがある

More Related