Web技術の基本を学ぶ（学習用）

はじめに

完全未経験からWebエンジニアを目指しています。
Web技術について根本的に学習してる最中で、アウトプットのためにまとめたものです。勉強中ですので間違いがあれば指摘していただければ幸いです。

Webアプリとは

• ソフトウェアとは　　コンピュータの中で動くプログラムのこと
• アプリとは　　アプリケーションソフトウェア の略でOS上で動作するソフトウェアのこと

アプリの種類に

1. Webアプリ
2. ネイティブアプリ（デスクトップアプリ、iOSアプリ、Androidアプリ等）

と大きく２種類に分類されています。両者の違いは端末上で動作するか、Webブラウザ上で動作するかという点にあります。

	Webアプリケーション	ネイティブアプリケーション
処理の主体	サーバー	各端末
インストール	不要	必要
画面の表示	Webブラウザ上	OS上

Webを支える技術

クライアントとサーバー

Webアプリの処理の主体はサーバ（Webサーバ）で、また利用者はクライアント（Webクライアント）で実現されています。

両者とも英語のclientとserverが語源となっておりお客様と召し使いの関係となっています。

ここでクライアント（客）からサーバー（召し使い）への要求をリクエスト（request）
サーバー（召し使い）からクライアント（客）への応答をレスポンス(response)
と呼んでいます。

リクエストとレスポンスも英語が語源ですね。

プロトコル(Protocol)

WebサーバーとWebクライアントはお互い通信を行なって情報をやり取りしています。
ここでやり取りをする際、どのように情報をやり取りするかということを決める必要があります。

• プロトコル　　約束のこと（規約、手順、前提条件などなど呼ばれている）

例えば、国際的な科学論文の発表会で各々が母国語で話す人はいませんよね？これではコミュニケーション（通信）できませんよね。皆さん共通して理解できる英語を話しますよね。それか事前に言語を決めますよね。

コンピュータも同様に、通信する時〇〇という条件でやり取りしましょうという事前に取り決めて互いに理解できるようにしています。その事前の取り決めをプロトコルと呼びます。

WebサーバーとWebクライアントは HTTP というプロトコルに従って通信を行なっています。

ちなみにHTTPというルールはIETFという団体によって制定されています。
IETFによってHTTPの詳細を記述したRFCが発行されています。
原文は英語です。。。
ありがたいことに日本語訳もありました。
（余談ですが、deeplという翻訳aiの精度高いですね）

TCP/IP

Webアプリ開発では

• 情報は パケット と呼ばれる単位に分割されて送受信されている
• パケットの送受信は TCP/IP が責任を持って行なっている

ということのみを覚えとけば良いそうです。

インターネットに接続されたコンピュータはIPアドレスという数値によって識別されています。
IPアドレスがわかると宛先のホストが特定できるので、そのホストへの任意の情報を届けることができます。そのプロトコルがTCP/IPです。

TCP/IPはブラウザなどから受け取ったHTTPリクエストなどの情報をパケットという小さな単位に分割して送信し、受信側で再度組み立てています。

しかし、受信した情報がどのプロトコルかはTCP/IPには判別できません。そこで ポート という考え方が用いられています。

• ポート 　　ネットワークとパソコンの間にあるドアのようなもの。0~65535までの数字で表される。

このポートを通ることでどのプロトコルで処理するかを判別しています。

Webで使うIPアドレスは通常であればIPアドレスにポート番号が記述されています。
(例) 172.217.175.110 :80

だが、HTTPプロトコルとわかった時点で、ウェルノウンポート（HTTPは80番）を宛先として設定されるので省略されています。

代表的なウェルノウンポート

ポート番号	プロトコル		ポート番号	プロトコル
20,21	FTP		53	DNS
22	SSH		80	HTTP
23	Telnet		110	POP3
25	SMTP		443	HTTPS

GETメソッドとPOSTメソッドの違い

	GETリクエスト	POSTリクエスト
利用するメソッド	GETメソッド	POSTメソッド
パラメータの格納場所	URL	メッセージボディ
セキュリティ	低い	比較的高い
パラメータの長さ	255文字に制限される可能性あり	制限なし
パラメータの保存・再現	しやすい	しにくい
副作用が発生しないこと	期待される	期待されない

• GETメソッドではURLにクエリ文字列で格納されWebサーバのログに記録される可能性があるため　第三者に漏洩しやすい
  → セキュリティーが低い

• GETリクエストの結果がシステムの状態に影響を与えないようになっている。
  　→ 副作用がない（同じ要求を何度繰り返しても同じ結果が得られること）
  　

*日本語はパーセントエンコーディングという表現方法で文字化けしないよう表されている

Webアプリケーション開発の必須技術

ログイン認証機能

ログイン画面でログインボタンを押した時の動作から考えましょう。

1. まず、フォーム上じの入力されたユーザ名とパスワードを取得して変数へ格納します。(POSTメソッド)
2. データベースを参照にしてユーザ名とパスワードが同じかどうか調べます。
3. 同じであればログイン後のページへ、違えばログイン失敗画面へ遷移します。

単純です。

*最初に要求したURLと異なるURLに誘導することをリダイレクトと呼びます。

単純ですが、問題があります。
それはURLさえ分かれば、ログイン画面に遷移できるということです。
HTTPでは状態を持つことができないからです。

• ステート（state）　状態のこと
• ステートレス（stateless）　前後の状況に関係せずその都度いつも同じレスポンスを返すプロトコル。機械的なイメージ。
• ステートフル（stateful）　以前のセッション状態を維持して、その後の処理結果に反映させるプロトコル。対人的なイメージ。

HTTPはリクエストに対してレスポンスを返すという繰り返しです。
つまり、HTTPはステートレスプロトコルということになります。

↓↓↓ 参考になりました。

Cookie(クッキー)

状態をもたないステートレスなHTTPに状態を教える技術がCookieです。

HTTPリクエストを行った後、サーバーから情報を保持するためCookieというテキストファイルを付与したHTTPレスポンスをおこなう。
そのCookieをクライアントが保持して状態の維持を行う

ということですかねぇ。。。。（すみません,正しいか自信がありません）

Cookieに設定してある条件のことを属性と言います。以下属性。

• Expires属性

  • Cookieの有効期限について記述。有効期限が切れたら削除されます。

• Max-Age属性

  • 有効期限の秒数について記述。

• Domain属性

  • Cookieを送信したいサーバーのドメイン名を指定します。指定されなかったらCookieを発行したサーバのみに送信します。

• Path属性

  • 送信するURLに指定するパスが含まれているのみCookieが送信されます。何も指定しなかったら発行したパスのみに送信します

• Secure属性

  • HTTPS通信が行われている場合のみCookieを送信するそうです。

• HttpOnly属性

  • JavascriptでCookieを取得できないようにする属性だそうです。

英語と日本語訳両方ついてます↓↓↓

終わりに

最後のRFCは読んでで頭がパンクしそうになりました。エンジニアはこのような文章をスラスラ読むのですね。尊敬します。
でも、今回色々調べる作業は非常に楽しかったです。まだまだ参考文書には続きがありますが、続きは次の記事にまとめようと思います。

間違い等ございましたら、指摘していただけると幸いです。
貴重なお時間、閲覧ありがとうございました。

参考文書