アーカイブ:  « 2011年5月 | メイン | 2011年9月 »

2011年7月27日

TCPフォールバック

DNSの問い合わせに対する回答が512byteを超える場合にUDPプロトコルではなくTCPプロトコルによって応答される事象を示す。

なぜudp/53宛に問い合わせしたのになぜTCPプロトコルで応答するのか?
- MTUの最小値である576byteDNSの応答パケットとしては512byte(現在は、576byteという経路はほとんどなく、1980年当初の事情を引きずっている)を超えてしまうと経路によってはパケット分割されてしまう。1パケットで処理できるようにRFC1035にて512byte以下の応答パケットに制限されると規定されている。そのため、512byteを超える場合には、TCPプロトコルで応答する。

○備考
DNSクライアント(リゾルバ)はudpプロトコルの任意のポートをバインドして問い合わせしており、応答があるまでバインドし続ける。DNSサーバーは送信元ポートを送信先ポートにし、送信元ポートを53番ポートにして応答することで途中の(外→内の通信を制限する)F/Wを通過することができ(るように設定されていることが一般的であり)、またリゾルバは応答を受けることができる。TCPフォールバックされる場合、UDPの応答パケットにてTCPプロトコルによって再度接続確立が行われて、TCPプロトコルによって応答される。

○なぜDNSはTCPのみでやり取りしてはいけないのか?(個人的な考察)
・SYN Flood攻撃により容易にサービス拒否に追い込まれる
・スリーウェイハンドシェイクをしなければならず、DNSの応答パケットの大きさにかかわらず、絶対的な通信量が多くなってしまう
・下位互換性がなくなる

詳しくはJPRSの資料を参考にするとわかりやすい。

2011年7月11日

memcachedのリソースモニター

初期値パラメタが適切かどうかstatsコマンドで把握するとよい。
bytes が limit_maxbytes の何パーセントを利用しているか
evictions が1を超えているか
の観点で確認する。

詳しくは、memcacheのstatsコマンドメモが詳しい。