ソケット接続を実現する第4層

 皆さんは既にルーティングについて学んでいると思います。したがって、ルーティングによってパケットがどのように宛先コンピュータにまで辿り着くことができるか理解しています。宛先までパケットを届けることができるのだからインターネットの通信はこれで完成だと思った人がいるかもしれませんが、そうは簡単にはいきません。

 プロトコルスイートについて既に説明しましたが、そこではOSIの7階層モデルと、 TCP/IPの5階層のプロトコルスイートについて学びました。ここではTCP/IPのプロトコルスイートに従って話を進めます。ルーティングではIPパケットのヘッダに記述された宛先IPアドレスに従って経路を制御します。従って送信元のコンピュータの第3層のIP(ipd=IPデーモン)と宛先コンピュータの第3層のIPの間の通信ということになります。実は、この通信で経由するルータにも第3層のIPが稼働していて、そのルータ上のIPの仲立ちによって宛先まで到達できることになっています。
 パケットはIPによって送信元のコンピュータから、宛先のコンピュータまで運ばれます。パケットはインターネット通信においては宅配便のトラックのようなものですので、中身のデータを運んでいます。パケットの中身であるデータはセグメントとか、データグラムなどと呼ばれています。これは第4層のトランスポート層のプロトコルが扱うデータのかたまりです。第4層のプロトコルがTCPの場合は、セグメントいい、UDPの場合はデータグラムと呼ぶことが多いようです。

※このあたりの呼び方はちょっと曖昧なところがあります。もともとパケットいう呼び方はOSI7階層モデルでの呼び方ですが、かなり一般的に利用されています。TCP/IPではデータグラムと呼んでいます。そして、UDPではIPとほとんど同じ事しか行われていないという意味で、データグラムという用語が利用されているようです。本書では、第3層のデータのかたまりはIPパケット、第4層がUDPの場合はデータグラムという用語を使用しています。



1 ソケット接続

 実際にインターネットの通信を行っているのは第5層のアプリケーション層のサービスです。ここでは電子メールやWebなどがサービスの提供をしています。サービスはクライアントサーバシステムという方式に従っている場合が一般的です。Webを例にとると、Webクライアント(通常はWebブラウザ)からWebサーバにアクセスしてドキュメントを閲覧します。つまり、クライアントからアクティブに相手を指定して接続要求を行います。接続相手(Webサーバ)は、特定のIPアドレスを持つコンピュータ上の特定のアプリケーションということになります。この特定のアプリケーションはポート番号という識別子を持っています。従って、IPアドレスとポート番号を指定すると、宛先のサーバまで辿り着くことができます。IPアドレスとポート番号の組み合わせは通常「ソケット」と呼ばれます。従って、IPアドレスとポート番号の組を使って確立した接続は、ソケット接続などと呼ばれています。

 なぜポート番号が必要なのかというと第5層では多くのアプリケーションサービスが稼働しているからです。たくさん稼働しているサービスから特定のサービスを選択しなくてはなりません。このポート番号は公開しておく必要あります。公開していないとそのポート番号を特別に知っているクライアントしかサービスの提供を受けられません。

 主なサービスのポート番は次の通りです。

ポート番号 プロトコル名 プロトコルの説明 TCP/UDP
22 SSH Secure Shell:Remote Login Protocol TCP/UDP
23 Telnet リモートログイン TCP/UDP
25 SMTP Simple Mail Transfer Protocol(電子メール) TCP/UDP
53 DNS Domain Name System(ドメイン名システム) TCP/UDP
80 HTTP Hypertext Transfer Protocol:WebブラウザとWebサーバの間の通信の規定 TCP/UDP
110 POP3 Post Office Protocol version3 TCP/UDP
143 IMAP Internet Message Access Protocol TCP
161 SNMP Simple Network Management Protocol:ネットワーク管理用のプロトコル UDP
179 BGP Border Gateway Protocol TCP
443 HTTPS HTTP Protocol over TLS/SSL(セキュアなHTTP) TCP/UDP
520 RIP Routing Information Protocol UDP

 セグメントヘッダのポート番号フィールドは16ビットの長さがありますので65,536(=256×256)個定義することができます。ポート番号は大きく3つの種類に分けることができます。それはIANA(Internet Assigned Numbers Authority)が管理しているいわゆるウエルノウン(Well Known)と呼ばれるポート番号と、IANAが利便性を考慮して公開している登録済み(Registered)ポート番号とそれ以外に自由に利用できるポート番号です。

