はじめに

ネットワーク関連のことが苦手すぎて今まで全く学習したことがなく、わからないまま放置していました。このままじゃ良くないということで今回ネットワークの仕組みや成り立ちを学習するため、Web 技術入門という本を読んだので備忘録として記事にしました。

1. 通信の基本

ブラウザの通信はHTTPというプロトコルで成り立っています。プロトコルと言うと難しそうに聞こえますが、要は「通信する時の決まりごと」のことです。

ブラウザで URL を入力したりクリックすると、以下の流れで通信が行われます。

ブラウザがサーバに「このページを見せて」とお願いする（リクエスト）
サーバがリクエストされたページを返す（レスポンス）
ブラウザが受け取ったページを画面に表示する

この「リクエスト」と「レスポンス」のやり取りのおかげでブラウザで見たいページが表示されるわけです。

HTTP リクエストの種類

ブラウザがサーバにお願いする方法には、主に 2 つあります。
HTTP リクエストは 3 つの部分に分かれています。ここで全ての書くのは割愛しますが、一部だけ書くとメソッドと言う部分があり、このメソッドの内容によってサーバにお願いする内容が変わります。

GET メソッド

目的：サーバからリソースを取得する
例：Web ページを表示する時、画像を表示する時

POST メソッド

目的：サーバに情報を送信する
例：ログインフォームを送信する時、コメントを投稿する時

簡単に書くとGETメソッドの場合は「このファイルを見せて」というお願いになりますし、POSTメソッドだった場合は「この情報を追加して」というお願いになります。

HTTP レスポンス

サーバからの応答には、必ず「ステータスコード」という番号がついています：

200 OK：正常に処理された（ブラウザに見たいページが表示される）
404 Not Found：リソースが見つからない（見たい情報がサーバから削除されたなどで見られない時）
500 Internal Server Error：サーバ内部でエラーが発生（リクエストはサーバまで届いているが、何らかのエラーでサーバから見たいページの情報を返せない時）

この番号を見ることで、どういう理由で失敗したかなどの大まかな判断ができます。

2. URL の構造

URL は、インターネット上の「住所」のようなものです。以下の要素で構成されています。

http://example.com:80/path/to/resource?param=value#fragment

スキーム：「http://」「https://」など、通信手段を指定する部分
- 他に ftp や file や mysql などいろいろある
ホスト：「example.com」など、サーバの名前
ポート：「:80」など、通信に使用するポート番号（標準ポートは省略可能）
パス：「/path/to/resource」など、リソースの場所
クエリパラメータ：「?param=value」など、追加の情報
- GET メソッドの場合は上記のように URL の後ろの方に「?param=value」がついて目に見える状態になる
- POST メソッドの場合は URL にはつかない。ので、ユーザーには見えないが、見えない所でついている
フラグメント：「#fragment」など、ページ内の特定位置
- 同じページの中の特定の場所にジャンプするための目印
  - 例を挙げると、Wikipedia でソースのニュースにジャンプするために[1][2]などの数字がついているが、その数字をクリックすると該当箇所にジャンプして URL にフラグメントが付く

標準ポート

特定のプロトコルやサービスが使用するポート番号を「標準ポート」または「ウェルノウンポート」と言います。

HTTP：80 番
HTTPS：443 番
FTP：21 番
SSH：22 番

0 番から 1023 番までは重要なサービスが使うために予約されているので、他のサービスでは使用不可。ポートは全部で 0 番〜65535 番まであります。

3. 通信の方式

通信をするときのプロトコルにTCPとUDPという 2 つのプロトコルがあります。

TCP（Transmission Control Protocol）

これは「品質重視」の通信プロトコルです。

メリット：信頼性が高い
デメリット：転送速度が低い

TCP は安全性や品質重視という感じでデータを受け取った側からの反応があるため、送ったデータが確実に届いたかどうかが分かります。

UDP（User Datagram Protocol）

こちらは「スピード重視」の通信プロトコルです。

メリット：転送速度が高い
デメリット：信頼性が低い

UDP はスピード重視なので一方的に送るイメージです。受け取った側からの反応がないので確実に送られているかはわかりませんが、反応を待たなくて良い分、転送速度は速いです。

4. 従来型の Web アプリケーションと SPA

従来型 Web アプリケーション

