通信研究会にはネットワークを触りたいという変態がよく現れます。自己紹介です。
ただ、コンピュータネットワークは非常に様々な事柄を理解する必要があり、若干難解です。今回は、そのネットワークの基礎の一つOSI基本参照モデルを解説する記事を書こうと思います。
ネットワークとは
コンピュータネットワークについて軽く解説しておこうと思います。といっても、あまりに抽象的な概念すぎるので、ここはネット辞典のちからをお借りしてざっくりと説明してみます。
コンピュータネットワーク（英: computer network）は、複数のコンピュータを接続する技術。または、接続されたシステム全体。コンピュータシステムにおける「通信インフラ」自体、あるいは通信インフラによって実現される接続や通信の総体が（コンピュータ）ネットワークである、とも言える。
コンピュータネットワーク - Wikipedia
実は、コンピュータネットワークという言葉の定義自体かなりあやふやだと思っていて、とりあえずコンピュータ同士を接続する技術という認識でいます。で、実際それは間違っていないはずです。
つまり、本エントリで解説するのは、主にコンピュータ間を接続する技術についてです。
ちなみに、ネットワークにおいていくつか用語的なものが登場します。この記事を読むにあたって必要なものをいくつか上げておきます。
- ホスト：ネットワーク上のネットワークに接続することができるすべてのコンピュータ、もの
- プロトコル ：通信するにあたっての決まり事や方法、フォーマット。
OSI基本参照モデル
数多のコンピュータが存在する中、それぞれの相互運用性を高めるために「標準」というものは数多く存在しています。USBやHDMIがいい例です。ネットワークの分野においては、姿形が異なるコンピュータ同士が正しく、期待通りに通信してくれるように数多くの標準によって、通信の方法・方式・技術が決まっています。
その標準の中の一つが「OSI基本参照モデル」です。OSI基本参照モデルとは、コンピュータが通信するうえで必要となる機能を7つのレイヤーに分けて定めた「モデル」です。モデルとは、手本とか模型とかの意味がありますが、OSI基本参照モデルはコンピュータ同士が通信する方法の「模型」を意味しています。
7つのレイヤー
では、OSI基本参照モデルの7つのレイヤーを見ていきます。
| 層 | 役割 | |
|---|---|---|
| 7 | アプリケーション層 | アプリケーション毎のプロトコル |
| 6 | プレゼンテーション層 | データの差異を吸収 |
| 5 | セション層 | 通信経路全体の管理 |
| 4 | トランスポート層 | ホスト間の通信を確立 |
| 3 | ネットワーク層 | ホスト間の通信を提供 |
| 2 | データリンク層 | 隣接したホスト間の通信を提供 |
| 1 | 物理層 | 物理的な機能の提供 |
この並びは覚えにくいのでよく「アプセトネデブ」なんていう語呂合わせ（？）で覚えたりします。
基本的に、この表の上の方に行くほどハードウェアから遠くなり「上位レイヤー」あるいは「上位層」、下の方に行くほどハードウェアに近くなり「下位レイヤー」あるいは「下位層」となります。下位レイヤーの物理層から順に「第何層」や「Layer X」（or Lx）ということもあり、例えば、物理層なら第1層やLayer 1（L1）、トランスポートそうなら第4層やLayer 4（L4）、アプリケーション層なら第7層やLayer 7（L7）なんて言ったり言わなかったりします。
ちなみに、機器の名称に「L2スイッチ」や「L3スイッチ」というものがありますが、「L2スイッチ」は第2層つまりデータリンク層でパケットを中継するスイッチ、「L3スイッチ」は第3層つまりネットワーク層でパケットを中継するスイッチを指しています。
各レイヤーにはそれぞれ「プロトコル」が存在しています。プロトコルとは、決め事やルールのことで、HTTPやIP、UDPやTCPもプロトコルの一種です。プロトコルでは後述する「ヘッダの中身」や「使用するポート番号」、「データの形式」や「表現方法」、「処理方法」などが定められており、これに従って通信することで適切なデータの受け渡しが可能になるということです。
コンピュータでなにかを話すとき、上位・下位という分類をすることがあります。これは、ハードウェアとソフトウェアの距離のことを話しており、例えばハードウェアを直接操作するOSや組み込みソフトウェアは下位・低レベルという事が多く、ハードウェアをそれほど意識しなくてもいいWebなどは上位・高レベルという事が多いです。
プログラミング言語でも、ハードウェアを直接変更や参照する事ができるアセンブリやC言語を低級言語、ハードウェアを意識する機会が少ないPythonやJava Scriptを高級言語と言ったりします。なお、この上位・下位、高級・低級の概念は文脈や分野によって異なるので注意が必要です。
通信の順序とヘッダ
では、この層に注目しながらコンピュータ間の通信の順序を見ていきたいと思います。
前提条件として、アプリケーション間の通信というのをお話しておこうと思います。これまで「コンピュータ間の通信」という話をしていますが、もっと厳密に言えば「アプリケーション間の通信」ということになります。2つのコンピュータが通信しているとすれば、実際にデータをやり取りしているのは、アプリケーション同士です。なので通信の起終点はアプリケーションということになります。
つまり、送信するときはアプリケーション層から順番にプレゼンテーション層、セション層・・・と下位層に進みます。そして、進む過程で順番に「ヘッダ」と呼ばれる情報を付加していきます。
ヘッダとは、OSI基本参照モデルの各層の処理に必要な情報で、データとともに付与されます。具体的には、データとは異なる「宛先」や「データの種類」、「プロトコルの種類」「データの長さ」などがヘッダ含まれています。
送信側ではこのヘッダを追加していきますが、受信側では逆に物理層から順番にヘッダを取り出しつつ上位層にデータを取り次いでいきます。
各レイヤーの役割
では、各レイヤーの役割をそれぞれ見ていきましょう。
OSI基本参照モデル7つのレイヤーは、アプリケーション層～セション層とトランスポート層～物理層の2つに大きく分類する事が可能です。前者のアプリケーション層～セション層は「送受信するデータ」を生成したり管理したりというのが中心であり、実際この3つレイヤーでは通信を行いません。一方で後者のトランスポート層～物理層は実際の通信を提供するレイヤーとなります。
特にセション層の役割はトランスポート層～物理層の管理というのも含んでおり、セション層以上のレイヤーが通信に直接関わっていないことは想像できます。
では、まず上位層から順に役割を見ていきたいと思います。
アプリケーション層
アプリケーション層では、実際にどのようなデータを送受信するかを処理しています。例えば、送信するデータが「メール」なのか「Webサイト」なのかなどを決定しているわけです。
この部分は、アプリケーション毎に実装が異なることもあるので、他の層と比較してプロトコルの数が極めて多いのが特徴です。
また、もし何らかの問題でデータが受信側できなかったときに、送信側のアプリケーション層がエラー処理を行ったりもします。
基本的にユーザーと最も近いレイヤーであることから、ユーザーに対してのデータの提供や、ユーザーが入力したデータの調整を行っているレイヤーです。
プレゼンテーション層
アプリケーション層で生成された送信データというのは、そのコンピュータに依存していたり、特定の表現フォーマットに依存していたりしています。
例えば日本語の場合、表現方法がUTF-8やUTF-16、Shift-JISにEUC-JPなど多彩です。もし、送信側がUTF-8でデータを送信したとして、受信側がShift-JISだと認識して処理を行った場合、正しくデータを表現することができません。
そこでプレゼンテーション層では、コンピュータ固有の表現形式のデータと、ネットワークで共通化された表現形式のデータを変換します。送信側ではネットワークで共通化された表現形式に変換し、受信側ではコンピュータ固有の表現形式に変換するのです。
このような役割があるプレゼンテーション層のヘッダには、どのようにデータが表現されるべきかが記載されています。
ただ、著名なプロトコルでは、アプリケーション層とプレゼンテーション層の役割を両方有するものも多く、アプリケーション層とプレゼンテーション層を分けて考えるってあんまりないような気もします。ただ、OSI基本参照モデルに基づく通信の場合、必ず必要な処理ではあるので覚えておきましょう。
コンピュータでは全てのデータを二進数で表します。これには文字も含みます。
文字をコンピュータで扱うときは、文字ごとに決められたルールに従って「0」と「1」の二進数に変換します。この変換ルールのことを文字コードと呼び、代表的なものに「UTF-8」や「Shift-JIS」があります。たとえば、「あ」という文字をUTF-8のルールで二進数に変換（エンコード）すると、「11100011 10000001 10000010」という数列になります。
しかし、この数列をShift-JISのルールで文字に変換（デコード）しようとすると、本来の「あ」ではない別の意味不明な文字に読み取られてしまいます。これが文字化けです。
セション層
セション層では、実際にどのようにデータを通信するのかを決定します。一部の参考書のセション層の説明に「通信の開始から終了までを提供する」と書かれていることがあります*1。
もう少し踏み込んでセション層を説明すると「通信の開始から、維持、そして終了までの手順を管理する」レイヤーとなります。アプリケーション層・プレゼンテーション層でデータを生成し、セション層がそれを「どのように送信するか」を決定するのです。
コネクション型通信では、通信する際「コネクション」と呼ばれる論理的な通信経路を確立して通信します。
このコネクションについては、確立して切断するタイミングについていくつかパターンが考えられます。例えば、5つのデータを送信するとして、データ1つずつコネクションを確立して切断するか、コネクションを確立してデータ5つを送ったあとに切断するか、複数のコネクションを確立して並行して送信するか の3つが考えつきますね。
セション層では、このコネクションをどのように確立して、維持して、切断するかを決定します。決定だけして、ヘッダに方法を記して、トランスポート層へ渡します。実際に実行するのはトランスポート層です。
また、通信経路を確立する・管理するということから、セション層では「通信経路自体の暗号化」についての機能を提供しています。著名なものとしてTLS/SSLがあります。ただ、通信経路に関わる層はセション層だけではないため、通信経路の暗号化はトランスポート層とセション層で曖昧な部分も多いです。
トランスポート層
さて、7つのレイヤーを2つに分けたときの「実際に通信を行うレイヤー」の説明に入っていきましょう
セション層で決定したコネクションの確立・維持・切断を行うのはトランスポート層の役割となります。それに加えて「相手にデータが届いているか」を確認するのもトランスポート層の役割となります。
トランスポート層においては重要な2つのプロトコルがあるので、説明しておこうと思います。
TCP
TCP（Transmission Control Protocol）は、コネクション型通信の最も著名なトランスポート層のプロトコルです。
TCPでは、通信を行う前に「3-way handshake」を行います。これは、通信相手がいることを確認し、データ送信の許可を得るという手順です。この3-way Handshakeでコネクションを確立し、データのやり取りを行います。
上の図でも示していますが、3-way handshakeの流れを説明します。
- 送信側が、受信側に対して コネクションの確立（SYN） を要求します
- 受信側がSYNを受け取ったこと（ACK）と、コネクションの確立要求（SYN）を送信側に送信します。
- 送信側がSYNを受け取ったこと（ACK）を受信側に送信します。
更に、データがしっかり届いたかどうかの確認も行います。
送信側がデータを送信し、受信側が受け取ると「ACK」と呼ばれるデータを応答しデータが正常に届いたことを確認します。逆に送信側が送信したあと、制限時間内にACKを受け取らなければ受信側にデータが正常に到達しなかったとして再送します。
終了のときも、3-way handshakeのような形で今度は「FIN」というデータをやり取りします。
これがTCPです。TCPは、確実にデータを届けることができる反面、送信毎に到達確認を行うことから、到達確認分の遅延が発生してしまいます。
そのため、リアルタイム性が求められる通信にはTCPは用いられません。使用場面はHTTPやメールなど、データの確実性が必要な場面が中心です。
なお、TCPはデータの順番を保証するという特性もあります。データが順番通りに届かなかったら、ACKを返さず、順番どおりに再送させるのです。
UDP
TCPと対を成すのがUDP（User Datagram Protocol）です。
UDPはコネクションレス型で、コネクションを確立せずに直接データを送りつけます。
UDPでは相手にデータが届いたかと言うのを確認しません。そのため、データが確実に届いたかどうかは保証しませんが、TCPと異なり到達確認を行わないので遅延が少なくリアルタイムが求められる通信に用いられます。NTPやRTPとかが代表例ですね。
ただ、UDPの一部にTCPの要素を組み込んでいる例もあり、例えばUDPでもコネクションを確立して通信したり、一部通信に到達確認を行ったりすることがあります。TCPとUDPがあまりに両極端すぎるので、ちょうどいい塩梅を独自拡張で実現しているということです。こういったものは標準化されるべきな気がしますが、それはそれで面倒な気がします（策定で絶対もめる）。
ネットワーク層
トランスポート層でコネクションの管理を行ったあとは、いよいよ「通信」です。ネットワーク層とデータリンク層では、実際に相手にデータを届ける役割を担います。
まずネットワーク層ですが、ここはエンドホスト間（つまり、実際にやり取りしたい相手同士）の通信を提供する層です。データを送るときに「送り主から受け取り手までデータを届ける」という論理的な経路を作るのがネットワーク層の仕事です。
どういうことかというと、ネットワークでデータを送ると、その道中にはルータやスイッチ、リピータなどいろいろな機器が間に入ります。でも、そんな途中の機器がいくらあったとしても、ちゃんと宛先までデータを届けるようにしてくれるのがネットワーク層の役割です。
ネットワーク層では「最終的な宛先のアドレス」を基にデータを送ります。このアドレスはほとんどの場合「IPアドレス」です。ネットワーク層で通信を行うときには、IPアドレスを使って「相手がどこにいるか」を決めて、データを運んでいきます。だからこそ、宛先までちゃんとデータが届くわけです。
ここまで話すとお気づきかもしれませんが、「ルータ」と呼ばれるネットワーク機器は、このネットワーク層で中継を担う機器になります。ネットワーク層について深掘りしようとすると、ルータや経路制御（ルーティング）、IPアドレスの話になっていくのですが、それぞれ語り始めると1本記事が書けるので、今回はこの辺で止めておこうと思います。
ちなみに、送信側から送信されたあと、受信側が受信するまでにルータが挟まっている場合、ルータは物理層～ネットワーク層のヘッダを参照します。しかし、前述の通り、IPアドレスを含むネットワーク層のヘッダを書き換えることはありません。
データリンク層
ネットワーク層では、エンドホスト間の通信を提供しました。その間にある機器間の通信を提供するのがデータリンク層です。隣接したホスト間の通信を提供するレイヤーと説明されることもあります。
ネットワーク層のヘッダでは「最終的にどこに届けるか」が書かれていましたが、データリンク層のヘッダでは「次にどこに届けるか」が書かれています。なお、このときに使われるのが「MACアドレス」です。
物流で例えましょう。
工場から、オフィスへ荷物を届けるとします。現代の物流においてはほぼ確実に、途中に集荷所や倉庫を経由することになります。
この例で、工場から荷物が発送された辞典で、最終的な宛先となるオフィスの住所がIPアドレス、次に荷物が向かう先である集荷所の住所がMACアドレスとなります。集荷所からオフィスへ発送されるときには、IPアドレスはオフィスのまま、MACアドレスが集荷所オフィスのものになります。
ちなみに、ルータやL3以下のスイッチなどは、データリンク層のヘッダを書き換えます。
物理層
そして最後に物理層。物理層は、実際にデータを信号に変換して送信する部分です。データリンク層のヘッダに書かれたMACアドレスを基に、データを次の機器に転送します。
TCP/IPとOSI基本参照モデル
OSI基本参照モデルは、ISOによって定められたモデルとなっていますが、実際に使われているのはTCP/IP階層モデルです。OSI基本参照モデルと対応はしていますが、レイヤーの構成自体は異なります。
これはOSI基本参照モデルが「ネットワークに必要な機能」を中心に策定されたのに対して、TCP/IP階層モデルモデルでは「プログラムを実装するときに、どのようにすればいいのか」を中心に考えられているためです。
具体的には、OSI基本参照モデルでアプリケーション層～セション層に当たる部分を「アプリケーション層」とし、アプリケーションが実装する部分としています。つまり、アプリケーションが、アプリケーション毎のフォーマットとデータの標準化、コネクションの指定までを行う必要があるということです。
そして、トランスポート層に対応するのがそのまま「トランスポート層」です。この部分は役割は同じです。そしてネットワーク層は「インターネット層」となっています。TCP/IPでは、「トランスポート層」と「インターネット層」はOSに実装される部分としています。
データリンク層に対応するのが「ネットワークインタフェース層」で、この部分はデバイスドライバが実装する部分としています。
と、このようにTCP/IPは比較的プログラマが作りやすい形で定められています。
また、多くのプロトコルは、OSI基本参照モデルの各レイヤーよりも、TCP/IPの各レイヤーに対応する形で定められており、現代のコンピュータ通信において「デファクトスタンダード」となっています。
通信レイヤーが変わっていることから、ヘッダのフォーマットが大きく変わっていますが、送信側の各レイヤーでヘッダが付与され、そのヘッダを基に通信されるという通信手順自体は、OSI基本参照モデルと大きく変わりません。
〆
OSI基本参照モデルとTCP/IPを説明しました。コンピュータ・ネットワークは、基本情報技術者や応用情報技術者でかなり重要な部分であるにも関わらず、わかりにくい部分が多い分野です。その登竜門とも言えるOSI基本参照モデルの重要な部分を抑えられた記事をかけたのではないかと思います。
今後、こういった記事を数本書いていくつもりですので、お楽しみに。
ほなまた
参考
- 井上直也,村山公保,竹下隆史,荒井透,苅田幸雄「マスタリングTCP/IP入門編 第6版」（オーム社、2019）
この記事を書いた人
西田（総合情報学部 情報学科 2021年入学）
通信研究会OB。当ホームページの保守運用を支援しています。組み込み系のソフトウェアエンジニア。応用情報技術者・修習技術者。
*1:出典：栢木 厚「令和05年 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室 情報処理技術者試験」 第18版（技術評論社、2022）
