Web技術入門用語を説明してみる

はじめに

初めまして、じょんと申します！
Qiitaへは初投稿となります。

未経験ではないのですが、恥ずかしながらWeb関連について、基礎知識からスカスカでした。
IT用語って、ほとんどが横文字で、日常で目にする耳にする言葉でもないので呪文？魔法？のように聞こえませんか？
やけに理解の早い同期がいたりして、焦ることもあるかもしれません。
大丈夫です。魔法に聞こえる人が大多数です。
。。。え？そうですよね？

今回、「プロになるためのWeb技術入門」を読んで、いくつかの用語について

• 自分自身、曖昧だった理解を深めるため
• これからWeb知識を学んでいこう！という方に微力ながら手助けになる

ような解説ができればと思います。

取り扱う用語

解説していく用語は、下記になります。

• リクエスト / レスポンス
• プロトコル
• ポート番号
• ステートレス / ステートフル
• クッキー

その他、説明していく上で必要な用語は、注釈を入れていきます。
また、本記事では用語の解説にフォーカスし、技術の実現方法には触れません。

リクエスト / レスポンス (request / response)

初めは、聞き覚えのある用語から行きましょう。
特に辞書を引くこともなく、要求 / 応答とわかります。

これ、用語の意味としては、本当にそのままなんです。
ただ、要求する人、応答する人が登場します。

下の図を見てください。

カフェであれば、当然お客様、そして店員の方がいらっしゃいます。
そして、「注文」すると、「注文された品を出す」という、お客様からの要求 / 給仕からの応答があります。

これを、Webに置き換えると、

• クライアントからのサーバへの要求をリクエスト
• サーバからクライアントへの応答をレスポンス

になります。
ね、そのままでしょう？

また、皆さん意識してはいませんが、日常的にしています。
お使いのスマートフォンで検索したりする際、「〇〇のページをください！」のようなhttpリクエストを、
対してサーバは、「〇〇のページです！どうぞ！」のようなhttpレスポンスを返します。

新しいワード、httpが出てきました。
次に解説する、プロトコルの項で登場します。

プロトコル (protocol)

あぁ、２つ目にして、聞き慣れない横文字ですね。
日本語訳してみると、「通信接続手順、通信規約などの決まり事」になります。

なんだか「規約」だなんて、とても大切そうですね。
先に、いくつかのプロトコルをさっくり紹介します。¹

プロトコル名	概要	ポート番号
HTTP	HTMLで書かれた文書などのやりとりを行う	80
DNS	IPアドレス2とドメイン3の対応を管理する	53
FTP	ファイルの転送を行う	20,21
SSH	暗号や認証を利用し、安全な遠隔操作を行う	22

ポート番号という用語がここで登場しましたが、のちに解説がありますので、
一旦は「番号ついてるんだ？」くらいで大丈夫です。

きっと、聞いたことあるな～となるのは１個目のHTTPでしょうか？
そうです、先に解説したリクエスト / レスポンスの最後で登場しました。
URLに含まれているので、以前から見かけているという人も多いでしょう。⁴

これらは何のために必要なのでしょうか？
図を見ていきましょう。

リクエスト / レスポンスで使用したものに、少し手を加えたものです。
双方が、異なる言葉で要求 / 応答をしても、互いに相手が何を言っているかわからないですね。

通信において、このような事が起きてしまわないように、
「HTTPに則ってやりとりしましょうね。」
という約束事が、プロトコルになります。

余談ですが、台湾に出張に行っていた頃、現地の社員に伝わらないだろうと「可愛い」とか言っていたら、普通に「ありがとう」と返ってきて、
「うわっ、伝わってた、うわあああぁぁ！」
と恥ずかしい思いをしました。
日本語を勉強されている方が多く、また台湾語の「可愛い」の発音がそもそも似ていたりします。
変な日本語なんかも教えたりしないようにしましょう。笑

ポート番号 (Port Number)

前項で、プロトコルを学びましたね。
では、使用しているプロトコルがどれなのか、自分自身はわかるとして、通信相手はどうやって判断できるでしょうか？

