Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

NW入門

はじめに

こんにちは、TIG DXユニットの西田と申します。

春の入門祭りの第4弾！ という事で、私はネットワークの入門編を書きます。

プログラマー視点ではあまり馴染みのない技術領域、ネットワーク。そもそもなんで馴染みがないのか？ それは…**独自用語あまりに多すぎ！ 概念も独自すぎ！ **という背景があります。わかります、その気持ち。私もプログラマ出身ですから。

ネットワークの設計という観点ではこちらの記事がありますが、今回は入門という事で、身近な仕組みを実機で動作を確認しながら、解説しようと思います。通常のNW入門って、大体はOSI参照モデルから入りますが、ちょっと重いので今回はやりません。

説明する事

ChromeやSafariなどのブラウザでhttps://www.future.co.jpを入力すると、会社の公式ページが表示されますよね。
その裏側でどんな通信が行われているのかを 実機で具体的に確認して理解する 事を目的にします。

DNSとは

皆さん、基本的にはfuture.co.jpとか、tokyo-calendar.jpとかそういう名前でアクセスする先を認識していますよね？ これはFQDN(Fully Qualified Domain Name：完全修飾ドメイン名)と呼ばれていて、（基本的には）世界中でアクセス先を1つに限定する名前になっています。

ですが、このFQDNだけでは、実はネットワークの世界では通信は出来ないんです。ネットワークの世界では、IPアドレス（ネットワーク上の住所・番地など）を用いて通信が行われています。

その対応付けがこのDNSという事ですね。例えるならこういう事です。

この対応付けをする技術がDNSであり、この対応付けをしてくれる人がDNSサーバという事です。

DNSの仕組み

DNSの仕組み自体は外部にいいサイトがたくさんあるので、仕組みそのものはそっちを見た方が良いです。例えばこのサイトがあります。

動きを見る

さて、それではDNS解決を実機で見てみましょう。DNS調査のコマンドといえば、digです。が、実はWindowsにはインストールされていないので、こちらのサイトでまずは試してみましょう。

基本編

まずはグループ会社である東京カレンダーから見てみましょう。ここがとても分かりやすかったので。
手順は囲いました。

これは、以下を実行しています。

  • 右上のNameserversで指定したDNSサーバ1.1.1.1に対して
    • 1.1.1.1は世界で一番早いと言われているDNSキャッシュサーバです。私は家のPCのDNSはこれにしています。
  • corp.tokyo-calendar.jpのIPアドレスの解決を
  • Traceオプション(反復問い合わせ箇所の結果を返すモード)で実行

結果はこうなりますよね。参考までに、以下は私の手元のlinuxマシンで実行した結果です。

nishida@Ubuntu:~$ dig @1.1.1.1 corp.tokyo-calendar.jp. +trace +nodnssec

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @1.1.1.1 corp.tokyo-calendar.jp. +trace +nodnssec
; (1 server found)
;; global options: +cmd
.			514237	IN	NS	a.root-servers.net.
.			514237	IN	NS	b.root-servers.net.
.			514237	IN	NS	c.root-servers.net.
.			514237	IN	NS	d.root-servers.net.
.			514237	IN	NS	e.root-servers.net.
.			514237	IN	NS	f.root-servers.net.
.			514237	IN	NS	g.root-servers.net.
.			514237	IN	NS	h.root-servers.net.
.			514237	IN	NS	i.root-servers.net.
.			514237	IN	NS	j.root-servers.net.
.			514237	IN	NS	k.root-servers.net.
.			514237	IN	NS	l.root-servers.net.
.			514237	IN	NS	m.root-servers.net.
;; Received 239 bytes from 1.1.1.1#53(1.1.1.1) in 55 ms

jp.			172800	IN	NS	a.dns.jp.
jp.			172800	IN	NS	b.dns.jp.
jp.			172800	IN	NS	c.dns.jp.
jp.			172800	IN	NS	d.dns.jp.
jp.			172800	IN	NS	e.dns.jp.
jp.			172800	IN	NS	f.dns.jp.
jp.			172800	IN	NS	g.dns.jp.
jp.			172800	IN	NS	h.dns.jp.
;; Received 507 bytes from 192.5.5.241#53(f.root-servers.net) in 107 ms

tokyo-calendar.jp.	86400	IN	NS	ns-1512.awsdns-61.org.
tokyo-calendar.jp.	86400	IN	NS	ns-211.awsdns-26.com.
tokyo-calendar.jp.	86400	IN	NS	ns-586.awsdns-09.net.
tokyo-calendar.jp.	86400	IN	NS	ns-1832.awsdns-37.co.uk.
;; Received 219 bytes from 203.119.1.1#53(a.dns.jp) in 42 ms

