TCP/IPのアプリケーション層は、OSI参照モデルの三つの層がまとまったもの(1)。
用途に応じて作成され、必要に応じて、一つ下位のトランスポート層を利用する。
DNS (name server) :
Domain NameをKeyとした分散D.B. Service。一番利用されるのは、Domain Nameから、IP Addressを答えること( Aレコート)であるが、同様にe-mailのDomain Nameから、その宛先のe-mail serviceを行っているServerを調べる( MXレコード)ことにも利用されている。
また、IP AddressからDomain Nameを求めるサービス(逆引と呼ぶ。PTRレコード)も行っている(2)。
問い合わせに応答するというサービスなので、原則としてはUDPで十分であるが、信頼性を確保するために、冗長度を高めると共に、DNSを利用するアプリケーションが、信頼性を保守する。
ftp (Control): Networkを利用してfileをやり取りするためのプロトコル。現在、httpにその地位を奪われつつあるが、未だに、その設計の効率のよさから、ftpも利用されている。
ただし、効率を重視するために、Control通信をTCPで、Data通信をUDPで行うようになっており、複数のPortを併用することが特徴的。このためにFireWall Ruleの作成時悩みの種となる。
tftp: LAN専用。限られた環境(6)で、限られたファイルを、特定な状況(7)で、単にFile転送するだけのプロトコル。
CISCO Routerが、boot時に、IOS等をtftpで取り出したりする。
smtp (e-mail送信、転送): MTA ( e-mailの配送を行うプログラム)が、e-mailをやり取りするために利用するプロトコル。
E-mailを作成したり、読んだりする仕事は、MUA ( Userにe-mailの読み書き手段を提供する)が行い、送信の場合は、MUAからMTAへsmtpを利用して、転送される。e-mailを受けたMTA (いわゆるMail Server )は、更に、必要に応じて、他のMTAに対し、smtpで通信を行う。
POP (e-mail受信) : MTAが受信したe-mailをUserが読むためには、smtp以外の方法で、入手する必要がある(8)。それがPOP。
MUAは、POP Server (9)と通信して、認証を行い、必要なe-mailを受取、Userに提示する。
元々は、遠距離の計算資源の利用のためのアプリケーションだったが、データをそのままやりとりするので、Secutiry上の観点から、その目的で利用することは少い。
むしろ、別の目的( TCPを用いたプロトコルの確認)に利用されることが多くなってきた。
元々が単純な設計なので、解りやすいが、効率が大変悪い。再設計が望まれているが、既に普及しすぎているために、難しいのが難点。
現在は、単なるWeb Dataでなく、(FireWallを越て通信するための..)様々な通信手段の中間トランスポート層としても利用されるようになってきている。
POP Serverは、(smtpを利用して受信を行うために..) MTAを動かすが、MTAは、単にMailを受け取り、DISK ( Spoolと呼ぶ)に保存するだけ。
要求をうけると、Spoolから、e-mailとりだし、Userに送るのがPop Serverの仕事。
Client/Server Modelで、通信を行うためには、ClientがServerのPort Number (と、もちろん、IP Address )を知らなければ( TCP/UDPで.. )通信を開始することができない。
そこで、Service毎に典型的なPort Number ( 1023以下(10))を定義(11)し、特に、指定がなければ(12)、そのServiceには、そのPort Numberを利用するように設計されている。
プロトコル | UDP/TCP | Port Number |
---|---|---|
ftp-data | UDP | 20 |
ftp | TCP | 21 |
ssh | TCP | 22 |
telnet | TCP | 23 |
smtp | TCP | 25 |
DNS | UDP | 53 |
tftp | TCP | 69 |
http | TCP | 80 |
pop-3 | TCP | 110 |
snmp | UDP | 161 |
https | TCP | 443 |
この制限があるのは、unixでは、1023以下のPortを利用するには、Root権限が必要だったということからきている。
Server Processは、悪用を防ぐためにRootにしか、利用できないように工夫されていたわけだ。
したがって、1023のPortで動いているServerは、管理されているとみなすことができるので、重要なServiceは、1023以下で動かすことが推奨されたわけだ。
しかし、他のOSには、そのような制約がなく、1023以下だから安全が保証されているわけでばなくなっているし、また、逆に、Server Processを経由して、Attackが行われるので、むしろ、root権限でない状態が望ましくなりつつあり、この制約は意味を失いつつある。
どのServiceにどのPort Numberを利用するかは、中央管理されており、現在は、ICANNが行っている。
割当られたPort NumberのListは、RFCの形で提供されており、unix OSなどでは、/etc/servicesに、その一部が記載され、利用されている。
Clientからのrequestを受け、それを調べて回答を返す。
requestに対応する回答を知っているかどうかを確認する。
しっていれば、それを返す。
Name Serverは、Clientに替わって、他のName Serverに問い合わせを行うので、Clinetは、どのName Serverに問合せても、同じ結果を得ることができる(14)。
普通にName Serverと言えば、両方の機能を提供することを想定しているが、前者の機能だけのName Serverも多々ある。