Network_02-digest__アプリケーション層

class: title, smokescreen, shelf, no-footer
# <small>アプリケーション層<br>- ダイジェスト -</small>

<div class=footnote>
<small><small>
アプリケーション層 通常版は、こちら:
<A HREF="/slides/network/tcpip/app_www">[WWW]</A>,
<A HREF="/slides/network/tcpip/app_dns">[DNS]</A> and 
<A HREF="https://www.youtube.com/playlist?list=PLS2cEmI21XYKUWdzZyvjE3mO0YuNIu0lQ">
[動画再生リスト]
</A>
</small></small>
</div>

---
class: img-right,compact
# 全体像(再掲)

![width640px](/images/network/end-to-end.png)

<small>
- 右図: ホストとホストの通信
    - ホスト = コンピュータ
    - END TO END (端〜端)通信
    - 用語: 階層(Layer), 〜層
    - 用語: プロトコル(取り決め,約束事)
        - TCP,IP,Ethernetなど
    - 用語: サーバ,クライアント
- 右図: サーバ(左)とクライアント(右)
    - サーバ (写真の業務用PC)
        - サービスを提供する側
        - WWWサーバ,メールサーバ
    - クライアント (右端のPC)
        - サービスを受ける側(お客様)
        - ブラウザやメールソフト
        - 人間が操作しているPC
</small>

---
class: img-right,compact
# アプリケーション層

<div class=footnote>
<small><small>
(脚注)
TCP/IPはOSI7階層モデルと独立に考えられた仕様なので、
OSI7階層モデルとは不整合です
(正確にはTCP/IPが先でOSIモデルが後に登場しています)。
また、TCP/IPとOSIの対応関係図を載せている教科書もありますが、
本ごとに解釈が異なっていたりします;-)
</small></small>
</div>

![width640px](/images/network/end-to-end.png)

<small>
- 4階層の一番上の階層を「アプリケーション層」と呼びます。
  ようするに、いちばんユーザ側に近いところです
- アプリたちの住まう世界と考えてもらってOKです。
  例: WWW (World Wide Web)、
      電子メール、
      DNS (Domain Name System)、
      twitterアプリ
- このあとWWWとDNSを取り上げます。
  また、**第2回にはAWS上の演習でWWWとDNSを体感**します
  (体感?!とは何か:-?
   実のところ、アプリケーション層は人間が体感できます。
   それをやってみましょう)
</small>

---
class: title, smokescreen, shelf, no-footer
# <small>Part 1: WWW<br>World Wide Web</small>

---
class: col-2,compact
# WWW (ワールドワイドウエブ)の全体像

<small>
- 転送プロトコルは HTTP
    - 特にHTTP/1.0はシンプルなステートレスプロトコルの良い例(後述)
- データ(転送する内容)は自由
    - 代表例はHTML形式のファイルですが画像でも動画でも何でもOK
    - **【重要】** データの種類や表現などはTCP/IPと無関係!
      **TCP/IPの仕事**はブラウザに**データを確実に届ける**こと
- 組織と規格文書
    - W3C (World Wide Web Consorcium)からの勧告
    - IETFでRFCになるものもある
    - だれでも参加可能

<wbr>
- ブラウザでは URI を指定する
    - かつては URL と呼んでいたため、歴史的に URL と呼ぶ人も多い
- 用語: URI が URL と URN の上位概念
    - 情報空間で一位に特定できるIDがURI
    - URL (Uniform Resource Locator), 場所に相当するもの
        - 例: https://サーバ名/場所/
    - URN 場所という概念が無いもの
      - 例: 電話番号, 本のISBN番号
```
[URIの例]
https://portal.mc.chitose.ac.jp/portal2/
tel:0123-27-6097
isbn:978-0321336316
```
</small>

---
class: col-2,compact
# WWW サーバの動作 (HTTP/1.0 の動作説明)

