hiramas’s blog

気になったことをちゃんと調べてみようってブログ

『HTTPプロトコル』とは?

先日はインターネットの大まかな全体像を見てきました。

今回はアプリケーション層に属している『HTTPプロトコル』について解説します。

developer.mozilla.org

 HTTPプロトコルの活躍例

HTTPプロトコルが使われている身近な例は、今皆さんがご覧になっているウェブブラウザがあります。

ウェブブラウザはサーバーにあるソースをクライアントのブラウザが解釈して描画しています。

このクライアントとサーバーの通信の仕組みを規定したものがHTTPプロトコルになります。

HTTPプロトコルの機能

ウェブサイトを表示するときにまず何が必要なのか考えてみましょう。

最もコアな機能

最も重要な機能として、

「ウェブサイトのデータ」

をサーバーからクライアント側へと伝達しなければなりません。

それを実現するためにはクライアント側からサイトのデータをくださいとサーバに要請する必要があります。

つまり、HTTPプロトコルでは、リクエストとレスポンスという2つの通信が最低限必要になります。

HTTPプロトコルであることの明示

クライアントから、「データをください!」とサーバー側に要請するわけですが、サーバー側に届く時にはバイナリという意味不明な文字の羅列になって届きます。

そこで、「データをください!」という要請にHTTPプロトコルでの通信ですよというパターンを枕詞のように置いておきます。

これをリクエストの最初の行に持ってきます。HTTP/1.1の通信では

GET /index.html HTTP/1.1

のように記述します。

HTTPプロトコルにおいて、リクエストの一行目にはMethod:通信の種類(リクエスト?レスポンス?)、Path:リソースのパス、Version of the protocol:プロトコルのバージョンを明記する必要があります。

データを用意するための情報

リクエストを受け取ったサーバーはせっせと要請をもとにデータを用意するわけですが、どういうフォーマットで見るのか、どのブラウザで見れるデータにすればよいのかがわかりません。

そこでリクエストをするときにそれらの情報も記載して送ります。

この「データを用意する際に必要な前情報」をHeaderと呼びます。

通信がうまくいったかどうかの明示

レスポンスでは、サイトのデータだけを送ればいいわけではなく、

通信が失敗した時のために、通信が成功したのか、失敗したのか

失敗したのであればなぜ失敗したのかをクライアントに渡してあげなければなりません。

レスポンスではこれらの情報をHeaderに格納し、それ以降にサイトのデータをくっつけてクライアントに送信しています。

 

 

最近ではHTTP/2の実装が続々と進んできて、通信規格も高速で大容量な通信が可能になってきています。

このあたりのプロトコルの知識があると、サーバーとの通信の全体像が見えやすいのではないでしょうか?

ルールで見る『インターネット』という技術

この間、4年?5年ぶりぐらいに

Socket 通信について振り返る機会があったり、漫画で似た構造を見たのもあって、

最近この辺のレイヤーの処理はほぼほぼブラックボックス化してるなと思い至り、備忘録的な意味も含めてまとめてみました。

本記事では、なんとなーく、インターネットの全容がわかる

OSI参照モデル』について解説します。

 

 『インターネット』のルール

『インターネット』をもうちょっと具体的に言うと、

「複数の要素が相互に情報を伝達しあえる機能」をもったものです。

実は1970年代までは、いろんな会社がそれぞれで思い思いのインターネットを構築していたのですが、

「いや、ややこしくね?」

ということでISO(国際標準化機構)が

「みんなで統一した仕組みを使おう」

と誕生したのが今回紹介する

OSI参照モデルOSI reference model)』

です。

これは『インターネット』に必要な機能を7つのレイヤーに分けて規定しています。

この仕組みを知っていると、『インターネット』とおぼろげだったものが少し、具体的なイメージを持てるようになるはずです。

第1層:物理層

この層では、電機や光などの物理現象を用いて情報を伝達するためのルールが規定されています。

その他にも、ケーブルの端子の形が~とか、ピンの数が~とかの規約もこの第1層に属する規約です。

この層の性能限界を超えるような通信を行うことはできないです。

第2層:データリンク層

この層では、直接接続されているある要素(A)とある要素(B)の間を通信するための決まり事が規定されています。

身近な例としては、無線LANIEEE 802.11などがこの層に属する規格です。

第3層:ネットワーク層

この層は 直接接続されていない要素間において、やり取りを中間させる要素が存在するときの仕組みを提供しています。

