第16回　信頼性のある通信を実現するTCPプロトコル（3）：基礎から学ぶWindowsネットワーク（4/4 ページ）

» 2004年02月13日 00時00分公開

　それでは実際にTCPプロトコルの通信例を見てみよう。ここではオープン、データ通信、クローズにおける典型的な例を取り上げてみる。より理解を深めるためには、Windows Server OSに含まれているネットワーク・モニタなどを使って、実際のパケットのやりとりを観測するのが望ましい。ネットワーク・モニタについては別稿の「Windowsネットワーク・プロトコルの理解と検証」を参照していただきたい。

オープン処理

　すでに述べたように、TCPのオープン処理は「3ウェイ・ハンドシェイク」というシーケンスに沿って行われる。実際にネットワーク・パケットをキャプチャして観測すると、その特徴的なパターンにより、すぐに見つけることができるだろう。

　以下は、あるマシン（マシン名は「CLIENT」。OSはWindows XP Professional）から、Webサーバ（マシン名は「SERVER」。OSはWindows 2000 Server）に対して、HTTPプロトコルで通信を行っているところである。この例では、CLIENT側からSERVER側に対して、最初にオープン要求を送信している。つまりCLIENT側がアクティブ・オープン、SERVER側がパッシブ・オープンを実行している。

　オープン時に渡されるシーケンス番号に対して、受信確認のACK番号が＋1されていることに注意していただきたい。これはSYNフラグも1byte分のシーケンス番号を占めるからである。

TCPのオープンにおける通信の例
　（1）クライアントからサーバへのアクティブ・オープン要求。
　（2）サーバからクライアントへのパッシブ・オープン要求（と（1）に対する受信確認）。
　（3）クライアントからサーバへの受信確認。
　（4）TCPフラグの状態。TCPのオープン時にはこのように、「SYN」「SYN+ACK」「ACK」という3つのフラグ・シーケンスが観測できる。以後のパケットはすべて「Ack」がセットされている。
　（5）CLIENT側の初期シーケンス番号。SYNフラグとともに送信されたシーケンス番号が、初期シーケンス番号となる。
　（6）SERVER側の応答パケットのACK番号は、（5）（SYN）に対応している。+1されているのは、SYNフラグもシーケンス番号を1つ分占めるため。
　（7）サーバ側の初期シーケンス番号。
　（8）サーバ側の初期シーケンス番号（（7））に対応するACK番号。やはりSYNの値に+1されている。
　（9）ウィンドウ・サイズ。クライアント側はMSSの整数倍であるが、このサーバはMSSの整数倍ではない値（65,535）を返している。少しチューニングした方がよいであろう。
　（10）TCPの送信元とあて先のポート番号。あて先ポートの80番は、HTTPプロトコルを表す。送信パケットと受信パケットでは2つのポート番号が入れ替わっていることが分かる。
　（11）TCPのフラグ・フィールドの詳細。TCPのオープン要求では、このようにS（Synchronize）のみがセットされている。
　（12）MSSオプション。ここでは1460となっている。
　（13）ウィンドウ・スケール・オプション。
　（14）SACKオプション。

データの送受信処理

　次はデータの送信処理を見てみる。

　データを送信すると、必ずそれに対応する受信確認のためのパケットが返信される。ただしこの受信確認は、データを受け取るたびにすぐ行われるのではなく、いくらかまとまった量のパケットを受信したり、最後の受信からある一定時間が経ったりしてから送られる。逐一受信確認を送信すると、パフォーマンスが悪くなるし、ウィンドウ制御によってまとめて受信できるようになっているので、すぐに応答する必要もないからである。

データの送信とその受信確認
ここでは、SERVER側からCLIENT側へデータが送信されている。この後にもデータの送信が続いているので、MSSサイズいっぱいまでデータが送られている。
　（1）SERVERからCLIENT側へデータを送信している。
　（2）（1）に対する受信確認。このパケット中にはデータは含まれておらず、ACK応答（Ackフラグ）を返すためだけに使われている。そのため、パケット・サイズはTCPのヘッダ部しかない、最小のものとなっている。
　（3）CLIENTからSERVERへのパケットにはデータは含まれていない。lenはTCPのデータ・サイズを表す（TCPヘッダ部は除く）。
　（4）SERVERからCLIENTへ送られるデータは、MSSサイズいっぱいの1460bytes。
　（5）SERVER側から送信されるデータの先頭バイトのシーケンス番号と、最後の（次の）バイト位置のシーケンス番号（ただしTCPのヘッダ中には先頭のシーケンス番号しか含まれておらず、範囲の最後はこのネットワーク・モニタ・ツールが計算して表示している）。
　（6）CLIENTからのACKシーケンス番号は、（5）の値の最後になっている。これは、SERVERから送信されたデータ（1460bytes）をすべて受け取ったということを表している。

クローズ処理

　終了時のパケットのやりとりも、ある決まったパターンがある。まず通信を終了させたい方がF（終了）フラグのセットされたパケットを送信すると、相手がそれに対してACKを返す。さらに相手もFフラグのセットされたパケットを送信し、それに対してACKが返される。Fフラグもシーケンス番号を1つ占めるので、ACK番号はそれぞれ＋1されていることに注意していただきたい。

クローズ処理
ここでは、SERVER側が先にCLIENT側へ終了要求（Fフラグのセットされたパケット）を送信している。SERVER側とCLIENT側のどちらが先にクローズ要求を出すかは、オープンの順序とは関係ない。送信するデータがなくなった方から順にクローズ処理を行えばよい。双方がクローズ要求を送信し、それに対するACK応答を受け取るとすべての通信が終了する。
　（1）一番最初にSERVERからCLIENTへ向けてクローズ要求が送信されている（アクティブ・クローズ）。
　（2）（1）のクローズに対する受信確認。
　（3）CLIENTからSERVERに対するクローズ要求の送信（パッシブ・クローズ）。
　（4）（3）のクローズに対する受信確認。
　（5）クローズ時の典型的なフラグ・パターン。Fとそれに対するAが続いている。双方から送信されるので、全部で4つのパケットが存在する。
　（6）データ部の長さは0。つまりこれらのパケットはFとAフラグを送信するためだけに使われている。
　（7）SERVERからのクローズ要求に対するシーケンス番号と、それに対するACK番号。Fフラグも1byte分占めるので、＋1されていることに注意。
　（8）CLIENTからのクローズ要求に対するシーケンス番号と、それに対するACK番号。Fフラグも1byte分占めるので、＋1されていることに注意。

次の回へ »