従来の Web アプリケーションでは、情報はサーバに保存されていて、ブラウザで何か書き込んだり更新したりすると、HTML の再更新が必要でした。サーバが HTML を作り直して描画し直すため、読み込み時間が多くかかっていました。

シングルページアプリケーション（SPA）

JavaScript の発展により生まれた新しい方式です。画面の一部だけを更新するため、サーバから読み込み直す必要がありません。また、画面の一部の更新は JavaScript がサーバへ要求してくれます。非同期通信により、UX が大幅に向上しました。

非同期通信の仕組み

同期通信

サーバが返すレスポンスを待つ間、一切の処理をブロックします。ユーザーは待機時間中に他の操作ができません。

非同期通信

リクエスト後にレスポンスが返ってくる前でも、新たなリクエストを送ることができます。処理は他の処理と同時に並行して行えて、ユーザーは画面の操作を継続できます。そのため、常に最新の情報が手に入ります。

5. 通信の階層

階層モデル

階層モデル（通信レイヤ）については、OSI 参照モデルと TCP/IP 階層モデルが紹介されていましたが、実際の開発では TCP/IP 階層モデルを理解しておけば十分なようです。こちらでは TCP/IP 階層モデルについて記述しています。

アプリケーション層

利用者が使うアプリケーションが通信できるように通信ルールを定義しています。HTTP、FTP、SMTP などのプロトコルが含まれます。

トランスポート層

通信する際の信頼性を高めるためにルールが定義されています。TCP、UDP などのプロトコルが含まれます。

インターネット層

IP（Internet Protocol）が定義されている層です。データを目的地まで届けることが役割で、目的の機器とのやり取りに関するルールが定義されています。

ネットワークインターフェース層

隣接するコンピュータ間の通信を可能にします。主なプロトコルはイーサネット。例えば、送信時は 0 や 1 で送られてきたビット列のデータを光信号や無線などに変換し、受信するときは逆に光信号や無線などを 0 や 1 のビット列に戻していく、という流れで通信を可能にします。

プロトコルスタック

通信する際は複数のプロトコルを使うことで通信ができます。プロトコルを通信レイヤごとに積み重ねてまとめたものがプロトコルスタックです。
通信のトラブル対応では、プロトコルスタックのどこに問題があるのかを特定するのが重要だそうです。

6. 基本的な用語

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

ステートレス

状態を把握していないことです。

例えば、HTTP はステートレスな通信です。インターネット上で情報共有するために作られた HTTP は状態を保持している必要がありませんでした。サーバにあるファイルを見るだけだったらサインインしている必要がないからです。
また、HTTP を作った人が多くの人に快適に使ってもらえるように複雑性をできるだけ無くして設計したという考えもあり、状態の管理をする機能は付けられませんでした。

ステートフル

状態を把握していることです。FTP 通信はステートフルな通信で、前回のやり取りの内容やその間の一連の通信が識別できます。

クッキー（Cookie）

やり取りが保存されている情報のこと。HTTP レスポンスの時にサーバから発行されます。

例えば、初めて行く病院で診察後にその病院の診察カードをもらうと思います。その診察カードが Web の中におけるクッキーに該当します。診察カードの中には自分の個人情報や今回診察した内容などが保存されています。そのおかげで次にまたその病院に行った時に診察カードを出すだけで前回以前のやりとりがわかるわけです。クッキーも診察カードと同じように情報を保存しています。

なお、有効期限があり、期限がくると削除されるため、いつまでも情報が保存されているというわけではありません。

クッキーの種類

ファーストパーティクッキー：訪問したサイトから発行されるクッキー。発行したサイト内でのみ情報管理がされる。
サードパーティクッキー：訪問したサイト以外から発行されるクッキー。複数サイトをまたいで利用可能なので、どのサイトに訪れても同じ広告が表示されるという現象はこのサードパーティクッキーが原因。

終わりに

全くわからない状態で読んでも、1 周読み切るとだいぶネットワークのイメージが掴めた気がします。
更にインターネットでも調べて自分なりに腹落ちした情報をまとめてみました。

ちなみに全体を通してサーバと書いてますが、サーバーでも良いとのことでした。
２種類ある理由はアルファベットをカタカナにする際のルールの変化によるそうです。

本記事では著者に合わせてサーバに統一しています。