サーバによるコンテンツ処理の仕組み
2019 年 2 月 15 日 Emil Hozan 著
コンピュータの能力はほとんど無限とも思えるほどであり、デジタル情報を送受信し、定義された多数のプロトコルを使ってコンテンツを処理し、人間よりはるかに高速にアルゴリズムを計算し、さらには、どれほど長時間であってもエンターテイメントを提供できます。コンピュータの極めて一般的な用途の 1 つとして、コンテンツを処理してユーザに提供する、クライアント／サーバモデルと呼ばれる技術的概念があります。日常生活の言葉に置き換えると、消費者（すなわちクライアント）が企業（すなわちサーバ）に行って（すなわち接続を要求し）、そこにあるコンテンツを見せてもらう行動に例えることができます。つまり、サーバがリソースやコンテンツをホスティングし、要求側のクライアントにそれを提供します。
クライアントとサーバの通信には、プロトコルと呼ばれる、事前に定義された通信方法が使用されます。今日使用されている代表的なプロトコルの 1 つに、誰もが知っている、インターネットで使用される HTTP プロトコルがあります。技術的な詳細は省略しますが、これ以外の我々の生活に欠かすことのできないプロトコルとして、次のようなものがあります。
- TCP（厳密には TCP/IP スイート） – コンピュータシステム（IP アドレスによって識別されます）間での信頼できる方法（TCP）での通信を可能にします。
- DHCP – ネットワーク管理者によるユーザへの手動での IP アドレスの割り当てが容易になります。
- DNS – これによって、識別子（すなわち、お気に入りの Web サイトの複数の IP アドレス）を記憶する必要がなくなります。
- NTP – 正確な時間調整を可能にします。
- ARP – ローカルネットワークで MAC と IP アドレスを照合します。
これ以外の一般的なネットワーキングプロトコルと上記のプロトコルの詳細については、こちらを参照してください。
この記事の説明は、クライアント／サーバアーキテクチャモデルに基づくものであり、このモデルに基づく考え方について説明しますが、他のアーキテクチャにも応用できます。つまり、ネットワーク接続された複数のホスト間で発生するネットワーク通信はいずれも、クライアント／サーバアーキテクチャとほぼ同じ方法で処理されます。
サーバによるサービスの処理
ある企業が特定のコンテンツを自社のユーザに提供したいと考えたとします。その手段として、HTTP プロトコルを使ってアクセスできる、自社のサービスを説明する Web サイトを作成します。また、（必要があれば）FTP プロトコルあるいはそれ以外の何らかのプロトコルを使ってファイルをダウンロードできるようにします。そして、Web アクセスを利用したくない、あるいは、FTP でコンテンツをダウンロードしたいといった、クライアントのさまざまなニーズに応えるためには、同じマシンから複数の方法でコンテンツが配信されるようにします。
処理するサービスが何かをサーバが知るには、到着した接続要求で指定された、要求ポート番号を使用します。接続には、たとえば、送信元 IP アドレス、送信先 IP アドレス、送信元ポート、送信先ポート、使用するプロトコルなどが含まれます。サーバがポート経由で接続要求を受け取った場合、そのサーバシステム（物理ハードウェア）にはサーバソフトウェアが存在しているはずであり、そこで、利用可能なソケットがポートにバインドされています。たとえば、一般的には、80 は HTTP のポート、443 は HTTPS のポート、21 は FTP のポートです。接続が確立されると（すなわち、カーネルがそのポートでリスンするソフトウェアに要求を送信すると）、サーバはその要求を内部でオフロードして、同じポートで次に到着する接続要求を処理できるようにします。StackOverflow のこの記事は、かなり技術的ではありますが、この処理がどのように進行するかをわかりやすく説明しています。
構成されているサーバソフトウェア（Web サーバまたは FTP サーバ）に応じて、対応するそのソフトウェアが以降の通信の処理方法を決定します。プロトコルごとに対応する RFC 番号が存在し、仕様が規定されています。RFC（Request for Comments）は、それぞれのプロトコルが接続クライアント間のどのような通信を許可するかを詳しく規定する標準規格です。ソフトウェアが実行する動作を識別する際に使用する、特別なキーワードがたくさんあります。たとえば、HTTP には、特定のホストのリソースを問い合わせる、GET というキーワードがあります。
ところで、コンピュータには、65,535 もの TCP ポート、65,535 もの UDP ポートがあります。この数を考慮すれば、サーバは TCP または UDP を使ってさまざまな異なるサービスを処理できることがわかります。許可されている各サービスがシステムの利用可能なリソース（RAM、CPU、ストレージの使用率）のプールを共有することになるため、すべてを 1 つのコンピュータシステムでホスティングするのは、おそらく賢明な方法ではありません。また、サーバコンテンツに同時にアクセスするクライアントの数も考慮する必要があります。ただし、個人でテスト用のサーバをセットアップするのであれば、おそらく、こういった点を考慮する必要はまったくないでしょう。事実、私の自宅にもマシンが 1 台あって、Web サーバ兼 FTP サーバとして使用しており、それ以外の用途にも利用しています。
クライアントとサーバの通信方法
上記のクライアントからの要求（送信元 IP、送信先 IP、送信元ポート、送信先ポート、プロトコルの 5 つの情報）について、もう少し詳しくみてみましょう。
クライアントがサーバに対して HTTPS 通信の要求を送信する場合、クライアントはシステムが生成した送信元ポート番号を使って、ローカルのルータ経由でサーバの目的とするポート、この場合は、HTTPS 通信のポート 443 に要求を送信します。クライアントのホストそのものの送信元ポートはランダムであるため、ルータが追跡に使用するランダムな送信元ポートを生成し、要求が対応するサーバへと渡されます。そのサーバは、トラフィック要求を送信元 IP アドレスの対応する送信元ポート番号に返しますが、この送信元 IP はクライアントが要求を送信したパブリック IP アドレスであり、ルータは、送信元ポートに基づいて、その要求を送信した内部クライアントを識別します。同じネットワークロケーションの複数のクライアントから同じリモートサーバに対する複数の接続が確立された場合、このような方法で、ルータが、戻りのトラフィックの送信先であるクライアントを判断します。
インターネットへと送信されるトラフィックには、通信要求を識別するための一意の IP アドレス、すなわち、パブリックにルーティングできるアドレスが必要です。内部クライアント IP アドレスは、RFC 1918 に基づいて区別され、予約されています。ここで必要になるのが NAT であり、この変換処理によって、パブリックサーバに要求を送信する内部クライアントの IP アドレスがネットワークのルータ／ゲートウェイデバイスによって書き換えられることで、要求をインターネットに送信できるようになります。ゲートウェイデバイスによる複数のクライアントの追跡では、接続テーブルを使用することで、内部クライアントの IP アドレスとそれに対応する送信元ポートを追跡します。戻りのトラフィックは、ネットワークのパブリック IP のゲートウェイデバイスによって生成された送信先ポートに渡され、そこから、ゲートウェイデバイスが、接続テーブルをチェックして、ゲートウェイが生成した送信元ポートに関連付けられているクライアントを調べ、そのクライアントにトラフィックが送り返されます。
まとめ
上記の説明は少し込み入っており、技術的な詳細は実際に複雑ではありますが、処理の概念は単純です。適切なソフトウェアがシステムにインストールされていれば、どのようなコンピュータシステムでもサーバになることができます。このサーバソフトウェアは、システムコールによってハードウェアそのものとやり取りします。簡単に言えば、システムコールとは、基本的には、インストールされているソフトウェアに対してオペレーティングシステムが提供している API（Application Programming Interface）またはライブラリのコールです。ソフトウェアは、このライブラリ、すなわち、OS が提供している、カーネルへと到達し、ハードウェアスタックにアクセスするためのライブラリ、つまり API を使用します。この件の詳細については、参考文献を参照してください。
インターネット接続要求の例をもう 1 つ紹介します。あるローカルネットワークが 10.0.1.0/24 に割り当てられているとします。そのネットワークに対する要求を送信する任意のクライアント（10.0.1.50 とします）には、その要求に対してランダムポート（たとえば、55,087）が割り当てられ、クライアントの IP アドレスと一緒にパケットの形で送信されます。ゲートウェイデバイスが要求を受け付け、インターネットトラフィックに設定されているルールと一致していれば、パケットをその送信元ポートに書き換え（55,087 を 53,798 に変更）、IP アドレスについても、ISP によって物理サイトに割り当てられたパブリック IP アドレス（たとえば、WatchGuard.com の IP アドレス が 54.212.248.139 であると仮定します）に書き換えます。パブリック IP アドレスはルーティング可能であるため、戻りのトラフィックには行き先がわかり、ゲートウェイデバイスによってもう 1 度分析されます。
この記事の内容の説明をさらに詳しく学ぶ際に役立つ参考資料やお奨めの文献を下記に記載しました。技術的な詳細に興味のある方はぜひお読みください。エンドユーザにとっての使いやすさをコンピュータそのものやその内側での実際の処理の複雑さと対比してみる作業は、私にとって、とても魅力的で興味深いことであり、だからこそ、複雑である技術的な詳細をできるだけ平易な言葉でわかりやすく説明できればと常に考えています。
参考資料
Chase, J. 著、「Sockets and Client/Server Communication」、
出典：https://users.cs.duke.edu/~chase/cps196/slides/sockets.pdf
Examcollection.com の寄稿者による
「How do Common Networking Protocols Function」、
出典：https://www.examcollection.com/certification-training/network-plus-how-do-common-networking-protocols-function.html
Mozilla.org の寄稿者による
「What is a web server?」、
出典：https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_web_server