H2OというWebサーバ

Webサーバの概要と有名どころ

Webサービスを運営する場合に必要になるのがWebサーバです。

Webサーバはブラウザなどクライアントからのリクエストに対して、htmlファイルに代表されるリソースを返すサービスのことを言います。

Webサーバにはいくつかの選択肢があります。 有名どころでは、インターネット系のWebサーバだと古くはapacheがデファクトスタンダードとなっていた時代もありましたが、ここ5年くらいはnginxも良く聞かれるようになってきました。 また、イントラネットなとWindows Serverが使われるケースではMicrosoftのIISが以前として相当程度のシェアを維持しているように感じます。

そんなWebサーバの市場にあって、私の中で最近マイブームになっているH2OというWebサーバについて、簡単にご紹介したいと思います。

H2OとはどんなWebサーバ?

元々はDeNA社内で奥さん(Kazuho Oku)という方が中心となって開発した、HTTP/2をデフォルトとする軽量高速なWebサーバです。

Nginxも「apacheよりも遥かに高速」が謳い文句だった時期もあったと記憶していますが、H2Oはその「Nginxよりも遥かに高速」だそうです。

ライセンス形態はMITライセンスです。

SCDB JAPANではNginxとH2O両方のWebサーバを使って負荷分散していますが、リソースを並列で転送できるHTTP/2でアクセスしたときの方が、ブラウザから見た体感としては早いように感じます。 時間が出来たときに詳しいベンチマークを取ってみたいと思います。

元々は2台目のWebサーバを立てようとしたときに、NginxでHTTP/2を採用しようとして色々調べていたときに見つけたのですが、いざ使ってみると導入も簡単ですし、mrubyというrubyライクなスクリプト言語で柔軟に設定を記述できます。 また、作った人が日本人という点も10年ほど前にrubyに出会った時のような感覚を思い出し、すっかり気に入ってしまいました。

作った人のご紹介

開発者の奥さんは、IPA(情報処理推進機構)が経済産業省の補助を受けて行なっている「未踏ソフトウェア創造事業」によって「天才プログラマー/スーパークリエータ」として認定された過去を持つスゴイ方です。

ネット上の情報によると、今年からDeNAを退社され、次世代CDNサービスを開発している米Fastlyに転職されたようです。 H2O の世界最大の利用者であり、世界有数の規模の HTTP トラフィックを捌く事業者であり、HTTP を高度に運用することを事業のコアとしている Fastlyで、これからもH2Oの開発をリードしつつ、Fastlyで得た果実をオープンソースに還元する取り組みを続けられるとのこと。 勝手・陰ながら、今後益々のご活躍をお祈り致します。

To be continued...

ほんとはサクッとH2Oサーバのインストール方法を書きたかったのですが、前置きが少々長くなりましたので、筆を改めたいと思います。

<解決済み>直接叩くと実行できるシェルスクリプトをcronで実行するとエラーになる件

今回はCentOSで遭遇した事象についての原因と調査内容の共有です。
11/17時点でまだ解決していません。
今後も調査を続け続報をアップする予定ですが、お気付きのことがありましたらアドバイス頂けると助かります。

11/19解決しました!!

何が起きている?

シェルにログインして直接起動すると問題なく動くシェルスクリプトがあるのですが、
これを定期実行しようとcronに登録したところ、エラーが出て動かないという事象に遭遇しました。


問題が発生している環境

# vi /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

これまで調べたこと

1. cronが起動しているかの確認

# systemctl status crond.service

● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since 日 2017-10-01 08:38:55 JST; 1 months 17 days ago

動いてます。

2. スクリプトのパーミッションの確認

# ls -al /usr/local/bin/hoge.sh

-rwxr-xr-x 1 root root 334 11月 17 21:31 /usr/local/bin/hoge.sh

パーミッションが755ですので誰でも実行可能なはずです。


3. エラーになったコマンドのログの確認

以下、ログファイルの内容

2017/11/17 19:00:00 process started.
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- iconv (LoadError)

(以下、省略)

iconvが見つからないようです。

 

4. iconvの確認

# which iconv
/usr/bin/iconv

/usr/binの下にあります。

 

5. PATHの確認

※cronの実行ユーザで確認しています。

echo $PATH
/user-name/.rbenv/shims:/user-name/.rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/user-name/bin