corp.tokyo-calendar.jp.	60	IN	A	54.250.204.18
corp.tokyo-calendar.jp.	60	IN	A	52.193.252.137
tokyo-calendar.jp.	300	IN	NS	ns-1512.awsdns-61.org.
tokyo-calendar.jp.	300	IN	NS	ns-1832.awsdns-37.co.uk.
tokyo-calendar.jp.	300	IN	NS	ns-211.awsdns-26.com.
tokyo-calendar.jp.	300	IN	NS	ns-586.awsdns-09.net.
;; Received 223 bytes from 205.251.194.74#53(ns-586.awsdns-09.net) in 160 ms

順に説明していきます。

  • .で始まるパート
    • .(ルート)レベルのドメインを持つのは、a-mのroot-serverである。このどれかに問い合わせる、という意味です。
  • jp.で始まるパート
    • 一番下にfrom 192.5.5.241#53(f.root-servers.net)と書いてあります。1.1.1.1が、a-m の中でf.root-servers.netに問い合わせを行った結果が返っています。
    • f.root-serversから、『jpドメインの名前を知っているのは、a.dns.jp-h.dns.jpだからそこに問い合わせてほしい』と返ってきています。
  • tokyo-calendar.jp.で始まるパート
    • 一番下にfrom 203.119.1.1#53(a.dns.jp)と書いてあります。1.1.1.1が、上記のa-h の中でa.dns.jpに問い合わせを行った結果が返っています。
    • a.dns.jpから、『tokyo-calendar.jpドメインの名前を知っているのは、ns-......だからそこに問い合わせてほしい』と返ってきています。
    • ドメインからわかりますが、awsにこのwebサーバが置かれているという事がわかります。route53使ってるんですかね、おそらく。
  • corp.tokyo-calendar.jp.で始まるパート
    • 一番下にfrom 205.251.194.74#53(ns-586.awsdns-09.net)と書いてあります。1.1.1.1が、上記の中でns-586.awsdns-09.netに問い合わせを行った結果が返っています。
    • ns-586.awsdns-09.netから、corp.tokyo-calendar.jpは54.250.204.18と52.193.252.137の2つであると返ってきています。

これで無事、**FQDN から IPアドレス に DNS解決** 出来ました。
解決出来たアドレスで、https通信ももちろんできます。
https://54.250.204.18/
証明書のCNが一致しないので警告画面は出ますが 詳細設定ボタン を押して、下のリンクをクリックすると当然閲覧出来ます。

少し応用

それでは次はwww.future.co.jpを見てみましょう。

nishida@Ubuntu:~$ dig @1.1.1.1 www.future.co.jp. +trace +nodnssec

～～　中略　～～
www.future.co.jp.	60	IN	CNAME	www.future.co.jp-v1.edgesuite.net.
future.co.jp.		172800	IN	NS	ns-1106.awsdns-10.org.
future.co.jp.		172800	IN	NS	ns-131.awsdns-16.com.
future.co.jp.		172800	IN	NS	ns-1906.awsdns-46.co.uk.
future.co.jp.		172800	IN	NS	ns-746.awsdns-29.net.
;; Received 229 bytes from 205.251.192.131#53(ns-131.awsdns-16.com) in 146 ms
{％ endcodeblock %}

最後が`CNAME`で終わってますよね。これ、Akamaiという`CDN`サービスを使っているからなんです。
`CDN`は、簡単に言うとwebのコンテンツ（例えば画像ファイルなど）をクライアントに（NW的に）近い場所にキャッシュしておくことで、webの応答を早くする＆webサーバの負荷を軽くするために使われるサービスです。
なので、実際のFutureのトップページのコンテンツが置かれているサーバではなく、Akamai 管理のコンテンツキャッシュサーバを案内されます。それを`CNAME`という名前の**別名**を設定する事で実現しています。では、この別名を今度は解決します。

{％ codeblock lang:dos line_number:false highlight:true %}
nishida@Ubuntu:~$ dig @1.1.1.1 www.future.co.jp-v1.edgesuite.net. +trace +nodnssec

～～　中略　～～

www.future.co.jp-v1.edgesuite.net. 21600 IN CNAME a1807.b.akamai.net.
;; Received 91 bytes from 23.211.133.64#53(a6-64.akam.net) in 32 ms
{％ endcodeblock %}

また`CNAME` 別名でしたね。ではもう1回。

