■ データ転送

さて、これでレイヤ１〜４が終わったわけだ。
ここでネットワークモデルを復習してみよう。

TCP/IPモデルですね。
OSIじゃないんですか？

うむ。TCP/IPの説明がメインだったからな。TCP/IPモデルの方が説明がしやすいのだよ。
なので、TCP/IPモデルで話す。

ははぁ。そういうもんですか。

そういうものだ。
さて、上のモデルを見てわかるとおり、レイヤ５〜７はアプリケーション毎に仕様が違う。

アプリケーション毎に仕様が違うって。
HTTPとFTPとDHCPとDNSでは違うってことですよね。

うむ。それぞれ別のプロトコルだ。当然といえば、当然だな。
だが、TCP/IPである限りレイヤ４とレイヤ３はどのアプリケーションでも共通だ。

ん〜っと。
TCPかUDP、それとIPを必ず使うってことですね。

そうだ。昔に話した例えで言えば、レイヤ４は緩衝材、レイヤ３がダンボールと宛名だったな。

第６回ですね。

運ぶ中身がなんであれ、緩衝材とダンボール、そして宛名は必ず必要。
そういうことだ。

あぁ、なるほど。
でも、最近は紙袋でも送れちゃいますけどね。

(ｼﾞﾛﾘ)

…ごめんなさい。

まぁいいだろう。ともかく、レイヤ２はWANかLANのテクノロジーの違いでまた分かれるが、レイヤ３と４は共通だ。
レイヤ３のまとめは以前やったので、レイヤ４をまとめてみよう。つまりここからの説明は、今後どのアプリケーションでも必ず行っていることだということだ。

ははぁ、了解です。

■ TCP・UDP共通

まず、アプリケーションが通信を要求する。
この時点で宛先IPアドレスと宛先ポート番号が決定される。

あれ？ IPアドレスはレイヤ３じゃ？

確かにそうだが。誰と通信するかはアプリケーションが決定する。
HTTPならばブラウザにURIを入力するのはユーザだろう？

そうか、そうですよね。
どのWebサイトを見に行くか、入力したり、リンクしたり、ブックマークから選択するのは自分ですよね。

そうだ。なのでこの時点で、宛先が決定されるわけだ。

なるほど。
はい、宛先IPアドレス・ポート番号が決定しました。次は？

次は通信するためにソケットを確立する。それによりアプリケーションとTCP・UDPが繋がるわけだな。
今回はそうだな1025番としよう。

これでレイヤ４に渡される。
TCPかUDPのどちらを使うことになるわけだ。

どちらを使うかはどうやって決定するんですか？

大体はアプリケーションでTCP/UDPどちらを使うか決まっている。
まずはTCPを使った場合から説明しよう。

■ TCPを使った通信

さて、TCPの1025番ポートを通ってデータがTCPに渡されたわけだ。
ネット君、TCPといえば何かね？

正確・確実が謳い文句のイヤミな優等生プロトコルです。

いや、イヤミかどうかはわからんが。まぁ、あまり深くツッコむとネット君のトラウマに触れるから置いておこう。
ともかく、TCPが最初に行うのはなんだったかね？

スリーウェイハンドシェイクですよね。

そうだ。
宛先との双方向コネクションを作るためにスリーウェイハンドシェイクを行う。

これによって、シーケンス番号、確認応答番号、ウィンドウサイズ、MSSが決定される。
これはなんの為に必要だったのかね？

確実に相手に届けるため、ですよね。
相手に届かないことがないように、バッファオーバフローを起こさせないように。

うむうむ。よしよし。
シーケンス番号などが決定されることにより、相手に確実に届く事が保証されたわけだ。

です。

つまり、レイヤ４だけ考えてみれば、以下のような形になる。

送信元の送信機と宛先の受信機。宛先の送信機と送信元の受信機。これが繋がっている形になる。

レイヤ４だけ見れば？

