TCP/IPにおけるリジュームの仕組みについて

質問

現在、「マスタリングTCP/IP 応用編」を読んで、TCP/IPについて学習をしています。
本を読んでいく中で、分からないことがあり、ネットで調べてもいまいち要領を得ませんでしたので質問いたします。

疑問に感じたのは上記書籍の2つの文言です。
(1)「データグラムがネットワークを通るとき、データグラムがネットワークのMTUを超えていれは、フラグメント化を行わなければなりません。」（101Pより引用）
(2)「マルチフラグメントデータグラムの最初のフラグメントを受信すると、受信側のホストはバッファースペースを割り当て、タイマー（再構成タイマー）を起動させます。このタイマーが終了しないうちに、すべてのフラグメントが受信されなければなりません。受信終了前にタイマーが終了すると、それまでに受信したフラグメントはすべて破棄され、ICMPメッセージが送信元ホストに送られます。」（102Pより引用）

●質問１
IEにて（LinuxOSのような）大きいサイズのデータをダウンロードしている際に、データ伝送に遅延が発生し、(2)におけるタイマーが終了してしまった場合に、「Internet Explorerではxxxxxxxをダウンロードできません。処理がタイムアウトになりました」といったメッセージが出るという考えで合っていますでしょうか？

●質問２
IEなどではデータのダウンロードが95%まで行っていてもタイムアウトエラーなどでダウンロードが中断すれば、また始めからダウンロードを開始しなければなりません。（この考えは(1)と合っている気がします。）
しかし、リジュームに対応しているダウンローダーなどを用いれば、中断しても95%からダウンロードを再開できますが、ダウンローダのリジューム機能というのはどのように実装されているのでしょうか？
もう少し具体的に書きますと、自分のPCからOSを格納しているサーバまでのルートが常に一定（たとえばA→B→Z）であれば、(1)で判明したMTUに従って分割された残りの5%に相当するフラグメントファイルのみダウンロードすれば残りファイル全てが手に入るのかもしれませんが、そもそもそんな要求ができるのでしょうか？
もし出来るとしても、それは中断前と再開時のルートが同じであるという前提であると考えています。たとえば、1日前にダウンロードを中断し、翌日にダウンロードを再開した際に、ルートが変わっていた場合（例えばA→C→Z）、MTUも変わる事があると思いますが、、、そんな時にはどうやってリジュームを実現するのでしょうか？

長くなりましたが、わかる方、教えていただけると幸いです。

回答No.5

yama1718

質問２だけ答えますね。
＞これから受信する2.5%のパケットをアプリケーション層にて結合する際には特に考慮する必要がない。
実際のプログラム例も紹介します。
http://www.atmarkit.co.jp/fdotnet/dotnettips/710resumedown/resumedown.html
http://dobon.net/vb/dotnet/internet/resumedownload.html
考慮した方が良い場合もあります。
同じアドレスで同じファイル名だったとしても内容が違う可能性があります。
少なくてもヘッダ情報などを照合して本当に同じファイルか確認する必要はあります。
他にソフトによってはダウンロードが切れた時に末端のデータが壊れている可能性を考慮して、ダウンロードを再開する位置を末尾から少し手前にロールバックする場合もあります。
APIからのタイムアウトエラーみたいな正式な中断以外に、フリーズなどもっと悪い状態で落ちる事もありますから。

お礼

回答ありがとうございます。

トランスポート層からの受信ファイルとして分割されていることは意識しなくても良いですが、
「中断されたファイル」としては、中断された契機・状態が分からないため
アプリケーション層でカバーする必要がある問ことですね。

回答No.4

Gotthold

> まず、191秒目で送信できたパケットは190秒目までの285Mbyte(95%)→あ
> 最後の1秒分は到達できず、タイムアウトとなったとする。
TCPのタイムアウトは応答がなくなってからの時間ではないですか？
190秒目まで継続的にダウンロードできていたなら
それまでずっと応答はあったと言うことなので
そこでいきなりタイムアウトになってはいけないと思います。

> アプリケーション層でのタイムアウトとなり、
> 「Internet Explorerではxxxxxxxをダウンロードできません。処理がタイムアウトになりました」
> と、表示される。
IEの場合、
Webページを表示するときはダウンロードに時間がかかるとタイムアウトになるようですが、
ファイルのダウンロードの場合はそうではないと思います。
（1GBのファイルを数時間かけてダウンロードとかできるので。）

まあアプリケーションのタイムアウトは自由に実装できるでしょうから
それこそ自由に想定してもかまわないとは思いますが。