/usr/binにもパスが通っています。

 

6. cron実行時のPATHの確認

cronに1分ごとにPATHを書き出すコマンドを設定して待機します。

# crontab -e
*/1 * * * * /bin/bash -l -c 'echo $PATH >> /tmp/path.txt'

 

1分後、cronが動いてファイルが作成されたので中身を確認します。

/user-name/.rbenv/shims:/user-name/.rbenv/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin:/user-name/bin

 

並べてみましょう。
上が対話型ログイン状態でのPATH、下がcron時のPATHです。

 

/user-name/.rbenv/shims:/user-name/.rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/user-name/bin
/user-name/.rbenv/shims:/user-name/.rbenv/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin:/user-name/bin

 

違いが2点ありました。
1つ目は、対話型の時には「/usr/local/bin」にパスが通っていますが、cron時には通っていません。
2つ目は、対話型の時には「/bin」にパスが通っていませんが、cron時には通っています。

今回はcronで動かないことが問題なので1つ目の方が怪しいです。
1.でも書いたように、今回起動したいスクリプトは「/usr/local/bin」の下にあります。
やはりhoge.shが実行できていないのでは?との錯覚に陥りましたが、
3.に書いたログの1行目「2017/10/04 04:03:01 process started.」はhoge.shの中で出力するように記述しているものですので、hoge.shは確実に起動しています。

もしかすると、hoge.shから呼んでいる処理の中で何らか「/usr/local/bin」の下のプログラムをパスなしで使おうとしているものがあるのかも知れません。
一縷の望みを託してhoge.shの頭に次の1行を追加してみます。

export PATH=$PATH:/usr/local/bin

 

7. cronの再実行を待つ

2017/11/17 22:03:01 process started.
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- iconv (LoadError)

ダメでした。。。

 

----- 11/19追記 -----

8. rubyを疑う

今回動かしたいスクリプトはシェルからrubyのプログラムを読んでおり、そのプログラムの中でiconvを見つけられないようなのですが、rubyにちょっと事情があったことに気が付きました。

対象サーバにはrbenvが入っており、2.4.1がデフォルトになっているのですが、今回呼び出しているスクリプトは、1.8.7じゃないと動かない仕様のため、シェルからスクリプトを呼び出すときにバージョンを指定して実行しています。

実際には以下の呼び出し方をしていました。

RBENV_VERSION=1.8.7-p375 /path-to-program/program.rb

 

ネット上で色々調べてみると、以下のように1.8.7のrubyプログラムを直接起動するやり方があるようなので、これを試してみることにします。

/user-name/.rbenv/versions/1.8.7-p375/bin/ruby /path-to-program/program.rb

 

結果は、、

動きました!!!

 

以下、ログファイルの中身

2017/11/19 04:00:00 process started.

2017/11/19 04:15:32 process finished.

 

改めて考えると、バージョンを指定してrubyを起動するのに環境変数を書き換えるのはちょっと乱暴すぎる気がします。

なんで今までこのやり方を良しと思ったのかは自分でも謎ですが、修正後のように、プログラムに引く数を渡して実行する方が常識的な感じがしますね(後だしならなんとでも言える)。

 

とにかく、動いて良かったです。以上解決!!!

 

9. あとがき

プログラムが動いたことで課題は解決したのですが、その後調べていた中で1点疑問が残りました。

どうやら今回のエラーは、rubyのバージョンの指定方法が拙かった以前に、cronの中でrbenvを認識できていないことが根底にあるようでした。

対話ログインした状態では、

 

# which rbenv
/user-name/.rbenv/bin/rbenv

とパスが返ってきますが、

cronで呼び出すシェルスクリプトの中にwhich rbenvを仕掛けて実行すると、

/usr/local/bin/hoge.sh: 行 6: rbenv: コマンドが見つかりません

となり、そもそものrbenvにパスが取っていないことが分かりました。

rbenvがある「/user-name/.rbenv/bin」にはcron時にもパスが通っていることは確認できているので、まだ何か問題が残っているようですが、当初の課題は解決したのでこれ以上の調査はペンディングにします。

独自ドメインで運営するはてなブログのサイトマップをGoogle Search Consoleに登録する方法

サイトマップのURL確認

