curl は POST や PUT でリクエストボディの長さが長いなどの特定条件になると、まず Expect: 100-continue をつけてリクエストを送り、サーバ側の対応を待ってからリクエストボディを改めて送るという行儀が良い実装になっている。
しかし、特に IoT っぽい機器では Expect: 100-continue に対応していないものもあるので、抑制したい場合がでてくる。そういうときは以下のようにする。
curl -H "Expect:" -d ... url
空の Expect ヘッダを指定することで上記のような挙動をしなくなり、最初からリクエストをフルで送りつけるようになる。
結論からいうと CAT6 か CAT6A を使う。33m までなら CAT6 でも良いことになっているので家庭なら CAT6 でも十分ということになる。ただ伝送帯域に余裕がないので、取り回しに問題がないなら CAT6A を使うほうが良さそう。
簡単にいうと CAT7 CAT8 のコネクタは CAT6A 以前とは互換性がない。
ケーブルにいくら CAT7 CAT8 適合なものを使っても、コネクタに 8P8C (RJ45) を使う場合には CAT6A と同等の扱いとなる。ただの硬い CAT6A ケーブル。
また、CAT7 以上では STP なので、機器側でアースがしっかりとれていなければならない。家庭用機器でアースをとるものはほとんどない (接地用端子・接地極がついたコンセントがそもそも普及してない) で、この点でもやはり意味がない。
経緯としてRTX1200 の DNS 機能が TCP フォールバックに対応してないのでオフにした、というのがある。直接 8.8.8.8 8.8.4.4 を DHCP で広告するようにしてみたが、RTT が 8ms ぐらいあるので、やはり LAN 内にキャッシュサーバがあったほうがいいかなと思いはじめた。
LAN内には常時動いている Raspberry Pi のホストがいるので、ついでにこのホストにDNS機能もやらせることにしてみた。
unbound がキャッシュサーバ専用でよさそうなのでこれにする。
sudo apt-get install unbound
#/etc/unbound/unbound.conf.d/my.conf
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
server:
verbosity: 1
num-threads: 4
interface: 0.0.0.0
interface: ::
msg-cache-size: 64m
msg-cache-slabs: 4
rrset-roundrobin: yes
rrset-cache-size: 64m
rrset-cache-slabs: 4
infra-cache-slabs: 4
access-control: 192.168.0.0/16 allow
key-cache-size: 64m
key-cache-slabs: 4
neg-cache-size: 64m
prefetch: yes
forward-zone:
name: "."
forward-addr: 8.8.8.8
forward-addr: 8.8.4.4 # 自動起動 sudo systemctl enable unbound # 起動 sudo systemctl start unbound # ステータス sudo systemctl status unbound # ログ sudo journalctl -r
以下のようなコマンドでクエリ数やキャッシュヒット率が見れる。
unbound-control stats_noreset | grep total
キャッシュヒット率を見つつ、あんまり意味がなさそうなら (数%ぐらいしかヒットしないとか) やめるつもり。
自宅は昼間は誰もいないので、このタイミングでTTLが短いほとんどのキャッシュは無効になってしまう。unbound の prefetch は TTL が残り10%になったときにクエリがくると再問合せする機能なので、クエリがこなければ一切 prefetch はされない。
さらには一番影響がでるブラウザでは、DNS prefetch が実装されているので、体感的にはネットワークの近くにDNSがあっても意味がないことが多い。
自分で DNS キャッシュサーバを運用するコストと釣り合わないかもしれない。
raspi の IP アドレスを固定しておく
#/etc/dhcpcd.conf interface eth0 static ip_address=192.168.0.222/24 static routers=192.168.0.1 static domain_name_servers=127.0.0.1
sudo systemctl daemon-reload sudo systemctl stop dhcpcd sudo ip addr flush dev eth0 ; sudo systemctl start dhcpcd sudo systemctl restart avahi-daemon.service
確認
dig @192.168.0.222 example.com
同一ホストで
sudo unbound-control stats_noreset | grep total sudo unbound-control dump_cache
127.0.0.1 より localhost のほうが書きやすいし良さそう、と思って localhost と書いているとしばしばハマります。
というかなんとなく localhost = 127.0.0.1 と考えがちではないでしょうか？ そんなことはないので気をつけましょう。
最近のシステムなら /etc/hosts を確認すると少なくとも2つの localhost エントリを見ることができるでしょう。
127.0.0.1 localhost ::1 localhost
上は IPv4、下は IPv6 です。localhost はどちらのアドレスにも解決しうるホスト名となっています。
例えば同一サーバでリバースプロキシを行ってバックエンドサーバと繋ぎこみを行う場合、フロントのリバースプロキシで localhost:5000 と書くと IPv4 IPv6 どちらでアクセスされるか不定です。バックエンドサーバが IPv4 しか bind していないと IPv6 アドレスが選択されたとき接続不可になります。
すべてのサービスで IPv4 IPv6 ともに接続可能にし、ホスト名でアクセスできるようにすること。
非公開な内部向けサーバとかだと割と IPv4 しか使えないようにしがちではないかと思いますが、ちゃんとやったほうが無難です。
ホスト名でひける IP アドレスの種類と実際に受けつけるプロトコルの種類をあわせること。
localhost の替わりに 127.0.0.1 か ::1 を使ってプロトコルを明示すること。
実際にところは localhost に限らず、ホスト名でアクセスするときには必ず気をつけるポイントです。DNS で IPv4 IPv6 いずれのアドレスも解決できるようにするなら、そのホスト上で待ち受けるサービスは全てデュアルスタックになっていないと、あらぬところでハマったりします。