{％ codeblock lang:dos line_number:false highlight:true %}
nishida@Ubuntu:~$ dig @1.1.1.1 a1807.b.akamai.net. +trace +nodnssec

～～　中略　～～

b.akamai.net.		4000	IN	NS	n5b.akamai.net.
b.akamai.net.		4000	IN	NS	n1b.akamai.net.
b.akamai.net.		4000	IN	NS	n7b.akamai.net.
b.akamai.net.		4000	IN	NS	n2b.akamai.net.
b.akamai.net.		4000	IN	NS	n6b.akamai.net.
b.akamai.net.		4000	IN	NS	n0b.akamai.net.
b.akamai.net.		4000	IN	NS	n3b.akamai.net.
b.akamai.net.		4000	IN	NS	n4b.akamai.net.
;; Received 347 bytes from 95.101.36.192#53(zd.akamaitech.net) in 30 ms

a1807.b.akamai.net.	20	IN	A	23.32.3.80
a1807.b.akamai.net.	20	IN	A	23.32.3.66
;; Received 79 bytes from 221.110.183.69#53(n5b.akamai.net) in 40 ms

ようやく解決出来ました。こちらのサイトでDNS解決を行った場合は、最後に解決できるIPアドレスは違うと思います。先ほど説明した通り、CDNはクライアントに近い場所のキャッシュサーバを案内するため、接続元の場所が大きく違うと違うIPアドレスになるのが正しいです。
ちなみに、私が試した上記の環境は、会社支給のポケットwifiで試しているので、そのSIM携帯キャリアの基地局（？）内に置かれているAkamaiのキャッシュサーバのアドレスが、上記のアドレスになっていると想定されます。

このDNSですが、調査方法を知っておく事は非常に重要です。
私の経験上、ネットワークがつながらない問題の5割が、DNSが解決出来ない 事です。digコマンドはWindowsにもインストール出来ます。

Routing

無事、IPアドレス（ネットワーク上の住所）が判明した、次はどう通信するのかに話を進めます。

  • データはパケットという単位で分割される
    • ご存知の方も多いかもしれませんが、ネットワーク上の通信は、パケットという単位で区切ってデータを送受信します。例えば動画などの大きなデータも、1パケットあたり（基本は）最大で1500バイトに分割して送られます、
  • 各パケットがそれぞれ、送信先のIPアドレスめがけて送信されます

Routing の仕組み

Routing も仕組み自体は外部にいいサイトがたくさんあるので、そちらを見た方が良いです。これくらいの説明の粒度を合致してそうなサイトは、このサイトあたりです。IPアドレス体系の説明をしていないので、まずはこれくらいの理解で良いです。

動きを見る

基本

それでは、先程名前を解決した、www.future.co.jp = a1807.b.akamai.net = 23.32.3.80 を例にしてみましょう。

Routing の様子を調べるには、Windowsではtracertというコマンドが使えます。(Macではtraceroute)

> tracert 23.32.3.80

a23-32-3-80.deploy.static.akamaitechnologies.com [23.32.3.80] へのルートをトレースしています
経由するホップ数は最大 30 です:

1     3 ms     1 ms     2 ms  192.168.128.1
2    47 ms   211 ms    38 ms  pw126240091001.0.tss.panda-world.ne.jp [126.240.91.1]
3    27 ms    42 ms    37 ms  pw126240091002.0.tss.panda-world.ne.jp [126.240.91.2]
4    45 ms    39 ms    40 ms  pw126240088129.0.tss.panda-world.ne.jp [126.240.88.129]
5    54 ms    28 ms    38 ms  pw126240088085.0.tss.panda-world.ne.jp [126.240.88.85]
6    44 ms    69 ms    47 ms  pw126240088065.0.tss.panda-world.ne.jp [126.240.88.65]
7    76 ms    25 ms    41 ms  pw126240088033.0.tss.panda-world.ne.jp [126.240.88.33]
8    27 ms    36 ms    39 ms  101.110.16.241
9     *        *        *     要求がタイムアウトしました。
10     *        *        *     要求がタイムアウトしました。
11     *        *        *     要求がタイムアウトしました。
12    41 ms    35 ms    37 ms  a23-32-3-80.deploy.static.akamaitechnologies.com [23.32.3.80]

トレースを完了しました。

上から順にNW的に近いルーティングデバイスです。
全部で12ホップである＝クライアント～サーバ間に11個のルーティングデバイス存在する事が明らかになりました。
応答時間が3回分返ってきています。目的地まで平均して40ms程度なので通信状況は良好と言えます。