> 質問２について
> ケース２の状態からのリジュームは以下のとおり。
> ～略～
> (アプリケーション層では受信前、受信後のパケットがどのようなMTUで分割されたかは意識する必要がないため。)
リジュームについてはその通りかと思います。
アプリケーション層からはパケットという概念は見えません。
（単にデータの流れ、ストリームとして処理するだけです。）

お礼

回答有り難うございます。

>TCPのタイムアウトは応答がなくなってからの時間ではないですか？
>190秒目まで継続的にダウンロードできていたなら
>それまでずっと応答はあったと言うことなので
>そこでいきなりタイムアウトになってはいけないと思います。

表現が悪かったです。
ここでいうタイムアウトとは
予め設定したタイマー（再構成タイマー）を超えてしまう、という意味合いでした。
私の理解では、
「受信終了前にタイマーが終了すると、それまでに受信したフラグメントはすべて破棄され、ICMPメッセージが送信元ホストに送られます。」
ですので、再送が必要になるかと思いましたが、、、ならないのでしょうか？

回答No.3

TooManyBugs

非常にざっくりとした答です。、「マスタリングTCP/IP 応用編」あたりだと既にこのあたりの事は理解している者ととして書かれていますので基礎的な書籍から読まれることをお薦めします。

答１　違います。
　　　アプリケーションレイヤのダウンローダのタイムアウトとデータリンクレイヤのTCP/IPレベルでのタイムアウトは別の物です。
　　ダウンローダがタイムアウトとなるのはTCP/IPでのタイムアウトではなく自身のタイマーによるものですから単にデータが送信側から来ない、TCP/IPでは受信しているが時間がかかりすぎるなどが有ります。また一般的にはTCP/IPからタイムアウトを通知されてもエラーで終了せず再送要求することになります。

答２
　TCP/IPはデータの内容には一切関知しませんからダウンロードの再開時にどこから開始するかはもっぱらアプリケーションの問題です。
どこまで受信したかを記憶しておく、或いは受信ファイルのサイズから再開すべき位置をホストに通知するだけです。
ただしタイムアウトでそれまでの受信データを破棄するようなものやダウンロードされるデータが頻繁に変更されるようなものであれば途中からの再開は出来なかったり意味のないものになります。

一般的に下層レイヤーほどタイムアウトをはじめとする通信エラーは多発しますのでそのことによって上位もエラーにしていると通信が成り立たなくなります。

お礼

回答ありがとうございます。

皆様からもご指摘があるように、各層での処理・役割についての理解ができていなかったようです。
（マスタリングTCP/IP 入門編を結構前に読んでいたので、今回は応用編から行きましたが、、復讐が足りなかったようです。）

皆様から頂いた回答を総括して以下のとおり解釈しましたが、理解は合っていますでしょうか？

質問１について
それぞれの層でタイムアウト管理は別とした時に、
以下の処理になる想定ですが認識は合っていますでしょうか？

以下の条件での接続とする。
a.ダウンロードファイルが300Mbyteある
b.ダウンロード要求を出したアプリケーション層のタイムアウトまでの時間は400秒
c.トランスポート層の接続では常にMTUは1500byte※1、タイムアウトまでの時間は191秒
d.1秒に1000MTU送信できることとする。

※1 単純化のため、ヘッダ部は含まず、データ部のみのサイズとします。
　　また、(byte→Kbyte→Mbyteの冪乗も単純化のため、1000とします。)
●ケース1
まず、191秒目で送信できたパケットは190秒目までの285Mbyte(95%)→あ
最後の1秒分は到達できず、タイムアウトとなったとする。
この場合に、再送処理をトランスポート層にて実施(タイムアウト値を＋50秒して送信)
→ICMP受信・再送処理に5秒かかるとする。→い
今回は201秒目に全パケットを送信完了→う

上記あ、い、うを足した時間は397秒であるため、アプリケーション層ではタイムアウトとならずに
正常にダウンロード完了となる。

●ケース2
まず、191秒目で送信できたパケットは190秒目までの285Mbyte(95%)→あ
最後の1秒分は到達できず、タイムアウトとなったとする。
この場合に、再送処理をトランスポート層にて実施(タイムアウト値を＋5秒して送信)
→ICMP受信・再送処理に5秒かかるとする。→い
196秒目で送信できたパケットは195秒目までの292.5Mbyte(97.5%)→う
最後の1秒分は到達できず、タイムアウトとなったとする。
この場合に、再送処理をトランスポート層にて実施(タイムアウト値を＋5秒して送信)
→ICMP受信・再送処理に5秒かかるとする。→え

