SQL Serverがクライアントリクエストを処理するまでの長いみちのり
SQL Serverはサーバーアプリケーションですから、ユーザーがSQL Serverを利用するには、まずSQL Serverに接続します。SQL Serverへの接続が成功したあとは、クエリを発行し結果を取得します。たったそれだけのことですが、SQL Serverや、SQL Serverへ接続するためのモジュールの内部ではさまざまなことが行われています。「SQL Serverに接続する」というアクションだけみても、深堀すると様々なプロセスがあることに気が付きます。
たとえば、SQL Serverへ接続するため、クライアントはまずSQL Serverがどのようなプロトコルでリクエストを待ち受けているのか問い合わせなければなりません。SQL Server Resolution Protocol(以降SSRP)というプロトコルでSQL Server Browserサービスへ問い合わせるわけです。
このように、SQL Serverが通常どのようなプロセスを経てクライアントリクエストを処理し、結果を返しているのか、「接続編」と「リクエスト処理編」の2回に分け、みなさんが普段あまり意識していない部分を少し掘り下げた形で見ていきたいと思います。今回は「接続編」です。
SQL Serverへの接続
SQL Serverはクライアントとの通信をTabular Data Stream Protocol (以降TDS)というプロトコルで行います。WebサーバーがHTTPというアプリケーション層のプロトコルでクライアントリクエストを処理するように、SQL ServerもTDSというプロトロルでクライアントと通信します。SQL ServerはTDSプロトコルを実装しているサーバー アプリケーションなのです。
TDSはマイクロソフトが定義しているオープンプロトコルで、仕様が公開されています。TDSはアプリケーション層のプロトコルですが、HTTPプロトコルと異なり、トランスポート層のプロトコルで接続が確立しただけではリクエストを送信することができません。リクエストを送信する前に、別途TDSレベルでのログイン処理が必要になります。TDSレベルでのログインが成功して、はじめてクライアントはクライアント リクエストを発行できる状態になるのです。
たとえば、以下のような.NET FrameworkのコードでSQL Serverに接続が成功した場合(Openメソッドが成功した場合)、TDSレベルでログインが成功したことを意味します。
SqlConnection conn = new SqlConnection(“My Connection string”); conn.Open();
整理すると、SQL Serverの接続を確立するということは、以下のような手順を経ているということになります。
1. SQL Serverとの物理接続*を確立
2. TDSレベルのログイン処理
*ここでは便宜的に、「物理接続」をアプリケーション層より下位の通信プロトコルによる接続のことを指すこととします。
各処理を少し掘り下げて、具体的どのようなことが行われているかを見ていきましょう。