サイトマップをSearch Consoleに登録するには、まずサイトマップの置いてあるURLを確認しましょう。

今回は独自ドメインで運営していることを前提にしていますので、サイトマップのURLは次のようになります。

http://blog.boost-up.net/sitemap.xml

http://blog.boost-up.net/sitemap_index.xml

 

前回の記事

でもご紹介しましたが、はてなブログのサイトマップは実際は「XMLサイトマップインデックスファイル」になります。

実際に上のURLにアクセスして中身を確認すると、次のようになっていますが、最上位のタグが<sitemapindex>となっており、サイトマップインデックスファイルであることを示しています。

ちなみに、<loc>タグの中にあるURLがサイトマップファイルになります。
(sitemap.xmlファイルの内容を掲載しますが、sitemap_index.xmlファイルもまったく同じものです)

f:id:boost-up:20171116233904p:plain

 

と、一応説明はしてみたものの、サイトマップでもサイトマップインデックスでもGoogle Search Consoleへの登録手順は全く一緒ですのでご安心ください。

サイトマップインデックスファイルがあるときはサイトマップインデックスファイルの方を登録します。

 

Google Search Consoleへの登録方法

まずはGoogle Search Consoleにログインして、サイトマップを登録しようとしているWebサイトのプロパティを表示してください。

続いて、画面左のメニューから[クロール]->[サイトマップ]をクリックしてください。

 

f:id:boost-up:20171116234607p:plain

 

「サイトマップ」をクリックすると、右側の領域が切り替わりますので、その右上にある「サイトマップの追加/テスト」を押してください。

すると、ポップアップでURL入力画面が表示されますので、先に確認しておいたURLになるようにドメイン以下を入力してください。

はてなブログの場合、サイトマップのファイル名は決まっていますので、迷わず「sitemap.xml」でOKです。

f:id:boost-up:20171116234802p:plain

入力したら「送信」ボタンを押してください。

スペルミスがなければ、画面が更新されて以下のように「アイテムを送信しました。」というメッセージが表示されるはずです。

f:id:boost-up:20171116235000p:plain

「ページを更新する。」ボタンをクリックするか、画面を再読み込みすると、先ほど送信したサイトマップが表示されていることが確認できます。

f:id:boost-up:20171116235030p:plain

「処理日」の欄が「保留」となっていますが、サイトマップは送信から処理までは少し時間がかかりますので、この時点では気にしなくて大丈夫です。

数日経っても「保留」状態が続くようならURLを確認したうえで、もう一度送信してみてください。

 

サイトマップ送信後にすべきこと

サイトマップはあくまでもウェブサイトに既に存在しているページをGoogleなどサーチエンジンに効率よく伝えるための手段でしかありません。

当たり前ですが良質なページ(コンテンツ)がなければいくらサイトマップを送信してもアクセスは期待できません。

特に、はてなブログのような外部サービスで運営しているブログの場合、サイトマップの生成についてユーザができることは殆ど皆無です。サイトマップを送信したら、ページ(コンテンツ)の作成に集中しましょう!!

 

他方で、ブログを自営で運営されている場合、WordpressなどのCMSでは基本的に自動で更新してくれるのですが、例えばサイトマップファイルの権限設定(パーミッション)が誤っている場合など、ファイルがあっても外部からアクセスできなくなっていることがあります。

たまにはSearch Consoleにログインして、サイトマップの処理にエラーが発生していないかを確認しましょう。

サイトマップという存在

サイトマップとは

サイトマップはあるウェブサイトに存在するページの一覧情報を持つ辞書のようなものです。

単に「サイトマップ」というときには、HTMLサイトマップを指す場合とXMLサイトマップを指す場合がありますので注意してください。

HTMLサイトマップ

HTMLサイトマップは、そのウェブサイトの構造や主なページへのリンクが並んでいるウェブページのことを言います。

主に人間を対象としたサイトマップで、HTMLで記述されているのでHTMLサイトマップと呼ばれます。

<サンプル>

以下はAll AboutさんのHTMLサイトマップです。

f:id:boost-up:20171115220622p:plain

 

ひと昔前のウェブサイトは必ずと言って良いほどHTMLサイトマップページを持っていましたが、最近はあまり流行らなくなったのか、目にすることがだいぶ減ったように思います。

