このドキュメントは http://edu.net.c.dendai.ac.jp/ 上で公開されています。
IP はもともと ARPANET でホスト間通信を行うプロトコル TCP を開発して いる途中で、ネットワーク間パケット交換処理とホスト間処理を分離、階層化し た過程でできました。 ネットワーク間パケット交換処理が IP で、ホスト間の処理が TCP になります。
IP は IP アドレスと言うアドレスを用いて通信をします。 そして、パケットには宛先の IP アドレスが付加されます。 そのパケットはルータによって中継されて目的のホストに到着します。 中継する際の経路の選択は途中の各ルータに独立に決定させています。 これをホップバイホップルーティングと言います。 IP は決められた長さのパケットを目的地まで送りますが、到着性を保証して いるわけではありません。 ルータは途中で輻輳が起きるとパケットを廃棄します。 大きなファイルを正確に端末間で送るのは、この IP を利用した TCP で行い ます。
IP ではルータに経路制御が任されています。 これには様々な方法がありました。
UDP(RFC 768 1980 年)は IP パケットは通常別のプロトコルを乗せて利用します。 UDP というプロトコルを使うと IP パケットにそのまま情報を載せてデータを やりとりできます。 但し、ポート番号により多重化されてます。
IP と同じ機能をもっていますから、ブロードキャスト、マルチキャストなど も使用できます。 TCP のようにハンドシェイクを行う必要もなく、最小限の手間で利用できます。 基本的には一方向通信なので、たとえるなら葉書のようなものになります。
UDP は RIP や DNS などのネットワーク管理や、映像、音声を流す RTP など リアルタイム通信に使われています。
TCP(RFC 793 1981 年)はインターネットでファイルを誤りなく送り合うために 作られました。
TCP も UDP 同様、ポート番号により多重化されています。 ポート番号は 0 から 65535 までありますが、特に 0 から 1023 まではシス テム領域で一般ユーザは自分のマシンのこのポート番号を管理下に置くことは できません。 このエリアには TCP, UDP とも重要なサーバが登録されています (cf. IANA port-numbers)。 なお、49152 から 65535 は Dynamic または Private ポートとして定義され ており、自由に利用できます。
TCP の特徴として、まず end to end 型、つまり、端末と端末間で行われるプ ロトコルであると言う点があります。 そして、コネクション型サービス、すなわち通信は end to end で行われます が、そこがあたかも管でつながっているよう、通信内容が順序よく並んで取り 出せるようになっています。これはたとえるなら電話のようなものです。 また、 TCP は再送や輻輳制御などを行うことで通信内容に関して高い信頼性 を保証します。 また、通信は両端で相互に同時にメッセージが行われる全二重という形態をと ります。 なお、 TCP は端末間のみのユニキャストだけに対応しているため、ブロード キャストやマルチキャストには使えません。 また、コネクションを確立するのに 1 往復半の通信(三方向ハンドシェ イクが必要で、さらにコネク ションごとにポートを生成する必要があるため、コストがかかります。
TCP は再送処理や輻輳制御をしてファイルを確実に届けるものです。 このプロトコルを利用してさまざまなインターネットのアプリケーションが作 られています。 電子メールや WWW もこの TCP を利用しています。
| 0 | 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 送信元ポート番号 | 宛先ポート番号 | ||||||||||||||||||||||||||||||
| セグメント番号 | |||||||||||||||||||||||||||||||
| 確認通知番号 | |||||||||||||||||||||||||||||||
| ヘッダ長 | 未使用 | URG | ACK | PSH | RST | SYN | FIN | ウィンドウ幅 | |||||||||||||||||||||||
| チェックサム | 緊急ポインタ | ||||||||||||||||||||||||||||||
| オプション(0 個以上) | |||||||||||||||||||||||||||||||
| データ | |||||||||||||||||||||||||||||||
| ... | |||||||||||||||||||||||||||||||
| ホスト X | 通信内容 | ホスト Y | |
|---|---|---|---|
| セグメント番号 | セグメント番号 | ||
| 2 | x | (SYN SEG=x)→ | |
| 3 | ←(SYN SEG=y ACK=x+1) | y | |
| 4 | x+1 | (SYN SEG=x+1 ACK=y+1)→ |
このようにセグメント番号を 0 から始めず、各ホストが独立に定めることに より、パケットの欠落や再送などによる混乱もさけることができます。 送信者が SYN を送った後、何らかの都合で接続を完了する前に再度 SYN を送っ てもセグメント番号が異なることになるので受信者は区別できます。
基本的にはデータはセグメントに分割され、セグメント番号と共に送られます。 受信側はセグメントを受けとるたびに ACK を送ります。 この時、ACK には次に受信したいセグメント番号を添えます。
| ホスト X | 通信内容 | ホスト Y | |
|---|---|---|---|
| セグメント番号 | セグメント番号 | ||
| 1 | 1 | SEG=1 のデータ → | |
| ←ACK=2 | |||
| 2 | SEG=2 のデータ → | ||
| ←ACK=3 | |||
| 2 | 3 | SEG=3 のデータ →× | |
| 4 | SEG=4 のデータ → | ||
| ←ACK=3 |
送信側は単純に ACK が来るまで次のデータを送れないわけではありません。 一度に送って良いサイズであるウィンドウサイズというのがあり ます。 ウィンドウサイズの詳しい話は後にしますが、ここではある程度の値と思って 下さい。 送信側は受け取った ACK の番号から ACK+ウィンドウサイズの番号までのセグ メントを送信することを許されています。 従って上で ACK=4 を受け取らなくてもセグメント 4 を送信しています。
一方受信側は(連続して受け取ったセグメント番号)+1を ACK として送ります。 つまり次に受け取りたいセグメント番号を ACK として送ります。 単純に(受信したデータのセグメント番号)+1 でないことに注意して下さい。 従って、 3 を受け取ってない限り、データを受け取る度に ACK=3 を送り返し ます。
なお、ウィンドウサイズを決める一つの要因に受信者の一度に受信できる最大 サイズがあります。 これはインターフェイスや OS などによりあらかじめ決められてる値です。 この最大サイズを最大セグメントサイズと呼び、これは最初の 3 方向ハンドシェイクの時に送信側、受信側の値が互いに交換されます。
なお、telnet などのインタラクティブなアプリケーションでは、キーボード やプログラムから送られるデータが文字単位になります。 これを一文字一文字をすべて一つのセグメントとして送るのは効率が悪いので、 ある程度の間隔以上で送らないとか、ウィンドウサイズによらず ACK が来る まで送らない(Nagle のアルゴリズム)という工夫がされてます。
大量のデータを送る際、ウィンドウサイズや ACK はどのように働くのでしょ うか? ここでは、途中にボトルネック(処理を遅らせる原因)として、通信経路内に細 い回線が接続されているとしましょう。 またウィンドウサイズは途中でパケットを捨てられない程度に小さいとします。
このように自動的にボトルネックの処理速度に合わるタイミングで処理が行わ れることをセルフクロックと言います。