lxyuma BLOG

開発関係のメモ

1章レイテンシと帯域幅:ハイパフォーマンスブラウザネットワーキング

ハイパフォ本

今、社内でO'Reillyの

「ハイパフォーマンスブラウザネットワーキング」

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

の勉強会（読書会）をしていて、

１章のレイテンシーをやったので、以下にも貼っておきます。

今この本読んでる方、沢山いらっしゃると思うので、

読書の手助けによければどうぞ。

ハイパフォ読書会

パフォーマンスを左右する要素

  • レイテンシー
    • 送信元がパケットを送信してから宛先が受信するまでの時間
  • 帯域幅
    • 論理的、物理的通信路における最大スループット
    • どれだけ情報をながせるか？の最大値
    • フレッツ等で、回線速度が100Mbps等話しているのは、要するに帯域幅の事。

レイテンシー構成要素

  • ルータ時間を消費する主要な構成要素

    • 伝搬遅延(propagation delay)
    • 伝送遅延(transmission delay)
    • 処理遅延(processing delay)
    • キューイング遅延(queuing delay)

  • 書籍の中の説明文が分かり辛いので

  • 別サイト参考に言い換えていくと

伝搬遅延

  • パケット送信時にかかる物理的な遅延
    • 例えば、光ファイバーだと、光の屈折等で遅延する時間の事(後で出て来る)

伝送遅延

処理遅延

  • パケットのヘッダー処理
    • パケットの次の方向を決定する間に、ルータが行うビットレベルのエラー検知
    • これらによっての遅れの話。

キューイング遅延

  • 帯域幅以上のパケットが到達した場合、ルータは、超過したパケットをバッファに溜め込む。
    • このパケットをバッファに保持する時間がキューイング遅延。
    • 輻輳（ふくそう）遅延も同じ話らしい(次の章で出て来る)

伝搬遅延

  • 光は毎秒29万km(真空中の早さ)
    • 光を運搬する素材により遅くなる
    • 屈折率が大きい程光も遅く伝わる
  • 光ファイバの屈折率(1.4~1.6)による遅延も含めて概算すると
    • 毎秒約20万km(元と比べると10万kmも違うんですね)

東京版伝搬時間の表

  • 書籍に有る様なアメリカ視点の数値見ても面白くないので
  • レイテンシを東京を中心にクラウド/VPS等と計算してみる
    • AWS(PaaS等も) :アメリカ西海岸 (※勿論、東京リージョン他もありますが、あくまで１例です）
    • digital ocean（最近おすすめのVPSです。news記事参照） :最近追加されたシンガポールで見てみる
ルート 距離 真空中の伝搬時間 光ファイバの伝搬時間 光ファイバでの往復時間
東京-サンフランシスコ 8280km 28 ms 41ms 83ms
東京-シンガポール 5350km 18ms 27ms 54ms

東京版伝搬時間

  • 東京-SFはNY-SF距離4000kmの２倍。NY-Sydneyが1.5万kmなので、その半分。
    • 意外と短い(勿論、直線距離なので、実際はもっと複雑で距離かかるが)
  • RTT:往復時間(Round Trip Time)
    • NY-Sydneyが1.5万kmで160msと非常に遅い（北半球と南半球またぐと距離かかりますね)

人間の遅れの知覚

  • 100-200msの遅延：遅れを知覚
  • 300msの遅延：反応が鈍いと報告
  • 1000ms超える：ユーザーの意識が切り替わる。
  • この数値とさっきのNY-Sydney(160ms)と比べると、いかに伝搬時間大きいか分かる。

ラストマイル問題

  • 大幅なレイテンシ：大抵、最後の数マイル

traceroute

  • 経路するルータを見るならtraceroute
    • windowsの方はtracert
    • mac は 勿論、黒い画面からtracerouteいけるが、実はGUIもある（アプリケーション=>その他=>ネットワークユーティリティ）
  • 参考

googleにtraceroute

$ traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 74.125.235.101
traceroute to google.com (74.125.235.101), 64 hops max, 52 byte packets
 1  xx.xx.xx.xx ( xx.xx.xx.xx)  1.416 ms  1.073 ms  1.470 ms
 2  xx.xx.xx.xx ( xx.xx.xx.xx)   1.991 ms  2.660 ms  1.772 ms
 3  xx.xx.xx.xx ( xx.xx.xx.xx)   2.167 ms  1.334 ms  1.391 ms
 4  xx.xx.xx.xx ( xx.xx.xx.xx)   1.726 ms  1.682 ms  1.927 ms
・・・省略・・・
11  209.85.251.39 (209.85.251.39)  2.467 ms
    nrt19s02-in-f5.1e100.net (74.125.235.101)  2.543 ms
    209.85.251.39 (209.85.251.39)  2.665 ms

tracerouteの見方

$ traceroute to google.com (74.125.235.101), 64 hops max, 52 byte packets
 1  12.34.56.789 (12.34.56.789)  1.416 ms  1.073 ms  1.470 ms

// 順序番号(TTL)　IPアドレス　１回目のTTL=1パケット往復時間　２回目　３回目
  • ホップ：ルータがサブネット間を超える度に１カウント
  • ここでは、最大６４回迄ルータ移動する
  • tracerouteはTTLを使ってる

TTL

  • Time To Live:パケットの生存期間
    • パケットが永遠に徘徊しないように、生き延びられる回数を指定する安全装置の仕組み
    • 期間は、ホップ数で指定
    • パケット送出時に、必ずTTLを設定(MAX=255)
    • ルータ１つ経由毎にTTL１減算。
    • TTL=1になった(ここを1引くとTTL0になる)時に、ICMP(echoで使われるプロトコル) Time Exceedエラーを送出
    • 参考

traceroute 原理

  • tracerouteは、TTL=1から初めて、エラー返されたらIPや時間計測して、１ずつ増やして繰り返す
  • ここの記事の図が分かりやすい
    • TTL = 1から始まり、１台目のルータにすぐに破棄されたら、
    • 次はTTL = 2にして、２台目のルータに破棄され、
    • 次はTTL = 3で、、、というか形で試して行く

tracerouteのエラー

各ユーザーの帯域幅

  • Userが使用できる帯域幅はクライアントと宛先サーバー間の一番小さい帯域幅に依存する
    • akamaiの2013年の平均帯域幅でも、日本は11.7Mbps
    • 昔自分も使ってたYahoo BBのADSLが8MBで、それより少し大きい位。当たり前だけどブロードバンド普及してる。
  • speedtestで、近くのサーバー(多分、東京)への上がり下りスピードを計測できる
    • 家のブロードバンド環境で試してみて、プロバイダーの言ってた値と比較すると面白いかも

余談

次は

TCP/UDPもやる予定です。

土日にまとめよう。