第2層までは、AさんとBさんの直接のやり取りだったので情報は直接渡せば完了でした。
第3層ではやり取りを仲介する郵便局的な存在が出てきます。
するとAさんがBさんに情報を送るにはBさんの郵便番号を知らなくてはなりません。
この時使われている郵便を行うための決まりがネットワーク層で規定されているものに当たります。
身近な例だとIPがネットワーク層で規定された仕組みです。

第4層:トランスポート層

さぁようやく折返し地点です。
トランスポート層では、通信の信頼性をいかに確保するorしないかを規定しています。
  
抽象的でわかりづらいですが、
先程の郵便の例で見ると、Aさんが送った郵便がBさんにちゃんと正しく届いているかどうか、半分だけ届いたり、欠けて届いたりしないか?そういったことを規定しています。

 

代表的なもので、TCPと呼ばれる通信の内容が発信時と変わっていないことを担保する通信プロトコルや、UDPと呼ばれるもう送りっぱなしの通信プロトコルがあります。

第5層:セッション層

この層では通信の始め方、終わり方を規定しています。
 
手紙の「〜さんへ」「〜より」みたいなフレーズに役割は似ています。
開始と終了以外にも、中断したときどーするの?など、通信の開始、終了に関する様々な規定はこの層に属します。

第6層:プレゼンテーション層

この層では、ネットワークでは0と1の組み合わせである電気信号が、コンピューターに渡されたとき、C言語で解釈するべきものなのか、それとも別の言語で解釈するものなのか、といった翻訳機としての決まり事を規定しています。

第7層:アプリケーション層

さあようやく最後の層です。この層では実際にコンピューターに解釈された情報をどうFTP通信やHTTP通信など(コンピューターに表示できる状態にするプログラム)が受け取るのかを規定しています。

まとめ

ネットワークの働きの全体像をなんとなーく把握するため、
今回は『OSI参照モデル』を紹介しました。
ルール自体が絶対の決まりというよりは、こういう風に分類したら、わかりやすいよねといった趣向のものなので、抽象的ではありますが、なんとなく全体像が見えたのではないでしょうか?
 
参考
 

『Koala』のオプションについて

Sass、便利ですよね。

構文的に、イケテル、スタイルシート

その名に負けず、圧倒的な速度と利便性を誇っています。

 

今回はその陰でひっそりと頑張ってくれている

コンパイラのKoala君のオプションをひとつづつ解説します。

 

 

Compass Mode

この項目にチェックを入れると、Compassと呼ばれるSassをベースに作られたフレームワークを利用できるようになります。

Compassフレームワークを使う利点としては、

ベンダープレフィックスクロスブラウザなどに最適化された記述を自動的に記入してくれるので、圧倒的に可読性が上がります。

 

Source Map

この項目にチェックを入れると、Source Mapを自動で生成してくれます。

Source Mapは、コンパイルしたコードと元のソースの関係性を記憶してくれているので、Chromeなどでデバッグした時に、

「このスタイルが、Sassでどこにあるのかわからない。。」

といった事態がなくなります。

Line Comments

この項目にチェックを入れると、cssにその項目が元のSassの何行目にあったのか

を逐次教えてくれるコメントを追加します。

Debug Info

この項目にチェックを入れると、@media -sass-debug-infoというタグがセレクタごとに付与され、それがどのscssに由来するものかが一目でわかるようになります。

Unix New Lines

この項目にチェックを入れると、UNIX用の改行コードでコンパイルされます。LFの文字コードで改行が表現されます。

Autoprefix

この項目にチェックを入れると、自動的にベンダープレフィックスが付与されます。

便利!

まとめ

いかがだったでしょうか?

特にSourceMapとAutoprefixはかなり使えるのでお勧めです!

 

 

タイポグラフィーで『視線』を集める。

Webデザインをしていると、

「意味を持ってデザインせよ」とお叱りをよく受けるので

自分への備忘録としても。。

 

皆さんサイトを見るとき、

どんなところについつい目が行っちゃいますか?

今回は「タイポグラフィーで『視線』を集める。」ということで、

タイポグラフィーなんて横文字を使いましたが要は文字で『視線』を集める方法です。

 

大きさで『視線』を集める。

えがおグループさんの採用サイトを例に見てみましょう。

www.241241.jp

 

いきなり、「CHALLENGE」がパワフルに視線を集めます。

もうちょっとスクロールすると、「超える」の文字に視線が行きますね。

これは、「超える」のフォントの大きさ・太さが他の文字の大きさに”比べて”大きいがゆえに視線を集めます。他の文字との差異が大きくかつ、可読性が高い(今回の場合は純粋にデカイ)と情報の優先順位が高くなる傾向にあります。

 

フォントの種類で『視線』を集める。