種類 範囲 内容
ウエルノウンポート番号 0~1023 一般的なポート番号
登録済みポート番号 1024~49151 登録されたポート番号
動的(Dynamic)AND/ORプライベート(Private)ポート番号 49152~65535 自由に使用できるポート番号

 クライアントに割り当てる番号などユーザが自由に利用できる番号は49152番以降が使われます。クライアントに割り当てる番号は通常エフェメラル(ephemeral、短命な)ポート番号などと呼ばれています。

 Powershellを使うとポート番号を確認することができます。

 ポート番号はservicesという名前のテキストファイルに記述されています。servicesというファイルはWindowsの場合は、C:\Windows\System32\drivers\etc\servicesにあります。64ビットOSの場合はsystem32はsystem64となります。





2 プロトコルの階層化

 先ほどインターネットの通信をしているのはアプリケーション層のプロトコル(に従った実装=プログラム)であるという話をしました。アプリケーションプログラム同士が直接通信をすれば事は簡単に済みそうですが、こうしようとすると、アプリケーションプログラムを開発する人は、物理回線や、IPのこと、ルーティングの事、エラー処理の事など全部を知らなくてはなりません。そのうえで、アプリケーションのことも熟知している必要あります。簡単なネットワークならこれでもいいかもしれませんが、現在のような複雑な仕組みになっているインターネットで物理層から、データリンク層、ネットワーク層のことからアプリケーションのことまでことごとく知らなくてはならないということになると誰も手を出せないことになります。やはり餅は餅屋にということで、それぞれの人が自分に得意な分野を持ち寄ってネットワークサービスを実現することになりました。それを実現する方法が、プロトコルを階層化することです。

 プロトコルを階層化すると、上の層に配置されたプロトコルは直下の層のプロトコルに仕事を頼む必要があります。この方法がどうなっているのかを次に見ていきます。

 トランスポート層にはいくつかのプロトコルが規定されていますが、その代表的なものがTCPとUDPです。アプリケーション層のWebクライアント(Webブラウザ)が遠隔地にあるWebサーバと通信をしようとする場合を例にして簡単に説明します。

 基本はWebクライアントとWebサーバの通信です。WebクライアントとWebサーバがやり取りする時にはお互いにデータを交換するのですが、アプリケーション層プログラムがやり取りするデータのかたまりは通常はメッセージと呼ばれています。このメッセージはお互いに直接交換することはできません。先ほど説明したように、プロトコルは階層化されていて、実際にネットワークとつながっているのは物理層だけだからです。

メッセージを直接渡すことができない

 アプリケーション層のプログラムは相手側のプログラムにメッセージを渡すときに、物理層に依頼することはできません。アプリケーション層のプログラムは、下の層のトランスポート層のプログラムに仕事を依頼します。ある人に遠くの人への言伝を頼むときにはいろいろのことを説明する必要があります。何も言わずにただメッセージだけを託しても多分うまくいきません。インターネットの通信でもこれは同じです。言伝をするときに必要な制御条件等はヘッダと呼ばれるフィールドに記述します。

 トランスポート層のプロトコルに対してメッセージの送信を依頼する時には相手をポート番号(宛先ポート番号)で指定しなくてはなりません。それから、自分が誰かも示す必要があります。これもポート番号(送信元ポート番号)で指定します。送信元のポート番号はOSがその時点で使われていないポート番号を指定します。それ以外にも様々な制御情報が必要ですが、これはトランスポート層のプロトコルがどういうものかによって異なりますので、それぞれのプロトコルの箇所で説明することにします。TCPの場合はセグメントヘッダを追加して、セグメントを作成します。

 もちろんTCPも相手方のTCPと直接情報の交換をすることができませんので、これを下の層に託します。TCPがIPに依頼した時には、IPに対して、相手側のTCPに渡してももらうように依頼する必要があります。この時の指定はプロトコル番号などと呼ばれています。相手先と自分はIPアドレスで指定します。IPパケットのヘッダの詳細はこちらをご覧ください


 プロトコル番号はWindowsの場合は、C:\Windows\System32\drivers\etc\protocolsに記述されています(64ビットOSの場合はsystem64です)。TCPのプロトコル番号は「6」、UDPは「17」、ICMPは「1」となっていることが確認できます。





