Web技術の基本：Webアプリケーション開発で必要な知識を私なりにまとめてみました！
おはようございます、こんにちは、こんばんは！
閲覧ありがとうございます！
Webの基礎を勉強しました。
これらの意味を上から順に自分なりの言葉でまとめてみました！
リクエスト
レスポンス
ポート番号
ステートフル
ステートレス
Cookie＆session
全体として少し長いのですが
分かりやすい感じでまとめて見ましたのでサラーっと目を通していただけると幸いです。
こちらは今回参考にした教材です
『プロになるためのWeb技術入門』――なぜ，あなたはWebシステムを開発できないのか
目次
プロトコル
プロトコルとは、コンピュータやネットワーク機器間の通信ルールであり
ウェブ上でHTMLや画像などの定められた通信プロトコルがHTTPと言います。
もう一つあってTCP/IPと呼ばれるプロコトルがあり
IPアドレス(住所)にむかってクライアントに情報を届ける役割があります。
現実的に言うと郵便配達の位置付けによく似ています
まとめると：コンピュータやネットワーク機器間の通信,情報の伝達方法のこと
リクエスト
一言で言うと
Webアプリ使うときやHPを見るときにWebクライアントからWebサーバーに通信すること。
さらに深掘りすると
例としてGETとPOST２通りのHTTPリクエストあり
HTTP通信GETメソッドは共有されてもいいページ頂戴とお願いする時。
HTTP通信のPOSTメソッドは個人情報などの機密性の高いリクエストで使用例が
フォーム入力やログイン情報をした時に使います。
分かりやすく言えば
GETメソッドは「共有されても大丈夫な情報をお願い！」というリクエストで
POSTメソッドは「機密性の高い情報を送るので、安全に処理して！」というリクエストになります。
レスポンス
一言で言うとレスポンスはWebサーバーからWebクライアントに通信を送ること。
リクエストした際に行われる行動です。
さらに深掘りするとHTTPレスポンスにて、ステータス・コードがあり200番だとリクエスト成功となる
300番台はURLの一時的な移動。
400番台はクライアント側で起きたエラーリクエスト失敗を示す。
401のユーザー認証失敗
403アクセス権限なし
404良くあるお探しのページはありませんで出てくるエラーです。
500番台はサーバーエラーサーバー側のエラーでプログラム実行によってエラーが発生します。
開発者が修正しなければ治らないエラーリクエストの失敗を示す。
以下をまとめると
- 200番台のステータスコードは、リクエストが成功したことを示す。例: 200 OK
- 300番台のステータスコードは、リダイレクトを示す。クライアントは、追加のアクションを行う必要がある。例）URLの一時的な移動がある場合に起きる。
- 400番台のステータスコードは、クライアント側で起きたエラーを示し、リクエストが失敗したことを示す。
- 401 Unauthorized: 認証が必要
- 403 Forbidden: 閲覧禁止、アクセス権限がない
- 404 Not Found: ページが見つからない（URLが間違っていることが多い）
- 500番台のステータスコードは、サーバー側で発生したエラーを示し、開発者が修正しなければリクエストが成功しないことを示す。例: 500 Internal Server Error
ポート番号
ポート番号は、通信を行うアプリケーションやサービスが特定のポートを待ち受けして、
送られてくるパケットを正しく処理できるようにするために使われます。
ポートは、通信を行う際の「港」のような役割を果たしている
TCP/IPによって情報を受け取るアプリケーションは必ず『待ち受けポート』を
決めて情報を持つ。ポートは0~65,535までの数字で表され、
同じポートを複数のアプリケーションは使用することはできない！
例えば：マンションの部屋番で考えると、住んでる人(アプリケーション)の部屋に
知らない人(違うアプリケーション)がその部屋に入るのはおかしいですよね？
なので別々のポート番号にしましょうと言うことです
ただしよく使われるポート番号が別々のポート番号にしてしまうと、
HTTPプロコトルの通信もバラバラで不便です。
URLで省略できているポート番号も指定しなければなりません。
そこでよく使われるプロコトルについてはポート番号を取り決めておくことになっています。
代表的なプロコトルで使用されるポートは『ウェル・ノウン・ポート』と呼ばれています
例えば↓
| ポート番号 | 用途 |
|---|---|
| 22 | SSH(暗号化された通信) |
| 80 | HTTP通信 |
| 443 | HTTPS（セキュアな暗号化されたHTTP） |
これらは必ず統一させます。
ステートレス
HTTPのみではログイン状態を維持できない（覚えられない）
HTTPでは１回のリクエストとレスポンスで処理が完結するため、
過去のリクエストに関する状態を持たない。
そのためHTTPは状態を持たないプロトコルで
このことをステートレスプロトコルといいます。
分かりやすくいうと：１歩歩くと忘れる感じです、鶏🐓の進化版ですね。
ステートフル
ステートレスの逆として
前回のリクエストの結果を覚えていてそれを踏まえて次のリクエストを実行している
リクエストに伴って状態が変化し、状態を持つプロトコルのことを
ステートフルプロコトルと呼ばれています。
ステートレスとステートフルの違いについて分かりやすく解説
ステートレスの例
自動販売機では、お客さんが飲み物を購入するたびに、
お金を入れてボタンを押す必要があります。
自動販売機は、その人個人の過去の購入履歴を記憶していません。
お客さんが何度も同じ飲み物を購入する場合でも、毎回同じ商品のボタンを押すことになります。
これがステートレスの例です。
ステートフルの例
一方、高級カフェ店では、常連さんが飲み物や食事を注文する際に、
店員が常連さんの過去の注文履歴や好みを記録していることにします。
次回以降、常連さんがそのカフェを訪れたときに、『いつものセットで』というと
店員は『かしこまりました』とそれだけで注文を完了できます。
これが前回のリクエスト(注文履歴)を踏まえているステートフルの例です。
ではこれらをどのようにして記録しているのかは
次のCookieと言う仕組みがあるので説明していきます。
Cookie
Webブラウザに状態を持たせる仕組みそれがCookieという仕組みです！
Cookieの仕組みは、WebサーバーからWebブラウザ(クライアント)へHTTPレスポンスのヘッダを利用し情報を送る
この情報は『キー＝値』の組み合わせでこれをCookieと呼びます
WebサーバーからCookie受け取ったWebブラウザ(クライアント)は、次回同じWebサーバーにアクセスする際に
受け取ったCookieをそのままHTTPリクエストヘッダに入れて送る。
Webアプリケーション側ではリクエストヘッダに
入っているCookieを調べることで
アクセスして来た相手がどんな相手なのかを知ることができます。
つまりCookieのおかげでステートフルが実現できている。
おまけ↓
Cookieの名前の由来：
お菓子の「フォーチュンクッキー」に由来しています。
フォーチュンクッキーは、クッキーの中に紙片が入っており、
紙片には短いメッセージや予言が書かれています。
サーバーからブラウザ(クライアント)へ送られる小さな情報（ユーザー認証や設定の保存など）を含んでいます。
このため、フォーチュンクッキーというアイデアに基づいて名付けられたとされているらしいです！
Webブラウザ(クライアント)のCookieは、内部に情報を持っている点とフォーチュンクッキーの中にあるメッセージと似てますね！
別の説として
マジック・クッキーとも関係があるらしいですが私は調べてないので分かりません。
気になる方は調べて見てください！意外と面白いですよ。
セッション(Session)
だだし今のままでは、問題があります。 Cookieの中身は個人情報が丸見えです。
ちょっと知識がある人ならば簡単にのぞけてしまいます。(PC上にtext fileとして保存されている)
もし個人情報の中にユーザー名やパスワード、クレジットカード番号が丸見えで見えていたら、、
と考えるだけで恐ろしいですね。
なりすましで勝手に買い物されたりと被害につながりかねません。
銀行口座が見れるアプリやECサイトなどは特に注意が必要ですね。
こんなセキュリティ上非常に大きな問題のあるCookieですが、
ある仕組みとセットにすることでこのデメリットは解消されます。
それが『セッション』と呼ばれる仕組みです。
セッション(Session)とは何か、
ログインします→お買い物で書籍を買います→注文確認画面が出て→ログアウト
このような一連のHTTPリクエストの処理の流れを『セッション(Session)』と言います。
じゃあこのセッションの状態をどこで保持するのか？
それはWebサーバーで管理します。
では、どのようにしてPC上の情報をWebサーバーに紐付けるのでしょうか？
その役割を果たすのが「セッションID（SessionID）」です。
セッションIDというのは数字です。分かりやすく言えば管理番号です。
管理番号で個人情報を管理することで、一意であり重複することがないので、
同姓同名な人いてもサーバー上では番号なので、迷わず管理して的確に今までの情報を割り当てます
このような重複しない一意なものを『ユニーク(unique)』と言います。
ここまでお話しすると勘の言い方はお気づきだと思いますが、
CookieにセッションIDだけ保管していれば個人情報丸見えの状態より安全性が高いことがわかります。
ただし！簡単なセッションID(数字のみ)だと
セッションハイジャックされ結局なりすましされてしまいます。
セッションIDは推測できないような長くて複雑なものにしましょう
例えばこんな感じ：AEIGAHIHVOWHEAHGREAOI12R442GVFGOGE
それでは、Cookieの一連の流れをまとめて見ました。
Webクライアント側が、個人情報を入力(ログイン)→HTTPリクエストされた個人情報をサーバー側でセッションID発行し個人情報を記録しCookieにセッションIDを格納して返す→ またクライアントがセッションIDを格納したCookieをサーバーに渡します→サーバーがそのセッションIDから個人情報を特定しこの人は今この状態だと認識することができます。
ステートフルな状態を保つためにはこの一連の流れが行われています！
ここまでの知識を踏まえた上で
それぞれのステートを使う場面について軽くご紹介します。
ステートフルとステートレスの使い分け
ステートレスの場合
静的コンテンツ(HTML)や情報を記憶しなくていい
ただ単にページ遷移するときに使われます。
メリットは、シンプルかつ軽いとこのような点がありますので全てステートフルで
いいというわけでは無いですね。
ステートフルの場合
ユーザーのログイン状態を保持するような場合や、
複数のリクエストにわたって状態を維持する必要がある場合は、
ステートフルが適切です。
複数のリクエストに関して状態の維持についてを分かりやすく深掘りしますと
ECサイトがあります。
買いたいものをカートに入れます→確認画面に入ります→購入ボタンを押します→購入ありがとうございました画面が出ます。 このようにいっぱいページ遷移する場合で、お客さんと買った物の情報を覚えてなきゃいけないですよね？
もしステートレスですと、
カートに入れて確認画面に入ると
買ったお客さんを忘れカートの中身が無いという
クソアプリができてしまいます。
無限ループです一向にお買い物できませんと、
こういう場合にステートフルを使います。
デメリットもあります。
サーバーの負荷が増える、開発や、メンテナンスのコストが増えるetc...
なのでうまくステートレスとステートフルを使い分けましょう！
正直なとこフレームワーク使いますと勝手に使い分けてくれてる気がしますが！
こうゆう裏の仕組みをわかっていると楽しくなってくると思います！
最後に
この知識は今後自分でWebアプリケーションを作る際に役に立ちます！
特にCookieとセッションの周辺知識はログイン機能でセッションIDとUser_IDを必ず一致しているかと 紐づけることにより
current_user.idとして現在ログインしているかどうかを判断することができます。
これによってログインしていない人は見れないページとログインしている人は見れるページと区別することができます。
閲覧ありがとうございました！！！！！
