1 / 36

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

情報処理 II www による情報発信とサービス提供 I. 第 13 回 2014 年 7 月 10 日 大塚 智宏. 本 日の予定. HTTP による Web サーバとの通信（２） HTTP の応用的な話題 その他の話題 最終課題 成績評価について. 前回までの課題について. 第 7 回課題の再提出分 採点して返却しました 授業支援でテキストファイルをダウンロードしてください ファイル先頭の学籍番号が間違っていないか確認してください 再提出の指示があった人は早めに再提出を 第 9 回課題 採点中 なのでもう少し お待ち ください m(_ _)m

emerson-nieves
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 第13回 2014年7月10日 大塚 智宏

  2. 本日の予定 • HTTPによるWebサーバとの通信（２） • HTTPの応用的な話題 • その他の話題 • 最終課題 • 成績評価について

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

  4. HTTPの応用的な話題

  5. バーチャルホスト • 1つのサーバで複数ドメインのWebページを収容・処理する機能 • HTTPリクエストのHostヘッダにより，どのドメインのリソースへのアクセスかを判別する • HTTP/1.1 で追加された機能であり，リクエストにHostヘッダが必須なのはこのため • ドメインごとにサーバを立てる必要がないため，運用コストやリソースを節約することができる abc.com GET / HTTP/1.1 Host: abc.com <html>...</html> xyz.net GET / HTTP/1.1 Host: xyz.net <html>...</html> クライアント Webサーバ

  6. HTTPキープアライブ（keep-alive） • 1回のTCP接続で複数のリソースを取得するために接続を維持しておく機能 • TCPの接続処理は手間がかかるため，キープアライブによりサーバやネットワークの負荷を軽減できる • これも HTTP/1.1 で追加された機能 （デフォルトで有効） • リクエストに Connection: close ヘッダを含めておくか，もしくはサーバ側で設定されたタイムアウト時間が経過すれば切断される • レスポンスを待たずに連続してリクエストを送信し，後でまとめてレスポンスを受信することによりさらに効率化できる • 「パイプライン処理」 と呼ばれる クライアント Webサーバ

  7. HTTPのステートレス性 • HTTPの欠点の一つとして，セッションの状態が保存されない点 （ステートレス性） が挙げられる • 各リクエスト-レスポンス対は互いに独立しており，関連付けすることができない • よって，以前の通信の内容に応じて次の通信の際の挙動を変える，といったことができない • このままでは，ネットショップにおける 「ショッピングカート」 などのWebサービスのほとんどが成り立たない (1) (2) クライアント Webサーバ

  8. Cookieによるセッション維持 • セッション状態を維持するための機構として 「Cookie」 （クッキー，HTTP cookie） が考案された • サーバは，セッションの状態を示すデータをSet-Cookieヘッダに含めてレスポンスを送る • クライアントは受け取ったSet-Cookieヘッダのデータを保存しておき，次の通信の際に保存しておいたデータをCookieヘッダに含めてリクエストを送る • これにより，前後の通信内容の間に擬似的に関連性を作り出すことができる Set-Cookie: ssid=123 Cookie: ssid=123 クライアント Webサーバ

  9. HTTPプロキシ（Proxy） • HTTP接続を中継するためのサーバ • proxy= 代理，代理人 • プライベートネットワークなどからWebにアクセスする際に，サーバへの実際の接続を 「代理」 で行う • Webサーバとクライアントの間に存在し，クライアントに対しては「サーバ」，Webサーバに対しては 「クライアント」 として振舞う 代理で接続 Webサーバ インターネット プロキシサーバ クライアントPC

  10. HTTPプロキシの主な用途 • キャッシュサーバ • Webサーバからのリソースをキャッシュし，それを複数のクライアントで共有することにより，ネットワークの負荷軽減や応答の高速化が可能 • アプリケーションゲートウェイ • クライアントPCが直接インターネットに接続しなくてもいいことから，内部ネットワークを守るためのファイアウォールとして機能する • フィルタリング • HTTPメッセージの中身をチェックすることにより，クライアントに見せたくないWebサイトへのアクセスを遮断したりできる • リバースプロキシ • Webサーバのためのプロキシで，外部からの接続に代理で応答することにより，負荷分散や攻撃に対する防御を行う

  11. HTTPとセキュリティ • HTTPのもう一つの欠点として，認証や暗号化といったセキュリティ機能が弱い，ということが挙げられる • サーバは，クライアント側のユーザが誰かを確かめない • クライアントは，サーバが本物であるかどうかが分からない • メッセージは暗号化されず平文のままネットワーク上を流れるため，盗み見ること （盗聴） ができ，中身を書き換えられても （改ざん） 分からない • これらは，古くからあるプロトコルの多くに共通する問題 盗聴・改ざん クライアント Webサーバ

  12. HTTPのユーザ認証方式 • 簡易なユーザ認証だけならHTTPにも実装されており，「Basic認証」 と 「Digest認証」 の2つの方式がある • ただし，どちらも単独ではセキュリティの高い方法とは言えないため，暗号化と組み合わせるなどの工夫をすることが推奨される • 実際のWebアプリケーションでは，HTMLの 「フォーム」 とCGI等による動的ページを組み合わせる方法の方がよく使われている • keio.jpのログインページ （https://login.keio.jp/koid/） などもフォーム＋動的ページによる認証を用いている

  13. HTTPユーザ認証の流れ • サーバは，認証が必要なリソースへのリクエストが来た場合，401 Unauthorized レスポンスに WWW-Authenticateヘッダを含めて送る • WWW-Authenticateヘッダには，Basic認証とDigest認証のどちらで認証させるか，およびその方式に必要なパラメータが含まれる • クライアントは，AuthorizationヘッダにユーザIDとパスワードの情報を含めて再度リクエストを送信する • Basic認証の場合はエンコードしただけの生パスワードが送信されるが，Digest認証ではサーバから受信したコードでパスワードをハッシュ化した文字列 （メッセージダイジェスト，不可逆） を送信する HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="auth" GET /index.html HTTP/1.1 Authorization: Basic QWxhZGRpbjp... クライアント Webサーバ

  14. HTTPS（１） • 通信内容の暗号化に対応したHTTP • HTTP over SSL/TLS • SSL （Secure Socket Layer） またはTLS （Transport Layer Security） と呼ばれる技術を用いて通信路を暗号化し，その上でHTTPメッセージのやり取りを行う • SSL/TLSにより，暗号化だけでなくサーバ認証，改ざん検出の機能も提供する 盗聴・改ざん 暗号化されたHTTPリクエストメッセージ 暗号化されたHTTPレスポンスメッセージ クライアント Webサーバ

  15. HTTPS（２） • SSL/TLSによる通信内容の暗号化 • SSL/TLSでは，暗号化およびサーバ認証 （サーバの身元保証） を行うために 「サーバ証明書」 を用いる • サーバ証明書はディジタル証明書の一種で，暗号化のための 「鍵」 がサーバ固有のものであることを証明するためのもの • 暗号化方式としては，公開鍵暗号を用いている • サーバ証明書に公開鍵のデータが含まれる形になっている • クライアントは，サーバ証明書に含まれる公開鍵を取り出し，それを使用して暗号化通信を行う • ただし，公開鍵暗号は暗号化・復号化の処理が重いため，実際にはまず初めに公開鍵を利用して共通鍵を生成し，実際のデータの送受信には共通鍵暗号を用いる，ということを行っている

  16. 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/

  17. その他の話題

  18. HTML5の関連機能 • 広義のHTML5には，関連する仕様やAPIも含まれる • メタデータ： RDFa，microdata • グラフィックス： SVG，WebGL • 位置情報取得： Geolocation API • ストレージ： Web Storage，File API • 双方向通信： WebSocket，Server-Sent Events • マルチスレッド： Web Workers • スタイリング： CSS3/CSS4，Web Fonts

  19. いろいろなHTML要素（１） • 今までに取り上げていない主なHTML要素 • 引用 （blockquote，q） • blockquote： ブロックレベルの引用を表す • q： インラインの引用を表す • フォーム関連 （form，input，select等） • サーバに対しユーザがデータを送信するための仕組みを提供 • 送信されたデータは，サーバ側のCGIプログラムなどが処理する • Webアプリケーションには欠かせない機能 • 秋学期の授業で詳しく取り上げます • スクリプト （script） • JavaScript等のクライアントサイドスクリプトの指定 • その他 • イメージマップ （map，area） • テキストの意味づけ （abbr，dfn，var，samp等）

  20. いろいろなHTML要素（２） • HTML5で追加された要素 • セクション関連 • article： 独立したコンテンツ （ニュース記事やブログエントリ等） • aside： 本文との関連が薄いコンテンツ （補足や広告等） • nav： ナビゲーションを伴うセクション • section： 一般的なページ内のセクション • ヘッダとフッタ，図表 • header： ページやセクションのヘッダ部分 • footer： ページやセクションのフッタ部分 • figure： 本文から参照される図表 （図や写真，ソースコード等） • その他 • canvas： 図形の描画 • video，audio： マルチメディアコンテンツの埋込み • ruby，rt，rt： ルビ （ふりがなや説明，異なる読み等）

  21. Web標準 • Webページ制作の際の拠り所となるWeb関連の規格 • 明確な定義は存在しないが，一般的には，W3Cが策定しているHTMLやCSS，WCAG等の仕様を指す • 現在では，Web標準に準拠したページを作ることは当たり前あるいは必須となっている • アクセシビリティの確保，検索エンジン最適化（SEO）の観点からも • メンテナンス性，前方互換性を向上させることもできる • Web標準の歴史と今後 • 昔は，特定のブラウザ（NetscapeやIE）でまともに表示できればOKとされ，Web標準はあまり関心を払われなかった • その後，Web標準自体の改良や，Web標準準拠を標榜するブラウザ（Mozilla Firefox等）の登場により状況は改善され，現在に至る • 今後，Web標準がどんどん新しくなっていったとしても，Web標準が無視される時代が再び来ることは考えにくい

  22. Webユーザビリティ • サイトの 「使いやすさ」 を表す指標 • Webサイトが 「使いやすいかどうか」 「分かりやすいかどうか」 「役に立つかどうか」 などで評価される使い勝手の良さ • SEOと同様，マーケティング等の観点からも非常に重要 • さまざまなノウハウ，テクニックが蓄積・公開されている • ユーザビリティ向上のポイント • サイトの論理的な構造，リンクの深さ • ナビゲーション （サイトナビゲーション，トピックパス等） • 1ページあたりの情報量 • ヘルプ情報，検索機能 • 操作のしやすさ （スクロール，マルチメディアコンテンツ等） • ユーザテスト，アンケート等からのフィードバック

  23. Webプロジェクト • Webサイトの立ち上げ，リニューアル，メンテナンス等のプロジェクト （計画およびその遂行） • 通常は，チームで行われる • 専門の業者や，フリーのデザイナ等が集まってチームを構成 • プロデューサ，プロジェクトマネージャ（PM），ディレクタ，デザイナ，コーダ，プログラマなど，複数の専門職が関わることも • 計画・意思決定 ⇒ デザイン・制作 ⇒ テスト といった流れで実施される • Webプロジェクトに限った話ではないが，マネジメントが重要 • 構築／リニューアル完了で終了ではなく，その後のメンテナンスや見直し，ユーザの声のフィードバック等も必要 • いわゆる 「PDCAサイクル」 の実践

  24. 「ホームページ」 • Webページのことを 「ホームページ」 と呼ぶケースが多いが，これは本来の意味とは少し違う • 「ホームページ」 の本来の意味 • ブラウザの起動時や 「ホーム」 ボタンを押した時に表示されるページ • ウェブサイトの入り口／最上位にあたるページ （トップページ） • 上記から派生して，Webサイトや，ひどい場合はWebやインターネットそのものを指す用語として広まってしまっている • 日本など一部の国でしか通用しない • さらに，「HP」 「ホムペ」 などの略語も… • 「ホームページ」 を含めこれらはいずれも正式な用語ではない • 特に 「HP」 はいろいろな言葉の略語になっているので注意 • Hewlett-Packard（企業），hospital（病院），馬力（horse power），ホールドポイント（野球），ハリー・ポッター，ハロー!プロジェクト，ヒットポイント，など

  25. レンタルサーバについて • 最近は，個人のみならず企業や団体等でWebサイトを立ち上げる際にもよく利用される • 自前でサーバを用意したりOSをセットアップする手間が省けたり，電気や空調などに気を使わなくて済む • 最近は，クラウドサービスに近い感覚のものも多い • 利用上の注意 • アップロードの際は，なるべく暗号化されたプロトコルを使う • FTPではなく，SCPやFTPSを使うようにする • 機密データを置くことには慎重になるべき • 流出等のリスクを考えると… • ただし，自社で管理するよりマシ，という考え方もある • コンテンツ等のデータは必ず自分でバックアップを取る • 某レンタルサーバ会社での大規模なデータ消失事故など

  26. 最終課題

  27. 最終課題 これまでの講義内容を踏まえ，何か一つ自分でテーマを決めて，そのテーマに沿ったWebサイトを制作する テーマの例 自分の所属している （または過去に所属していた） 各種団体 サークル，クラス，出身校など 自己紹介や，自分だけの組織は× 学問や趣味などの話題に関する解説やドキュメント 必ずしも上記に限らないが，自分が内容に関して責任を持つことができ，なおかつ対象とする閲覧者をなるべく限定しないテーマを選ぶのが望ましい コンテンツのファイル構成 トップページと，それに相互リンクされた2つ以上のページを作成する つまり，少なくとも3つのHTMLファイルを作成する必要がある 各ページに共通して適用される共有CSSを最低1つ用意する ページごとにCSSを用意する場合は，共有CSSをインポートする

  28. ファイル構成の例（１） トップページ + 2個以上のサブページ 3個目以上のサブページは，概観だけ／リンクだけでもOK つまり，大きめのサイトの構成を考え，そのうちのトップページ＋2ページだけを実際に制作する，というのでもよい もちろん，最初からトップページ＋2ページのみの構成でもOK サブページ間のリンクはあってもなくてもよい 共有CSSを各HTMLファイルから参照 HTML（トップ） CSS（共有） リンク リンク HTML（サブ1） HTML（サブ2） ・・・

  29. ファイル構成の例（２） ページごとに異なるスタイル指定をしたい場合 各HTMLごとにCSSを用意する それぞれのCSSに共有CSSの内容を取り込む （@importを利用） HTML（トップ） CSS（トップ） リンク リンク HTML（サブ1） HTML（サブ2） CSS（共有） ・・・ CSS（サブ1） CSS（サブ2）

  30. 最終課題（続き） その他の制作条件 以下の内容をまとめた仕様書を作る （様式は自由） テーマの簡単な説明 サイトの全体構成 （図があるとよい），内容の目次 （サイトマップ） ファイル構成 （HTML，CSS，画像等すべて），各ファイル間の関係 各ページの構成，デザインに関する説明 この講義全体の感想，気付いたこと等 HTML，CSSについて HTMLは HTML5 （XHTML形式） に準拠すること CSSは CSS3 に準拠すること HTML，CSSともにバリデータで文法エラーがないことを確認する 見やすさ，読みやすさ，アクセシビリティに配慮する 分量は自由だが，内容を踏まえて適正なコンテンツ量を考える

  31. 最終課題（続き２） アップロードについて ITCの環境にアップロードし，表示等を確認する 複数のブラウザでチェックすること 提出物 以下をZipファイルにまとめたもの HTML，CSS，画像等を含むコンテンツ一式 アップロードしたものと同じであることをよく確認すること 仕様書 （ファイル形式は自由） アップロード先のURIを書いたテキストファイル レポート提出時の 「コメント」 欄に，連絡先メールアドレスを必ず書いておいてください 提出期限： 8月3日（日） 23:59

  32. 採点方針 評価項目 （全体で40点満点） 仕様書，コンテンツの内容 （約15点） 仕様書の内容，コンテンツの質・量・オリジナリティ HTML，CSS （約15点） 文法，マークアップの適切さ，制作条件を満たしているか その他 （約10点） デザイン，見やすさ，読みやすさ，アクセシビリティ

  33. 成績評価について

  34. 成績評価方針 • 課題の採点結果をもとに評価します • 第3，5，7，9，11，12回課題（全6回）： 各10点満点 • 最終課題： 40点満点 • 全部合わせると，100点満点 • 評点の付け方（あくまで目安） • 75点以上： A • 60点以上： B • 50点以上： C

  35. 追加レポート 授業に関係する内容について，追加でレポートを提出することを認めます 内容と形式は自由 内容次第で，プラス点を差し上げます あくまで内容次第 提出しなくても全く問題ありません 提出期限： 8月3日（日） 23:59 （最終課題と同じ）

  36. 質問・疑問など 課題に関する質問，採点に関する疑問など，連絡事項がある場合は以下宛にメールすること otsuka@itc.keio.ac.jp ただし，内容によっては回答できないことがあります 最終的な成績表（評点）に関する質問は，学生部へ 直接質問されても回答できません

More Related