概要

本記事は、Web技術の基本についてまとめたものです。
※あくまで学習中の備忘録メモとして作成したものですので、正しい知識ではないことをご了承の上でご精読頂けますと幸いです。

プロトコル

プロトコルとは

通信する際の決まり事。

例えば、Aさん(母国語は日本語)とBさん(母国語はフランス語)が自己紹介するとします。
ふたりとも、互いの母国語を話せませんが、英語は話せます。そこで、ふたりは「会話する時の言語は英語にしよう」と決めました。この「会話する上でのふたりの決め事」こそがプロトコルに値しています。

もし、それぞれが異なる言語で一方的に話していたら、コミュニケーションは成り立ちませんよね。コンピュータも同様に、ネットワーク経由で通信する際のあらゆる決まり事（どういう順番やどんな中身をやりとりするのか等）が決まっています。

HTTP

「HyperText Transfer Protocol」の略。
HTMLファイルの受け渡しを行う際に使用する通信プロトコル。
- HTMLファイルは、HyperTextをルール通りに記載したファイル。

通信プロトコルには、通信する内容や目的によっていくつか種類があります。HTTPはそのうちの1つです。HTTPは、私たちが普段ブラウザから任意のWebページにアクセスする際に使用されています。

SSH

「Secure Shell」の略。
TCP/IPのアプリケーション層のプロトコル。

SSHは、ネットワーク経由で任意のコンピュータに遠隔地からログイン・操作する際に使用されています。通信内容が暗号化されるので、安全性が高いとされています。

同様の通信が可能なプロトコルにはtelnetもありますが、通信内容は暗号化されません。そのため、ログイン時のパスワードも平文でサーバへ送信されます。パケットキャプチャツールを使用すれば、第三者が簡単に通信の中身を覗き見できてしまうのです。

例えば、tcpdumpコマンドやWiresharkを実際に使ってパケットの中身を見てみると、どんなパスワードを入力したか丸見えです。そこで知ったパスワードを利用して、簡単にサーバへログインされ、乗っ取られます。

SSHでは、通信内容自体が暗号化されることは勿論ですが、ログインする際に悪意のあるユーザでないかどうかの認証作業が入ります。身分証明に似ていますね。
この認証作業には、いくつか種類がありますが、よく知られているのが公開鍵認証方式とパスワード認証方式です。

パスワード認証方式：ログインしたいサーバに、パスワード入力でログイン
公開鍵認証方式：秘密鍵を持っているクライアントかサーバ側が確認→ログイン
- クライアント側：秘密鍵と公開鍵のセットを作り、公開鍵のみをサーバにコピー
- サーバ側：クライアントのログイン時に、電子署名を要求
- クライアント側：身元を証明する電子署名を秘密鍵で暗号化し、サーバへ送信
- サーバ側：コピーされた公開鍵で電子署名を復号化→成功すればログイン許可

参考

SSL

「Secure Sockets Layer」の略。
- ソケット：送信元/宛先IPアドレス、送信元/宛先ポート番号の組み合わせ
OSI参照モデルのセッション層のプロトコル。
インターネット上でデータを暗号化して送受信できる。
- HTTPS通信を成立させるために使用される技術。
- HTTPS：HTTP over SSL/TLS
TLSは現在使用されている後継プロトコル。SSL/TLSと表記されたり総称してSSLとも呼ばれたりもする。

SSL通信は...
公開鍵暗号・共通鍵暗号・電子署名・SSLサーバ証明書の技術を使用して暗号化を実現しています。この説明だけだと複雑かつ難しいので、もう少し噛み砕いて具体的に説明すると…

ブラウザがSSL通信を要求します。
サーバは自身の身元を保証するSSLサーバ証明書と公開鍵を送ります。
ブラウザは、サーバから送られた証明書と公開鍵を確認します。
この確認作業で電子署名が使われています。
問題なければ2.でもらった公開鍵を使って、共通鍵を2つ作成。
片方を暗号化してサーバへ送ります。
サーバは、元々持っている秘密鍵で共通鍵を復号化します。
以降は、お互い共通鍵で暗号化・復号化してやり取りします。

SSL通信で暗号化に使われている技術

公開鍵暗号：暗号化と復号化に別の鍵を使用
共通鍵暗号：暗号化と復号化に同じ鍵を使用→合鍵的な役割
電子署名：証明書へ署名したもの・秘密鍵から生成する
SSLサーバ証明書
- Webサイト運営者の実在性を証明する
- 認証局(CA)が発行する→安全性が高いサイトであることを利用者に証明できる
- CA自身の証明書がルート証明書
  ルート証明書はブラウザに入っており、電子署名を復号化する公開鍵が含まれる
