今回まで講義、実習で第三層まで勉強してきました。
通常、コンピュータでは、複数の通信プログラムを動かすことが出来ます。
<IP>
| (PC) |
|
|
|
(web上のHTTPサーバ) |
| | |
|
|
|
| |
| ・---- |
--- |
インターネット |
--- |
----------・ |
エンドtoエンドはネットワーク層（インターネット層）が面倒をみます。
（隣のコンピュータまではデータリンク層が面倒をみます）
しかし、サーバ側もHTTPだけでなく、ftp、
SMTPなどいろんなプログラムが動いています。
PCでも、Outlook Express 、Internet Explore、
などが動いています。
IPは相手先まで届けるけど、どのプログラムかは関知していません。
TCP/UDPが面倒を見ます。
TCP/UDPではそれを識別しなければなりません。これがTCPポート番号です。
TCP/IPでトランスポート層の機能を果たす代表的なプロトコルには「TCP」と「UDP」の2つがあります。
TCP （Transmission Control Protocol) （マスタリングTCP/IP
P.195)
コネクション型。自前にコネクションを確立します。
水道のホースのように切れ目の無い通信を提供します。
信頼性が高く、順序制御や再送制御など多くの機能を持ちます。
| 送信元ポート番号 |
あて先ポート番号 |
| シーケンス番号 |
| 確認応答番号 |
| データオフセット |
予約 |
コードビット |
ウインドウサイズ |
| チェックサム |
緊急ポインタ |
| オプション |
パディング |
| データ |
図 TCPセグメントフォーマット
（マスタリングTCP/IP
P.195) |
UDP (User Datagram Protocol) （マスタリングTCP/IP
P.193)
「とりあえず送ってしまえ！」相手PCの電源がOFFでも送ってしまいます。
相手に投げて終わりなので、信頼性はありません。
データ壊れてたとか細かい処理は上のプロトコルが面倒をみることによって簡単な構造になっています。
| 送信元ポート番号 |
あて先ポート番号 |
| パケット長 |
チェックサム |
| データ |
図 UDPデータグラムフォーマット
（マスタリングTCP/IP
P.193) |
この2つのフォーマットを見比べてもいかにUDPヘッダの方が簡単かわかりますね。
☆ TCPの目的と特徴 ☆（マスタリングTCP/IP
P.178)
TCPではチェックサムやシーケンス番号と確認応答、再送制御、コネクション管理、ウインドウ制御など
により信頼性のある通信を実現しています。
☆
シーケンス番号と確認応答で信頼性を提供 ☆（マスタリングTCP/IP
P.179)
TCPでは肯定確認応答で信頼性を実現します。
データを送信したホストは、データの送信後に確認応答を(一定時間）待ちます。
もし、確認応答されなければ、データが喪失した可能性があります。
図 送信パケットが喪失した場合
図 確認応答が喪失した場合
ホストB側は、確認応答喪失により、Aからの同じデータが2回届くと、
2回目のは破棄します。
送信側は、確認応答がされないと再送します。
ただし、確認応答の待ち時間を2,4倍と指数関数的に増やしていきます。
それでもだめなら異常終了を通知します。
（TCPはコネクション型なので勝手にやめれません。
「何回も試みたけどダメでした」と報告する必要があります)
☆ ウインドウ制御で速度向上 ☆（マスタリングTCP/IP
P.184)
図 1パケットごとに確認応答する
TCPでは、信頼性は高いですが、何かを送って返事を待って・・・
と効率は悪いです。ここで、効率を上げるために出てきたのがウインドウ制御です。
図 スライディングウインドウ方式で、並列処理
図のように、1セグメント単位ではなく、もっと大きな単位で確認応答すると、
転送時間が大幅に短縮されることが分かると思います。
確認応答を待たずに送信できるデータの大きさをウィンドウサイズといいます。
ウィンドウですから、窓を覗くようなイメージです。（マスタリングTCP/IP
P.185 図5.12)
データを送る際には、
「送るよ」
「いいよ！」
「ウィンドウサイズは 10です！」
「こっちのウィンドウサイズは5です」
「じゃあ、5で行きましょう」
最初のネゴシエーションでこのやりとりもしています。
☆ スライディングウィンドウ制御 ☆
ここで 送信側の立場になって考えて見ましょう。
ウィンドウサイズが3で、A→Bにデータを送信する場合、
まず、データ①,②,③と送信します。
ここで一杯になったので、Bから①の確認応答を待ちます。
確認応答が来たら、送信側にとって①のデータを持っておく必要がないから、
捨てて一つずらして④を送れます。
このように、ウィンドウ枠をずらしていくのでそう呼ばれます。
この順次複数のセグメントを並列的に送信して通信性能を
向上させる仕組みをスライディングウィンドウ制御といいます。
☆ ウィンドウ制御と再送制御 ☆（マスタリングTCP/IP
P.186)
もし、送信したセグメントが失われたらどうなるでしょう？
確認応答が無くなったら？
確認応答が無くなっても、ウインドウ制御ならOKです。
上の図で考えてみましょう。
1～1000の送信に対する確認応答が失われました。
しかし、1001～2000までの確認応答は届きました。
そうすると、送信側は、1001～2000の確認応答で、1～1000と1001～2000の
両方OKとして判断します。それは、1～1000を相手が受け取っていないと、
1001～2000は受け取れないからです。
行きのデータが失われたらどうなるでしょう？
上の図のように1001～2000のデータが失われたとします。
新しいデータを送りつづけても、受信側は「1001～2000のデータをくれ！」と言いつづけます。
それはまるで「私の受信したいデータは1001からのデータです。他のデータではありません。」
と言ってるみたいですね。送信側はそれを3回聞くとデータが失われたと判断して再送します。
3回待っても、タイムアウトによる再送制御よりも速いので、高速再送制御と呼ばれます。
☆ フロー制御（流量制御) ☆（マスタリングTCP/IP
P.188)
バッファサイズをコントロールして、フローをコントロールします。
1～1000、・・・、3001～4000と送りつづけますが、4001からは受信が一杯になって送れなくなります。
そのなりますと、一旦送信をやめ、一定時間おきにウィンドウプローブを送り、
「ウィンドウサイズ、いくつ残ってる？」と確認します。
それで、OKならまた送信を始めます。
☆ コネクション管理 ☆（マスタリングTCP/IP
P.181)
TCPでは、これらのコードビットでコネクションを管理しています。
(マスタリングTCP/IP P.196)
| URG |
|
| ACK |
コネクション中は常に1 |
| PSH |
|
| RST |
|
| SYN |
コネクション確立用。
コネクションを確立したい！の意思表示に使用。 |
| FIN |
コネクションの切断用。
コネクションを切断したい！の意思表示に使用。 |
相手からFIN=1が来ても、こっちがまだ送りたいときは送ってもいいです。
「もう話したいことは無くなったし、終りたいねんけど・・・」
と言われても、
「いや、まだしゃべりたいことはある！」
と続けてもいいわけですね。
☆ コネクションの確立 ☆（これは午後問題のレベルですので覚えておきましょう)
AとBはコネクションが貼られていない状態で。
①AからBに「話したいねんけど・・・」
(A to B) SYN=1、ACK=0（このときに限り)
②BからAに「うん、ええで。こっちもしゃべりたいことあるし・・・」
(B to A) SYN=1、ACK=1
③AからBに「じゃあ、話しましょう」
(A to B） ACK=1
これで、コネクションは確立できました。
①のSYN=1に対する②のACK=1、②のSYN=1に対する③のACK=1はペアで考えましょう。
このように、①②③でコネクションが確立することから、
3way Handshake
と言います。
☆ コネクションの切断 ☆
AとBにコネクションが貼られた状態で。
①AからBに「そろそろ話を終えたいね」
(A to B) FIN=1、ACK=1
②BからAに「うん、分かった。でももうちょっとしゃべりたい」
(B to A) ACK=1
（しゃべりつづける時は FIN=1にしない)
・・・・しばらくBはAにしゃべりつづけて・・・
③ BからAに「いいたいことはこれで全部。じゃあ、そろそろ終わろうか」
(B to A) FIN=1、ACK=1
④ AからBに「うん、終わろう」
(A to B) ACK=1
これで、コネクションは切断できました。
ACKビット、FINビット、SYNビットは覚えましょう。
