とりあえず、その1の文末でご紹介しましたように、ネットワークの概要やインターネットプロトコル(IP)については、「ネットワーク入門」と「インターネットプロトコルの謎」を読んどいてくださいませ。え?この2つでぐったりしてしまいましたか?う〜ん、そんな方は、慌てず騒がず、ゆっくりとお勉強してくださいませ。
トランスポート層の主なお仕事は、下位のネットワーク層から運ばれてきたデータを目的のアプリケーションへ届けたり、アプリケーションから返されたデータをネットワーク層へ送り届けることです。アプリケーションには、種類ごとにポート番号と呼ばれる番号が割り当てられており、トランスポート層では、このポート番号を頼りに振り分けを行います。郵便配達に例えると、マンションやアパートなどの集合住宅へ配達にきた郵便配達員さんが、各戸の郵便受けへ郵便物を振り分けるような処理です。つまり、大雑把に言うと、IPアドレスは住所、ポート番号が宛名といった感じでしょうか。そして、そのトランスポート層で用いられる代表的なプロトコルがTCPとUDPです。
TCP(Transmission Control Protocol)の役割は、IP層から運ばれてくるデータの信頼性の確認や整列をし、データを上位層へと運びます。以下の表のように、個々のTCPデータにはシーケンス番号が記録されており、番号順に並べたり、欠落している情報があれば再度送信元へ要求するなど、届いたパケットを整える機能を持ち、プロトコル自体で信頼性を確保しています。
0-3 | 4-9 | 10-15 | 16-23 | 24-31 |
---|---|---|---|---|
Source Port(16bit) 送信元ポート番号 | Destination Port(16bit) 宛先ポート番号 | |||
Sequence Number(32bit) シーケンス番号 | ||||
Acknowledgement Number(32bit) 確認応答番号 | ||||
Data offset (4bit) | Reserved (6bit) | Code Bit (6bit) | Window(16bit) ウィンドウサイズ | |
Checksum(16bit) チェックサム | Urgent Pointer(16bit) 緊急ポインタ | |||
Options (24bit) | Padding(8bit) | |||
DATA・・・ |
TCPは、通信を始めるにあたって相手側ホストと確認応答を行うコネクション型のプロトコルです。相手先にSYNパケットと呼ばれる確認パケットを送り、相手からACK及びSYNパケットが返ってきてから、さらにACKを送り返した後通信を始めます。TCPによるコネクション管理の手順は以下のようになります。
パソコンA | パソコンB | ||
1 | 繋いでもいいかなぁ〜? | −SYN−> | |
2 | <−SYN/ACK− | いいよぉ〜、 おらも繋いでいい〜? | |
3 | いいよぉ〜 | −ACK−> | |
4 | <…通信中…> | ||
5 | 切ってもいいかなぁ〜? | −FIN−> | |
6 | <−ACK− | いいよぉ〜 | |
7 | <−FIN− | おらも切っていい〜? | |
8 | ばいばぁ〜い | −ACK−> |
これらコネクション管理で用いられるSYN、ACN、FINなどはフラグと呼ばれ、TCPヘッダのCodeBitに含まれています。
URG | Urgent Flag | このフラグがたっている時(1の時)は、緊急に処理すべきデータが含まれていることをあらわします。 |
ACK | Acknowledgement Flag | 肯定確認応答フラグです。コネクション確立時のSYN時以外はずぅ〜っと1になっています。 |
PSH | Push Flag | このフラグがたっている時は、データをバッファリングせずにすぐ上位層へ渡さないといけないようです。 |
RST | Reset Flag | このフラグがたっている時は、コネクションを強制終了する必要があるみたいです。 |
SYN | Synchronaize Flag | コネクションの確認のときに使われます。 |
FIN | Fin Flag | コネクションの終了のときに使われます。 |
その他、ウィンドウ制御とか輻輳制御とかピギーバックだとかいろいろ機能があるのですが、面倒なのでこの辺で。(^^;
UDP(User Datagram Protocol)は、TCPと違って並べ替えや再要求などを行わず、信頼性は保証されない形式のプロトコルです。信頼性を確保する処理を省いているため、逆に処理効率が良くなります。信頼性を保証する部分は、必要に応じてアプリケーション側で補完する必要があります。たとえば、パケット通信ではひとつのデータが複数のパケットに分割されて送信されることがあります。しかも、すべてのパケットが同じ経路で到達することを保証していませんし、途中で分割したパケットの順番が入れ替わったり部分的に消失したりします。UDPでは、これらについて何ら制御することなく上位層へパケットを転送しますので、必要によりアプリケーション側で必要な制御を行わなくてはいけません。しかし、アプリケーションを利用する上で必要以外の制御をすることが無いため、アプリケーションの種類によっては高効率の通信を行えるようになります。
0-15 | 16-31 |
---|---|
Source Port(16bit) 送信元ポート番号 | Destination Port(16bit) 宛先ポート番号 |
Length(16bit) パケット長 | CheckSum(162bit) チェックサム |
DATA・・・ |
ポートは、同一ホスト内で複数のサーバーを識別するために割り当てられた番号です。ポート番号の概念を使って、ひとつのコンピュータでも複数のアプリケーションを稼動させ、それぞれ個別に通信することを実現させています。ポート番号は、0から65535までの番号があり、大きく分けて0から1023までのWELL KNOWN PORT NUMBERS(良く使われるポート番号)、1024から49151までのREGISTERED PORT NUMBERS(予約済みポート番号)、49152から65535のDYNAMIC AND/OR PRIVATE PORTS(動的/プライベートポート)の3つにわかれています。通常サーバー側で使うのは、WELL KNOWN PORTで、SMTPの25、httpの80、POP3の110など、おなじみの番号も登録されています。また、クライアント側にも受け取るためのポート番号が必要になりますが、それらは通常クライアント側のアプリケーションによって、1024以上で空いているポート番号を探して自動的に割り当てられます。本来ならDYNAMIC AND/OR PRIVATE PORTS使うべきものなのかなぁという気はしますけど、詳しく調べたことはありません。いくつか代表的なTCPポートを以下に示しますが、その他、各ポートの詳細は、ianaのPORT NUMBERSのページをご覧下さい。
ポート番号 | キーワード | 概要 |
---|---|---|
20 | ftp-data | File Transfer [default data] |
21 | ftp | File Transfer [Control] |
23 | telnet | Telnet |
25 | smtp | Simple Mail Transfer |
53 | domain | Domain Name Server |
80 | http | World Wide Web HTTP |
110 | pop3 | Post Office Protocol-Version 3 |
119 | nntp | Network News Transfer Protocol |
ここまでにお話してきた内容だけでは、実際のところ目的となる処理は何も行われません。ネットワークに接続してデータを送受信するのはあくまで手段であって目的ではないからです。ま、それが目的の一部のマニアな方もいらっしゃいますが、一般的には「ホームページ(そこ!笑わないように!)を見たい」とか「電子メールを送受信したい」と言った目的があるはずです。アプリケーション層とは、この目的となる処理を行う層になります。たとえば、インターネットへアクセスしてWebページを見たいとした場合、どのような経路をどのような手順で送受信したかということは、あまり重要ではありませんね。目的としては、あくまでも送られてくるページをみることになります。つまり、このページがほしいといって催促し、ページを探して送り返したり、送られてきたページを表示するのがアプリケーション層のお仕事です。ちなみに、このページを催促したり送られてきたページを見る側をクライアント、ページを送り出す側をサーバと呼びます。
さて、ここまでに出てきた「目的の場所」をあらわすものとしては、IPアドレスしかありませんでした。しかし、すでにインターネットを活用されている方ならご存知かと思いますが、実際にIPアドレスを指定して目的の場所へアクセスすることは非常に稀です。たとえば、うちとこのサイトを見たいときには、通常「http://www.kisnetor.jp/to_tera/ (当時)」と入力していますね。これを見る限りIPアドレスは何処にもありません。しかし、実際にはちゃんとうちとこのページが表示されるはずです。さて、どうしてでしょうか?そこで登場してくるのがDNS(Domain Name System)です。このDNSですが、前述のWebへのアクセスの例で見ますと、アドレスを指定した時点で一番最初に動き出すのはDNSへの問い合わせです。何を問い合わせているかといいますと、「www.kisnet.or.jpのIPアドレスってなんじゃ?」ということになっています。なぜhttp://とか、/to_tera/を問い合わせないのかいいますと、このアドレス形式にはルールがありまして、以下のようになっているからです。
スキーム://ユーザ名:パスワード@ホスト名:ポート番号/目的の場所
この記述方法を一般にはURL(Uniform Resource Locator)といいます。スキームは、アクセスするときの手段といいますか、アプリケーションの種類といいますか、目的の通信方法をあらわすものです。その他、ユーザ名やパスワードは必要であれば指定しますし、サーバーへのログインが必要無ければ無くても問題ありませんし、ポート番号などは、特に指定しなければデフォルトの値になります。httpなら80ですね。この他のスキームには、ftpやmailtoなどがあります。そして、このルールにのっとってDNSで問い合わせるのは、ホスト名の部分です。
そもそもDNSを利用する以前、インターネットの祖であるARPANETでは、hostsファイルと呼ばれるホスト名とIPアドレスの対応表を使って目的のホストを参照していました。hostsファイルは、ネットワークにつながるすべてのホストのホスト名とIPアドレスの対応表を記録したファイルで、かつて一台のコンピュータで管理していました。ネットワークを利用するすべての端末に保存しておく必要がありましたので、その他の端末からは、適宜ダウンロードして使っていました。しかし、規模が拡大するに伴って、随時増減するホストなどに対応することが難しくなり、さらにhostsファイルを管理するコンピュータや回線の負荷も高くなりました。そこで自動化と負荷の分散をするために考えられた世界規模の分散型データベースシステムがDNSです。
.(root) | −+− | com | ||||
+− | net | |||||
+− | jp | −+− | co | |||
+− | ne | |||||
+− | or | −+− | kisnet |
DNSでは、木(Tree)構造と呼ばれるデータベースシステムを構成しています。頂点に「.」であらわされるルートサーバーと呼ばれるネームサーバーが存在し、公共利用可能なcomやorgなどのgTLD(generic Top Level Domain)、各国に割り当てられているjpやtoなどのccTLD(country code Top Level Domain)の2種類のTLD(Top Level Domain)を管理しています。また、個々のTLDのネームサーバーは、セカンドレベルドメインを管理し、最終的に企業などの末端のネームサーバーに行き着きます。このような構造にしておくと、個々のネームサーバーでは、自分の管轄するホスト名のみネームサーバーに登録しておけばよく、自分のネットワーク内のホストを問い合わせるのに、いちいち世界中のサーバーを問い合わせる必要がなくなります。また、不明な場合はルートサーバーへ問い合わせれば、世界中どこのホストのIPアドレスでも見つけ出すことができます。ちなみに、www.kisnet.or.jp.の様な、右端がルートをあらわすピリオドで終わる表記をFQDN(Full Qualified Domain Name)と呼びます。
DNSを使ったホストのIPアドレスの検索は、大きく分けて二段階で行われます。第一段階として、一般のユーザさんの場合、みなさまの使っているプロバイダさんや、会社であれば、企業内のネームサーバーへの問い合わせを行います。通信開始にあたって、IPアドレスを検索するためにリゾルバと呼ばれるDNSクライアントが、自分の利用するネームサーバーに目的のホストのIPアドレスを問い合わせます。目的のホストが同じドメイン内であれば、ネームサーバーは、自分の管理するホストとIPアドレスを記録したゾーンファイルを参照して即座にIPアドレスを返してきます。ということで、最低限、DNSクライアントは自分の利用するネームサーバーをあらかじめ知っていないといけないわけです。
さて、見つからない場合が第二段階です。たとえば、www.kisnet.or.jpを問い合わせたい場合、目的のホストが見つけられなかった自分のネームサーバーは、ルートサーバへwww.kisnet.or.jpのネームサーバーを問い合わせます。すると、ルートサーバーは、jpのネームサーバーの場所を教えてくれますので、次にjpのネームサーバーへ問い合わせます。すると、jpのネームサーバーは、or.jpのネームサーバーを教えてくれます。次に、or.jpのネームサーバーは、kisnet.or.jpのネームサーバーを教えてくれます。このように次々と問い合わせを展開して行き、kisnet.or.jpのネームサーバーを聞いた自分のネームサーバーは、kisnet.or.jpのネームサーバーに問い合わせて、ここでやっとwww.kisnet.or.jpのIPアドレスを教えてもらい、最終的に教えてもらったIPアドレスをクライアントへ通知します。しかし、世界にたった13台しかないルートサーバーを毎回こき使うわけにもいきませんし、いちいちトップダウンで検索するのは効率的ではありませんので、通常、問い合わせた内容は、ネームサーバーが記憶し、一時的にキャッシュとして保存します。記憶する期間はネームサーバーによっていろいろですが、次回同じドメインへの問い合わせを行った場合には、キャッシュの内容から高速に通知を返すことができますし、各レベルのネームサーバーの負担を減らすこともできます。以上のような、ドメイン名に対するIPアドレスの問い合わせは、個々のネームサーバーに記録されているAレコードと呼ばれる情報によって管理されます。また、NSレコードには、上位・下位のネームサーバーが記録されています。DNSには、その他逆引き検索用のPTRレコードや電子メールで用いられるMXレコードなどもあります。MXレコードについては、以下のSMTPで少々触れることにいたしましょう。
☆ダイナミックドメイン☆ 今回、この自宅サーバー構築入門の目的では、自分でネームサーバーを立てることはいたしません。また、オリジナルのIPアドレスやドメイン名の取得もいたしません。そこで登場するのがダイナミックドメインです。前段のwww.kisnet.or.jpを見てみましょう。このドメインの中で、ホスト名はwwwでした。ダイナミックドメインでは、このwwwのホスト名を使って擬似的にドメイン名のように利用してしまう方法です。プロバイダさんに接続したときに割り当ててもらったIPアドレスに対して、ダイナミックドメインのサーバーを通して取得した仮のドメイン名とIPアドレスを対応付けてしまうサービスです。従って、ご利用になるDNSは、ダイナミックドメイン提供業者さんのネームサーバーになります。プロバイダさんに割り当ててもらっているIPアドレスは、定額接続で常時接続しているような環境でも、別途固定IPアドレスを取得していない場合は、一定期間で変えられてしまうことがほとんどです。そこで、ダイナミックドメインのネームサーバーに対して定期的にIPアドレスの変更を通知するのですが、これがまた、キャッシュが利いているうちはすぐには切り替わりません。これがちょっとしたトラブルを発生しかねないことに注意が必要です。 |
http(Hyper Text Transfer Protocol)は、その名のとおり、HTML(Hyper Text Markup Language)によって書かれたハイパーテキスト、つまり皆様良くご存知のWebページを配信する、TCPポート80を利用するプロトコルです。WWW(World Wide Web)によって、インターネットに公開されている情報をWebブラウザを用いて表示することができます。いま表示されているこのページも、WWWによって公開されている情報です。実際には、ページだけでなく画像やファイルのダウンロードなども併せて行えるとても多機能なプロトコルですが、サーバーとクライアントのみで形成される単純なプロトコルでもあります。
さて、ページを読み込むまでを順を追ってみてみましょう。
たとえば、ユーザが「http://www.kisnet.or.jp/index.html」が見たいとブラウザへ命令を下すと、1.最初にDNSクライアントがwww.kisnet.or.jpのホストのIPアドレスを問い合わせます。2.次に、返ってきたIPアドレスに対して、3.Port80へのコネクションの確立を試みます。4.無事コネクションが確立されたら、Webブラウザは「GET http://www.kisnet.or.jp/index.html」のページをくださいとWWWサーバーに対してお願いします。5-7.GET命令を受け取ったWWWサーバーは、望まれているページを探し出し、見つかれば要求されているページを返します。最終的に受け取ったデータをWebブラウザがHTMLに沿ってページを構築して表示します。
webサーバーに対する命令は、GET以外にもヘッドメッセージだけを取得するHEADなど数種類ありますが、これらはASCII文字で表現されています。Telnetクライアントを用いてアクセスすることもできますが、通常TelnetクライアントにはHTMLを解釈する機能がありませんので、テキストだけが表示されます。
Method Definitions | |
---|---|
コマンド | 概要 |
GET | 指定したURIのデータを取得 |
HEAD | ヘッダ情報だけを取得 |
POST | 指定したURIにデータを登録(CGI掲示板への投稿など) |
Additional Request Methods | |
PUT | 指定したURIにデータを保存 |
DELETE | 指定したURIのデータを削除 |
SMTP(Sinple Mail Trasfer Protocol)は、電子メールを転送するためのTCPポート25を利用するプロトコルです。httpより、やや複雑なプロセスを必要としますが、基本的にはASCII文字によるコマンド体系など、大きな違いはありません。
電子メールの転送には、メールアドレスが利用されます。たとえば、私のメールアドレスは「to_tera@kisnet.or.jp(当時)」ですが、これは「名前@住所」で構成されています。しかし、私の利用してるSMTPサーバーは、実際にはpo.kisnet.or.jpです。メールアドレスの住所部には、ホスト名部分である po は記載されていません。そこで登場するのがDNSで登場したMXレコードと呼ばれるものです。MXレコードには、メールアドレスと、配送先のメールサーバーが記載されていて、メールを転送するに先立ってDNSへ問い合わせると、配送先がわかる仕組みになっています。
転送手順は、ドメインの確認と転送の繰り返しです。メールを転送しようとしたクライアントは、クライアントに登録してあるSMTPサーバーのドメインを問い合わせ、転送します。メールを受け取ったSMTPサーバーは、宛先のメールアドレスから転送先のSMTPサーバーを検索します。この際にDNS側で利用されるのがMX(MaileXchange)レコードです。さらに通知されたSMTPサーバー(MXホストと呼びます)のIPアドレスをDNSに問い合わせてからメールを転送します。転送先のSMTPサーバーにメール転送の設定がされている場合は、同様にSMTPサーバーの検索と転送を繰り返します。最終的に受け取ったSMTPサーバーが、個々のメールボックスへメールを保存します。
Method Definitions | |
---|---|
コマンド | 概要 |
HELO <SP> <domain> <CRLF> | 通信の開始要求 |
MAIL <SP> <domain> FROM:<reverse-path> <CRLF> | メール転送の開始と送信元の設定 |
RCPT <SP> <domain> TO:<forward-path> <CRLF> | 宛先の設定 |
DATA <CRLF> | メール本文 |
RSET <CRLF> | リセット |
VRFY <SP> <domain> <string> <CRLF> | 受信者情報の確認 |
EXPN <SP> <domain> <string> <CRLF> | メーリングリストのユーザ情報への展開 |
HELP [<SP> <domain> <string>] <CRLF> | ヘルプ情報の要求 |
NOOP <CRLF> | サーバーの動作確認 |
QUIT <CRLF> | 通信終了 |
電子メールは、SMTPサーバーを見てわかる通り、常時インターネット上に存在しないといけません。転送先が見つからなければ、メールの転送は成立しないからです。このような状況を考慮して、常時接続しているサーバーに、一時的に電子メールを保存しておき、端末側で受信操作をしたときに電子メールを取り出せる仕組みを考え出しました。それがPOP(Post Office Protocol)です。現在一般に広く普及して利用されているのはPOP3(POP version 3)で、TCPポート番号110のプロトコルです。
POP3もASCII文字列によるコマンドと、それに対する応答により通信を行っています。始めに、POP3サーバーのドメイン名からIPアドレスを問い合わせ、POP3サーバーとの通信を確立したあと、POP3サーバーに対してアカウント情報を送り、ログインしてからメールの受信を行います。通常、これらの一連の動作は、SMTPも併せてMUA(Mail User Agent)が自動的に行っています。下記のコマンドは、POPアクセス時に利用されるものですが、次項でお話するように、telnetクライアントなどで実際に試してみることもできます。たとえば、私の場合、インターネット接続環境が56Kモデムだったりして、大きなメールを受け取ると、ウィルスバスターのPOP3スキャン(メール経由のウィルスをチェックしたり削除してくれるソフトです)がメールを溜め込んでいるうちにタイムアウトしちゃったりします。そんなときは、telnetで繋いで「えい!」って消しちゃうこともあります。ははは。内容くらい見れ(^^ゞ。
The AUTHORIZATION State | |
---|---|
コマンド | 概要 |
QUIT | 通信終了(DELEメッセージがある場合、実行して終了) |
The TRANSACTION State | |
コマンド | 概要 |
STAT | 着信メールの件数とサイズを表示 |
LIST [msg] | 着信しているメールの番号とサイズを表示 |
RETR msg | 指定したメールメッセージの受信 |
DELE msg | 指定したメールメッセージの削除 |
NOOP | POPサーバーの動作確認 |
RSET | DELEコマンドの取り消し |
The UPDATE State | |
コマンド | 概要 |
QUIT | DELEメッセージがある場合、実行して終了 |
Optional POP3 Commands | |
コマンド | 概要 |
TOP msg n | メールの先頭からn行目までを取得 |
UIDL [msg] | メールのユニークID情報の取得 |
USER [user] | ユーザ名の送信 |
PASS [Password] | パスワードの送信 |
APOP name digest | APOP認証 |
プロトコルのお話って難しいですね。このアプリケーション層までで、ネットワーク入門、IPの謎と併せて、一通りのプロトコルの説明が終わりました。実は、あれでもすべてのコマンドではありません。ま、必要であれば、インターネットを徘徊すると、こと細かく解説しているサイトもありますので、探してみてください。で、ここまでに書いた各アプリケーション層のプロトコルで利用されるコマンドは、実際に試してみることができます。ここでは、実際にちょっとしたコマンドを試して見ましょう。
WindowsNT系 | Windows9X系 |
---|---|
1.telnet起動 2.open www.goo.ne.jp 80[enter] 3.head /[enter][enter] 4.ヘッダー情報が表示されます。 | 1.telnet起動 2.[接続] - [リモートシステム] 3.ホスト名[www.goo.ne.jp]、ポート[80] 4.head /[enter][enter] |
以上のようなコマンドを発行しますと、相手先のWebサーバーが発行したヘッダ情報が表示されます(表示しないサーバーもあります)。今回のwww.goo.ne.jpを例にとりますと、このサーバーはIIS4.0ですから、OSはWindowsNT Serverであることがわかります。
●2001.11.26 現在のwww.goo.ne.jpのヘッダ HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Mon, 26 Nov 2001 10:39:20 GMT Connection: Keep-Alive Content-Length: 46082 Content-Type: text/html Set-Cookie: inkid=n92b0ATOgACIgYwRAwjtFCAAiBDj; expires=Tue, 30-Nov-2010 15:00:0 0 GMT; domain=goo.ne.jp; path=/ Cache-control: private |
実は、インターネットの世界では、このように簡単にさまざまな情報を手に入れることができます。たとえば、前述のように利用しているアプリケーションやバージョンなどが知られてしまうと、それらに脆弱性が報告されたとき、すぐに不正アクセスの対象となってしまうことが考えられます。しかも、一度インターネットへ繋いだからには、サーバーであるなしにかかわらず、実はさまざまな手法にてみなさまのパソコンなどを調査したり不正利用や破壊行為を行う人もいます。次回は、これら不正アクセスの横行する世界で、いかに安全にインターネットを利用していくか、どのような攻撃手法があるのかを主体に、セキュリティについてお話する予定にしています。それでは次回も、またいっしょにおべんきょいたしましょお〜。