Yukiharu YABUKI の tDiary
このtDiaryを検索します。
2009-04-23 [長年日記]
_ Bandwidth*Delay Products (BDP)
BDPとは、帯域*遅延時間をかけ算した結果である。おなじようなことを表す言葉にLFP(Long Fat Pipe)がある。詳解TCP/IP〈Vol.1〉プロトコル(W.リチャード スティーヴンス/W.Richard Stevens/橘 康雄/井上 尚司)の20.7 バルク・データ・スループットの帯域幅遅延積(BDP) (327p) および 24.3 ロング・ファット・パイプ (386p)にも同じ式がある。
キャパシティ(ビット)=帯域幅(ビット/秒) * 往復時間(秒)という表記である。ACKが相手から往復して戻ってくる時間、つまり遅延時間である。
上記の式は、TCPへの与えるバッファを考える上での基礎となる式である。
- LONG FAT PIPE問題(http://www.soi.wide.ad.jp/class/20040022/slides/08/27.html)
ロング・ファット・パイプ問題とは、「回線は太くなりうる。でも遅延がなくなるわけではない。」ってことで、土管は太くなる可能があるけど、土管の距離が短くなる訳じゃないって感じか。遅延はなくならない。それに光ファイバーで伝送しているなら、光速が律速だ。 - (http://www.psc.edu/networking/projects/tcptune/)
_ 高速再転送と高速リカバリ・アルゴリズム
Linuxカーネルで言及されている(net/ipv4/tcp_input.cあたりや、各輻輳制御でも関連する) "Fast retransmit(高速再転送)" と "Fast recovery(高速リカバリ)" は、詳解TCP/IP〈Vol.1〉プロトコル(W.リチャード スティーヴンス/W.Richard Stevens/橘 康雄/井上 尚司)の21.7 高速再転送と高速リカバリ・アルゴリズム (p351)で言及されている。
_ 最大セグメントサイズおよびウィンドウ・スケールの係数
TCPオプションで、最大セグメントサイズおよびウィンドウ・スケールの係数は設定される。tcpdumpやwiresharkでは、synパケットが流れたときに一緒にみえる。Linux同士のの場合はSACKも有効になるし、タイムスタンプも有効である。両端のどちらかがdisableにしてなければだが。
TCPウィンドウのスケール・オプションの説明については、詳解TCP/IP〈Vol.1〉プロトコル(W.リチャード スティーヴンス/W.Richard Stevens/橘 康雄/井上 尚司) の24.4 ウィンドウ・スケール・オプション (p389)を参照せよ。0から14までの、シフト値であり、16ビットのウィンドウ値をシフトすることでスケールするするようになっている
synをやり取りするときに、スケールが決まる。TCPがバッファを持っていないと、このスケールの値を大きくすることはできないだろうと思う。
ウィンドウサイズの議論は、詳解TCP/IP〈Vol.1〉プロトコル(W.リチャード スティーヴンス/W.Richard Stevens/橘 康雄/井上 尚司) の 「20.4 ウィンドウ・サイズ」(p320)で述べられる。この議論の先には、TCPのスループットを向上させるバッファサイズについての議論がある。ここでは理論と、各OSによりソケットバッファ割り当ての実際について学ぶ必要がある。Linuxの場合は、/procとか、ソケット生成時のバッファ指定の話だ。
_ GPLv3 逐条解説
IPAから最初の版がでた。八田氏はmhatta のジャーナル - GPLv3逐条解説(http://sourceforge.jp/magazine/journals/mhatta/526)で、
関わっていた人間の一人が言うのもなんだが、こんな長くてややこしいものを誰が読むんだろうという根本的な疑問が無くもない。念のため付け加えておくと、もちろんこの逐条解説をすみからすみまで理解しなければGPLv3は使えないなんてことはない。これはある種パラノイアックな仕事である。と言われているが、仕事でFLOSSを使う場合にGPLv3の隅から隅まで知りたいという要望が、IPAを動かしたので、わたしの周りでも少なくとも3人は、隅から隅まで読むだろう人が思い浮かぶ。