数十程度のページなら良いのですが、数万ページを持つような大規模サイトですべてのページをHTMLサイトマップに並べるとユーザにとって迷惑この上ないページになります。

XMLサイトマップ

HTMLサイトマップと同様、そのウェブサイトの構造や主なページへのリンクが並びますが、いわゆるウェブページではなく、XML形式のファイルで提供されます。

XMLは本来、作成者が自由にタグ付けし、データに意味を付加するマークアップ言語なのですが、XMLサイトマップはsitemaps.orgにより標準化されており、そのルールに沿って記述する必要があります。

XMLサイトマップは通常人間が目にすることはなく、主にクローラーがそのサイトの全容を把握するためにダウンロードし、XMLサイトマップに記載されているURLにクローラーを呼び込むための入り口として用いられます。

<サンプル>

HTMLサイトマップと比較できるよう、同じAll AboutさんのXMLサイトマップ(後述するインデックスファイルでした)を紹介します。

f:id:boost-up:20171115220733p:plain

立ち上げたばかりのブログにどんなページがあるのかを一刻も早くクローラーに伝え、また、新しく記事を書いたときにもその存在をクローラーに伝えるためにも、XMLサイトマップは非常に重要です。

一般的なブログサービスであれば、XMLサイトマップは基本機能として用意されており、自動で最新化されるのが通常ですので、ブログを始めたときは必ずXMLサイトマップのURLを確認しておきましょう。

Wordpressなどでブログを自営されている場合も、一般的なCMS(コンテンツマネジメントシステム)であればXMLサイトマップを作る機能が用意されていますので、必ず設定するようにしましょう。

 

 

XMLサイトマップの制約

XMLサイトマップの細かい規約は各論となりますので割愛しますが、1つのサイトマップに含めることができるURLの数は50,000件以下であること、サイトマップファイルは非圧縮状態で50MB以下であること、という制約だけは覚えておいて良いかもしれません。

ウェブサイトの中にページが50,000ページ以上ある場合は、各XMLサイトマップを1つのURLとして定義した「XMLサイトマップインデックス」というものを使います。

XMLサイトマップインデックスファイルには50,000件までのXMLサイトマップのURLを含むことができますので、一切のロスなく各々50,000件のURLを含むXMLサイトマップを50,000個用意してXMLサイトマップインデックスを作成すると、理論上は50,000×50,000で最大25億ページまで対応することが可能です。

個人でブログを運営するくらいであれば、50,000件の制約が問題となることは皆無と思われますが、ウェブサービスを運営する場合には問題となることがあります。

私が運営するSCDB JAPANというサイトは、日本中の全法人に対してページを持っている関係から、法人ページだけで約4,500,000万ページあります。

また別の機会にご紹介したいと思いますが、25億からするとわずか0.2%程でしかない450万ページのXMLサイトマップ(インデックス)を日々更新するのは意外と大変で、色々探し回った結果、今は手作りのプログラムで日次更新しています。

 

サブドメインで運営するはてなブログをGoogle Search Consoleに登録する

Google Search Consoleとは

Googleが運営するサイト管理ツールで、検索トラフィックの状況を表示したり、クローラーの巡回状況や被リンクの状況を確認することなどができます。

他にもWebサイトの改善に関するアドバイスなど色々な機能を持っていますが、その中でも特に、サイトマップ登録機能とFetch as Googleは、立ち上げ間もない名もないウェブサイト(ページ)の存在をGoogleに伝える上で非常に重要な役割を果たしてくれる機能です。

Google Search Consoleはサイトの管理者であることを証明できれば無料で利用できますので、独自ドメインのウェブサイトを運営する場合は必ず登録しておきましょう。

 

Google Search Consoleの登録方法

ブラウザを起動し、 Google Search Console にアクセスします。

画面右上の「プロパティを追加」ボタンを押します。

f:id:boost-up:20171115205724p:plain

 

ポップアップ画面が表示されますので、登録したいドメインまたはサブドメインのトップページのURLを入力し、「追加」ボタンを押します。

f:id:boost-up:20171115210014p:plain

 

 

続いて、サイトの所有権を確認する画面が表示されます。

サブドメインで登録したい場合で、ドメイン自体の認証が済んでいない場合は、「別の方法」タブを押して上から2つ目の「HTMLタグ」をクリックします。

