2020-09-27 用課題¶
- FTP: file transfer protocol
- 先に進む前に録画してあるか確認しよう
進捗¶
- 今日の進捗
- 基礎知識編:P.370 プロトコルとサービス、ポート・ポート番号、P.397 アプリケーション間の通信、P.398 7.6 アプリケーション層のプロトコル、P.398 7.6.1 メール関連、P.398 メールプロトコル、補足:POP と IMAP、Gmail と IMAP
- 本編:03_03 終了
- 次回
- 本編:03_04 はじめから
課題¶
- オリジナルコンテンツへのリンク
- 勉強会のコンテンツまとめ:GitHub へのリンク
- matplotlib を忘れないように、簡単なグラフをいくつか描いてみてください。
- TeX でいろいろな式を書いてみましょう。
- 実際に競プロの問題をいくつか解いてみましょう。例えば次のあたりからアタックします。数学・物理系の話として、まずはマスターオブ整数を眺めてみます。今回は6. 素因数分解を活用した考察の6-2. ひねった状況でも「約数の個数」がわかるを見ましょう。
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
TODO¶
- 東大の AWS クラウド講義資料を眺めてみてください。せっかくなので状況を見て(私の勉強も兼ねて)「勉強会前半パート」で取り上げようと思います。(とりあえず当面はやらない感じにする?)
- 面白そう:Julia での機械学習アルゴリズム本
- Algorithms for Optimization by Mykel J. Kochenderfer and Tim A. Wheeler @mitpress
自分用メモ¶
- 遅延型方程式に対するコメント追加
- matplotlib のチュートリアルを読もうの会
- 公式情報に触れる重要性
- 古い情報が古いと書いてあったりする:たとえば
pylab
- Gallery
- 見ていて面白い
- 「どこをいじるとどう変わるか」が視覚的にわかる
- 公式情報なのできちんとアップデートしてくれている(はず)
- 公式情報にソースがあるので自分でいろいろ書き換えていて破滅したとき、必ずオリジナルを復元できる
Matplotlib¶
- 本当に簡単な図を描く
- これを参考に scipy お絵描き
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
TeX の記録¶
- 3 次元極座標
\begin{align} x &= r \sin \theta \cos \phi, \ y &= r \sin \theta \sin \phi, \ z &= r \cos \phi. \end{align}
競プロ、AtCoder¶
6. 素因数分解を活用した考察の6-2. ひねった状況でも「約数の個数」がわかる¶
問題¶
$N!$ の正の約数の個数を $1000000007$ で割ったあまりを求めよ。
$1 \le N \le 1000$
(数値例)
・$N = 3$
答え: 4
$3! = 6$ の約数は、$1, 2, 3, 6$ の $4$ 個です。
ポイント¶
- $N!$ は巨大なので約数列挙では途方もない時間がかかる。
- $N!$ を求めてからの約数列挙は非現実的。
-
素因数分解で約数の個数を求める
- 正の整数 $M$ が $M = p_{1}^{e_{1}} p_{2}^{e_{2}} \dots p_{K}^{e_{K}}$ と素因数分解できるとき、$M$ の約数の個数は $(e_{1} + 1)(e_{2} + 1) \dots (e_{K} + 1)$ 個
- $N!$ を計算しなくても $N!$ の素因数分解が分かれば十分
-
n_1 = p_1^{e_1} ...
- n_2 = p_1^{e_1} ...
- N! = p_1^{e_1} ...
コードの参考¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
|
1 2 3 |
|
Project Euler も見てみよう¶
- Problem5
- GitHub の回答集
- 中高生の数学・プログラミング学習用によかろうと思い、ちょこちょこやっている
IT 基礎知識¶
- 応用情報の本を一日2ページくらい眺めてみてください。毎日やれば大体 1 年で読み終わります。
復習¶
OSI基本参照モデル¶
- 会社の部署と同じ気分
- 特定層は自分のところにしか責任を持たない
- 「他の層は他の層で専門的に管轄してね」
- お互い全くの無関係ではないが、基本的には自分のことだけ考えていればいい。
いろいろなプロトコル¶
- IP, HTTP, SMTP, POP, ARP...
- 通信の規格
- 状況に応じて適切なプロトコルを選ぶ
- ヘッダ・ボディーの概念
本の記述を追いかける¶
ポート・ポート番号¶
ポートとは、ネットワークでデータを通信するための扉のようなものだと思うとわかりやすいだろう。ポート番号はその扉の番号だ。
それぞれプログラムの種類によって、使うポート(扉)が違う。例えば、メールを送るにはこの扉、メールを受け取るにはこの扉、Webページを見てもらうのはこの扉、などと決まっているわけだ。
実際TCPやUDPで通信を行うときは、コンピュータ一台という単位ではなく「プログラム単位」つまり「プロセスやスレッド単位」で通信が行われる。そのためプロセス同士、正しく受け渡しをする必要がある。
- プロセス・スレッドなどいきなりかなり低レイヤーの話がでてくることに注意。
このとき通信しているプロセスには「ポート番号」というものが割り振られる。プロセスやスレッドはこのポート番号を目印にして、どのアプリケーションとどのアプリケーションが通信をとっているのかを判別することになる。
IPアドレスを建物の住所に例えるなら、ポート番号は「部屋の番号は何号室か?」という例えになる。コンピュータネットワークにおいて、プロトコル、IPアドレスとポート番号はまとめると、「どのような方法」で「どこ」の「何号室」に通信をとるのか?という形にいいかえることが出来る。
通信において重要なポート番号だがポートを開くということは、特定の部屋の扉をあけはなっている状態に等しいので、サービスを提供するサーバでもないかぎり、基本的に不必要なポートは開かないように設定しておかなければならない。
- サーバーのセキュリティなども絡むが分かる。
代表的なポート番号とプロトコル それぞれ「どの様なプロトコルがどの様なポート番号で運用されるのか?」代表的な例をあげると以下のようになる。
- TCP 20 : FTP (データ)
- TCP 21 : FTP (制御)
- TCP 22 : SSH
- TCP 23 : Telnet
- TCP 25 : SMTP
- UDP 53 : DNS
- UDP 67 : DHCP(サーバ)
- UDP 68 : DHCP(クライアント)
- TCP 80 : HTTP
- TCP 110 : POP3
- UDP 123 : NTP
- TCP 443 : HTTPS
- WELL KNOWN PORT NUMBERS 0~1023
- MySQL: 3306
P.397 アプリケーション間の通信¶
- トランスポート層にはアプリケーション間の通信の実現という役割がある
- 各アプリケーションはトランスポート層のヘッダにあるポート番号をみて自分宛のデータか判断する。
P.398 7.6 アプリケーション層のプロトコル¶
P.398 7.6.1 メール関連¶
P.398 メールプロトコル¶
- 送信転送する SMTP (Simple Mail Transfer Protocol)
- メールを受け取る POP3 (Post Office Protocol 3)
- IMAP (Internet Message Access Protocol)
補足:POP と IMAP¶
- (気分的には)管理する主体が違う
- POP は単純にサーバーからメールデータを取ってくる
- 取ってきたらサーバーからデータが消える
- そのあとは自分で管理する
- IMAP の説明の参考
- 郵便にたとえると、(実際にはできませんが)郵便局から手紙は受け取らずコピーをもらってくるような形になり、手紙は郵便局が保管することになります。
- メールはサーバに保管されますので、既読・未読・削除、フォルダの分類といった管理は、すべてサーバ上で行われます。
- いろいろな端末でメールが見られる
- POP と IMAP のメリット・デメリット
- POP
- メリット
- PC などの端末にメールが保存される
- 端末が許す限りメールを保存できる
- 端末に保存されたメールはネット接続なしで見られる
- デメリット
- 落としてきた端末でしたメールが見られない
- サーバーに一定期間メールを残す設定で複数端末でメールを見ることもできるが、未読・既読・削除などの状態が反映されない
- メリット
- IMAP:サーバー上でメール管理
- メリット
- 未読・既読などの状態が共有できる
- サーバー上で一元管理できる。
- デメリット
- メールの閲覧・状態修正のためにサーバーと通信する必要がある
- サーバーの容量の上限に達するとメールからサーバーを削除する必要がある
- メリット
- POP
Gmail と IMAP¶
- (何となくの理解しかないので間違っているかもしれない)
- Web インターフェースからの Gmail 利用と Thunderbird などのアプリからの利用で事情が違う
- POP や IMAP が関係してくるのはアプリからの利用
- アプリを使う場合はふつう IMAP を使う
- 参考:公式での説明
- IMAP にしないと他の端末、もっといえば Web インターフェースからも見られなくなる(はず)
- 会社で特定端末からしかメールを見ないなら POP でもいいかもしれない。
- マシンが変わるとき、メールデータも引越ししないと昔のメールが掘れない
- 会社のメールサーバー管理問題・容量問題などはかなり大変
- 一頃「Gmail でサーバー管理問題を解決して、IT 部門が攻めの IT を提案できるようになった」みたいな記事も出ていた
- メールが止まると直接的にビジネスに被害が出る
- 何にせよサーバー管理は大変なので
P.398 メール受信プロトコル、メール関連のプロトコル・規格¶
- 昔のプロトコルはセキュリティ関連の仕様がなかった
- SMTP-AUTH, SMTP over TLS/SSL など
P.399 Web 関連¶
- HTTP: HTTP(Hyper Text Transfer Protocol)は WebサーバとWebクライアント(ブラウザ)間でHTMLなどのWeb情報の配信 に使うプロトコル
- セキュリティ:HTTP に SSL/TLS の認証機能や通信の暗号化を実装した HTTPS が登場
- SOAP: XML を使ってデータ構造を記述
- 最近あまり見かけない印象
- XML 自体もうあまり使わない
- 最近は JSON や GQL をよく見かける
P.401 DNS(Domain Name System)¶
- TCP/IPでは,各ノードに対して一意なIPアドレスが割り当てられている
- IPアドレスは覚えにくい
- IP アドレスと対応する別名であるドメイン名がつけた
- ドメインと IP を対応させるサービスが DNS
- 原理的には世界中のすべてのノードのドメイン名とIPアドレスの対応関係を知ってい なければならない
- 事実上不可能
- DNSの規約では変換表作成の負担を細分化して,DNSを分散データベースとすることで対応しています。
- DNS ルートサーバー
- DNS ポイズニングのような攻撃手法もある
P.402 DNS クライアント(リゾルバ)の名前解決要求¶
コンテンツサーバへの問い合わせを繰り返すのは非効率なので,通常,自組織内にキャッシュサーバを置きます。この場合,リゾルバはキャッシュサーバに問い合わせを行い,キャッシュサーバ内に該当情報がキャッシュされていれば直接回答を得ることができます。ない場合は,キャッシュサーバが組織外のコンテンツサーバに問い合わせを行い,その結果をリゾルバに回答します。また,キャッシュサーバは,同様の問い合わせの際に再利用できるよう,問い合わせで得た結果を一定期間キャッシュします。
リゾルバからキャッシュサーバに送られる問い合わせを再帰的な問合せという。"再 帰 的"とは,「再び帰ってくる」という意味で,再帰的な問合せに対しては,最終的な結果を回答する必要がある。
- 例えばディレクトリツリーを掘るタイプのプログラムではよくやる処理
- (F* で)競プロをやっていると意外と再帰を使う(使える)ことに気づいた
- いわゆる関数型言語は(命令型で)ループを使うところは高階関数か再帰で処理する
- たいてい高階関数で足りる
- 再帰は末尾再帰など面倒ポイントがある
P.402 インターネット上の電話サービスで用いるプロトコル¶
- VoIP(Voice over Internet Protocol)
- IPネットワークで音声をやり取りするための技術
- データの伝送にはリアルタイム性に優れたUDPをベースとしたプロトコルが使われる
- 届かなかったらもう一度しゃべらせればいい
P.403 その他のアプリケーション層プロトコル¶
- FTP:ファイルを送る。ポートは 20、21
- セキュリティが甘いので FTP、FTPS、SFTP、SCP などがある
- Telnet:(あまり使ったことない)
- SSH(Secure SHell):サーバーにログインするときに使う。とにかくよく使う。
- テキストベースの通信であるTelnetに対し,暗号化や認証技術を利用して安全に遠隔操作するためのプロトコル
- NTP・SNTP(Network Time Protocol):時刻合わせ
- LDAP(Lightweight Directory Access Protocol):ディレクトリサービスにアクセスするためのプロトコル
- Windows の ActiveDirectory も LDAP を使っている
- 社員情報をやり取りするシステム間連携で出てくる
P.404 7.7 伝送技術¶
P.404 誤り制御¶
- 誤り検出により再送を行う方法 ⇒ パリティチェック,CRC
- 誤り訂正により自己修復を行う方法 ⇒ ハミング符号
P.404 パリティチェック¶
- 最もシンプルな検査方法
- 7 ビットのデータを送信する場合,8 ビット目に誤り検出用のパリティビットを入れてデータの整合性を検査
- 偶数パリティ:8ビットの各ビットについて"1"の数が偶数になるようにパリティビットを挿入する
- 奇数パリティ:上で奇数にする
- 有限体(ガロア体)$\mathbb{F}_2$ (ビット)で考えるといってもいい。
- 微分形式で偶数次と偶数次・偶数次と奇数の積が偶数次になり、奇数次と奇数次の積がと奇数次になるのも一種のパリティチェック。
- cf. P.405 水平垂直パリティチェック
P.404 CRC¶
- CRC:巡回冗長検査(Cyclic Redundancy Check)
- 送信するデータに生成多項式を適用して誤り検出用の冗長データを作成し,それを付けて送信
- 受信側は送信側と同じ生成多項式で受信データを割り,同じ結果であればデータ誤りが ないと判断
- CRCでは複雑な演算を使ってバースト誤り も検出できる
- バースト誤り:データ転送回線上で連続して発生するビットの誤りのこと。ノイズの混入で生じることが多い。
- HDLC 手順が採用
P.404 ハミング符号¶
- 上で紹介した動画で簡単に数学的な原理を紹介している
- 情報ビットに対して検査ビットをつけて 2 ビットまでの誤り検出と,1 ビットの誤り自動訂正機能をもつ誤り制御方式
- 原理的には何ビットの誤り検出・自動訂正でもできる
- 代数幾何符号もある
- 数学的にはもちろん難しい
- 有限体上の(非特異な射影)代数曲線を使う
P.406 同期制御¶
- 通信時に送信側と受信側でタイミングを合わせる必要がある。
- 本の話題とは別に同期・非同期にはいろいろな話があって難しい。
- プログラミング、特に JavaScript フロントエンド周り。
- 通信待ちしていると UX を阻害するのでうまいこと非同期処理を使う
- もちろんバックエンドでもいろいろやらないといけない
- 参考:マイクロサービスにおける非同期アーキテクチャ
- データベースの同期・非同期
- 大規模サービスでの問題、READ-WRITE、マスター・スレーブ
- ふつう読み込みに比べて書き込みは少ない
- 場合によっては読み込みは完全に最新の情報でなくてもいい
- 書き込みメインのデータベースと、その内容を適当なタイミングでもらってくる読み込み専用のデータベースがある:これがマスターとスレーブ
- 参考:前にやった Twitter のシステム構成など
- 適当な意味で完全同期していないとまずいシステムもある:銀行・金融系
- cf. トランザクション
- トランザクションはふつう銀行が例になるくらい、そちらの話が有名でしかもイメージしやすい
P.408 7.8 交換方式¶
P.408 パケット交換方式¶
- 回線交換方式と対になる概念
- 回線交換方式:通信を行うノード間で物理的な通信路を確保してから通信する
- 例:電話
- パケット交換方式について
- データ送信するノードはデータをパケットに区切る。
- ひとつひとつのパケットにヘッダを付けて送信。
- ネットワーク内ではパケット交換機にパケットがたまる
- ネットワークの状況に応じて順次送られる
パケット通信のメリット・デメリット¶
メリット¶
耐障害性 - 通信路を固定しないため,迂回経路が取れる。 - パケット交換機にデータが蓄積されているため,復旧まで待てる。 - パケット多重 - 1 対 1 の通信で回線を占有する必要がないため,1つの回線を多くのノードで共有でき,回線を効率的につかえる - 異機種間接続性 - パケット交換機で中継するときにプロトコル変換・速度変換でエンドノードどうしが同じプロトコルをサポートしていなくても通信できる
デメリット¶
- ネットワーク内の蓄積交換処理による遅延
- 蓄積交換処理による遅延解消のために主に回線の帯域を広げることで対応してきた
- 構造上,完全には遅延をなくせない
- パケット到着順序の不整合
P.408 ATM 交換方式¶
- ATM(Asynchronous Transfer Mode:非同期転送モード)
- 遅延のない回線交換方式とパケット交換方式の利点を得たい
- パケット交換方式の発展
- 遅延の原因をつぶす:特にパケットの多様性
- 多種多様なパケットに対応するために,パケット交換機はソフトウェア処理が必要 ^ ATM での工夫の一例:最も特徴的なのは,パケット(ATMではセルという)の長さをヘッダ部 5 バイト,ペイロード 48 バイトの53バイトに統一
- パケット解析がハードウェアだけでできる。
- ソフトウェアは不要になった。
- Wikipedia から
- 当初の意図に反して非常に複雑な技術になってしまった
- ATM は次世代の主流にならず限定的な使用にとどまった
- ATM の設計思想は MPLS へと引き継がれた
- 汎用のレイヤ 2 のパケットスイッチングのプロトコルとして、ルーターを介したIPの通信網で利用されている。
P.408 ペイロード(payload)¶
- データ通信で本来転送したいデータ本体の部分、ボディを指す。
- ATM ではペイロードのサイズを固定して処理を簡素化
- 難点:パケット全体に占めるペイロードのサイズが相対的に小さくオーバヘッドが大きい
P.410 輻輳¶
- フレームリレー:パケット交換方式の一種
- 1 つの回線を多数のユーザで共有。
- 回線がもつ潜在的な伝送能力(ワイヤスピード)を十分に引き出すうえで効果がある
- 輻輳:ユーザの利用が一時期に集中すると,ワイヤスピードを超えるパケットがネットワーク上に流れる
- ネットワークが輻輳状態になるとスループットが落ちる
- フレームリレーサービスを提供する事業者は,ネットワークが輻輳状態に陥ってスループットが低下しても最低限保証する通信速度を決めている
- CIR(Committed Information Rate:認定情 報速度)
P.370 7 ネットワーク¶
- 確か 7.4 から始めた気がするので 7 章はじめから
P.370 7.1.1 OSI基本参照モデル¶
- 改めて復習
- OSI(Open System Interconnection)基本参照モデル- 異なる設計思想・世代のシステムと円滑に通信するのが目的に標準化
- プロトコルの単機能化,交換の容易さが目的
- 階層化のおかげで一部の階層の技術体系が変わっても、その階層だけ取り替えればいい
- コスト・リスクを小さくする
P.370 プロトコルとサービス¶
- N 層:それぞれの階層のこと
- エンティティ:N 層に存在する通信機器などの実体
- この言葉はいろいろなところで出てきていろいろな意味で使われる
- もちろん気分的には適当な実体を指すことが多い
- プロトコル:N 層に属するエンティティが通信するための取り決め
- 上位の層が下位の層を利用しながら通信する
- 別の階層間のエンティティどうしが通信する窓口が必要
- これを提供するのが下位層:この機能をサービスと呼ぶ
- プロトコルに沿った仕様で製品を開発すれば別のベンダの機器でも通信できる
- 参考:ベンダーロックイン
特定ベンダー(メーカー)の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。
出来上がった情報システムの正確な仕様が、システムを開発・構築したベンダーにしか解らなくなる場合がある。結果、システムの保守・拡張・改修等の際、現存システムを開発・構築したベンダーに引き続き発注せざるを得なくなる。
- 「Excel で行政に提出する書類を作れ」事案もそれ。
- Apple 製品で身の回りを固めるのも同じ。
- 「多様性が大事」事案でもある。
7.1.2 TCP/IPプロトコルスイート¶
- プロトコル同士には相性がある
- 「ネットワーク層がこのプロトコルならトランスポート層はこのプロトコルにしておくとトラブルが少ない」
- 一般に同じ団体が作ったプロトコルはセットで使われることが多い
- このセットがプロトコルスイート ^ 最も代表的なのは IP を中心に組まれた TCP/IP プロトコルスイート
- 独自の階層モデルをもつ
P.372 TCP/IPの通信¶
- データをパケットに区切る
- 各パケットにヘッダを付けて送信
- ヘッダは各階層ごとに付加されて次の階層へと渡される
- 各ヘッダにはその階層で必要となる送信元や送信先,大きさ,順番などパケット自体に関する情報を含む
- TCPヘッダを付加したパケット:TCP セグメント
- IP ヘッダを付加したパケット:IP パケット
- MACヘッダを付加したパケット:MAC フレームあるいはイーサネットフレーム
P.372 MAC(Media Access Control)アドレス¶
- イーサネットや FDDI で使用される物理アドレス
- イーサネット (Ethernet):コンピューターネットワークの規格の1つ。オフィスや家庭で一般的に使用されている有線LAN (Local Area Network) の技術規格
- FDDI:LAN でデータ転送を行うための標準の一つ
- Fiber distributed data interface
- データリンク層
- 同じネットワークに接続された隣接ノード間の通信で相手を識別するために使う
- MACアドレスの長さ:6バイト
- 先頭24ビットの OUI(ベンダID)
- 後続24ビットの固有製造番号(製品に割り当てた番号)
- MAC アドレスは機器が固有にもつ番号
- 必ず一意に定まるように IEEE が管理
P372 ポート番号¶
- トランスポート層にでノード内のアプリケーションの識別に使う識別子番号
- 0-65535の範囲
- TCP/IPではパケット交換方式でデータをやり取りする
- よく使われるアプリケーションについてのポート番号は Well-Known ポートとして標準化
- TCP・UDPそれぞれで 0-1023 番までの番号を割り当てている
- SSH:TCP22番
- Telnet:TCP23番
- SMTP:TCP25番
- HTTP:TCP80番
- POP3:TCP110番
- IMAP4:TCP143番
- HTTPS :TCP443番
- NTP:UDP123番
- SNMP:UDP161番
- SNMP Trap :UDP162番
- セキュリティ対策のために標準とはポート番号を変えることもある
- Web 開発の本を読んでいると、いろいろな都合から http のポートを 80 以外にしていることもよくある。
- 80 の場合はポートを指定しなくてもいい
- 例:http://localhost/hoge/fuga
- 例:http://localhost:5000/hoge/fuga
- 80 の場合はポートを指定しなくてもいい
P.373 ネットワーク間の通信¶
- 同じネットワークに接続されたノード間はデータリンク層(第 2 層)の通信
- ネットワークを超えたノード間はネットワーク層(第 3 層)の通信 -実際に図 7.1.4 を見よう
- どこが IP アドレスでのやりとりか?
- どこが MAC アドレスでのやり取りか?
P.374 7.2 ネットワーク接続装置と関連技術¶
P.374 7.2.1 物理層の接続¶
P.374 リピータ¶
- ネットワーク上を流れる電流の増幅装置・整流装置
- 物理層:第 1 層
- データ通信はネットワーク上を流れる電流
- ケーブルが長いと電流が減衰・波形が乱れが起きる
- データが読み取れなくなる
- これを増幅するのがリピータ
- 大昔の電話は距離が遠いと音が小さく聞こえにくかった
- まさにこの減衰が問題
- リピータは 1:1 で繋ぐ
- 現在では複数のノードを接続できるマルチポートリピータ(ハブ)が使われるのが一般的
P.374 7.2.2 データリンク層の接続¶
- 第2層
P374 ブリッジ¶
- データリンク層に位置
- ネットワーク上を流れているフレーム(情報の単位)の MAC アドレスを認識して通信を中継する
- 接続されているノードをコリジョンドメイン(セグメント)という単位に分割
- MAC アドレスで判定したフレームのあて先のあるセグメントだけにフレームを送信
- 無駄なトラフィックの回避