第 7 回 UDP, TCP

本日の内容

• 7-1. IP のまとめ
• 7-2. UDP
• 7-3. TCP

このドキュメントは http://edu.net.c.dendai.ac.jp/ 上で公開されています。

7-1. IP のまとめ

IP はもともと ARPANET でホスト間通信を行うプロトコル TCP を開発して いる途中で、ネットワーク間パケット交換処理とホスト間処理を分離、階層化し た過程でできました。 ネットワーク間パケット交換処理が IP で、ホスト間の処理が TCP になります。

IP は IP アドレスと言うアドレスを用いて通信をします。 そして、パケットには宛先の IP アドレスが付加されます。 そのパケットはルータによって中継されて目的のホストに到着します。 中継する際の経路の選択は途中の各ルータに独立に決定させています。 これをホップバイホップルーティングと言います。 IP は決められた長さのパケットを目的地まで送りますが、到着性を保証して いるわけではありません。 ルータは途中で輻輳が起きるとパケットを廃棄します。 大きなファイルを正確に端末間で送るのは、この IP を利用した TCP で行い ます。

IP ではルータに経路制御が任されています。 これには様々な方法がありました。

スタティックルーティング

人間が手で設定を行う。複雑で細かい設定が可能。 但し、故障時にルーティングを自動的に変更できない。

ダイナミックルーティング

ルータがプログラムによって経路を制御するもの。 障害時に経路を自動的に変更するなど耐故障性がある。

EGP

AS 間ルーティング。責任者のいない分散管理。ネットワークアドレスと AS 番号で管理する。 プロバイダ間などで使用される。 BGP ver.4

IGP

AS 内ルーティング。管理責任者が管理を行う。通常一つのネットワーク アドレスに対してサブネットマスクを定義し、サブネットの管理を行う。 RIP, OSPF

7-2. UDP

UDP(RFC 768 1980 年)は IP パケットは通常別のプロトコルを乗せて利用します。 UDP というプロトコルを使うと IP パケットにそのまま情報を載せてデータを やりとりできます。 但し、ポート番号により多重化されてます。

IP と同じ機能をもっていますから、ブロードキャスト、マルチキャストなど も使用できます。 TCP のようにハンドシェイクを行う必要もなく、最小限の手間で利用できます。 基本的には一方向通信なので、たとえるなら葉書のようなものになります。

UDP は RIP や DNS などのネットワーク管理や、映像、音声を流す RTP など リアルタイム通信に使われています。

7-3. TCP

TCP(RFC 793 1981 年)はインターネットでファイルを誤りなく送り合うために 作られました。

TCP も UDP 同様、ポート番号により多重化されています。 ポート番号は 0 から 65535 までありますが、特に 0 から 1023 まではシス テム領域で一般ユーザは自分のマシンのこのポート番号を管理下に置くことは できません。 このエリアには TCP, UDP とも重要なサーバが登録されています (cf. IANA port-numbers)。 なお、49152 から 65535 は Dynamic または Private ポートとして定義され ており、自由に利用できます。

TCP 80

HTTP(Hyper Text Transfer Protocol)つまり WWW

TCP 25

SMTP(Simple Mail Transfer Protocl) つまり電子メールサーバ

TCP 110

POP3(Post Office Protocol Version 3) つまりパソコン用電子メールダ ウンロードサーバ

UDP 53