すると、以下のようにメタタグの情報が表示されます。

メタタグというのはウェブサイトのヘッダー情報に持つ属性情報のことで、ウェブサイト本体の情報と異なり、外部から容易に書き換えることができないものです。

通常、ヘッダー情報を変更できるのはウェブサイトの管理者であることから、Google Search Consoleでもヘッダー情報にGoogleが指定する文字列を持つメタタグが含まれているかどうかで、そのウェブサイトの管理者であるかどうかを判断しています。

 

f:id:boost-up:20171115210352p:plain

 

はてなブログでは、ブログ運営者がメタタグを直接設定するのではなく、指定された文字列を登録するための画面が存在しますので、上記のメタタグをメモ帳などにコピーして、contentで始まる部分の文字列(以下の赤枠部分。ダブルクオーテーションも不要です。)だけをコピーします。

f:id:boost-up:20171115210931p:plain

 

次に、はてなブログの設定画面を開きます。

画面中ほどの「解析ツール」のブロックまで移動すると、「Google Search Console(旧Googleウェブマスターツール)」という項目がありますので、その下のテキストボックスに先ほどコピーした文字列を貼り付けて、画面最下部にある「変更する」ボタンを押します。

これではてなブログ側の設定は完了です。

 

最後に、ドメイン(サブドメイン)に指定のメタタグがセットされたことをGoogleに伝える必要があります。

もう一度Google Seach Consoleを開きます。

改めて、先ほど表示したサイトの所有者を確認する画面に移動し、そのまま画面最下部にある「確認」を押します。

f:id:boost-up:20171115211616p:plain

 

無事にGoogleがメタタグを認識すると、以下のような画面が表示されます。

f:id:boost-up:20171115211656p:plain以上で、Google Search Consoleへのサブドメインの登録が完了しました。

Google Search Consoleのトップ画面に戻ると、登録したサブドメインが表示されています。

f:id:boost-up:20171115211831p:plain

 

次回はサイトマップの登録方法を紹介します。

ウェブページがブラウザに表示されるまでの流れを本気で整理してみた

生まれながらにしてインターネットがある世界で育ったデジタルネイティブもそろそろ成人を迎え、
誰もがパソコンやスマートフォンを扱い、インターネットの中で自由に情報を受け取り、発信できることが当たり前の時代になりました。

今日は改めて、ウェブブラウザがウェブページをブラウザに表示するまでの流れを整理してみます。

ウェブページの表示に関係する登場人物

ウェブブラウザがウェブページにアクセスし、その情報が画面に表示されるまでには、通常以下のような登場人物が関係してきます。

  • ウェブブラウザ
    ウェブページを呼び出し、ページを組み立てるソフトウェアで、クライアントとも呼ばれます。
  • DNSサーバ(DNSキャッシュサーバ)
    URLとIPアドレスを紐づける役割を果たします。
  • ウェブサーバ
    ウェブブラウザがリクエストしたURLから特定されるファイルをウェブブラウザに送るソフトウェアです。
  • アプリケーションサーバ
    ウェブブラウザがリクエストしたURLから特定されるファイルを生成し、ウェブサーバに渡すソフトウェアです。
  • データベースサーバ
    アプリケーションサーバと通信してデータを提供したり、受け取ったデータを保存したりするソフトウェアです。


以上をその関係と合わせて図示すると次のようになります。

f:id:boost-up:20171115001108p:plain


これから①~⑨について、それぞれ見ていきますが、
その前に、今回は以下のURLを具体例として見ていきたいと思います。

https://www.yahoo.co.jp

(詳しい方々へ、今回はCDNは存在しないものとしますのでご了承ください。)

また、説明に入る前にURLの構成についても整理したいと思います。

 

 

URLの構成要素

URLはUniform Resource Locatorの略称で、要求するリソースを一意に特定するための住所であり、次の要素から構成されます。

[プロトコル]://[ホスト部](:[プロトコル])(/[ファイルパス])

※丸括弧の箇所は自明の場合は省略されます。

今回の具体例では次のようになっています。

f:id:boost-up:20171115001250p:plain

仮に今回の具体例を省略せずに記載すると次のようになります。

試しにブラウザに入力してみると、上の省略形のURLにリダイレクトされて同じページが表示されるはずです。

