ラウンドトリップROCA前回記事に対して、「ICMP(ping)のパケットの優先度を落としているだけでは」という意見も幾つかあったようだ。本文でも書いているとおり、僕自身はパケットロス率に注目したのではなく、それに伴うラウンドトリップタイム(RTT)の時間帯での差異から(ICMP/TCPあるいはUDP関わらず)バックボーンを守るための何らかのパケット制限がかけられているのではないか、という見解だ。70-90%という値があまりにセンセーショナルだったため数字が一人歩きしたか、エントリー全文が読まれていないということかと思うのだが、せっかくなので、ではTCPではどうなのか確かめてみた。データ定額(mopera.flat.foma.ne.jp)でSafariから3ページ表示させ、その間にパケットロスなどがどのように発生しているか計測する。-sにて統計値も取得する。テスト前にはiPhoneは再起動しておく(つまりnetstat統計値をクリア)。前回のテストサーバー2(さくらインターネットのVPS、国内設置。このサーバーである)netstat計測値については起動直後にテストを開始しているとは言えsshアクセスなども含まれるので絶対値ではないことに注意して欲しい。各テスト間での相対値に注目したい。以上だが、まずはリファレンスとしてWi-Fi(フレッツ光)アクセス時のnetstat値を示す。基本的には回線上何のストレスもかかっていない場合と理解することが出来るだろう。以下、テスト時間帯はPM10時台である。この時点でSB回線でのpingテストではロス率54%程度を示していたが、Wi-Fi環境では0%である。overflow今回ポイントになりそうなところは強調しておいた。送信210パケットに対して同再送によるパケット送信は1に止まっている。61セッションに対する再送回数は1回だ。再送というのは一般的には途中回線品質などにより送信パケットがロスし、受信側が送信側へパケットが欠けていることを通知し再び欠けているところから送信が再度行われたことを意味している。影響は欠けた1パケットに止まるのではなく、セッション中欠けたところから全て再送されなければならないので、受信バッファが大きいとそれだけコストの高い再処理となる。Wi-Fi環境でも起き得る一般的な現象であることはここから分かるだろう。それは全体に対して大したインパクトでも無さそうだ。以下はtcpdumpから該当箇所を抜き出した例だ。次にソフトバンク回線で試した。以下は同様にnetstat値である。overflow違いに気付いてもらえるだろうか。再送率が格段に上がっている。112回のセッションに対して再送は174回起きている。1セッション当たり1-2回は送信がやり直されている計算になる。以下はtcpdumpから一部のセッションを抜き出したものだ。ドコモ回線ではどうか同様にnetstat値を示す。overflowドコモ回線とてWi-Fi並みの品質ではないと言えるだろう。その再送回数は108セッション中35回であるので単純に考えると75%程度のセッションでは再送は行われず綺麗に完了している計算だ。次にAM3時台のソフトバンク回線の例も示そう。この時点でpingパケットロス率は0%になっている。overflowドコモに比べれば率は悪いものの、PM11時時点に比べればかなり改善されていることが分かる。時間帯により何らかの外的要因により(要するに回線品質)変動が起きていると言えるだろう。ICMPとTCPが異なったポリシーで優先度が変えられているかも知れないという意見については同意だ。それは外部から判別できるものではなく(予想は大いにされているようだが)正直なところ中の人にでも聞かなければ分かるはずもない。繰り返しになるが、これは憶測でしかないがTCPでも同様の傾向がある以上、何らかの運用ポリシーがあるのは間違いなさそうだし、そもそもRTT変動からすれば繁忙期にバックボーンを守るための何らかの施策が関わっている可能性は高いのではないかと思う。エビデンスとして、こちらにtcpdump結果を公開しておく。前回も書いたとおり、筆者は専門家でも詳しいわけでもないのであまり応答することはないと思うが、意見や見解・議論などは大いに拝見できればと思っている。僕自身は仮に内部的に問題抱えていようと、「いいじゃん、普通に使えるなら。他社より安いし」という立場です。GETリクエストのパケットのようですね。下りの再送も、上りで再送が起こったセッションと同一のセッションで発生していることが多いようです。特定のHTTPリクエストでレスポンスが返ってくるのが想定より遅かった(それまでの通信のRTTから計算したRTOの時間内にレスポンスが返って来なかった)ために、再送タイムアウトが発生したのかも知れません。1秒前後でリクエストを再送している例が多くありました。回線の太さや混雑具合が引き金になっていると思いますが、最終的にはエンドホストの問題のように見えました。20:26時間帯で変わるみたいですね。こちらでも、iPhone4使って試してみましたが、この時間帯は、20MByteのファイルのUPLoad/DownLoadを試しても、どちらも大きな再送などは発生しませんでした。@東京都北部#データのダウンロードでは上位のスイッチ-iPhone間での、#再送が発生したとしても、netstat上ではカウントされない#気がするので、正確な再送率を調べるのは難しいようですが。コメントをキャンセルメールアドレスが公開されることはありません。date*日本語が含まれない投稿は無視されますのでご注意ください。コメントデータの処理方法の詳細はこちらをご覧ください。