今週の月曜日にお話を伺った現役エンジニア方とお話をした際にこんな質問をされた。

「インターネットが何か説明できる？」

なんとなく、わかるような気はするけど、それはあくまで体感的なもので、きちんと理解していなかった。
他にも、「WEBページとWEBアプリケーションの違いは？」、「フレームワークって何」、「GETとPOSTの違いは？」など、わかった気でいて説明できないことが多い。

曰く、私のようにRuby on Railsのような強力なフレームワークをもつ言語からプログラミングに触れてしまうと、WEBの基礎知識が欠落し、フレームワーク依存になってしまうという。
フレームワークを使うことでまず作ってみるというハードルが下がるのは確かではあるが、その分基礎がおざなりになりやすく、仕組みを知らないまま何となく動かすようになってしまうという。

確かに、フレームワークがあればなんとなくポートフォリオは形にできるかもしれないし、WEBアプリを動かせている気になることはできるが、その実仕組みがわかっていなければ、そのアプリにエラーが生じた場合にどのように対処すればいいかなどわかるべくもない。

そういうわけで、良書と紹介されている「プロになるためのWeb技術入門なぜ、あなたはWebシステムを開発できないのか」を早速購入し、読んでみることにした。

この本、読めばわかるが非常にわかりやすい。
Webやプログラミングの知識がなくてもわかりやすいように平易な言葉で書かれている。
本稿では、この書籍で紹介されている各Webにまつわる技術の具体的な意味について、用語集のような形で備忘録をまとめたいと思う。
本編の章ごとに、３章までをまとめる。

1 「Webアプリケーション」とは何か

デスクトップアプリケーション
- 主な処理が手元のPC上で行われる
- 画面はOSの機能を利用して表示されている。
- アプリケーションをPCにインストールする必要がある。
Webサイト
- 公開されたコンテンツを受動的に閲覧するだけのもの。
Webアプリケーション
- デスクトップアプリケーションで実現されていたことをインターネットを通じて利用できるようにしたもの。
- 主な処理はサーバ上で行われている。
- 画像はHTMLで表現されWebbブラウザ上に表示されている。
- アプリケーションのインストールは不要

２ Webとはどのように発展したか

インターネット
- 世界中のコンピュータを相互に接続し、通信できるようにしたネットワーク網
World-Wide Web
- ネットワーク上のHTMLで記述された文書間をハイパーリンクで繋げたもの。
クライアント・サーバモデル
- WWWによるハイパーテキストの公開と閲覧を行うための形態。
- クライアントとなるPCからのサーバに対する「リクエスト」という要求と、サーバからクライアントに対する「レスポンス」という回答のやりとりでコンテンツのやり取りを行うモデル。
- サーバを使うことでコンテンツを一箇所にまとめて管理できる一方、クライアント側は自由にコンテンツを閲覧できる。
URL
- インターネット上のコンテンツを一意に指定するための仕組み
- 先頭からスキーム、ホスト名、パス名の３部位からなる。
- スキーム
  - リソースを取得するための方法を表す。例えばWebアプリケーションであればほとんどの場合「HTTPプロトコル」を使用することになる。通信プロトコルとは、サーバとクライアント間での情報のやりとりの仕方についての決め事。
- ホスト名
  - リソースが存在するホスト（コンピュータ）名を表す。
  - ホストコンピュータとは、ネットワークに接続されて他のコンピュータからの要求を受け取り、処理した結果を返すコンピュータのこと。
  - 「ローカル名.親ドメイン」という構造をしている。
- パス名
  - ホストコンピュータ上のリソースの位置を示す。
  - 具体的には「ディレクトリ/ファイル名」という構造をしている。
- 上記のように、URLを用いることで、「ドメイン -> コンピュータ -> ディレクトリ -> ファイル」というようにファイルの位置を指定できる。
URI
- URLにURNを加えたもの。2010年当時はURNはあまり使われていなかったようだが、リソースが別のホストやディレクトリに移動しても指名できるように名前を表すのがURNと説明されている。
動的コンテンツ
- プログラムによって生成されたコンテンツのこと。例えばリクエストに応じてHTMLを生成して返したりする。これを行うための仕組みがCGI。
静的コンテンツ
- あらかじめ用意されたコンテンツのこと
ライブラリ
- よく利用される処理をプログラム部品として再利用できるように整備したもの。
フレームワーク
- 部品でしかなかったライブラリから、再利用できる部分を増やしてアプリケーションの土台として作られた基盤となるようなプログラム。詳細はLesson６で解説される模様。

ーー中略ーー

3 HTTPを知る

HTTPによる通信

HTTP
- Hyper Text Transfer Protocol HTMLをやりとりするために定められたプロトコル。
- HTTPリクエストのログの１行目をリクエストライン、HTTPレスポンスのログの１行目をステータスラインという。　
- ２行目以下を「メッセージ・ヘッダ」といい、リクエストやレスポンスの付加的な情報が記述される。後述になるが、POST通信のデータの受け渡しやCookieの受け渡しはここで行われる。
- レスポンスログの最後の部分を「メッセージ・ボディ」といい、要求されたHTMLファイルなどの内容が記述される。画像ファイルなどの場合、バイナリ形式となる。
IPアドレス
- インターネットに接続したコンピュータを識別するための数値。
- インターネット上で唯一のIPアドレスを「グローバルIPアドレス」という。
- 対して、プライベートネットワーク内で割り当てられたIPアドレスを「プライベートIPアドレス」といい、３つのクラスに分割されており、その範囲で自由に使用できる。
TCP/IP
- IPアドレスによって特定したホストに任意の情報を送るための通信プロトコル。
- ブラウザなどから受け取ったHTTPリクエストなどの情報を「パケット」という小さな情報の単位に分割して送信し、受信側で組み立て直してから、Webサーバなどのアプリケーションに届けている。
- パケット単位に分割することで、例えば送信に失敗しても、成功した部分は送り直さずに、失敗した部分以降のパケットだけを送ればよいので、全体の効率が上がる。
DNSサーバ
- ドメイン名とIPアドレスの対応表を持ったコンピュータ
- 実際にやりとりされるURLにはIPアドレスは書かれていない。クライアントはURLに記述されたホスト名を用いてDNSサーバに問い合わせることで、対応するIPアドレスを知ることができる。
ポート番号
- TCP/IPには、その情報がどのような通信プロトコルでどのようなアプリケーションが処理すべきかがわからない。
- そのため、受信するアプリケーションは待ち受けポートを決めて情報を受け取る。
- 特に頻繁に使用される通信プロトコルには、「ウェルノウンポート」という、あらかじめ統一されたポートが与えられており、URLのスキームが分かった時点で、ポート番号をいちいち指定しなくてもよくなっている。

GETメソッドとPOSTメソッド

GETメソッド

送信したい情報をURLの後ろに「？」から始まる「クエリ文字列」としてWebサーバに渡す。
クエリ文字列は「パラメータ名 = 値」の塊が「＆」で区切られる形式をしている。

pros
- URLにパラメータが含まれるため、パラメータごと記憶したり、人に伝えるのが便利である。（例えば、ブックマークやURLのコピペで該当のWebページを再度訪問できる。）
- GETリクエストの結果がシステムの状態に影響を与えない（= 副作用がない）
cons
- URLにパラメータが表示されるため丸見えでセキュリティが低い。
- Webサーバにログが残る。
- URLの文字数制限を受けるため、大量の情報を送信するのには適さない。

POSTメソッド

送信したい情報はメッセージ・ボディに格納される

pros
- Webサーバにログが残らないことが多いので、GETメソッドに比べてセキュリティ強度が高い。
- 送信できる情報量に制限がない。
cons
- ブックマークなどができず、パラメータを都度渡す必要がある。