※リダイレクトの理屈は本題から外れますので今回は割愛します。

f:id:boost-up:20171115001338p:plain

少し解説します。

プロトコル

システムの世界で「通信手順を定めた約束事」のようなもので、これからHTTPSというルールで通信を開始することを宣言しています。
プロトコルの末尾がSになっているものは大抵暗号化プロトコルであることを意味し、HTTPSの場合はHTTPを暗号化したものであることを意味します。

ホスト名

ウェブサーバ(ホスト)を特定する名前です。
インターネットの世界ではIP(Internet Protocol)と呼ばれる32bit(IPv4)または128bit(IPv6)の識別子でサーバを特定しますが、このような識別子を人間が直接使いこなすことは困難であることから、一般的にはそれらと紐づけて人間が理解しやすいようにしたホスト名が用いられます。

そして、ホスト名とIPアドレスの関係はDNSサーバ(またはその情報をキャッシュしたDNSキャッシュサーバ)が保持しており、ホスト名からIPアドレスを取得することを「名前解決」と呼びます。

たまに、企業内のシステムなどでIPアドレスで運用されているシステムを見かけることがあります。
仮想ホスト形式で1つのウェブサーバが複数のウェブサイトをホストしている場合は例外がありますが、基本的にはIPアドレスが分かればウェブサイトは表示可能ですし、直接IPアドレスを指定してアクセスする方が、①②の手順を省略する分、理論上は高速です。

ポート番号

ウェブサーバでは、ウェブサービス以外にも様々な内部サービス、外部サービスが起動しています。

TCP/IPネットワークの下では他のホストにアクセスする際にはIPアドレスの他にポート番号を指定することで、何のサービスを要求しているのかを明確にします。

IPアドレスが外線番号だとすると、ポート番号は内線番号のようなものです。

どのサービスをどのポート番号で起動するかはウェブサーバ側で自由に決めることができるのですが、システムの世界にはウェルノウンポートと呼ばれる「良く知られたポート番号」があり、「普通このサービスはこのポート番号で起動する」というのが決まっています。

HTTPやHTTPSは正にその代表例であり、HTTPは80、HTTPSは443と決められています。

そのため、プロトコルにHTTPSを指定した場合で、ポート番号を明示しなかった場合は、443が指定されたものとサーバ側で判断して処理を行います。

インターネットで一般公開されるウェブサーバを前提とすると、ウェルノウンポート以外のポートでサービスを稼働させた場合、一般的なクライアントは稼働ポートを知り得ないため、アクセスすることが困難となります。

そのためクライアントであるウェブブラウザの立場から見ると、ごく一部の例外的なケースを除き、通常ポート番号は省略されます。

ファイルパス

ウェブサーバ上にホストされているファイルを特定するためのファイルパスとなります。

このファイルパスはウェブサーバの「ルートドキュメント」と呼ばれるディレクトリ(フォルダ)を起点とした相対パスで表され、サブディレクトリ内にあるファイルを要求する場合はスラッシュで区切って指定します。

パラメータ

今回は詳しい説明を省略しますが、ファイルパスの後ろに”?”を挟んで引数を渡すことができます。

ウェブサーバは引数を受け取った場合、アプリケーションサーバに対してファイルと合わせて引数を要求条件として引き渡します。

 

だいぶ長くなりました。。

さて、ここから漸く①~⑨のお話です。

先ほどと同じ図になりますが、もう一度掲載しておきます。

f:id:boost-up:20171115001108p:plain

ウェブブラウザがウェブページを表示するための流れ

①ホスト名の名前解決依頼

ブラウザがホスト名に対応するIPアドレスの情報を持っていない場合、DNSサーバに対してホスト名の名前解決を依頼します。

ブラウザが名前解決を要求するDNSサーバは通常、端末の設定やネットワークのプロキシ設定により定義されています。

また、例えばWindowsパソコンにはhostsファイルというファイルがあり、任意のホスト名とIPアドレスを対応させるための設定を定義することが出来ます。

余談となりますが、hostsファイルやDNSサーバのレコードが意図せず書き換えられた場合、名前解決の結果として偽のIPアドレスが回答されることになります。このような不正行為はDNSスプーフィングと呼ばれます。

②該当するサーバのIPアドレスを回答