次はSINCEさんの公式サイトを見てみましょう。

since2018.jp

このサイトでは、見出しは「明朝体」で上品な印象を、

地の文は「ゴシック体」で可読性を高めています。

ファーストビューの印象も相まって、その後の見出しに『視線』を誘導してユーザーの可読性をあげることに成功しています。

 

多くのサイトで見出しに英語が使われているのも同じような効果を狙ってたりします。

 

文字詰めで『視線』を集める

次はRINNさんの公式サイトを見てみましょう。

rinn.co.jp

ファーストビューから少しだけスクロールしてみてください。

MEOW!

思わず、『視線』を誘導される仕掛けです。

動きによるインパクトもさることながら、文字一つ一つの間隔が非常に広く取られていることに注意してください。

実はファーストビューのロゴと見出しの文字詰めも地の文より少し広く取られています。

 

まとめ

タイポグラフィーで『視線』を集める手法を見てきました。

① フォントの大きさや太さで

② フォントの種類で

③ フォントの文字詰めで

①を除いてどれも基本的に1種類で使われることは少ないです。

基本的に他の個所よりもなにかしら異なっている(コントラストが強い)場所に『視線』は誘導される傾向にあります。

そのためWebデザインでは、色、動き、タイポグラフィーなどでコントラストを作っていきます。

しかし、タイポグラフィーでコントラストをつけるときは、乱用するととっ散らかって、かえって可読性の低下という本末転倒な結果を招きやすいので慎重にデザインする必要があります。

 

HTTP:X-SAKURA-FORWARDED-FORってなんだ?

httpからhttpsにリダイレクトさせるこの処理

RewriteEngine On
RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$
RewriteRule ^(.*)$ https://domain/$1 [R=301,L]

は、さくらのレンタルサーバーを利用している人の間ではあまりにも有名なおまじないです。

また同時に、これほど、コピペのまま使わている処理もないでしょう。
このコードを一層分けわからなくさせているのが、2行目の
RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$
です。サーバー変数が空の場合除外するだろうこと以外はほぼ意味不明です。
今回はこの2行目の処理について解説します。
 
ざっくりこの2行目の『機能』としては受け取ったHTTPリクエストの中の

X-Sakura-Forwarded-For
というヘッダーの中身が空でなければ、3行目の対象になるというものです。

 

2行目がある『理由』

では前述した機能がなぜ、さくらサーバーにおいて、httpsのアクセスのフラグになり得るのか?
 
それは、さくらサーバーがリバースプロキシと呼ばれる仕組みを使ってSSL通信を実現しているからです。
 
リバースプロキシとは、簡単に説明すると、
ファイルが置いてあるサーバーとは別に、関所のように別のサーバーを必ず経由させるとき、この関所の働きをするサーバーをリバースプロキシと呼びます。
  さくらサーバーでは暗号通信を担うサーバー(リバースプロキシ)が最初にアクセスを受け、その後、実際にファイルのあるサーバーにアクセスする仕組みを採用しています。
 
ここで特に注意したいのが、.htaccessが読み込まれるタイミングは実ファイルが格納されているサーバーにアクセスがあったときであり、.htaccess的にはリバースプロキシサーバーからの通信となるわけです。
 
感の鋭い人はもうわかったのではないでしょうか?
 
つまり、リバースプロキシサーバーからのHTTP通信のヘッダーに
X-Sakura-Forwarded-For
が記載されているのです。
 
ちなみにこの
X-Sakura-Forwarded-For
は、AddHeaderと呼ばれる機能でサーバー側で別途設定しなければ生成されないヘッダーです。
X-Forwarded-Forと呼ばれるヘッダーの亜種なのですが、役割や、詳しい説明は
下記を参照してください。

2行目の『意味』

つまり、この記載をより意味に即して説明するならば、
このアクセスの途中にSSL通信を担うリバースプロキシを通っていれば、
次の行の処理をする
というコードになります。
 

『.htaccess』とは?

リダイレクトやら、Basic認証を掛けるときによく使う『.htaccess

フロントエンジニアであれば一度は目にしたことがあると思いますが、

いざ、必要となるタイミングで、『.htaccess』がなんなのか?

手持ちのヒントが足りない状態で出会うことが多いと思うんです。

HTMLチックでもなければCSSっぽくもない。PHPJavaScriptとも違う。

そんな『.htaccess』の正体に迫っていきます。

 

 

本記事の対象

.htaccess』わかんない。
の原因は大きく二つあると思います。

1.よく出てくる"^"とかの正規表現がわからない
2.そもそも『.htaccess』ってなに?