また、コンピュータはたった１つの処理で済むわけがなく、非常に多くの処理を行っています。
１つの受け口で足りるでしょうか？

そこで、ポートが登場します。
ポートは、0～65,535の65.536種類の数字で表されます。

ここでは、扉のイメージで説明します。
扉がポート、扉に振られている数字がポート番号です。

どの数字の扉を通ってきたか？で判断しているわけです。

勘の良い方はお気づきかもしれませんが、何やら見覚えのある数字ですね。
そうです、プロトコルの項のテーブルに突如現れたアイツです。
これらの番号は、ウェルノウンポートと呼ばれており、専用のポートになります。

つまり、「80番を通ってきたならば、HTTPだな」と判断できます。

また、ウェルノウンポートで調べていただくと、専用ポートがたくさん出てきます。
しかし、それでも65.536種類には全く届かず、残りは何なの？と疑問を持つでしょう。

ポート番号レンジ	名称
0～1023	ウェルノウンポート
1024～49151	登録済ポート
49152～65535	ダイナミック/プライベートポート

とそれぞれ呼ばれています。

完全に自由に使えるかというと語弊があるのですが、現時点ではダイナミック/プライベートポートが自由に使えるポートと考えていただければ良いです。

ステートレス / ステートフル(stateless / stateful)

再び、聞き慣れない横文字がやってきました。
では、日本語訳してみましょう。

• ステートレス（stateless) ➩ 処理状態を把握しない（保持しない）
• ステートフル（stateful) ➩ 処理状態を把握する（保持する）

横文字よりは幾分わかりやすくなりましたが、まだピンときませんね？

唐突ですが、下記を見てください。

このように、毎回初めましてとなるのが、ステートレスになります。
（※例なので数日後と書いてますが、このやり取りが終わった直後でも同じことです）

反対に、

のように、前回のことを覚えているのが、ステートフルになります。
こちらの方が、自然で理解しやすいかと思います。

さて、これはWebにおいてはどういったことでしょうか？

例えば、皆さんお使いのスマートフォンやPCで、何か検索する。
これは、ステートレスに当たります。
過去の検索により、検索結果が変わることはないですよね？
１つの要求に対して、１回の応答といった関係だけで、状態を保持しないことになります。

また、スマートフォンやPCで買い物をする際、「カートに入れる」という操作を行ったことがあると思います。
そして、一通りカートに入れ終わり、「お会計」の操作をすると、当然「カートに入れる」を行った商品が表示されます。
これが、ステートフルになります。
もし、これがステートレスだったら、「おぉいっ！？俺の考えた最強の買い物カゴ、空になっとるやんけ！！」となります。
そんなことで、タイムセールなんかを買い逃したらクレームものですよね。。。

以上をまとめると、実のところ、「なんだ、日本語訳のままじゃん」となるのです。

クッキー (Cookie))

「また横文字か～、とりあえず日本語にしよ～。」
「。。。調べんでも分かる。クッキーはクッキーorくっきー！なんの理解のヒントにもならん！！」
初めてクッキーを目にした時は、こんな気持ちでした。

さて、この言葉ですが、実は皆さん見覚えがあると思います。
そうです。サイトを色々見ていると、表示されたりするこんなやつです。
)
冒頭では、名前から何も分からないと書きましたが、由来を調べると結構なヒントだったりします。

諸説あるのですが、

• Cookieは保存するものであり、クッキー=保存食であることからという説
• 毎回違うメッセージを表示することから、おみくじ入りクッキーであるFortune Cookieからという説

なんかがあります。
頭に入れておくと、以降の解説で「なるほろ～」となる瞬間があるかと思います。

現実世界に置き換えてみましょう。
スマートフォンの契約に、窓口へ行った時を想像してください。

実際には、初めの窓口からではなく、機械で受付番号を発行すると思いますが、
シンプルにするために、１つ目の窓口で受付した際に「個人情報と対応内容が書かれた札」（以降、識別札）を受け取るとします。