3 トランスポート層の仕事

 トランスポート層のプロトコル(プログラム)はどんな仕事をしているのでしょうか?トランスポート層のプロトコルはアプリケーション層のプロトコル(プログラム)に頼まれた仕事をするために、ネットワーク層のプロトコルに仕事を依頼します。通常の場合は、ネットワーク層のIPに仕事を頼みます。IPがいっぺんに送信できるデータのサイズには制限がありますので、IPの仕事のやり方に合わせてデータを分割する必要があるかもしれません。従って、受信側には分割したものを元に戻すための仕組みを必要となります。順番はシーケンス番号で制御しています。
 でも、データの分割はアプリケーション層の分担にしてもそれほど困ることはないでしょう。ポート番号の指定も直接ネットワーク層でできそうです。こう考えると別段トランスポート層がなくても困らないような気もします。

 ではトランスポート層がないと仮定するとどういうことになるでしょうか?アプリケーション層のプロトコルは直接ネットワーク層のプロトコルを利用しなくてはなりません。全てのネットワークが完璧な伝送を提供でき、サービスが同じならトランスポート層の必要性は低くなります。しかし、実際はネットワークは完璧ではなく、提供するサービスは様々です。ネットワーク層でしばしば発生するトラブルはアプリケーション層のプログラムが自分で対処しなくてはなりません。つまり、アプリケーションプログラムの作成者はネットワーク層レベルの問題や、技術に精通していなくてはなりません。現実的にはかなりの負担をアプリケーションプログラムの作者の強いることになります。この負担に耐えられる人がどれだけいるかという問題になります。また、物理ネットワーク毎に提供する機能は異なりますので、様々な物理ネットワークに対応するアプリケーションは物理ネットワーク毎に違ってきます。従って、物理ネットワークによって違うバージョンのアプリケーションが必要となるでしょう。

 トランスポート層はネットワーク層とアプリケーション層の間に介在することで、ネットワーク層の技術、設計、不完全さを吸収することができます。また、上位層に信頼性の高い均一のサービスを提供することも可能です。
 ネットワーク層はコネクションレスなので送信途中にパケットの損失や破壊が起きても対処できません。トランスポート層では仮想的なコネクションを確立してからパケットを送信するという方法も採用できます(TCP)。この用法をとった場合は、コネクションが途中で切断した場合は、再度コネクションを確立し、新しいコネクションを介して、前のコネクションの到達済みと未到達のパケットを確認し、データ送信を途中から再開することが可能です。



4 TCPとUDP

 TCP/IPの代表的なトランスポート層のプロトコルはTCPとUDPです。

 TCPはコネクション型のサービスを提供します。しかし、これはデータリンク層レベルでコネクションを確立し、共有ネットワーク上の2つのデバイス間で帯域を確保する電話タイプとは異なります。TCPのコネクションはコネクションレス型のネットワーク層サービスを利用して実現しますので、2つのノード間の帯域を予め確保する形のコネクションを確立することは無理だと言っていいでしょう。TCPのコネクションは仮想的なものです。コネクションは3ウェイハンドシェークによって相手の都合を確認しつつ構築されます。構築されたコネクションは、受信データに対して確認応答を返すこと、データフローを制御することなどによって維持されます。

※TCPのコネクションでは、2つのノード間での帯域の確保は難しいといいましたが、リアルタイム性を重視するマルチメディアタイプのアプリケーションが増えるとそうとも言っていられません。そこで、できるだけリアルタイムタイプのアプリケーションの要求に沿うように帯域を確保するにはどうすべきかという研究が盛んになされています。

 UDPはコネクションレス型でほとんど見るべき機能は持ちません。UDPのデータユニットがデータグラムと呼ばれているのはほとんどIPと同じ事しかしていないことのあらわれです。しかし、それは機能が劣っているという意味ではありません。UDPはほとんど何もしないことに意味があるといえます。このことについてはまた別の章で説明いたします。







更新履歴

2016/04/05 作成



























 ページの先頭