本記事で対象とするのは「2.そもそも『.htaccess』ってなに?」って人です。

 正規表現はそれこそもうたくさん…

www.mnet.ne.jp

.htaccess』ってなんなの?

.htaccess』はざっくり、Apacheサーバーの設定を書くところです。

もう少し詳しく書くと、Apacheと呼ばれるHTTPサーバーの機能の一種で、
サーバーの管理者がサーバー全体に行う設定とは別に、
「ここのディレクトリは特別な処理をしたい。」
というときに使われるファイルです。
そのため、「分散設定ファイル」と呼ばれています。

実は『.htaccess』という名前もただデフォルトでそう設定されているだけで、サーバー全体への設定をいじると名前を変更できたりします。

 

よく使う`RewriteCond`とかは何なの?

Apacheサーバーの設定項目の一つです。

設定項目は「ディレクティブ」と呼ばれ、

RewriteCond

RewriteRule

なども、ディレクティブです。

それぞれの詳しい使い方は公式ドキュメントが優秀です。

httpd.apache.org

 

<IfModule hoge>

もディレクティブの一種で、コア機能以外を使うときにそのモジュールがロードされているかの条件分岐を行うディレクティブです。

比較的よく使いますが、普通に使う分には必要ないよねっていうのが公式の見解です。

httpd.apache.org


新世界(西野亮廣)に『本の正体』を見た。

そういえば全文無料公開とか不思議なことをやっている人が
いたなと思い、気が付いたら全文読み終えていました。

僕はテレビを見ないので『お笑い芸人』としてのキングコング西野は
正直、知らないです(ネタも多分見たことない)。
それでも、この本?を読んだ後、
陳腐な表現だけど、ものすごく心に響くものがありました。
その時ふと、『本の正体』について少しだけわかった気がしたのです。

r25.jp

 

『本』ってなんだろう?

『本』とは、思考や体験、情報を言語化し、文字というフィルターを通して紙に転写、それをまとめたもののことをさします。

『本』の機能は、思考や体験、情報を伝達することであり、
特に本の場合はその媒体として文章が使われます。

文章はまず、視覚的な情報として脳に伝達され
そこから言語知識をもちいて理解できる情報へと変換されます。

僕の場合は文章が一度音声に変換され、
音声に紐づけられた映像を参照し情景となり、
疑似体験することで、いくらか損失はあれど「情報が伝達」されます。

つまり『本』は、文章を主たる媒体とした情報伝達装置の一種ということです。

『本』が僕らにしてくれること

一番のキモは、文章という媒体が伝えられうる情報の幅広さです。

記述されている事象を疑似体験できるので、
視覚、聴覚、触覚、味覚、嗅覚。
なんでもござれです。

ただここには一つ、問題点があります。

あくまで「疑似」体験なので、
文章から作成された「仮想現実」の材料は
自身が実際に体験した事柄の組み合わせでしか表現できません。

僕が新世界を読んでいた時に脳内で流れていた西野さんの声は「西野さんの声」ではありません(聞いたことがないから)

それでも、疑似体験の脚本は他者のもの。

そこに大きな学びの場があります。

『本』の正体

本は、一種の仮想現実を構築する装置です。

五感に関係するパーツは自前のものですが、
ストーリーは他者のものであり、そこから得られる教訓・情報は

自分の中には存在しなかったものになります。

そしてその教訓・情報こそ本によって複製されたものです。

すんごい回りくどいコピペみたいな感じです。

『本』の信用構築機能

ここからは、新世界を読まれた方向けです。

新世界を読んだ後、西野亮廣という人物と少しだけ仲良くなった気分になった方も多いはずです。

僕自身、やたらと好感。親近感をもちました。

今も持ってます。

そんな親近感、好感。
いいかえると読者の信用を獲得できたのはなぜなのか?

それは文章が仮想現実を構築する装置だからです。

これは脳の機能をかなり使います。
それはもう他のことができなくなるほどに。。

僕らは新世界を読んでいる間、西野亮廣という人物の話を聞いていました。
それも親身に僕たちの話をしていたのです。
これはいわば西野亮廣さんと二人きりで話していたようなものです。
つまり二人っきりで話す『場』を複製したことになります。

文章(本にかかわらず)が信用構築のツールとしていかに強力であるか?
その可能性を感じずにはいられません。

 

新世界を読んで、西野亮廣さんにやたらと親近感?好感?を持ったのはなんでだろう?
と思い、いろいろ考えていたら『本』というものが少しわかった気になり。
書き留めてみました。
新世界の良さはいろんな人が語っていると思うので、ここでは割愛します。