女子高生がやってきました。
必需品である、スマートフォンが壊れてしまったようです。
１番窓口の受付の方は、識別札を渡しています。
（受付は、お客さんが識別札を渡してこないので、初回の対応だなとわかります。）

次に、男性が新しいiPhoneが発売されたというので、機種変更にやってきました。
１番窓口の受付の方は、こちらへも識別札を渡しています。

先に来ていた女子高生は、２番窓口へ呼ばれ、１番窓口で渡された識別札を渡します。
受付の方は、識別札を見て、お名前や、どういった内容で来店されたかがわかります。

図にはありませんが、女子高生の内容の方が、後から来た男性より時間がかかりそうで、
順番を前後させて男性を先に呼んだとします。
そのケースでも、男性が１番窓口で渡された識別札を渡せば、それに応じた対応を行ってくれるでしょう。

実は、ここで登場した識別札のような考えが、Cookieにあたります。

どんなものなのかがわかったら、「どう使われてるの？」が気になりますね。

一般的な例として、HTTPを挙げます。
HTTPはステートレスなプロトコルなので、そのままでは次の窓口へ行っても、
「どういった内容でしょうか？」
と言われてしまうのです。

そこで、HTTPにCookieを入れる事にしました。
携帯ショップでの識別札同様、初回のリクエストへのレスポンスにCookieを入れます。
２回目以降では、クライアントは１回目で発行されたCookieをリクエストに入れます。
そうすることで、サーバは前回の状態を把握することができます。

「おー、便利ぃ！！」と思うのですが、実は結構問題があります。
全てではないですが、下記のようなものです。

• 第三者に盗聴される可能性。（パスワードなんかを書いてたらまずいですね。。。）
• 盗聴された情報を悪用され、攻撃を受ける可能性。
• ユーザー側の設定でCookieを無効にされてしまうことで、ウェブサイトやアプリが正常に機能しない可能性。

携帯ショップの例の時点で、違和感があったと思います。
対応内容はまだしも、個人情報が書かれた札を第三者から見られるかもしれない状態で持っていたくはないですよね。

この問題を解消するために、セッションがあります。
今回取り扱いませんが、イメージだけさっくりとお伝えしたいと思います。

個人情報、対応内容の書かれた識別札から、数字だけ書いてある番号札に変えます。
そして、受付側で、番号と氏名、対応内容を記録しておきます。

自然であり、実際の携帯ショップなんかもこういった形式だと思います。
（久しく行っていないので、今は違っているかも…）

Cookieは便利だけれど、使い所や相応の対策を考えなければ痛い目を見るよ。
ということを頭に入れておいてください。

さいごに

初めに、ここまで読んでいただき、ありがとうございました！

わかりやすいように工夫できているところもあれば、きっとより良くできるポイントもあることでしょう。
また、気をつけてはいますが、誤解を生むような表現、間違った情報もあるかもしれません。
そのようなものがあれば、ぜひコメント等々でご指摘いただけると幸いです！

また、この記事が少しでもお役に立っていればとても嬉しいです。
これからも、少しずつですが工夫された、わかりやすい表現で記事を書けるよう努めていきたいと思います！

1. 「プロトコル　一覧」などで検索してもらうと、簡単に見つかります。
   ただし、解説で取り上げていませんが、「層」という概念があり、少々混乱するかもしれません。
   ここで取り上げたプロトコルは、アプリケーション層のものになります。 ↩

2. ここでは、192.168.XXX.XXX のような、3桁の0~255の数字が"."で区切られてるもので、郵便番号みたいなもの、くらいの認識で大丈夫です。 ↩

3. 例えば、https://www.google.co.jp/のwww.google.co.jpがドメインにあたります。郵便番号に対して、「〇〇県◇◇市△△町」みたいなものです。 ↩

4. 「え？HTTPよりHTTPSを見かけるけど…」と思ったあなた、そうですよね。
   これらの違いは、通信が暗号化されているかいないかの違いです。
   暗号化されているとは、仮に盗み見られてもそれがどのような内容なのかわからない、ということですね。 ↩