ウェブブラウザから名前解決依頼を受けたDNSサーバは管理している情報を検索し、該当するIPアドレスがあればそれを回答します。該当するホスト名が管理DBに存在しない場合、DNSサーバは更に上位のDNSサーバに照会し、該当するIPアドレスが得られた場合にはそのIPアドレスを回答します。

③ファイルの要求

ここまでで問い合わせ先のホスト名が特定できたので、次にウェブブラウザはウェブサーバに対してファイルの要求を行います。

④ファイルの作成要求

今日のウェブサーバは静的なHTMLファイルだけをホストしていることは稀であり、多くの場合は何らかのアプリケーションサーバと連動して動的なページを生成しています。

ウェブサーバはウェブブラウザから要求されたファイルがが、自身が直接管理している静的ファイルである場合には、そのファイルを直接返しますが、それ以外の場合はウェブブラウザから要求されたファイルパスを条件にアプリケーションサーバにファイルの作成を要求します。

⑤ファイルに含めるデータの要求

ウェブサーバから要求を受け取ったアプリケーションサーバはプログラムに基づいてファイルの生成処理を行いますが、多くのケースではアプリケーションサーバのプログラムはファイルのひな型を作成する役割を担い、そこに充て込むデータはデータベースサーバで管理されています。

そのため、プログラムの中で適宜データベースサーバと通信を行い、データを要求する処理が行われます。

この要求はデータベースサーバがRDBMSの場合はSQLという言語によって行われます。

⑥データの提供

データの要求を受け取ったデータベースサーバは、要求された条件に従ってデータベース内を検索し、検索結果をアプリケーションサーバに回答します。

⑦ファイルの提供

データベースサーバからデータの提供を受けたアプリケーションサーバはプログラム処理を継続してファイルを完成させ、そのファイルをウェブサーバに回答します。

ここでの回答は一般的には実ファイルを伴わないソケット通信などの形で行われます。

⑧ファイルの提供

アプリケーションサーバからファイルを受け取ったウェブサーバは実ファイルを生成し、ウェブブラウザに回答します。

⑨画面の描写

実はウェブブラウザで行われる最後のこの処理が重要なのですが、これまでの手順を通じて受け取ったファイルはHTMLファイルであり、テキストファイルとして開くとわかるように、画面そのものではありません。

実はウェブページはHTMLファイルという設計図をウェブブラウザが描写(レンダリングとも言います)して初めて人間が視覚的に理解できるものになります。

そしてこの描写の仕方にはウェブブラウザによって若干の方言があるため、「Chromeではちゃんと見えるのにEdgeだとレイアウトが崩れる」といったような現象が起こるのです。

また、ウェブページを描写するためにはHTMLファイルだけでなく画像ファイルやスタイルシート、javascriptファイルなど様々なファイルが必要であり、①~⑨の手続きは実は何度も繰り返されます。

具体的には1回目にHTMLファイルを受け取った後、ウェブブラウザはそのHTMLファイルを上から解釈していきます。そして解釈の途中で他のファイル(例えば画像ファイル)が必要なことが書かれていた場合は、解釈を中断してそのファイルを取得するため、再度①~⑨の手続きを行います。この作業を延々と繰り返し、必要なファイルをすべて取得し、その結果を描写しきってようやく処理の完了となります。

※実際には各々でキャッシュという概念があるため、すべての手順が繰り返されるわけではありません。また、HTML/1.1の次の規格として普及が始まっているHTTP/2ではウェブブラウザが要求する前にサーバからファイルをプッシュする機能が実装されているなど、この手順は今後変化していく可能性があります。

 

以上、とても長くなりましたが、若干枝葉の議論は残るものの、
自分なりに一定の整理が付いたので良しとします。

はてなブログの開設とはてなブログProへのアップグレード方法

はてなブログの開設

はてなブログを開設するにあたり、どうせなら独自ドメインで始めたいと思い、「はてなブログPro」を使うことにしました。
最初に「ブログ開設(無料)」からはてなIDを登録し、はてなブログにログインします。
続いて、画面右上のはてなIDをクリックし、展開表示されるメニューの中から「Proにアップグレード」を押すと、
アップグレードの手続きを行う画面が表示されます。

はてなブログProには1ヵ月コース、1年コース、2年コースの3つのプランがあります。
使える機能はどれも一緒で、契約期間が長いほど割引率が上がります。
私は今回1年コースで申し込みをしました。

