- 情報コース
- テレビ科目
- 森本容介先生（放送大学准教授）
- 伊藤一成先生（青山学院大学准教授）
- 難易度 ★★☆☆☆
- おすすめ度 ★★★☆☆
webを中心としたネットワーク周りの話。HTTPの話が多い。慶應の図書館情報学でやったRDFの話もある。あまり深い話はせず、多種多様な話題を浅く広く学ぶ感じで、お手軽。後半の伊藤先生が楽しそうなのがよい。
第1回
森本先生による概説。森本先生若々しい。こういう同級生いた。
web以前はtelnetとかネットニュースとかあったね。あの人たちどうなってしまったんだろう。95年にwebがトラフィック1位になったらしい。webは一般名詞になったので小文字になった。
webといえばハイパーテキスト。ハイパーリンクのおかげで他のページに飛べるようになった（当時めっちゃ画期的だと思われてたな）。HTMLベタ打ちが紹介されている。テキサイだ！いまは阿部寛のホームページ以外では完全に滅びたよね。
webシステムについて。昔のwebシステムではURLとファイルが1対1に対応していた。静的なwebページという。サーバやクライアントの状態において、同じURLでも異なる結果を返すのが動的なwebページという。webシステム/webアプリケーションという。乗換案内とかショッピングとかネットバンキングとかね。SNSも当然そう。ソフトウェア不要、異なる端末からアクセスできる、更新が楽勝ってのが利点。欠点はwebアクセスしないと無理なこと、セキュリティの問題。
第2回
webの基礎。クラサバモデルから。ユーザ⇔クライアント⇔サーバのデータのやり取りで表現される。ユーザとクライアントの関係は、クライアントとサーバの関係そのまんまとも見える。
URLは構文がある。<scheme>://<host>:<port><path>?<query>#<fragment> らしい。言われてみればそうだ！httpsってhttpとどう違うんかよくわかってない。暗号化されていることだけはわかっているが、実装はどうなのか。相対URLの書き方。//から始めれば、実質http://の略と同じらしい。スキーム名は電話番号でtel:ってのもあるらしい。
リクエストメッセージとヘッダフィールド。空行までがヘッダなのね。GETメッセージにはHTML1.1って書いてあるが、1.1以上のバージョンはあるのか？ステータスラインの404って最近あんま見ないよね。ウェブページがサーバーへのリソースではなくクエリを使って動的表示されることが多くなったから、404より500の方が多い感じがある。メディアタイプはだいたい知ってたけど、octet-stream（任意のバイナリ）はしらんかった。
第3回、第4回
HTML/CSSを2回取り扱うらしい。内容はほぼ知っていたので略。まさか2022年にHTML/CSSベタ打ちについて教えてるとは驚き！
知らなかったこと一覧。HTML上のエスケープシーケンス("とか)は名前文字参照という。あとHTML5は2021年に廃止されたらしい。今は？（→HTML Living Standardらしいです）
第5回
HTTPについて。今の最新バージョンは2015年、HTTP/2。でもこの授業では1.1の解説をやるらしい。
リクエストもレスポンスも、リクエストライン/ステータスライン＋ヘッダフィールド、空行、ボディという構成は変わらない。ヘッダはフィールド名: フィールド値という構成。
HTTPメソッドは8つ。GETのほか、POST、PUT(更新)、DELETE(リソース削除)など。
Refererってスペルミスだったのか！
キャッシュについて。webサーバーからは、キャッシュしてもよいかどうか、リソースの有効期限、最終更新日時、エンティティタグ（etag？バージョンを表す）が得られる。最終更新日時やエンティティタグを見れば、前回と同じリソースかどうかわかる。条件付きGETを送れば、304 Not Modifiedが返ってくるのでキャッシュが使える。キャッシュの可否は、Cache-Control:タグで返ってくる。クライアントからは、GETのあとにIf-Modified-Sinceとか、If-None-Matchタグをつけてやれば、条件付きGETを作ることができる。
持続的接続について。TCP接続を切るかどうかの話。持続的接続をすると負荷が軽減できる。Connection: Keep-Aliveを使えばよい。
第6回
動的webサイトについて。随時変化するサーバー情報、データベース内容のGETとか。ヘッダーでリソースを変えることは、コンテントネゴシエーションという。Accept: とか Accept-Language: で指定したメディアタイプによってサーバーが返してくるリソースを変える。一番よくあるのはクエリやメッセージボディでの指定。ここまでの3つは全部組み合わせられる。
で、フォーム？突然技術が古くなった感じ。フォームデータを+とか&とか=とかで加工する古い方法が出てきたが、これってセキュリティ的にやばいやつじゃなかったっけ？POSTで送信する場合は暗号化できたりするんかな。httpsだと勝手にやってくれるのか？（→TLSという技術を使うらしい）
第7回
RDBMSについて。「データベース(’17)」とかぶってるので略。
第8回
クライアントサイドの技術について。描画処理とか、ユーザ操作に対する再描画とか。JavaScriptを使って表示を変えたりすることもこれに該当する。
JavaScriptが出てくると、HTMLの解釈が一旦停止になるらしい。そういえばページ表示してから実行したかったら、何か特殊な実装をしていた記憶がある（→AddEventListener(“load, …)でやるって説明あった）。JavaScriptの具体的な操作は、知っていたことばっかだったので略。まず
第9回
認証とセッション。基本はIDとパス。注意点については情報セキュリティ概論とかぶってるので略。
HTTP認証。まずBasic認証。何も指定しない場合、WWW-Authenticate: Basicが返ってきて、ID+パスを問われる。Authorization: Basicで返してやる。ID+パスはBase64エンコードで送るけどこれはデコードもできてしまう。ヘッダを見られたらアウトになってしまう。Digest認証を使うとMD5でハッシュ化するので安全。
フォームベース認証。INPUT要素のフォームを使う。これもコンテンツ内にべた書きになってしまうので危険な気がする。
セッション。ブラウザとサーバーのやり取りの1単位のこと。検索→商品ページ→購入→情報入力→確認→完了までとか。HTTPはセッション管理がない（ステートレス）ので、同一ユーザーの推定をすることになる。使う情報はIP、UserAgent、Refererあたりが考えられる。アクセス解析はこれを使ってる。しかしIPは同一ユーザでも変わることがあるし、LANから来たら同一IPから複数アカウントが来ることもある。なのでこれはセッション管理としては使えない。なので、毎回認証用の情報を送受信するという手もある。WebブラウザがAuthorizationヘッダを記憶しておいて、毎回送信する。でもこれも面倒。
これを解決するためにCookieを使う。Cookieとはwebサーバーがwebブラウザに記憶させるデータのこと。サーバとブラウザが毎回保存しておいたCookieをやり取りすればよい。webブラウザからはSet-Cookieヘッダが返ってくる。idが入っているので、ブラウザはリクエストのヘッダに毎回Cookie; id=XXXX を送ってやればいい。クッキーには有効期限や有効なドメインなどを指定できる。クッキーにはショッピングカートの商品番号を入れたり、様々なプロパティを保持させることもできる。けど、後述のセッション管理を使うことが多いから、あんまりやらない。セキュリティ上もよくないし。
クッキーによりセッション管理。セッションIDを含むクッキーを発行する。webサーバー側でユーザ固有の情報をセッションIDと結び付けて保存しておけばよい。例えばID+passを送ったらサーバーはセッションIDを返す。ブラウザ側はあとは毎回セッションIDを送ることで認証済みであることを示すことができる。ログアウト時はクッキーを削除する。削除するという命令はないので、例えばクッキーのExpiresを過去にしてしまう。
シングルサインオン。専用の認証機構で一度認証を受けると、横断的に別のリソースを使うことができるようにする。放送大の認証システムや、keio.jpなんかがこれに該当する。IdP（認証局）とSP（サービスプロパイダ）間の直接の通信はない。
第10回
webのセキュリティ。盗聴、不正誘導、攻撃、なりすましについて。
盗聴を防ぐにはTLSを使う。TLSはSSLが元祖。認証には証明書を利用する。認証局から発行されたものが信頼できる。クライアントから証明書を送って、サーバからサーバ証明書を送ってもらう。TLSはTCPとHTTPの真ん中の層として提供される。HTTPと合わさってHTTPS, HTTP over TLSを作る。
ルート認証局の信頼性はどう確保するか。webブラウザ内に保存される。（ちょっとここらへんはわからんかった）「安全な接続ではありません」的なメッセージが出るのは、証明書の検証に失敗しているということ。
フィッシング。偽サイトに誘導してパスワードなどを搾取すること。以下略
webシステムの欠陥について。脆弱性をついた攻撃について。ヘッダに不正なデータを含めたり、存在しないパスを指定したり、メッセージボディにデータをつけたりすることが考えられる。
SQLインジェクション。パスワードに ’’ OR ‘a’ = ‘a’ と入れる。すると、SQLではORが優先されるため、’a’ = ‘a’ が成り立ち、無条件でSELECT文が通ってしまうというもの。
クロスサイトスクリプティング。フォーム送信するデータの中にJavaScriptを入れる。img src=の後に別サイトのURL+クッキーのデータをエンコードするコードを入れて、クッキーを別サイトに送信させること。
セッションハイジャック。セッションの乗っ取り。ここまでの技術を利用してセッションIDを詐取すればできる。
第11回
大規模webシステムについて。冗長化と負荷分散から。予備システムを用意して、システム障害児の即時復旧を図る。コールドスタンバイ方式（予備システムは通常時は停止）とホットスタンバイ方式が（予備システムは常時稼働）ある。負荷分散はリクエストを複数のサーバーに振り分けること。障害発生時も残りのサーバーで処理できるので可用性が高い。ロードバランサを使う。他の実現方法としてはDNSラウンドロビンがある。同一ドメインについて複数のサーバーを割当てているDNSをそのまんま使って負荷分散をすること。あとリバースプロクシ。ネットとサーバーの間に挿入され、サーバへのアクセス要求を転送する。
データセンター。コンピュータやデータ通信機器などの装置を集中管理するところ。電源が大事なので自家発電装置、UPSを多数配備する。発熱するので空調も大事。あと免震、床の耐荷重も必要。監視カメラ、ICカード認証、高速ネットワーク回線もいる。
IIJのデータセンターにインタビューしてる。広報部課長の堂前さん。昔は電算センターと言ったらしい。いまでは大規模データセンターの一部を借りることが多い。事業者の業務はコンピュータ設置場所の貸出がメイン。電気系統やネットワーク、ラックを提供する。コンピュータ設置の依頼もできる。セキュリティオペレーションセンターに監視を依頼することも可能。建物の特徴：大量のケーブルのため50cmの空間がある。耐荷重、免震も大事。免震がないと地震の際にコンピュータがぶつかって壊れる。エンジニアが出入りするのでセキュリティカードをゲートに通さないとダメ。6600Vの受電装置。非常用発電機。道路工事などで断線しないよう、通常と異なった電気の呼び込み。ラック1個で一般家庭数件分の電力を消費するらしい。あと最近はGPGPU(画像演算CPUの目的外使用)が増えてきて、消費電力が高くなってる。ラック一個で中型電気ストーブ10個分。空調装置が故障すると終わるので、空調装置にも冗長性を確保している。
IaaS、PaaS、SaaS。他でやったので略
CDN。Content Delivery Network。アクセス集中を避ける技術。複数のサーバーを用意してミラーリングする。これもIIJにインタビューしている。メーカー新製品発表会とか、ゲームのアップデートの時にアクセスが集中する。大量の設備を用意するのはコストがかかりすぎ。なので従量制のCDNサービスを利用するとよい。CDNは光回線の物理的遅延を回避するのにもよい。セキュリティ対策としてもCDN事業者に外注できるから有利とのこと。
HTTP/2。リクエスト/レスポンスの多重化の方法が1.1と違う。1.1はTCPコネクションを複数確立する。2ではストリームという仮想的なチャネルを使う。ヘッダもバイナリ形式になり、圧縮して差分だけ送信する方式になって効率化されてる。サーバプッシュ機能。リクエストなしでサーバーからコンテンツが来る。キャッシュも使える。1.1との後方互換性もある。ブラウザとサーバのどちらかが古ければ1.1を使うようにできる。
第12回
検索エンジン。クローラ、インデクサ、検索部からなる。クローラはwebページの選定と制御部分からなる。収集は再帰的に行える。クローラは複数同時に動くので制御が必要。同一ページを収集しないようにしたり、重要度をつけたりする。
インデクサは索引情報で、形態素解析を使って単語に分割したり、一定の文字数を切り出したりする（N-gram）。webページはHTMLなので、タグ構造を踏まえた解析を行わないといけない。
検索部。キーワードとインデックスを照合して、webページをランキング形式で提出する所。検索部の処理は世界中のデータセンターに分散している。
PageRank。webの構造を解析してランク付けする。具体的にはバックリンクの数が多いページを重要なwebページとし、ここからリンクを張られているページも重要な頁とするものである。算出式は卒論にも書いたので略。Σがあるからどうやって計算するのだろうと思ってたが、何回も計算して収束するまでやればいいらしい。
HITS。Hyperlink Induced Topic Search。動的にランキングを作る方法。検索結果に適合したページの集合をR（ルートページ集合）とし、ここからリンクを張られているページの集合を考える。HITSではHubとAuthority問概念を使う。Authorityとは、多くのwebページからリンクを張られていること。これを値で表現する。Hubは、多くの権威あるページにリンクを張っているページのこと。これも値にする。HITSではこの2つを使って重要度を算出している。
接続行列。iからjへリンクが存在したら1、なければ0になる行列のこと。Authority値をa1~an、Hub値をh1~hnとして、初期値は全部足したら1にしたあと、接続行列をかけたり、L1ノルムを正規化するということを何回も続けていく。するとだんだん収束していく。これをAuthority, Hubの最終的な値とする。実は接続行列の固有値を求めることでも計算できるので、こっちの方が楽。
マルチメディア検索。テキスト（メタデータ）に基づく方法（TBIR）と、画像特徴量に基づく方法(CBIR)の2通りがある。画像でも音声でもやることは同じ。
第13回
セマンティックwebとリンクトオープンデータ。セマンティックwebとは、人間と機械とのコミュニケーション実現を目指すwebのこと。意味情報の記述にはRDFを使う。
RDFはリソース、プロパティ、プロパティ値の3つの組（トリプル）でリソース間の関係を表す。主語、述語、目的語に相当する。http://kazuanri.org→(dc:creator)→伊藤一成なら、http://kazunari.org がリソース、伊藤一成がプロパティ値、dc:creatorがプロパティ。どれもURIで表記する。プロパティはリテラル（文字列や数値）も指定可能。RDFはXMLを使って表記する。スペース区切りのTurtle形式もある。プロパティ値をURIにすれば、リンクと同様になって関連を表すことができる。
ダブリンコア。あらゆる情報資源に付与可能な語彙集合のこと。titleやcreatorなど15要素がある。図書館情報学でやったな。
ダブリンコア拡張語彙（DCTerms）。dctermsをつける。より厳密なメタデータ記述ができる。available, created, dateなど。foaf(friend of a Friend)というのもある。foaf:knows(知ってる人)とか。
語彙の定義づけはRDFS(RDFスキーマ)で定義する。例えばライオン(S)が肉(O)を食べる(P)は意味をなすが、朝顔(S)が肉(O)を食べる(P)は意味をなさない。これはどうやって定義するのか。クラスを用いる。OOPLに近い。rdfs:Resourceが基底クラス、rdfs:classがクラスそのもの、rdfs:Literalがリテラル値・・・など。他にも下位インスタンス、サブクラスを表すプロパティもあるし、リソースであることを表すプロパティもある。
スキーマ定義の例。これは文字で表すのは難しい。rdfs:typeとかrdfs:SubClassOfとかを使って関係性を記述していく感じ。現実世界をクラス化してrdfs:で構造化していくようなことをするのかな。
OWL。Web Ontology Language。概念間の高度な関係を表せる。犬と猫は互いに素とか、年齢は0以上の整数とか。難しいのであまり実現されてないらしい。
リンクトオープンデータ(LOD）。個々の情報をまず共用することを優先しようとする試みのこと。政府、図書、メディア、ライフサイエンス、地理情報などで使われている。すでにLODのクラウドができている。
5スターオープンデータ。オープンライセンスを使う、構造化データを使う、非独占形式を使う、URIを使う、他のデータへリンクする。これを守るとLODにしやすい。
DBpedia。wikipediaからLODを生成するプロジェクトのこと。
SPARQL。RDFの検索に使うクエリ言語のこと。SQLに似てる。
第14回
HTMLテクノロジ。HTML5では大きな機能拡張があった（廃止されてなかったっけ？）今ではスマホ対応など多様な環境を前提にしたwebシステムを作らないといけない。例えばデバイスごとにCSSを切り替えるとか、user-agentに応じてページを切り替えるとか。
センシングデータの利用。先生が作ったGOSEICHOというコンテンツを見る。
スマホを裏返すと「ご清聴ありがとうございます」というというアプリ。デバイスの軸を検出する仕組みがある。alphaがZ軸、gammaがy軸、betaがx軸「を中心とした回転」を検出する。回転なんだね。javascriptの実装としては、deviceorientationイベントをゲットすればいい。abs(e.beta)が170↑、abs(e.gamma)が10↓なら裏返しと判断する。なるほど！
SVG。HTML内にインラインでSVGを書ける。アフィン変換すれば位置や向きも簡単に変換できる。transform=”translate(100. 20) rotate(40)” などと書けば平行移動＋回転ができる。JavaScriptと組み合わせて、図形を要素とみなして操作も可能。
ストレージ技術。WebStrageを使えばローカルストレージを使うことができる。形式はキーバリュー（KVS）。Local Storage(期限なし）とSession Storage(セッション終了まで)がある。
リアルタイム双方向通信。今まではAjaxを使ってた。これはクライアント側で動作し、ブラウザでポーリング（定期的にリクエストすること）していた。一定時間ごとに更新の有無をチェックするので、無駄が多い。
Comet→サーバ側でリクエストを保留し、任意のタイミングでレスポンスを返す。コネクションを維持しておき、更新があったらレスポンスを返す。無駄がないがTCPコネクションを占有するのが欠点。これはHTTPの限界と言える。
これを克服するのがWebSocket。まずハンドシェイクでコネクションを確立。プロトコルが確立したらあとは双方向通信を行える。JavaScriptではonmessageイベントとして処理できる。
第15回
WoT時代のwebについて。IoTはデバイスやネットワークが標準化されていないので、インタフェースを統一したい気持ちがある。これをWoT(web of thing) という。
Web API。サーバが提供するAPIのこと。WoTの前提となる。APIのデータ交換にはJSONが広く使われている。JSON形式のライブラリは充実しており、相互運用性を意識することなく利用できる。
JSONにはスキーマがないので、スキーマ付きのものとしてJSON-LDがある。リンクトオープンデータを表現できる。
REST。Representational State Transfer。クラサバが原則、インタフェースは統一、ステートレス（情報や状態の保持なし）、キャッシュ可能、階層型システムという5原則を満たすこと。これを満たすとネットワークを状態機械として扱える。ROA（Resource Oriented Architecture）。リソース指向のアーキテクチャ（？）。識別子にはURIを使う。Restful WebAPIの実装では、CRUDをPOST, GET, PUT, DELETEのHTTPメソッドに対応付ける。
WoTの実例。モータ、LED、光センサをつける。これをROAで階層化しておく。例えばGETメソッドで光量をJSONでゲットできる。POSTでサーボモーターの回転方向を移動させられる。実際にロボットを動かしてる。かわいい。先生がなぜか人形と同じ格好をしている。
KDDIの高木悟さんにインタビューしてる。スマホでアプリケーションを動かす時代なので、ブラウザが大事。KDDIの仕事が増えてる。W3Cにも関わっている。GitHubを中心に標準化のプロセスを議論してるらしい。全部オープン。W3Cの勧告は仕様書と同時に実装がないといけないらしい。ブラウザとOSはほぼ同じ概念になりつつある。webOSという考え方もある。WoTの考え方が浸透し、画面表示できるものなら何でも動くという時代になった。
WebDINO Japanへ。瀧田さん。mosaic時代からブラウザに関わっているらしい。多言語対応を行っていたらしい。CHIRIMENというコミュニティがある。ハードウェアをフルオープンにしようというプロジェクト。ラズパイを使って、ブラウザ上で動く開発環境を作っている。センサーの状態がブラウザで簡単に見られるようになっている。サーボもJavaScriptで操作可能。コードはHTMLとJavaScriptを同時に表示し、簡単に編集できるようになっている。すげー。
WoTの未来。Webがプログラム可能、知識表現の構築、即時処理、活発な交流がキーワードとなる。