<div class=footnote>
<small><small>
(脚注1)後日、実際に手動でこれをやってみる演習をします
<br>
(脚注2)listen(2)の2は引数ではなく、Unix マニュアルの第2章「システムコール」を参照という意味
</small></small>
</div>

<small>
- WWW サーバはリクエストを待つ
    - ポート番号は 80, プロトコルはTCP
    - 専門用語では「80/tcp で listen(2)」
- クライアント(WWWブラウザ)〜サーバ間にTCPの通信回路を確立(詳細は後日)
- クライアントからサーバに「このURIのデータをください」とリクエスト
    - サーバクライアントモデル
    - サーバ       = WWWサーバ
    - クライアント = WWWブラウザ

<wbr>
- サーバからクライアントに返答
    - 「HTTP ヘッダ + データ本体」を返す
    - **ヘッダ**には制御情報が書かれます
    - ヘッダとデータ本体の区切りとして空行を1行挿入します
      (これはメールと同じRFC822準拠フォーマット)

![width320px](/slides/network/tcpip/app_www/images/http-overview.gif)
</small>

---
class: img-right,compact
# WWW サーバの動作 (サーバの内側をもうすこし詳細に)

![height480px](/slides/network/tcpip/app_www/images/httpd-internal.png)

<small>
- WWW サーバは要求を待っている
- (1) クライアントからサーバに接続し「このURIをください」と要求
    - `GET /index.html HTTP/1.0`は「/index.htmlをください」という要求で、
      HTTP/1.0はプロトコル番号の指定
- (2) WWWサーバ内の動作
    - URIから対象のコンテンツが/index.htmlであることを割り出す
    - サーバのコンテンツ領域を検索しindex.htmlファイルを探しだす
    - ファイルからデータを読み込む
- (3) サーバからクライアントに返答
    - HTTP ヘッダ + データ本体(index.html)
</small>

---
class: compact,center
# HTTP/1.0のデモ