- 公開鍵と共通鍵が含まれている
  例：ブラウザからQiitaのSSL証明書とルート証明書を確認できる

リクエスト・レスポンス

リクエスト

WebサーバとWebクライアントがHTTP通信をする上で、クライアント側がサーバ側に、任意のHTMLファイルを要求すること。
例えば、カフェでのやりとりを想像してみてください。
お客さん(クライアント)が店員さん(サーバ)に、「コーヒー(HTMLファイル)をください」と注文しています。
この時の注文がリクエストに値します。

レスポンス

WebサーバとWebクライアントがHTTP通信をする上で、サーバ側がクライアントの要求に基づいて、指定されたHTMLファイルを渡すこと。
もう一度、カフェでのやりとりを想像してみてください。
お客さん(クライアント)にコーヒー(HTMLファイル)をください」と注文を受けた店員さん(サーバ)は、コーヒーを用意してお客さんにお渡ししています。
この時にコーヒーの提供がレスポンスに値します。

ポート番号

コンピュータ上で、処理するアプリケーションを識別するための番号。
受付の窓口的な役割を担っている。

例えば、役所で何か手続きをするとき、手続き内容によって対応窓口が異なっていますよね。同様に、ポート番号も使用するプロトコルによってそれぞれ番号が異なります。

ex. 住所変更は〇〇番窓口、印鑑登録は△△番窓口 ===> HTTPは80番、SSHは22番

ステートフルとステートレス

ステートフル

コンピュータ(システム)間で通信する際、通信履歴やログイン状態などの情報を保持し、それに基づいた処理を行うこと。
ステート「状態」がフル「並々」⇒ 状態が維持されている

ステートレス

コンピュータ(システム)間で通信する際、毎回決まった処理を行うこと。
ステート「状態」がレス「ない」⇒ 状態が維持されない

上述した「ステートフル」とは反対に、これまでどんなやりとりをしたかといった情報は保持されません。そのため、入力に対して同じ出力結果になります。

HTTPは、普段私たちがWebアプリケーションを利用する際に使うプロトコルです。しかしながら、ステートフルプロトコルではありません。リクエストとレスポンスの対で1回のやり取りが終了するため、Webサーバはクライアントの前回の通信のリクエスト結果に応じることはできません。

例えば、ログインユーザにしか見せたくないページがあります。しかし、もしログイン後のURLを推測できれば、未ログイン状態でもブラウザのアドレスバーに入力してアクセスできてしまいます。これではセキュリティ上安全でないですし、意図しないアクセスが発生します。

そこで、HTTP通信で状況に応じた処理を実現させるために、セッションやCookieといった仕組みが利用されています。

Cookie

Webブラウザに状態を持たせる技術。
HTTPの仕様を拡張して実現された。
名前=値の組み合わせ

ステートレスなHTTP通信で、ステートフルを実現するために登場したのがCookieです。
Cookieにより、Webサーバ（アプリケーション）とWebブラウザ間での情報交換が可能になります。

具体的には…

サーバ：初回リクエスト時に、Cookieの情報をヘッダに入れてレスポンス
ブラウザ：次回リクエスト時にサーバから取得したCookie情報をヘッダに入れて送信
サーバ：Cookie情報から、アクセスしたユーザを調べ、状況に応じた内容をレスポンス
ブラウザ：以降のHTTP通信でも、初回リクエスト時に取得したCookie情報を使用する

ログアウトすると、ブラウザはCookie情報を削除し、サーバはヘッダのCookie情報を空してレスポンスします。
そのため、以降の通信ではブラウザにCookie情報は残りません。

この通り、Cookieを利用することで、状態を維持しながら複数回のHTTP通信が可能になります。

セッション

通信の一連の処理の流れ。
Cookieよりも安全かつ多くの情報を保持する（ステートフルを実現する）仕組み。

Cookieを利用すればHTTP通信でステートフルを実現できると説明しました。
しかし、Cookieは保持できる情報量に制限があります。加えて、パスワードなどの個人情報を平文でヘッダに含められます。そのため、第三者に通信を覗き見され、情報を悪用される可能性が高いです。
そこで、一連の処理の流れ（セッション）に番号をつけて、Webサーバ側で管理する仕組みが登場しました。この番号をセッションIDと言います。
セッションIDをCookie情報に含めれば、サーバとクライアント間の通信は、セッションIDのやり取りだけで良くなります。

例えば、ネットで買い物をする際は、「商品をカートに入れる〜決済終了」までが1セッションとなります。