f:id:boost-up:20171114220817p:plain


独自ドメインの取得

独自ドメインを使うためにはまずドメインを取得する必要があります。
ドメイン販売業者も色々ありますが、私は昔からお名前.comにお世話になっているので、今回もあまり悩まずにお名前.comで取得しました。

【意外と知らないIT用語】ドメインって何? お名前.com

 

ドメイン販売業者によって多少価格やサービスが異なったり
レンタルサーバなどの周辺サービスを扱っていたり厳密に比較するとそれなりに差はあるのですが、
個人で数個程度のドメインを管理する分には、コスト的にはブログサービスやサーバレンタルのコストに比べると相対的に少額ですし、
ドメイン販売業者によって品質が大きく異なるものでもないので、個人的にはあまり気にするところではないように思います。

今回はお名前.comで「boost-up.net」を取得しました。
「押し上げる、力をつける、強くする、高める、レベルアップする」といった言葉の持つ意味に肖り、
インターネット(net)の世界で自分自身これからより一層boost-upすべく、
ちょうど空いていた(ここが最重要ポイント!)ドメインを選びました。

 


(今回は)サブドメインの設定

さて、ドメインとサブドメインの違いについては別に記事を書きたいと思いますが、
いずれこのドメインでブログ以外のサービスを立ち上げることも考え、
今回はサブドメインで運営することにします。

今回はサブドメインとしてblog.boost-up.netを登録しました。
こちらもいずれ別記事を書きたいと思いますが、設定はドメインを管理するDNSサーバ(今回ならお名前.comの管理画面)のCNAMEレコードの設定として行います。
以下はお名前.comのDNS設定画面ですが、はてなブログで運営する場合はVALUEには「hatenablog.com」と入力します。

f:id:boost-up:20171114231118p:plain

 

サービスによっては「hatenablog.com.」と末尾にドットが必要になることもあります。
TTLの説明は割愛します。1秒でも早くサブドメインを有効にしたい人以外はデフォルトのままで大丈夫です。
多少TTLを知っている方のために補足しますと、TTLを小さくしても伝播が極端に早くなることはありません。

この設定を済ませるまではblog.boost-up.netというサブドメインは世の中に存在しないため、はてなブログ側の設定を行うことができません。
ここまでの設定ははてなブログで独自ドメインの設定を行う前に済ませておいてください。

 

はてなブログの管理画面から独自ドメインを設定

さて、いよいよ独自ドメインの設定を行います、と言いたいところですが、
ドメインは世界中に散らばっている権威DNSサーバやDNSキャッシュサーバに設定値が伝播するまで時間が必要であり、
この伝播が完了するまでは名前解決ができない可能性がある状態です。
名前解決ができないとblog-boost-up.netがはてなブログのサーバで運営されていることを特定できず、
ブラウザがページを表示できないことになります。

というわけで、ドメインまたはサブドメインを取得してからはてなブログの設定を行うまでは、
できれば数時間から一晩(一般的にはDNSの設定情報の伝播が完了するまでには最大72時間が必要と言われています)置くことをお勧めします。


独自ドメインの設定は、はてなブログの管理画面メニューから「設定」を選択し、「詳細設定」のタブで行います。
上から2つ目のブロックに「独自ドメイン」の欄があるので、DNS設定済みの「blog.boost-up.net」を入力し、「ドメイン設定をチェック」を押します。
以下の画面はチェックが正常に終わっていることを示していますが、DNSの伝播が完了するまでは、あるタイミングではOKでも別のタイミングによってエラーとなることがあります。
これは、名前解決に使うDNSキャッシュサーバが毎回同一ではないことによるものです。時間が経てば安定してきますので安心してください。
独自ドメインを入力後、画面の最下部にスクロールし、「変更する」ボタンを押下すると設定が完了します。

試しにブラウザのアドレスバーに先ほど設定した「blog.boost-up.net」を入力してみましょう。

f:id:boost-up:20171114225353p:plain

 

f:id:boost-up:20171114225415p:plain

 

無事にブログページが表示されれば作業完了です。
うまくページが表示されない場合はまだDNSの伝播が完了していない可能性があります。
しばらく時間を置いてから再度試してみてください。