web-dev-qa-db-ja.com

HTTPダウンロードはしばらくすると停止し、再開できません

HTTP経由でファイルをダウンロードしようとすると、約30MB後にダウンロードが停止することがあります。ダウンロード速度は0B/sに低下し、データは送信され続けません。ダウンロードを停止して再開しても、ダウンロードがハングします。しかし、バイト0から再度ダウンロードすると、再び停止すると30MBまですべて正常に動作します。場合によっては、数時間後、問題なく再び機能することがあります。ダウンロードが停止したときのファイル内の位置は可変ですが、ほとんどの場合、約30〜35MBです。

ダウンロードマネージャーとして、私はwgetを使用しています。 curlやその他のダウンロードマネージャーを使用しても、同じ動作が発生します。このエラーは、ダウンロード元のサーバーとは関係なく発生します。ネットワーク内の他のLinuxコンピューターでもこのエラーが発生しました。ネットワーク上のすべてのコンピューターは、x86上でGentooLinuxを実行しています。

ネットワーク上のすべてのインターネット接続は、ポート80で透過的なSquidプロキシを実行するネットワーク上のサーバーを経由します。そのサーバーは、Deutsche TelekomAGのSpeedportW700Vであるルーターに接続されています。そのルーターは、ADSLを使用してインターネットに接続されており、ダウンスピードは448 kbit/s、アップスピードは96 kbit/sです。

私の透過プロキシは問題ではないとほぼ確信しています。問題を解決せずにオフにしました。また、問題を解決せずに、WLAN経由でルーターに直接接続しました。また、HTTP経由で別のポートを介してダウンロードしようとしました。さらに、ゲートウェイ6トンネルを備えたIPv6を使用してコンピューターからファイルをダウンロードしようとしましたが、まったく同じ問題が発生しました。

奇妙なことに、FTPとHTTPSを使用すると（同じコンピューター上のwgetでも）すべてが正常に機能します。さらに奇妙なことに、FTPまたはHTTPSを使用してHTTPでハングしたダウンロードを再開し、その方法で数バイトをダウンロードし、wgetを停止してから、HTTPを使用して再開すると、データが再度読み込まれます。ただし、数MBを超えると、再び停止する場合があります。残念ながら、その方法でダウンロードされたファイルは常に壊れているため（MD5の合計は正しくありません）、ある時点で、偽のデータがあったに違いありません。ダウンロードしたファイルでHTMLエラーメッセージを検索しようとしましたが、grep -ihtmlで何も見つかりません。 （ファイル内のGZIP圧縮されたHTMLエラーメッセージを検索する方法が思いつかないので、試しませんでした。）

ダウンロードの再開に失敗したときにwgetでstraceを使用してみましたが、出力全体を見つけることができます Pastebin上 。重要な行は毎秒繰り返されます：

clock_gettime(CLOCK_MONOTONIC, {326102, 62176435}) = 0
)                    = 1
write(2, "78% [++++++++++++++++++++++++++++"..., 19578% [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++                                  ] 110,683,685 --.-K/s              ) = 195
select(4, [3], NULL, NULL, {0, 949999}) = 0 (Timeout)

この問題の原因が何であるかはまったくわかりません。問題の原因は何でもHTTPを話しているようです。 HTTPは、IPv6-over-IPv4トンネルでそれを認識することさえインテリジェントに話しているようです。しかし、それは何である可能性があり、なぜそれがたまにしか起こらないのですか？他の可能性は、他のGentooLinuxコンピューターでも同じ問題が私のコンピューターにあることです。

誰かがそのような問題を抱えたことはありますか？その理由は何でしょうか。また、問題について詳しく知るためにどこで調査を続ける必要がありますか。

更新：

もう一度問題が発生し、ルーターのWLAN経由でダウンロードを再開しようとしましたが、今回は機能しました。たぶん、WLANでの最後のテスト中に何か間違ったことをしました。おそらく私の透過プロキシサーバーが実際に問題になっています。これは、何もキャッシュしない非常に基本的なSquidプロキシサーバーです。 2番目のSquidプロキシが同じコンピューターの別のポートで実行されているという事実は興味深いかもしれません。

更新：

ダウンロードが再びハングし、今回はすべてのファイアウォール設定をオフにして、すべてのプロキシサーバーを停止しました。ルーターに直接接続されているネットワークサーバーからのダウンロードを再開できませんでした。したがって、私のプロキシサーバーは間違いなく問題の原因ではありません。管理者アクセス権はありませんが、ルーターのファームウェアをアップグレードしようとしています。何ができるか見ていきます。

更新：

ルーターの最新のファームウェアにアップグレードしても効果はありませんでした。これが私のISPのせいである以外の可能性は見当たらない。私の「解決策」は、SSHサーバーを介してすべてのトラフィックを別の場所にトンネリングすることです。

linuxnetworkinghttpwget
3
cdauth

この投稿は本当に古く、すべてのネットワークインフラストラクチャが長い間置き換えられていますが、それでもソリューションを投稿したかったので、当時は投稿しませんでした。

この問題は、ネットワークサーバーをルーターに接続しているネットワークカードが原因で発生しました。カードを交換すると問題が解決しました。正確に何が問題だったのかわかりません。特定のバイトシーケンスまたはその他の特定の条件によって引き起こされたファームウェアのバグである可能性があります。

1
cdauth

さらに奇妙なことに、FTPまたはHTTPSを使用してHTTPでハングしたダウンロードを再開し、その方法で数バイトをダウンロードし、wgetを停止してから、HTTPを使用して再開すると、データが再度読み込まれます。ただし、数MBを超えると、再び停止する場合があります。残念ながら、その方法でダウンロードされたファイルは常に壊れています（MD5の合計は正しくありません）

これは「壊れたプロキシ」と叫びますHTTPダウンロードを再開するためのプロトコルは決して複雑ではありません（それは単なる余分なヘッダーです）が、これはまさに壊れたプロキシが台無しになるようなものです。

Wgetを使用して大きなファイルをダウンロードし、失敗するのを待ってから、wget -cを実行してhttpをhttpsに変更しようとすると、問題なく再開されるはずです。

2
Justin