WEBVTT 00:00.090 --> 00:01.020 Jason: このレッスンでは､ 00:01.020 --> 00:03.480 TCP､ UDPを含むIPプロトコルの種類と､ 00:03.480 --> 00:10.020 コネクションレス方式とコネクションオリエンテッド方式の概念について説明します｡ 00:10.020 --> 00:12.300 さて､ TCPとは何か？ 00:12.300 --> 00:15.270 TCPとはTransmission Control Protocol（伝送制御プロトコル）の略｡ 00:15.270 --> 00:17.340 これはコネクション指向のプロトコルであり､ 00:17.340 --> 00:22.080 ネットワーク上でセグメントを伝送する信頼性の高い方法であることを意味する｡ 00:22.080 --> 00:23.580 これで､ セグメントがドロップされた場合､ 00:23.580 --> 00:26.603 プロトコルは実際に毎回確認応答を求めることになる｡ 00:26.603 --> 00:28.890 そして､ 承認が得られなければ､ 00:28.890 --> 00:31.530 その情報を再送することになる｡ 00:31.530 --> 00:34.410 コネクションフル・プロトコルと呼ばれる所以は､ 00:34.410 --> 00:38.280 私があなたに情報を送り､ あなたがそれを受け取ったかどうかを私が確認し､ 00:38.280 --> 00:43.170 あなたが私に応答を返すという双方向の情報伝達があるからです｡ 00:43.170 --> 00:46.230 では､ この小さな図をちょっと見てみよう｡ 00:46.230 --> 00:49.800 左がクライアント､ 右がサーバーであることがわかるだろう｡ 00:49.800 --> 00:55.950 さて､ クライアントは同期パケットと呼ばれるものをサーバーに送る｡ 00:55.950 --> 00:58.170 サーバーはそれを受け取ると､ 00:58.170 --> 01:02.580 同期確認をクライアントに送り返す｡ 01:02.580 --> 01:04.740 さて､ クライアントはその確認応答を受け取ると､ 01:04.740 --> 01:07.380 サーバーに確認応答を送り返す｡ 01:07.380 --> 01:09.060 これを「アック」と呼ぶ｡ 01:09.060 --> 01:11.940 さて､ このsyn､ syn ack､ ackを行うとき､ 01:11.940 --> 01:15.030 私たちはこれを3ウェイ・ハンドシェイクと呼んでいる｡ 01:15.030 --> 01:16.807 基本的には､ クライアントが「おい､ 01:16.807 --> 01:20.377 サーバー､ 何か情報を得る準備はできたか？ するとサーバーは「もちろんです｡ 01:20.377 --> 01:20.377 なぜだ？ 01:20.377 --> 01:21.367 「情報を送ってくれ｡ そしてクライアントは､ 「よし､ 来た｡ そして､ 3者間のハンドシェイクが確立し､ 01:21.367 --> 01:22.920 双方が通信の準備ができていることがわかったので､ 01:22.920 --> 01:25.440 送信を開始する｡ 01:25.440 --> 01:27.630 「さあ､ 準備はいいかい？ 「はい､ そうです｡ "来たぞ｡ セグメントと呼ばれるこのデータがネットワークを介して送信されるたびに､ 01:27.630 --> 01:35.107 受信した確認応答があり､ 双方向通信が成功したことを教えてくれる｡ 01:35.107 --> 01:39.150 もしこのサーバーが100の情報を期待していたのに､ 01:39.150 --> 01:46.980 98の情報しか得られなかったとしたら､ クライアントにこう言うだろう｡ 01:46.980 --> 01:48.600 「足りないものを2つ送ってくれ｡ そして､ 再送信が行われる｡ 01:48.600 --> 01:53.587 こうすることで､ パケットをネットワーク上で再送信することができるため､ 01:53.587 --> 02:00.450 通信を円滑に進めることができる｡ 02:00.450 --> 02:03.563 現在､ これは最終目的地に到達するために保証が必要なすべてのネットワークデータに使用されている｡ 02:03.563 --> 02:05.310 私はこれを内容証明郵便のように考えたい｡ 02:05.310 --> 02:07.470 例えば､ 国税庁にメッセージを送りたい場合､ 02:07.470 --> 02:09.450 確実に受け取ってもらいたい｡ 02:09.450 --> 02:10.920 だから､ 少し余分にお金を払って､ 02:10.920 --> 02:13.170 配達証明付きの領収書を発行してもらい､ それにサインをしてもらって､ 02:13.170 --> 02:19.470 それを郵送してもらうこともある｡ 02:19.470 --> 02:25.620 そうすれば､ 領収書が戻ってきたときに､ 国税庁が私の郵便物を受け取ったことがわかる｡ 02:25.620 --> 02:27.630 それがTCPの仕組みだ｡ 02:27.630 --> 02:31.080 一方､ UDPという別のプロトコルもある｡ 02:31.080 --> 02:32.820 UDPはいわゆるコネクションレス・プロトコルで､ 02:32.820 --> 02:33.653 接続を待つ必要がない｡ 02:33.653 --> 02:34.740 UDPはUser Datagram Protocolの略｡ 02:34.740 --> 02:37.500 これをデータグラムと呼ぶのは､ UDPを使う場合､ 02:37.500 --> 02:41.220 このタイプのデータを使うからだ｡ 02:41.220 --> 02:44.250 これはデータグラムと呼ばれる｡ 02:44.250 --> 02:47.250 さて､ UDPについて話すと､ UDPは信頼性が低く､ 02:47.250 --> 02:52.830 データグラムと呼ばれるセグメントを送信する｡ 02:52.830 --> 02:54.270 そして､ もし落とされたとしても､ 02:54.270 --> 02:56.160 送り手はそのことに気づくことはない｡ 02:56.160 --> 03:01.317 さて､ なぜ送り主が気づかず､ 領収書ももらえないようなものを送りたいのだろう？ 03:01.317 --> 03:06.510 UDPはオーディオやビジュアルのストリーミングにとても適している｡ 03:06.510 --> 03:14.220 なぜなら､ UDPを使えば､ 大量のデータを送信してもオーバーヘッドが少ないからだ｡ 03:14.220 --> 03:17.850 つまり､ UDPを使えば､ 再送信がゼロになるので､ 03:17.850 --> 03:22.620 ネットワークのパフォーマンスを本当に向上させることができる｡ 03:22.620 --> 03:24.810 情報を垂れ流すだけになってしまう｡ 03:24.810 --> 03:25.950 さて､ それは悪いことではないのか？ 03:25.950 --> 03:27.840 なぜ情報を落としたいと思うのか？ 03:27.840 --> 03:32.520 まあ､ 特定の用途では､ それは本当に問題ではない｡ 03:32.520 --> 03:35.190 例えば､ あなたは今このビデオをストリーミングしている｡ 03:35.190 --> 03:37.800 それに､ もし私が1/100秒でも抜けたとしたら､ 03:37.800 --> 03:39.870 あなたはそれに気づくだろうか？ 03:39.870 --> 03:41.490 UDPが優れているのは､ 03:41.490 --> 03:46.740 1/100の時間でドロップしても､ 03:46.740 --> 03:49.440 再送信が発生しないことです｡ 03:49.440 --> 03:52.110 しかし､ TCPの場合､ 待たされ､ 03:52.110 --> 03:56.820 再送信され､ 適切な場所に置かれ､ 03:56.820 --> 04:01.320 再生されるため､ バッファリングが多くなる｡ 04:01.320 --> 04:03.120 そのため､ この映像の1秒1秒を認識し､ 04:03.120 --> 04:04.740 オーバーヘッドを発生させるため､ 結局､ 04:04.740 --> 04:07.440 映像が大きくなり､ 帯域幅を多く使うことになる｡ 04:07.440 --> 04:09.810 これが､ ビデオ・ストリーミングやオーディオ・ストリーミングにUDPを使う大きな理由のひとつだ｡ 04:09.810 --> 04:11.250 さて､ ここでTCPとUDPについて簡単にまとめてみよう｡ 04:11.250 --> 04:13.770 これは本当に､ 本当に重要なコンセプトだからだ｡ 04:13.770 --> 04:15.870 TCPとUDPの違いについて話すので､ もし今ノートを持っているのなら､ 04:15.870 --> 04:21.150 このグラフを書き留めておいてほしい｡ 04:21.150 --> 04:24.660 それは本当に重要なことだからだ｡ 04:24.660 --> 04:28.740 さて､ まずTCPは信頼性が高く､ 3ウェイ・ハンドシェイクを行うが､ 04:28.740 --> 04:33.600 UDPはあまり信頼性が高くない｡ 04:33.600 --> 04:36.420 三者間ハンドシェイクがないため､ 信頼性の低いプロトコルだ｡ 04:36.420 --> 04:38.520 TCPはいわゆるコネクションオリエンテッド､ 04:38.520 --> 04:40.770 あるいはコネクションフルのプロトコルだが､ 04:40.770 --> 04:47.040 これは確認応答で3ウェイハンドシェイクがあるからだ｡ 04:47.040 --> 04:48.540 火をつけて忘れる方法だ｡ 04:48.540 --> 04:53.490 私はただ情報を発信し始め､ うまくいけばそれを受け取ってもらえる｡ 04:53.490 --> 04:56.880 TCPはセグメント再送とフロー制御を使用し､ これはウィンドウウィングによって処理されている｡ 04:56.880 --> 05:00.660 一方､ UDPには再送信もウィンドウウィングもない｡ 05:00.660 --> 05:06.660 TCPでは､ すべての異なるセグメントのシーケンスをセグメンテーションしている｡ 05:06.660 --> 05:10.170 UDPの場合､ シーケンシングはない｡ 05:10.170 --> 05:12.030 さて､ これは何を意味するかというと､ 05:12.030 --> 05:13.230 私がすべてを送るとき､ 適切な順序で､ 05:13.230 --> 05:16.230 1から100まで送るつもりだということだ｡ 05:16.230 --> 05:17.160 TCPとUDPの両方でやってみよう｡ 05:17.160 --> 05:19.140 さて､ これらの断片のいくつかを見逃してしまった場合､ 05:19.140 --> 05:25.530 あるいはネットワーク上の経路が異なるために異なる順序で到着した場合､ 05:25.530 --> 05:28.710 TCPでは順序が決まっているため､ 1個から1000個まであることを認識し､ 05:28.710 --> 05:31.260 正しい順序に戻してくれる｡ 05:31.260 --> 05:32.910 UDPの場合､ 送られてきたものが何であれ､ 05:32.910 --> 05:36.480 それがブロードキャストされる｡ 05:36.480 --> 05:37.500 そして､ 1､ 50､ 2､ 05:37.500 --> 05:38.520 500､ 3､ 4､ 5､ 6､ 05:38.520 --> 05:43.440 20､ そんな風にランダムに来ることができる｡ 05:43.440 --> 05:44.850 そうやって聞くことになる｡ 05:44.850 --> 05:46.650 ビデオの場合､ フレームがずれているため､ 05:46.650 --> 05:50.910 少し音が飛んだり､ 甲高い音が聞こえたりすることがあります｡ 05:50.910 --> 05:55.230 さて､ TCPに戻ると､ TCPはそれぞれのセグメントを認識する｡ 05:55.230 --> 05:56.580 だから､ 私たちは認めている｡ 05:56.580 --> 06:00.780 もし受信できなかったら､ 受信できなかったことがわかるし､ 06:00.780 --> 06:01.740 再送信してもらって､ 06:01.740 --> 06:04.320 また受信できる｡ 06:04.320 --> 06:05.550 UDPでは､ 確認応答はない｡ 06:05.550 --> 06:08.010 UDPは､ コネクション､ ウィンドウウィング､ 06:08.010 --> 06:09.780 再送､ シーケンス､ 確認応答がないため､ 06:09.780 --> 06:11.513 オーバーヘッドが少ない｡ 06:11.513 --> 06:15.000 さて､ もしあなたが何かを届けなければならず､ 相手がそれを受け取ったことを確認したいのであれば､ 06:15.000 --> 06:17.190 TCPプロトコルを選択しなければならない｡ 06:17.190 --> 06:23.790 そのため､ 銀行やウェブサイト､ eコマースなどでTCPを使うことになる｡ 06:23.790 --> 06:26.610 しかし､ オーディオやビデオ・ストリーミングのような大量のデータがある場合､ 06:26.610 --> 06:36.930 UDPはそのようなファイルに対応できる｡ 06:36.930 --> 06:40.770 あちこち少し飛ばしてもいい｡ 06:40.770 --> 06:44.550 -TCPとUDPについては､ コネクションフル､ つまりコネクションオリエンテッドなプロトコルと､ 06:44.550 --> 06:47.490 コネクションレスなプロトコルがあるという話をしました｡ 06:47.490 --> 06:52.510 そこで､ TCPとUDPのどちらかを使うプロトコルの例をいくつか挙げてみよう｡ 06:52.510 --> 06:58.560 まず､ TCPとコネクションオリエンテッドまたはコネクションフルのプロトコルについて見てみよう｡ 06:58.560 --> 07:00.510 これにはSSHやHTTP､ HTTPSなどが含まれる｡ 07:00.510 --> 07:02.190 さて､ なぜこのような場合にコネクション指向が必要なのだろうか？ 07:02.190 --> 07:07.680 まあ､ SSHのようなものを使う場合は､ リモート・サーバーやリモート・ワークステーションを双方向通信でコントロールするわけだから､ 07:07.680 --> 07:09.420 ポート22でできるようにする｡ 07:09.420 --> 07:17.520 コネクション重視､ あるいはコネクションフルでやっていることを確認したい｡ 07:17.520 --> 07:20.940 そうすれば､ 私がコマンドを送ってサーバーをリブートしろと言えば､ 07:20.940 --> 07:28.320 そのコマンドが実際にそこに届き､ サーバーのリブートが起こることがわかる｡ 07:28.320 --> 07:34.920 同様に､ HTTPSを扱う場合､ TCPを使用したコネクション・フルまたはコネクション・オリエンテッドなプロトコルを使用することを確認したい｡ 07:34.920 --> 07:40.080 その理由は､ 繰り返しになるが､ 送信したものが実際にそこで受信されることを確認したいからだ｡ 07:40.080 --> 07:42.060 その中には､ ユーザー名とパスワードを使ってウェブサイトにログインしようとする際の認証のようなものも含まれるかもしれないし､ 07:42.060 --> 07:52.440 口座残高や銀行情報など､ ウェブサイトから得られる情報も含まれるかもしれない｡ 07:52.440 --> 07:54.690 一方､ プロトコルにUDPを使っている場合は､ 07:54.690 --> 07:58.500 コネクションレスでやりとりすることになる｡ 07:58.500 --> 08:03.030 さて､ 私たちがオーディオやビデオのストリーミングのようなことにいつもこれを使用しているという事実はすでに述べた｡ 08:03.030 --> 08:06.180 それに加えて､ DHCPやTFTPと呼ばれるTrivial File 08:06.180 --> 08:08.970 Transfer Protocolなどにも使っている｡ 08:08.970 --> 08:11.400 DHCPはダイナミック・ホスト・コントロール・プロトコル（Dynamic Host Control 08:11.400 --> 08:13.470 Protocol）と呼ばれ､ 67番と68番のポートで動作する｡ 08:13.470 --> 08:16.680 さて､ あるネットワークに参加すると､ あなたのデバイスがIPアドレスを動的に割り当てるように設定されていれば､ 08:16.680 --> 08:24.030 そのネットワーク上でDHCPサーバーを探すブロードキャスト・メッセージを発信します｡ 08:24.030 --> 08:27.480 これが､ コネクションレス・プロトコルとして使う理由だ｡ 08:27.480 --> 08:30.660 というのも､ 情報を発信して誰も反応しなければ､ クライアントは他の誰かが来てくれることを期待して､ 08:30.660 --> 08:33.690 また情報を発信するだけだからだ｡ 08:33.690 --> 08:35.850 これがDHCPの仕組みだ｡ 08:35.850 --> 08:38.520 ブロードキャスト・メッセージを発信し､ 08:38.520 --> 08:40.650 応答が返ってくるのを待つ｡ 08:40.650 --> 08:43.860 一定時間内にその応答を得られなかった場合､ 08:43.860 --> 08:47.220 単にメッセージを再ブロードキャストし､ 08:47.220 --> 08:51.510 再び新しいDHCPサーバーを探します｡ 08:51.510 --> 08:53.070 同様に､ ポート69で動作するTFTP（Trivial 08:53.070 --> 08:55.080 File Transfer Protocol）は､ UDPをトランスポートとして使用し､ 08:55.080 --> 08:59.340 コネクションレスで動作する｡ 08:59.340 --> 09:01.560 その理由は､ TFTPがTrivial 09:01.560 --> 09:04.590 File Transfer Protocolであるため､ 09:04.590 --> 09:13.380 すべてのパケットが確認応答付きで送受信されたという保証が不要であり､ TCPを使用するとより多くのオーバーヘッドが発生するからである｡ 09:13.380 --> 09:16.680 つまり､ UDPを使うことで､ FTPのようなコネクションフルなプロトコルを使う代わりに､ 09:16.680 --> 09:22.740 TFTPのようなものを使うときに､ より高速なファイル転送が可能になるのだ｡