このあ、い、う、えの合計時点で経過時間は397秒
ここからトランスポート層にて再送処理を始めると、
アプリケーション層でのタイムアウトとなり、
「Internet Explorerではxxxxxxxをダウンロードできません。処理がタイムアウトになりました」
と、表示される。

質問２について
ケース２の状態からのリジュームは以下のとおり。
送受信側でリジュームが可能な場合、
292.5Mbyte(97.5%)まで受信しているため、
アプリケーション層からの制御により、
残り2.5%を受信するリクエストを出す。
この際に、接続経路が変わることにより
MTUが4500byteとなったとしても、
受信済みの97.5%のパケットと
これから受信する2.5%のパケットをアプリケーション層にて結合する際には
特に考慮する必要がない。
(アプリケーション層では受信前、受信後のパケットがどのようなMTUで分割されたかは意識する必要がないため。)

回答No.2

Wr5

アプリケーション層、トランスポート層などがごっちゃになっているみたいですね……。

>タイマーが終了してしまった場合に、「Internet Explorerではxxxxxxxをダウンロードできません。処理がタイムアウトになりました」といったメッセージが出るという考えで合っていますでしょうか？

タイムアウトすればそうなるでしょう。
タイムアウト値はそこそこ長く設定されているかも知れませんが。
# 低速回線を使用している場合もある。ということで、1分か2分くらいは無通信でもタイムアウトしないと思われますが。

>リジュームに対応しているダウンローダーなどを用いれば、中断しても95%からダウンロードを再開できますが、ダウンローダのリジューム機能というのはどのように実装されているのでしょうか？

アプリケーション層までデータが届いていれば、何バイト目まで受信済みか…などは判明しているのですから、リジュームで再開する時に取得する範囲を指定する形になります。
# 可能かどうかはプロトコルにも依存しますけど。

>もし出来るとしても、それは中断前と再開時のルートが同じであるという前提であると考えています。

関係ありません。
リジューム再開する時に新たにTCP接続を行いますので、どのルートを通ろうがMTUが違っていようが関係ありませんから。
# 中断する前の通信でMTUに達していないパケットはアプリケーション層まで来ませんから「受信済み」扱いにはなりません。

まぁ、そのうちもっと詳しい方がわかりやすく回答してくれるでしょう。
たぶん。
# WireSharkなどで実際の通信とか覗いてみた方がいいかと思いますけどね。

お礼

回答ありがとうございます。

パケットをトランスポート層で分割した場合、
それを復元するには、トランスポートで分割した全ファイルが必要だと思っていました。

そうではなくて、トランスポート層経由で受信した一部のファイルに関して
アプリケーション層で解釈可能であれば、残りのファイルの受信要求をすることでリジュームが実現されるということで理解しました。

例えば1～100まで分割したうちの95までのパケットを受信しており、そこまでアプリケーション層で解釈できる場合は、残りの96～100についてトランスポート層から送信要求をすることができる、ということですね。その場合、前者（1～95）と後者（96～100）のMTUが異なっていても、それぞれ独立したTCP接続なので、何ら問題がないということですね。

WireShark…面白そうなソフトですね。一度使って見たいと思います。

回答No.1

yama1718

通信のエラー訂正や再送はトランスポート層の役割ですが、
ダウンロードのレジューム機能はもっと上層(アプリケーション層)のＨＴＴＰやＦＴＰプロトコルに含まれる機能ですね。
レジューム機能の無いクライアントはダウンロードが失敗したら、途中までダウンロードできたファイルを放棄します。
レジューム機能のあるソフトの場合はどこまで正常にダウンロードできたか記録していて、再ダウンロード時に何バイト目からダウンロードと指示します。
ダウンロード支援専用のソフトによっては単純に先頭からじゃなくて、ファイル全体をブロックに区切ってそのブロック毎にダウンロードやレジュームを行う高度な物もあります。
そしてサーバー側も途中からのダウンロードのレジュームに対応している必要があります。

参考URL：

http://www.forest.impress.co.jp/article/2006/03/27/madota148.html

お礼

回答ありがとうございます。

そもそもリジューム機能というのはアプリケーション層の処理なので、トランスポート層での再送処理には関係ないということですね。
そのため、トランスポート層からダウンロードファイルの一部を受け取っていれば、アプリケーション層で残りをダウンロードすることができるのですね。