埋め込みが動作しない方は[こちら](https://www.youtube.com/embed/hq-CTEZK1-k?rel=0)

---
class: col-2,compact
# ステートレスプロトコル, ステートフルプロトコル

<small>
- stateless protocol (例: HTTP 1.0)
    - サーバに要求、データを受信
    - 一回ずつ終了、つまり「状態」がない（ステートレス）
    - HTTP/1.0ではブラウザで表示する部品の数だけ取りにいく
        - 右図の例: index.html 背景画像 ...
        - (もちろん、あれば広告なども)
- statefull protocol (例: POP, SMTP)
    - 現在の状態を追跡、状態によって挙動も変わりうる。
      メールの受信を例にとると、認証前後で挙動が異なる
</small>

![width320px](/slides/network/tcpip/app_www/images/http-stateless.png)

---
class: title, smokescreen, shelf, no-footer
# <small>Part 2: DNS<br>Domain Name System</small>

---
class: img-right,compact
# WWWの動作(DNS込み)

![](/slides/network/tcpip/app_dns/images/resolver.png)

<small>
- 前回はDNSを省略しています(図(3)(4))
- 右図がDNSを含めたHTTPの動作です。
  ブラウザにURIを指示すると
    - (1) ブラウザはURIに含まれるサーバ名portal.mc.chitose.ac.jpの
          IPアドレスをDNSサーバに問い合わせます
    - (2) DNSサーバはブラウザにIPアドレス=210.128.52.45を回答
    - (3) ブラウザは210.128.52.45と通信を始めます
          (このあとは[前回](https://lectures.fml.org/slides/network/tcpip/app_www/#4)のとおり)
- このIPアドレスを検索する仕組みを**DNS**と呼んでいます。
  今回はコレの解説
</small>

---
class: img-right,compact
# DNS = Domain Name System (Service)

<div class=footnote>
<small><small>
(脚注)
ディレクトリサービス(DS)の典型例が電話帳(e.g. タウンページ)です。
認証システムもユーザとパスワードの一覧という電話帳似のデータを持つので DS です。
例: Active Directory, OpenLDAP(-> 後継? 389-ds?)
</small></small>
</div>

![電話帳](/slides/network/tcpip/app_dns/images/yellowpage.jpg)

<small>
- Domain Name System (Service)の略
- **ディレクトリサービス**の一種
- 文字列からIPアドレスを検索する仕組みが代表例です:
  DNSの検索例
    - portal.mc.chitose.ac.jpドメインのIPアドレスを知りたい
    - IPアドレス210.128.52.45に対応するサーバ(のドメイン)名が知りたい
    - user@photon.chitose.ac.jp宛メールの送信先(メールサーバ名)を知りたい
    - photon.chitose.ac.jpについて管理しているDNSサーバを知りたい
</small>

---
class: img-right,compact
# あらゆるサービスが裏でDNSを使っています

<div class=footnote>
<small><small>
右図: portal.mc.chitose.ac.jp にアクセスしている様子。
<br>
ブラウザは、裏で
(1)(2)DNSを使ってIPアドレスを割り出し、
(3)(4)そのIP(210.128.52.45)へアクセスします
</small></small>
</div class=footnote>

![](/slides/network/tcpip/app_dns/images/resolver.png)

<small>
- ユーザ利便性はドメインの方がよいはず
- ユーザがIPアドレスでインターネットにアクセスするのは現実的ではありません
    - 何十個も数字を覚えられる?
    - 英語に近い表記を使いたい
        - 例: `https://portal.mc.chitose.ac.jp/`
        - 例: `username@photon.chitose.ac.jp`
- プログラムにとっては、すべて**数字**
    - **OSの内部**では、通信先の指定を**数字=IPアドレス**で行っています
      <br>
      (例: 210.128.52.45)
</small>

---
class: col-2,compact
# DNS関連の重要用語まとめ

<div class=footnote>
<small><small>
(脚注1)業界人はdotを発音しませんが、あうんの呼吸で理解してね
(脚注2)Googleのchubbyも地球規模ですな...
</small></small>
</div class=footnote>

<small>
- **DNS**
    - Domain Name System (Service)
    - インターネットの基盤技術
    - 地球規模の**分散システム**の成功例
    - **UDP**ベースの数少ない例
- **ドメイン名**
    - **.**(発音はdot)区切の文字列
        - chitose.ac.jp
    - **FQDN** (Fully Qualified Domain Name)
        - ホストの完全なドメイン名
        - 階層をすべて表記したもの
            - portal.mc.chitose.ac.jp
            - g201pc001.pc.chitose.ac.jp

<wbr>
- **木構造**をしたデータベース
    - 格納している情報を**レコード**と呼ぶ
    - 例:Aレコード(IPアドレス)
- **ネームサーバ** (歴史的にはコレ)
    - 最近はDNSサーバと言うことも多い
    - スライドは**DNSサーバ**に統一
- **名前解決**(name resolution)
    - ネームサーバから情報を取得することで、
      この動作をするソフトウエアが**リゾルバ**(resolver)
    - 例:ドメイン名からIPアドレスを取得
</small>

---
class: col-2,compact
# ドメイン名

- ドット`.` 区切りの文字列
    - 使える文字は、英数字とハイフン(**-**)です
      (大文字小文字は区別しません)
    - 階層構造を表現しています(後述)
- 例: メールアドレス
    - b999999@photon.chitose.ac.jp
       - photon.chitose.ac.jp がドメイン名
       - b999999 はユーザ名
         (大文字小文字を区別したほうが良いでしょう。
	  区別するかしないかは微妙な話題で、
	  メールサーバとOSの実装依存ですが、
	  厳しい方に合わせるのが安全です)

<wbr>
- 用法上の注意
    - ドメインとドメイン名の使い分けはRFCも曖昧で断言しづらい...;_;
        - ドメイン: 領土のような意味合いに力点がある場合?(抽象的?)
        - 同じ意味で使っているようにみえる場合もあり...
            - ドメイン名をドメインと呼ぶ例: TLD(後述), サブドメイン
    - たとえばportal.mc.chitose.ac.jpの場合、(一番左の)
      ホストの役割を説明するportal部分をホスト名と呼ぶ風習がありますが、
      **コンピュータを識別するための名前(ホスト名)にはFQDN**を使うべきです

---
class: col-2,compact
# ドメインの階層構造(全体とTLD)

- ドット`.` 区切りの文字列
- 階層構造
    - **ホスト名.組織.組織種別.国名**
    - 右側がより大きな単位
    - 例: chitose.ac.jp
        -    chitose (千歳、この場合は大学名)
        -    ac (高等教育機関,academic)
        -    jp (日本,TLD)
- TLD (top level domain)
    - 一番大きな単位(一番右側)
    - もともとは国ごと+アメリカ特例枠
    - 基本は二文字の国名
        - jp (日), uk (英), us (米国,USA)
    - 各TLDごとに登録を管理する組織(レジストラ,民間企業)があります
    - アメリカ特例枠
        - (初期から存在する)us をつけないアメリカのドメイン
        - com net org が有名
            - 1990年代後半に一般開放したため、
              ドメイン取得者がアメリカ人とは限りません
            - 慣習的に<br>「**ソフトウエア名(OSS).org**」
                - 例: fml.org (このサーバ:-)
        - edu gov mil ... アメリカ固有
    - 目的別? info tel
    - 地域? asia など
    - その他も(気づくと)新TLDが登場...

---
class: compact
# ドメインの例

| TLD | 2LD     | 属性                   | 例                                        |
|-----|---------|------------------------|-------------------------------------------|
| net |         | ネットワーク           | nuinui.net                                |
| com |         | 営利企業               | amazon.com zoom.com(zoom.usへ転送)        |
| org |         | 任意団体(ソフト名)     | netbsd.org debian.org postfix.org fml.org |
| edu |         | アメリカの高等学術機関 | mit.edu                                   |
| gov |         | アメリカ政府           | www.whitehouse.gov                        |
| mil |         | アメリカ軍             | af.ml  (US空軍)                           |
|     |         |                        |                                           |
| us  |         |                        | zoom.us                                   |
|     |         |                        |                                           |
| jp  | ac      | 日本国内の高等教育機関 | chitose.ac.jp                             |
|     | co      | 民間の営利企業         | toyota.co.jp amazon.co.jp                 |
|     | go      | 政府関係               | mext.go.jp                                |
|     | ed      | 教育機関               | sapporonishi.hokkaido-c.ed.jp             |
|     | lg      | 地方自治体             | pref.hokkaido.lg.jp                       |
|     | 名前    | なし                   | toyota.jp amazon.jp(co.jpへ転送)          |

---
class: img-right,compact
# ドメインの階層は木構造

<div class=footnote>
<small><small>
(脚注)
正しいドメイン名は一番右に.がつきますが、
面倒(?)なので、たいてい一番右の.を省略して書くことが多いです
(例: portal.mc.chitose.ac.jp.)
</small></small>
</div>

![](/slides/network/tcpip/app_dns/images/tree.png)

- 各TLDごとに管理
    - 各TLDごとにレジストラ(+ レジストラへの登録代行業者)
    - jpドメインは[JPRS](https://www.jprs.co.jp/)(2002/04/01-)
      (2002/03/31までは[JPNIC](https://www.nic.ad.jp/))
- DNSは図のように木構造と考えられます
    - 数学のグラフ理論由来で、接点はnode、端はleaf(葉)、線はedge(枝)です。
      一番上には**.**で表現される**root(根)ノード**があるという想定
    - DNSの検索(query)とは、一番上の**rootノードから枝を下っていくこと**