屑俺日記

☆ たとえば某サイトにアクセスしただけで

3960ほどのパケットがキャプチャできた。
アクセスした先のIPアドレスが、

$ tcpdump -q -n -r $DATA -p not arp |
  awk '$0=$3'| sed 's/\.[[:digit:]]*$//'|
  sort | uniq -c | sort -n
reading from file $DATA, link-type EN10MB (Ethernet)
     18 23.59.139.27
     27 54.230.111.130
     33 54.200.125.198
     35 216.58.196.232
     58 117.18.237.29
     64 216.58.197.14
    100 192.168.100
    112 31.13.95.36
    129 31.13.95.12
    169 8.8.8.8
   1341 160.16.82.120
   1860 192.168.100.101

DNS(8.8.8.8のみ)だけでも、

$ tcpdump -n -q -r $DATA -p udp port 53 | wc -l
reading from file $DATA, link-type EN10MB (Ethernet)
338

以下、v4。

$ tcpdump  -n -r $DATA -p udp port 53 |
  grep ' A?' | awk '$0=$8' |
  sort | uniq -c | sort -n
reading from file $DATA, link-type EN10MB (Ethernet)
      1 rapidssl-ocsp.geotrust.com.
      1 support.mozilla.org.
      2 normandy.cdn.mozilla.net.
      2 self-repair.mozilla.org.
      2 staticxx.facebook.com.
      2 www.facebook.com.
      4 ocsp.digicert.com.
      5 ssl.google-analytics.com.
      8 platform.twitter.com.
      8 www.openstreetmap.org.
     10 clients1.google.com.
     13 k-of.jp.
     16 connect.facebook.net.
     17 safebrowsing.google.com.

それからv6。

$ tcpdump  -n -r $DATA -p udp port 53 |
  grep ' AAAA?' | awk '$0=$8' |
  sort | uniq -c | sort -n
reading from file $DATA, link-type EN10MB (Ethernet)
      1 rapidssl-ocsp.geotrust.com.
      1 support.mozilla.org.
      2 normandy.cdn.mozilla.net.
      2 self-repair.mozilla.org.
      2 staticxx.facebook.com.
      2 www.facebook.com.
      3 ocsp.digicert.com.
      5 ssl.google-analytics.com.
      8 platform.twitter.com.
      8 www.openstreetmap.org.
      9 clients1.google.com.
      9 safebrowsing.google.com.
     10 k-of.jp.
     16 connect.facebook.net.

ここでは相当負担になっているに違いない。
dnsmasq入れるべきか。

☆ ブラケットの中

ちょっと正規表現確認。

$ echo -e 'A?\nA \nAx\nA*\nA5'
A?
A 
Ax
A*
A5
 
$ echo -e 'A?\nA \nAx\nA*\nA5' |
>  grep "A[? *]"
A?
A 
A*

☆ どこで遅いのか

また同じサイトに繋ぐ前後、ping してみた。
今度は送信元と送信先とにtcpdumpを仕掛けて、 どのシーケンス番号がいつ送受信されたかを確認できるようにする。
直前に時計を合わせておく、べきだったかも。

$ ping $REMOTEHOST
//
--- $REMOTEHOST ping statistics ---
513 packets transmitted, 512 received, 0% packet loss, time 512349ms
rtt min/avg/max/mdev = 94.498/13376.913/36369.618/8838.699 ms, pipe 37

まず、いちばん遅延の大きいパケットのシーケンス番号を確認。

$ grep 36369 typescript
64 bytes from mail.kuzuore.com ($REMOTEHOST): icmp_seq=438 ttl=55 time=36369 ms
rtt min/avg/max/mdev = 94.498/13376.913/36369.618/8838.699 ms, pipe 37

で、其奴の出入りした時刻を送信元と送信先でそれぞれ確認。

$ tcpdump  -n -r put_ping.cap |grep "seq 438"
reading from file put_ping.cap, link-type EN10MB (Ethernet)
14:50:52.114341 IP $LOCAL_IP > $REMOTEHOST: ICMP echo request, id 15301, seq 438, length 64
14:51:28.483845 IP $REMOTEHOST > $LOCAL_IP: ICMP echo reply, id 15301, seq 438, length 64
 
$ tcpdump  -n -r get_ping.cap |grep "seq 438"
reading from file get_ping.cap, link-type EN10MB (Ethernet)
14:51:28.476450 IP $LOCAL_IP > $REMOTEHOST: ICMP echo request, id 15301, seq 438, length 64
14:51:28.476496 IP $REMOTEHOST > $LOCAL_IP: ICMP echo reply, id 15301, seq 438, length 64

pingのrttと、tcpdumpの時間差はだいたい一致している(約36秒)みたい。
要するに、pingのrtt遅延は、request(アップロード)の時点で、向こうに着く前に、 どこかで待たされていることに由来する可能性。
replyはすぐに戻っている(7msの計算値以前に、放置気味のntpを疑わないと)ようだけど。

流石にtypescriptより、tcpdumpの出力のほうをつついたほうがいいか。