これまでの記事で、通信を理解するための重要概念の周りをウロウロしてきました。
実際のWebではこの通信の仕組みをどのように活用しているのか、そろそろ手を動かしながら理解を深めていきたい頃です。
しかし、その前に、あともう１つだけ押さえておきたいモデルがありました。
それがクライアントサーバーモデルです。
今回の記事では、このシンプルなモデルを学習したいと思います。
モデルの復習
以前の記事でモデルとは
「目的に合わせて現実世界を切り取り、単純化した形で表現したもの」だと学びました。(https://qiita.com/iamgami/items/045f81c05334b6696ee3#そもそもモデルとは)
モデル化のメリットとは、複雑な事象の理解を助けてくれることでした。ネットワーク通信の仕組みは手に取ることもできず非常に複雑なので「〇〇モデル」が頻出するのは必然なのかもしれません。
クライアントサーバーモデルとは
クライアントサーバーモデルとは、コンピュータネットワーク上で行われる通信を
「お願いする役」と「応える役」という２つの役割に分担するモデルです。
お願いする役はクライアントと呼びます。
応える役はサーバーと呼びます。
代表的なクライアントの具体例は、SafariやChromeなどのウェブブラウザです。
サーバーの具体例を上げるにはまだまだ学習が必要ですが、ひとまず
世界中にある処理速度の高いコンピューター としておきます。
図書館を例に、クライアントとサーバーのやり取りをイメージしてみたいと思います。
図書館で考えるクライアントサーバーモデル
図書館におけるクライアントは、利用者にあたります。利用者は司書さんに向かって様々なお願いをします。
- 「会員カードを作りたいです」
- 「この本を貸してください」
- 「本を予約させてください」
- 「貸し出しを延長させてください」
- 「リファレンスを手伝ってください」
これらの要求に1つずつ応じて図書館サービスを提供してくださるのが、図書館司書さんです。司書さんがサーバーにあたります。
２種類のメッセージのやり取りを行う
お願いの仕方とその返答にはバリエーションがあるものの、これらを整理すると以下の２つのメッセージのやり取りに回収できます。
- 「リクエスト(要求)」
- 「レスポンス（応答）」
ネットワーク通信も、図書館で行われる会話と同様に
- クライアントによる「リクエスト」
- サーバーからの「レスポンス」
この２つのメッセージを送り合って成り立っている、と見ることができるようです。
図書館の利用者が受けたいサービスに合わせてお願いの仕方を変えるように、通信リクエストにおいても受けたいサービスごとにお願いの種類があり、それに対するレスポンスにもバリエーションがあります。
そんなクライアントサーバーモデルを、自身のPCで実装できることを知りました。
PythonとFlaskで数行のコードを書くことでリクエストとレスポンスの会話を実行できるらしいのです。
それは私にとって、予想外のことでした。
サーバーと聞いて真っ先に浮かぶのは、あの黒い箱だったからです。
固定観念「サーバー＝黒い箱」ではない
私がITを学び始めてから教わったサーバーとは、黒い箱でした。
Linuxを学び始めてすぐに、サーバーOSという言葉と共に黒い箱がズラリと並んだ無機質な部屋の画像を目にしました。
サーバーというと、何か特別なマシンを想像していました。
ITパスポートの参考書が、私の疑問に答えてくれました。
「普通のパソコンをサーバにすることも、超高性能のコンピュータをクライアントにすることもできます。でも、一般的には処理能力が高く、故障対策などを施したものをサーバにしますね」
引用 : 『ITパスポート合格教本』
処理能力の高さから黒い箱の形をしたコンピューターがサーバーとして使われるのが一般的なだけで、実際には、サーバーという機械があるわけではありませんでした。
サーバーはクライアントにサービスを提供する
文脈によっては、私が想像した黒い箱(筐体というらしい)を含めたハードウェアのコンピューターを指してサーバーと呼ぶ場合もあると思います。しかし、今回扱っているクライアントサーバーモデルにおいては、
サーバー＝「サービスを提供する機能を持ったプログラム」
と捉えて良いようです。
私がサーバーと聞いてイメージした黒い箱も、中身はコンピューターであり、さらにそのコンピューターの中ではプログラムが実行されていることを考えると、少しずつ理解が追いついてきました。
サーバーの実態は、クライアントからのお願いに応えてくれるプログラムです。
さらに、サーバーはそれ単体で動作することはなく、リクエストがあって初めて処理を開始するという特徴があるそうです。(『サーバーの基本第２版』)
サーバー＝黒い箱という認識を改めようと思います。
クライアントは、サービスを要求し描画する
クライアントも同様にプログラムです。クライアントという機械が存在するわけではありません。
ウェブの世界のクライアントは、その形態に関わらず以下の２点の特徴があります。
- サービスを要求する
- その結果をユーザーにわかる形で表示する機能を持つ
サーバーは作れる
ようやく、自分で書いたプログラムがサーバーになれる理由がわかってきました。
リクエストとレスポンスのやり取りが実現できるのであれば、自分が書いたプログラムをサーバーにすることもできるようです。
「サーバーを作ってください」と言われて、黒い箱から作る必要はなかったのです。
まずはたった数行のコードからwebサーバーを体感できると知りました。(APIサーバーと呼ぶようです。)Flaskを始めとしたウェブアプリケーションフレームワークのパワーを感じました。裏にどんな仕組みがあるのか気になるところです。
NginxやApacheというサーバソフトウェアをインストールすることによっても、サーバーを作ることができるそうです。
クライアントはウェブブラウザからモバイルアプリまで何でも可能で、サーバーは仮想マシン、コンテナ、サーバーレス機能などがある。
引用 : Akamai クライアント／サーバー・モデルの紹介(https://www.linode.com/ja/blog/cloud-computing/client-server-model-introduction/)
とあるように、クライアントサーバーモデルは、形態や規模に関わらず、通信の役割を２種類に分けて理解するためのモデルのようです。
今日のまとめ
クライアントサーバーモデルとは、
- コンピュータネットワークの通信を、お願いする役・応える役の２つの役割に分担したモデル
- リクエストとレスポンスによって通信が成立している
Qiitaを始めてから、プロトコルの概要、TCP/IPモデル、URL、クライアントサーバーモデルを頭に描けるところまできました。Flaskの力を借りながら、手を動かしてこれらの知識の理解を深めていきたいと思います。
追伸：シンプルこそ強力なのかもしれない
モデルはわかりやすさを提供してくれる一方、抽象化の過程で多くの情報を切り捨ててしまいます。クライアンドサーバーモデルだけを見ていると、通信を理解する上で重要な概念を意識することは難しいです。
- DNSによる名前解決
- IPアドレス
- ポート番号
- ・・・
TCP/IPの下層の技術も正直感じ取りにくくなっています。
これは、図書館の本の貸し出しの裏側が見えにくい現象と同じだと思いました。
- 日本十進分類表の仕組みがわからなくても、本のタイトルさえわかれば本を借りることはできる
- 本には一冊ごとにIDが与えられているはずだが、意識せず借りることができる
- 本の破損があれば修繕してくださっている
- 予約した本が遠くの図書館にあった場合、近隣の図書館や県外から車で運んできてくれる。利用者が近隣の図書館の住所を知っている必要はない(図書館ネットワークにおけるネットワーク層や物理層と言えそうです)
クライアントサーバーモデルを見た時、あまりにもシンプルに感じました。人の会話に例えることができて、身近に感じたからだと思います。そのため、TCP/IPモデルのときのように立ち止まることをせず、スルーしてしまいそうでした。
しかし、今後クラウドを学ぶにしても基本となる視点を提供してくれるのが、このクライアントサーバーモデルのようです。
Akamaiのサイトにおいては、このモデルがクラウド・コンピューティングの基礎である、という記載がありました。(私は最近、CDN(Contents Delivery Network)について学習したのですが、そのCDNを提供しているプロバイダの１つがAkamaiという会社のようです。)
「オンプレミスがわかっていなければクラウドは理解できない」と聞いたことがあります。オンプレミスどころか、localhostでの接続にドキドキしているわけですが、今日も一歩ずつ進んでいきます。
参考資料
『ITパスポート合格教本』岡島裕史 著
この一冊で全部わかるサーバーの基本 第2版 きはし まさひろ 著