連載第5回
|
 |
|
 |
送信データが消えてしまう ケースを追う |
図3を使って、送信データが消えてしまう場合に、TCPはどんな動きをしているのか説明します。図3は（1）から順に送信側と受信側の振る舞いを示したものです。
（1）送信側がウィンドウ内にある［1］〜［4］のデータを順に送信します。TCPでは、ウィンドウ内にあるデータは、肯定確認応答を受信しなくても送信してよいことになっていますので、データは何も待たずにそのまま送信します。
（2）［1］のデータが受信側に到着したら、データを受信側の箱に入れ、肯定確認応答を送信側に返送します。この肯定確認応答には「次は［2］を送ってください」という情報が含まれています。このとき［2］〜［4］のデータは、まだ通信回線の中を伝わってきている最中です。
（3）受信側は［1］の肯定確認応答の送信をもって、また送信側は肯定確認応答の受信をもって、ウィンドウの位置をスライドさせます。このときスライドさせる位置は、（2）の肯定確認応答に含まれている「次に送ってほしいデータの番号」にします。ここでは［2］をリクエストしていますから、ウィンドウの先頭は［2］に合わせます。
ところで、このとき通信回線に問題が発生して、回線を送信中だった［2］は消えてなくなりました。このトラブルにどうTCPが対応するか、その様子をここから見てください。
 |
| 図3 送信データが消えてしまうケース |
（4）ウィンドウをスライドした結果、ウィンドウ内に入った［5］が未送信なので［5］の送信を開始します。また、通信回線の中を送信中だった［3］のデータが到着します。
ここで受信側のTCPはハタと気付きます。［2］がまだ受信できていません。そこで受信した［3］は箱に取り込むものの、肯定確認応答には「次は［2］を送ってください」という内容を繰り返します。先の説明で「送信データを受信できないときには、受信できるまで文句をいう」と書きましたが、それがまさにその動作です。
なお、このとき肯定確認応答でリクエストしているものは［2］ですから、ウィンドウの位置は［2］のまま動きません。
（5）［4］が受信側に到着します。このときもやはり［2］は受信できていませんので、受信した［4］を箱に取り込みつつ、「次は［2］を送ってください」という内容の肯定確認応答を返します。
ここで新しい出来事が起こります。同じ肯定確認応答を3回受信すると、送信側が「相手にデータが届いていないな」と判断して、リクエストされたデータを再び送ってあげるのです。ここでは送信側が［2］のデータを再送します。
（6）［5］が受信側に到着します。相変わらず［2］は受信できていませんので、受信した［5］を箱に取り込み、［2］をリクエストする内容の肯定確認応答を返します。
（7）送信側が再送した［2］が到着します。このデータを箱に入れると、受信側のウィンドウの先頭が埋まりました。次に送信してほしいデータは［6］です。そこで受信側は「次は［6］を送ってください」との内容を含んだ肯定確認応答を返します。
（8）返した肯定確認応答の内容が［6］のリクエストなので、受信側はウィンドウを［6］の位置までスライドさせます。また送信側も受信した肯定確認応答が［6］をリクエストしているので、ウィンドウを［6］までスライドさせます。
（9）ウィンドウをスライドした結果、ウィンドウ内に入った［6］〜［9］のデータが未送信なので、順に送信を開始します。［6］が到着したら、受信側はそれを箱に保存して、［7］をリクエストする内容の肯定確認応答を返します。
（10）受信側は自分が返した肯定確認応答の内容に従って、また送信側は受け取った肯定確認応答の内容に従って、ウィンドウを［7］の位置にスライドさせます。
（11）ウィンドウをスライドした結果、ウィンドウ内に入った［10］が未送信なので、送信を開始します。通信回線上を伝わってきていた［7］が受信側に到着します。受信側は、それを箱に保存して、［8］をリクエストする内容の肯定確認応答を返します。
（12）受信側は自分が返した肯定確認応答の内容に従って、また送信側は受け取った肯定確認応答の内容に従って、ウィンドウを［8］の位置にスライドさせます。
以降、これと同じ動作を繰り返します。アニメーション1で動作を確認しましょう。
 |
