PSPのxdsファイルを用いたダウンロードの際の挙動の一観察

PSPにはWebブラウザが存在している。このブラウザはNetFrontベースで意外としっかりしているが、やはり、PCブラウザには敵わない。

そんなWebブラウザであるが、一応、インターネットから大きなファイルをダウンロードすることができる。そのダウンロードの形式の1つとして非公式ではあるが、xdsファイルを用いるものがある。このxdsファイルを用いることで、複数ファイルのダウンロードに対応することができる。複数ファイルといっても、動画or音楽ファイル+サムネイルを一緒のフォルダに入れるということ程度しかできない。

xdsではmp3などのメディアのファイルとjpgを指定することができる。このxdsファイルによるダウンロードが行うことができたかどうか、Webサーバプログラムであるapacheのログを確認してみたところ、xdsファイルアクセス後にmp3ファイルに3,4回のアクセスを行っていることが確認できた。間は1秒程度だ。

このmp3ファイルへの複数のアクセスは、複数コネクションを張っているのではないか?と仮説を立ててみた。PSPは無線LAN接続のみしかインターネットにアクセスすることができない。そのためTCPコネクションを複数張ることで無線LANの帯域変化を吸収しているのではないかと考えたからだ。

仮説を検証するべく、自宅内でネットワークを構築し、Webサーバ上でキャプチャを行い、観察を行った。tcpdump(正確にはtshark)によるキャプチャを行い、キャプチャ結果から簡易な解析を行った。結果として、複数コネクションを張っているという仮定は正しくはなかった。

キャプチャの結果、xdsファイルへのアクセスが1回、mp3ファイルへのアクセスが4回、が確認された。

xdsファイルにアクセス後の初回のmp3へのHTTPアクセスはサーバからの応答HTTPヘッダを参照後、直ちにTCPによるRSTフラグを送信していることが分かった。つまりmp3の実体をダウンロードすることなくPSPから切断を行っている。このアクセスは実際にダウンロードを行っていないことから、実際に指定したmp3ファイルが存在しているかどうかを確認していると考えられる。

後の2回のmp3へのアクセスは同様にTCPのRSTフラグを送信することによってコネクションを切断しており、実体は4回目のアクセス時にダウンロードを行っていることが分かった。複数回の確認を行う理由を知るため、セグメントを確認してみたところ、HTTPヘッダに違いがあることが分かった。

1回目のアクセスの要求時のHTTPヘッダ

Connection: Keep-Alive

2回目のアクセスの要求時のHTTPヘッダ

Pragma: no-cache
Cache-Control: no-cache
Connection: close

3回目のアクセスの要求時のHTTPヘッダ

Connection: Keep-Alive

この挙動について調べてみたところ、確信はないが、2回目のHTTPヘッダはProxyサーバに対する制御を行っていると考えられる。

Cache-Controlにおけるno-cacheはHTTP 1.1においてブラウザやProxyがキャッシュを行ってはならないことを示す。PragmaはHTTP 1.0への互換性のために指定している。この設定を行うことによって、(実際にそのような挙動を行うのかどうか確認はおこなっていないが)Proxyのキャッシュを削除しているのではないかと思う。またConnectionのcloseはKeep-Aliveを終了する旨であり、Proxyがサーバに対する永続的接続を一旦終了するように促している。

その後、キャッシュクリアされたProxyにおいて、オリジナルのサーバのファイルにアクセスしようとしているのではないか、と考えられる。

以上の結果をもって、当初の仮定であるTCP複数コネクションによるダウンロード説は棄却とする。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください