はじめに
突然ですが、みなさんはwebの基礎に関する理解に自信はありますか？
私はなんとなくはわかっているものの、説明をしてくださいと言われると少し自信がありません(汗)
今回は、自信を持って説明できるようになるべく、プロになるためのWeb技術入門を読みました。読んだ内容を簡単にですが、まとめてみました。
リクエスト
クライアント(依頼者)からサーバ(提供者)へ要求すること。
具体的には、ユーザがGoogleやYahooのようなブラウザからURLを入力したり、検索ボックスに文字を入れて、検索をかけることもリクエスト。正確にはHTTPリクエスト。
HTTPリクエスト
HTTPリクエストは、 リクエストヘッダー、リクエストボディなどで構成されている。
リクエストヘッダー
以下の情報などが格納されている。
-
URLの情報。
-
GET、POSTのようなメソッド。
-
英語や日本語などの言語指定。この指定で、サーバはクライアントに英語と日本語のコンテンツがある場合、指定された言語のコンテンツを返却する。
-
リクエストしている端末は、スマホなのかPCなのか。これによって、サーバ側はスマホ用か、PC用のサイズのコンテンツをクライアントに返却するのかを決める。
-
Cookie。（※説明は後述）
リクエストヘッダーの一行目に、「GET http://www.littleforest.jp/web/text/index.html HTTP/1.1」のような情報のことをリクエスト・ラインと呼ぶ。
リクエストボディ
ログイン画面でユーザが入力したIDやパスワードなどが格納されている。
URL
クライアントがどのサーバに対して要求しているのかを明確にするための情報。 ネットワーク上でPCを特定するための住所みたいなもの。例えば、http://www.littleforest.jp/web/text/index.html
URLはスキーム、ホスト名、ポート番号、パス名 などから構成されている。
-
スキーム は
http、https、ftpなどがある。 -
ホスト名 は
www.littleforest.jpの箇所。人間が認識しやすい文字で表現されている。ネットワーク上でパソコンにはIPアドレスが割り振られており、192.168.0.1みたいな数字の羅列で、人間には認識しづらいため、IPアドレスをホスト名にDNSサーバが変換している。 -
ポート番号 はIPアドレスでネットワーク上のPCを特定できたら、そのPCのどのアプリケーションなのかを特定するためのもの。マンションの部屋番号みたいなもの。 HTTPは80、HTTPSは443 など。
-
パス名 は
web/text/index.htmlのようにWEBサーバの中にコンテンツが格納されている場所を指定する。
ポート番号はブラウザのURLに明示的に記載しなくてもよい。スキームでhttpと記載した時点でHTTPプロトコルを使用すると認識され、80が自動的に設定されるため。
GET、POST
HTTPリクエストのリクエストヘッダーに指定するもの。それぞれの特徴をまとめると以下。
-
GET
- フォームに入力した内容がブラウザのURLに表示される。
- ログイン画面で入力するID、パスワードもURLに表示されてしまい、 セキュリティ的に危険
- HTTPリクエストを行うと、 WEBサーバ側のログにリクエスト・ラインの情報が残ってしまい、情報漏洩の可能性が高い 。
- メリットとしては、検索エンジンで調べた内容を他の人に共有する際に便利。検索したキーワードがURLに表示してくれるため。
-
POST
- フォームに入力した内容がリクエストボディの中に格納されるため、URLには入力内容は表示されない。
- GETと異なり、ログインIDやパスワード情報がリクエスト・ラインに表示されない。そのため、WEBサーバ側のログにも残らない。
- ただ、GETメソッドの逆で 検索エンジンで検索した内容を他の人と共有はできない。 URLに検索キーワードの情報が表示されないため。
レスポンス
クライアントからの要求にサーバが応えること
先程の例でいうと、YahooやGoogleで検索ボックスに検索キーワードを打ち込んだ後に、検索結果がブラウザに表示されているのも、サーバからコンテンツがクライアントにレスポンスされているため。正確にはHTTPレスポンス
HTTPレスポンス
ステータス・ライン、メッセージ・ヘッダー。メッセージ・ボディ から構成されている。
-
ステータス・ライン は
HTTP/1.1 200 OKのようなもの。その中で 重要なのがステータスコード。 リクエストが成功したのか、失敗したのかを3桁の数字で表す。200は成功、500はサーバエラー、404はページが見つからないなど。 -
メッセージ・ヘッダは、Cookie（※説明は後述）のような情報が格納されている。
-
メッセージ・ボディ はWEBブラウザからのリクエストされたHTML、CSS、Javascript、画像などが格納される。
ステートレス、ステートフル
WEBクライアントの状態を保持できないこと
例えば、アマゾンのようなショッピングサイトで買い物かごに商品を入れていたものの、その状態を保持しておくことができないこと。
床屋でいうところの1000円カットみたいに前回依頼した髪型をカットする人が覚えていないため、毎回切ってほしい髪型をお客側が伝える必要がある。
HTTPプロトコルは状態を保持できない。
状態を保持できるFTPプロトコルを使用するにもオーバーヘッドがかかったり、認証が必要がになってしまい、手間がかかる。
逆にHTTPはオーバーヘッドが少なく、認証不要だが、クライアントの状態を保持できない。
HTTPの長所をいかしつつも、状態を保持する （ステートフル） ために生まれたのが、 Cookie。
Cookie
クライアントの状態を保持するために、HTTPリクエストのリクエストヘッダー、HTTPレスポンスのメッセージ・ヘッダーにSession IDが設定される。また、クライアントのブラウザにCookieは保存される
ただ、CookieにユーザIDやパスワード情報を設定してしまうと、HTTPリクエストやレスポンスの通信を悪意のある第三者から盗まれた場合に、情報が漏洩してしまうため、危険。
セキュリティの問題を解決するために生まれたのが、 Session 。
Session
ログインからログアウトまでの一連の流れのこと
例えば、アマゾンのようなショッピングサイトで、ログイン → 買い物かごに商品を入れる → 注文 → ログアウトのような一連の処理のこと。
Sessionではクライアントがログイン中なのか、ログアウト状態なのかを管理する必要がある。管理するために生まれたのが Session ID。
Session IDはログインしたクライアントに対して、WEBサーバ側で発行される。発行されたSession IDはCookieにセットされて、レスポンスされる。
セッションIDはWEBサーバ側のメモリやデータベースで管理される。
Session IDはただの数字のため、ユーザIDやパスワードをCookieにセットするよりもセキュリティ的に安全。
プロトコル
異なるパソコン同士がネットワーク上で通信するための取り決め、ルールみたいなもの。
例えば、会社内で他の社員との通信手段をメールにするのか、LINEにするのか、slackにするのかなどを事前に取り決めておかないと、相手と連絡が取れなくってしまうことがある。コンピューターの世界でも通信する前に事前に取り決めをする必要がある。
具体的には HTTP、HTTPS、TCP/IP などがある。
TCP/IPは、異なるPC同士がネットワーク上で、データをやり取りする際に、データをパケットという小さな単位に分割してやりとりする。
なぜなら、ネットワークによっては小さなデータしか通らない箇所もあるから。また、パケット単位にしておけば、失敗したパケットだけを再送すればよいため、効率もよい。