少しだけ細かく説明します。

  • 1は、会社支給のポケットwifiのアドレス
  • 2～8は、Softbankさん運営のNWです。NW内で（＝AS内で）、何回かルーティングされています。
    • ネットワークの所有者はwhoisというサービス（コマンドもインストール可能）で調べる事が出来ます。
  • 9～11は、Firewall or 装置の設定などの問題で、tracerouteの信号に応答してくれない状態になっています。
  • 12は、www.future.co.jpのトップページのhtmlファイルがキャッシュされているAkamaiのサーバです。

この様に、tracerouteを使用すると、サーバまでのNWの経路と、その応答時間（レイテンシ）を測る事が出来ます。
何かしらの**処理が遅い系のトラブルは、まずtraceroute**を見るのが良いです。
NWの問題か、サーバの問題か、明らかになりますから。

少し応用

今度はcorp.tokyo-calendar.jp = 54.250.204.18を見てみましょう。

> tracert 54.250.204.18

ec2-54-250-204-18.ap-northeast-1.compute.amazonaws.com [54.250.204.18] へのルートをトレースしています
経由するホップ数は最大 30 です:

～～　中略　～～

 22    22 ms    41 ms    33 ms  52.95.31.82
 23    48 ms    28 ms    31 ms  27.0.0.72
 24     *        *        *     要求がタイムアウトしました。
 25     *        *        *     要求がタイムアウトしました。
 26     *        *        *     要求がタイムアウトしました。
 27     *        *        *     要求がタイムアウトしました。
 28     *        *        *     要求がタイムアウトしました。
 29     *        *        *     要求がタイムアウトしました。
 30     *        *        *     要求がタイムアウトしました。

返ってきませんね。これは明らかにターゲットとなる 54.250.204.18 の前にいるFirewall、今回はおそらくAWS の Sercurity Groupでtracertで使用するICMP(Ping)というパケットを許可していないため、途中から探索が出来なくなっています。

逆に言えば、webサイトの閲覧の通信（https）は許可されているわけなので、その通信に成りすまして trace してみましょう。
Windowsではまたもやコマンドがないので、以下はlinuxマシンで試しています。

nishida@Ubuntu:~$ sudo traceroute -T -p 443 54.250.204.18
traceroute to 54.250.204.18 (54.250.204.18), 30 hops max, 60 byte packets
 1  _gateway (192.168.128.1)  3.666 ms  3.563 ms  3.613 ms
 2  pw126240091001.0.tss.panda-world.ne.jp (126.240.91.1)  205.578 ms  205.551 ms  205.487 ms
 3  pw126240091002.0.tss.panda-world.ne.jp (126.240.91.2)  99.263 ms  99.244 ms  99.178 ms

～～　中略　～～

29  * * *
30  ec2-54-250-204-18.ap-northeast-1.compute.amazonaws.com (54.250.204.18)  46.987 ms  37.726 ms  37.653 ms

今度は返ってきました。

途中で中継しているルーティングデバイスはやっぱり返答してくれませんでした。

全部で30ホップ。FutureのトップページよりはNW的には倍以上遠いです（というか、FutureはCDNを使っているから特別近いだけ）。ただ、応答時間は約40msなので良好です。応答時間の大部分を占めるのは、4G回線の部分という事も明らかになっています。

まとめ

説明の関係で誤解を招きそうなのでここで訂正しますが、最初のDNSの通信でもRoutingは使われています。

  • 例えば、自分のPC → 1.1.1.1に対して、DNSパケットを投げた時からすでに。
  • そして、1.1.1.1 → f.root-servers.net(192.5.5.241) へのDNS通信でももちろん。

最初からIPアドレスの世界から入ると、どうしても壁を感じてしまうため、本記事は名前から入ったためこの様な順序になっています。
OSI参照モデルと呼ばれており、各層で役割が分かれています（例えば、Routingは3層、DNSは7層）。次があればこの辺りも説明します。
OSI参照モデルに関しては、こちらの記事で、冗長構成の観点から少しだけ説明しています。

最後に

企業のシステム構成がだんだん明らかになっていくので、まるでハッキングしているみたいで面白いですよね。もちろん全部合法なので、知っているサイトを調べてみてください。特にFutureグループのWebサイトのほとんどがAWS上で作られている事がわかります。

トップページの様にそもそも公開しているサイトであれば別に構わないですが、逆にVPNサーバなど『本当は隠蔽したいけど通信のために公開しなければならないサービス』もありますよね。最近ではこれらのサービスの隠蔽のためにSDPという技術も出始めています。ニーズがあればどこかで書きます。