DNS(Domain Name Server) つまりネームサーバ(ホストやドメインの名前 を IP アドレスと対応づける

UDP 520

RIP(Routing Information Protocol)

TCP の特徴として、まず end to end 型、つまり、端末と端末間で行われるプ ロトコルであると言う点があります。 そして、コネクション型サービス、すなわち通信は end to end で行われます が、そこがあたかも管でつながっているよう、通信内容が順序よく並んで取り 出せるようになっています。これはたとえるなら電話のようなものです。 また、 TCP は再送や輻輳制御などを行うことで通信内容に関して高い信頼性 を保証します。 また、通信は両端で相互に同時にメッセージが行われる全二重という形態をと ります。 なお、 TCP は端末間のみのユニキャストだけに対応しているため、ブロード キャストやマルチキャストには使えません。 また、コネクションを確立するのに 1 往復半の通信(三方向ハンドシェ イクが必要で、さらにコネク ションごとにポートを生成する必要があるため、コストがかかります。

TCP は再送処理や輻輳制御をしてファイルを確実に届けるものです。 このプロトコルを利用してさまざまなインターネットのアプリケーションが作 られています。 電子メールや WWW もこの TCP を利用しています。

TCP のプロトコルの内容

URG

緊急ポインタ有効

ACK

確認通知番号有効

PSH

バッファリングせずに送信

RST

リセット

SYN

コネクション確立

FIN

コネクション終了

三方向ハンドシェイク

1. 始めに各ホストはセグメント番号はそれぞれのホストのローカルな時計に より値が決められているとします。ホスト X は x, ホスト Y は y という値 になっているとします。
2. X は Y に接続を申し込むため、 SYN を送ります。その時、セグメント番 号 x を送ります。
3. Y は SYN を受けとったら、同様に X に SYN を送ります。 その時、セグメント番号 y を送ります。 さらに X の SYN を受けとったことを示すため、x のセグメントを受けとった ことを示す ACK=x+1 を送ります(Ack とは Acknowledgement 受領確認)。
4. X は Y から SYN を受けとったら、Y に ACK=y+1 を含めた SYN を送りま す。その時、セグメント番号は x+1 を送ります。
5. これで双方がセグメント番号を交換し終えたので、次のセグメント番号か ら実際のデータの送受を行うことができます。

このようにセグメント番号を 0 から始めず、各ホストが独立に定めることに より、パケットの欠落や再送などによる混乱もさけることができます。 送信者が SYN を送った後、何らかの都合で接続を完了する前に再度別の SYN を送っ てもセグメント番号が異なることになるので受信者は区別できます。

データ転送

データは基本的にはセグメントに分割され、セグメント番号と共に送られます。 受信側はセグメントを受けとるたびに ACK を送ります。 この時、ACK には次に受信したいセグメントの番号を添えます。 例えば、 セグメント 1 を受け取ったら 2 を、セグメント 2 を受け取ったら 3 を添え ることになります。 但し、順番にセグメントを受け取れなかった時は単純に(受け取った番号+1)を 送るわけではありません。 受信側は連続したセグメントを受信したいので、番号が飛んだら、既に飛ばさ れたセグメント、つまり(連続して受信できたセグメントの番号の最大値+1)、あ るいは受信できていないセグメント番号の最小値を送ります。 もし、セグメント 2 を受け取った後でセグメント 4 を受け取った場合、セグ メント 3 を受け取りたいので、 ACK には 3 を添えます。

このように TCP では 1 つのセグメントに対して一つの Ack が送られること になります。 しかし、送信側は単純に ACK が来るまで次のデータを送れないわけではありません。 送信側のパラメータとして、 一度に送って良いサイズであるウィンドウサイズというのがあり ます。 ウィンドウサイズの詳しい話は後にしますが、ここではある程度の値と思って 下さい。 送信側は受け取った ACK の番号から ACK+ウィンドウサイズの番号までのセグ メントを送信することを許されています。 従って上で ACK=4 を受け取らなくてもセグメント 4 を送信しています。

一方受信側は(連続して受け取ったセグメント番号)+1を ACK として送ります。 つまり次に受け取りたいセグメント番号を ACK として送ります。 単純に(受信したデータのセグメント番号)+1 でないことに注意して下さい。 従って、 3 を受け取ってない限り、データを受け取る度に ACK=3 を送り返し ます。

なお、ウィンドウサイズを決める一つの要因に受信者の一度に受信できる最大 サイズがあります。 これはインターフェイスや OS などによりあらかじめ決められてる値です。 この最大サイズを最大セグメントサイズと呼び、これは最初の 3 方向ハンドシェイクの時に送信側、受信側の値が互いに交換されます。

なお、telnet などのインタラクティブなアプリケーションでは、キーボード やプログラムから送られるデータが文字単位になります。 これを一文字一文字をすべて一つのセグメントとして送るのは効率が悪いので、 ある程度の間隔以上で送らないとか、ウィンドウサイズによらず ACK が来る まで送らない(Nagle のアルゴリズム)という工夫がされてます。

セルフクロック

大量のデータを送る際、ウィンドウサイズや ACK はどのように働くのでしょ うか? ここでは、途中にボトルネック(処理を遅らせる原因)として、通信経路内に細 い回線が接続されているとしましょう。 またウィンドウサイズは途中でパケットを捨てられない程度に小さいとします。

|< < > >|

1. まず送信者はウィンドウサイズ分だけパケットを一気に送ります。
2. それが通信経路を通りボトルネックの手前まで到着します。
3. しかし、ボトルネックでは一気に来たパケットはそのまま処理できず、時 間をかけて徐々にパケットを送ります。 この間到着したパケットは待ち行列に入ります。
4. パケットはボトルネックを徐々に通過して出てきます。
5. 出てきたパケットはボトルネックの処理の速さに合わせて間隔が空きます。
6. 受信者にパケットが届いたら受信者は順次 ACK を発行しますが、その間 隔はパケットの到着間隔、つまりボトルネックの処理の速さに合わせ て空くことになります。
7. 送信者に返る ACK は受信者の発行した間隔、つまりボトルネックの処理 の速さに合わせて到着します。
8. 送信者は返ってきた ACK に応じてパケットを再度送信し始めます。この 間隔はボトルネックの処理の速さに合っています。
9. 再び送信されたパケットはボトルネックの処理の速さに合っているので、 ボトルネックに到着しても待ち行列に入ることなく、順次処理され、 通過してきます。
10. その後、ACK やパケットの間隔が短くなることはなく、全体として通信の 流れがボトルネックの速さに合うことになります。

このように自動的にボトルネックの処理速度に合わるタイミングで処理が行わ れることをセルフクロックと言います。