| アニメーション1 送信データが消えてしまうケース |
要点を簡単にまとめると、途中で受信できていないデータがあるとき、TCPはしばらくそのデータの到着を待ちます。その間、受け取ったデータはウィンドウ内に保存しつつ、同時に未到着のデータを催促する内容の肯定確認応答を出し続けます。送信側は、同じ内容の肯定確認応答を3回受信したら、相手に届いていないものと判断して、指定されたデータを再送します。それを受け取った受信側は、その段階までに受信済みのデータと併せて一括処理して、次の受信に備えるわけです。
また、この説明はデータが通信途中に消えてなくなることを想定していましたが、データが入れ替わってしまった場合にも通用します。例えば［3］と［4］が入れ替わって到着しても、（4）と（5）の順番が逆になるだけで処理は正常に進みます。また［4］が到着して、そのずっと後に［3］が到着するようなケースでは、［3］の到着より前に、［3］の再送が先に行われて処理が進みます。後で忘れたころに［3］が到着したら、処理対象のウィンドウと無関係と見なして捨てればよいだけです。
つまり冒頭に説明した通信失敗のケースの（2）も（3）もカバーできることになります。
ウィンドウというシンプルな仕組みを使いながら、このように効率的に再送のコントロールをするこの仕組みは、まさにTCPの優秀さを表しているといえるでしょう。
なお実際には、この仕組みのほかにタイマも併用します。データ送信後にやや長めのタイマをセットし、それが切れるまでの時間に肯定確認応答が到着しない場合には、データを再送します。通常、こういう状態が起こるのは、ネットワークが非常に込み合っていたり、重大な故障が起きている場合と考えられます。
 正確な通信のための確信 |
|
||||||||
| 関連リンク | |
| 連載：TCP/IPアレルギー撲滅ドリル【超実践編】（上位レイヤ編） 連載：インターネット・プロトコル詳説 連載：ルータの仕組みを学ぼう ホストのネット接続は正しく行われているか？ 〜netstatによるネットワーク設定の確認〜 |
|
 |
「Master of IP Network総合インデックス」 |
- 完全HTTPS化のメリットと極意を大規模Webサービス――ピクシブ、クックパッド、ヤフーの事例から探る （2017/7/13）
2017年6月21日、ピクシブのオフィスで、同社主催の「大規模HTTPS導入Night」が開催された。大規模Webサービスで完全HTTPS化を行うに当たっての技術的、および非技術的な悩みや成果をテーマに、ヤフー、クックパッド、ピクシブの3社が、それぞれの事例について語り合った - ソラコムは、あなたの気が付かないうちに、少しずつ「次」へ進んでいる （2017/7/6）
ソラコムは、「トランスポート技術への非依存」度を高めている。当初はIoT用格安SIMというイメージもあったが、徐々に脱皮しようとしている。パブリッククラウドと同様、付加サービスでユーザーをつかんでいるからだ - Cisco SystemsのIntent-based Networkingは、どうネットワークエンジニアの仕事を変えるか （2017/7/4）
Cisco Systemsは2017年6月、同社イベントCisco Live 2017で、「THE NETWORK. INTUITIVE.」あるいは「Intent-based Networking」といった言葉を使い、ネットワークの構築・運用、そしてネットワークエンジニアの仕事を変えていくと説明した。これはどういうことなのだろうか - ifconfig 〜（IP）ネットワーク環境の確認／設定を行う （2017/7/3）
ifconfigは、LinuxやmacOSなど、主にUNIX系OSで用いるネットワーク環境の状態確認、設定のためのコマンドだ。IPアドレスやサブネットマスク、ブロードキャストアドレスなどの基本的な設定ができる他、イーサネットフレームの最大転送サイズ（MTU）の変更や、VLAN疑似デバイスの作成も可能だ。
 |
|
|
|
|
注目のテーマ
Master of IP Network 記事ランキング
転職／派遣情報を探す