そうだ。レイヤ４だけ見ればだ。実際は、IP、イーサネットを使いネットワーキングメディアを通ってして送受信されるわけだ。
ルーティングやCSMA/CDという制御を行いつつな。だが、前も言ったとおり下位層のことなど知ったことではない。

知ったことではないって。それでいいんですか？

「もしもし？」「もしもし？○○ですが」「××です。こんにちは」
電話でこのやりとりがあったなら、相手に繋がっていると言えるだろう？

そうですね。相手に繋がっていると普通考えますよね。

電話機がどうやって音声を信号化して、NTTの交換機がどうやって相手に繋げているか。
そんな事は別に知らなくても、アプリケーション(電話する人)は相手と繋がっていて会話をする準備がOK。コネクションが確立さているわけだ。

会話をする準備がOK？

すでに双方のウィンドウサイズをやりとりして、通信に使うバッファを決定してメモリをその分を確保したわけだ。
さらに、MSSを決定して、一度に送るデータサイズまで決定している。準備完了だろ？

確かに。
物理的にどう繋がっているかは関係なくって、論理的に接続されているってことですね。

そういうことだ。
コネクションが確立されるとデータが転送される。TCPはこの際何を行うのだった？

スライディングウィンドウとスロースタートアルゴリズムですね。

バッファオーバフローを防ぐためにスライディングウィンドウを。
輻輳を防ぐためにスロースタートアルゴリズムを使いこなしてデータを送るわけだな。

確実・正確ですね。

そういうことだ。
宛先に届いたセグメントは、シーケンス番号順に整列してから上位アプリケーションに渡される。

宛先ポート番号に対応したアプリケーションに渡すわけですね。

そうだ。
宛先ポート番号がソケットとして確立していない場合(閉じている)や、ソケットを確立していても送ったデータと違うアプリケーションだった場合はエラーになる。

ポートが開いているだけじゃ駄目なんですね。

それは当然だ。
メールサーバアプリケーションにHTTPのWebページ要求をしてもしょうがあるまい。

そういえばそうですね。

さて、データの送受信が終わったらコネクションの切断を行わなければならない。
通信用に確保していたメモリなどを開放してやるわけだな。

スリーウェイハンドシェイクで接続して、またセグメントをやりとりして切断するわけですね。

うむ。
せっかくなので、TCPの状態フローを見せておこう。

CLOSE/LISTENからESTABLISHEDまでで、赤の流れがコネクションを接続しようとした側の流れ。
青の流れはコネクションを接続される側の流れだ。

ということは。ESTABLISHEDからCLOSE/LISTENまで戻る流れは、赤が切断しようとした側。青が切断される側の流れですね。

その通り。
こまめにnetstatを眺めていれば、このTCPフローそのままに動くのがわかるぞ。

netstat - a の後に数字を入れると自動的にその秒数に１回表示されるそうです。

■ UDPを使った通信

次は、UDPを使った場合について話そう。
まず通信アプリケーションからUDPにデータが渡される。

受け取ったUDPは…。

UDPは？

細かいことはすっとばしていきなり送信する。

……。

以上。

豪快さんですね。

そうだな。
届いたか届かないかも知ったことではないからな。

受信側は？

シーケンス番号がないので受け取った順番で上位アプリケーションに渡す。
あとは上位アプリケーションの仕事だ。

宛先ポート番号がソケットとして確立していない場合(閉じている)や、ソケットを確立していても送ったデータと違うアプリケーションだった場合はエラーになる。
これはTCPと同じだ。

分かり易いプロトコルですよね。

■ TCPとUDP

非常に対称的な２つのプロトコルがTCPとUDPだ。
違いをよく覚えておくように。

イヤミな優等生がTCP。
大雑把な不良がUDP、と。

うぅむ。イヤな覚え方だ。

そうですか？

うむ。もうちょっと考えたまえ。
ともかく、今回はここまで。

はい。

次回はレイヤ５だな。

いやぁ、とうとうレイヤ５ですか。
思えば遠くに来たもんですね。

そうか？ まだまだお楽しみはこれからだ。
ではまた次回。

はい。
３分間ネットワーキングでした〜♪