【python】Flaskを使ってAPIサーバを公開する
Flaskとは
Flaskとは、pythonのWebフレームワークです。 軽量なWebフレームワークであり、小さく使い始めることができるのが特徴です。 公式でも"microframework"と銘打っています。
Welcome | Flask (A Python Microframework)
同じpythonのフレームワークとしてはDjangoやも挙げられますが、Djangoはフルスタックなフレームワークなので、規模が大きめのWebアプリケーション作成に向いている気がします。
Usage
例によってpip
でインストールできます。
$ pip install Flask
Anacondaで管理したい人はconda
でも良いでしょう。
$ conda install -c anaconda flask
Source & Demo
Hello, World!
まずは Hello World
から!
# hello.py from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello World!"
サーバを立ち上げてみましょう。
$ FLASK_APP=hello.py flask run
ローカルサーバーが立ち上がるので、ブラウザで開くとHello, Worldが表示されるのがわかります。
またアプリの実行はスクリプト上でも行うことができます。
# hello.py from flask import Flask app = Flask(__name__) app.run(host="127.0.0.1", port=5000)
$ python hello.py
APIの定義
次はAPIを提供してみましょう。
FlaskではAPIの定義も簡単に行なえます。
from flask import Flask, request, jsonify, make_response app = Flask(__name__) @app.route("/hoge", methods=['GET']) def getHoge(): # URLパラメータ params = request.args response = {} if 'param' in params: response.setdefault('res', 'param is : ' + params.get('param')) return make_response(jsonify(response)) @app.route("/hoge", methods=['POST']) def postHoge(): # ボディ(application/json)パラメータ params = request.json response = {} if 'param' in params: response.setdefault('res', 'param is : ' + params.get('param')) return make_response(jsonify(response)) app.run(host="127.0.0.1", port=5000)
@app.route
デコレータの引数にパス・メソッド種別を指定しています。
Hello Worldのときはtext/plain
を返していましたが、今回はapplication/json
(JSON形式)でレスポンスを返しています。レスポンスをJSONにするには、jsonify
関数を使って作成したJSON型データをmake_response
関数の引数に渡し、それをAPI関数の返り値とします。
make_response
はレスポンスヘッダ及びレスポンスボディの情報を持つオブジェクトを作成します。このオブジェクトを介して、リクエストヘッダやボディの編集を行うことができます。
body = { "param" : "hoge"} response = make_response(jsonify(body)) response.headers['X-HogeHoge'] = 'hoge...' # 新しいヘッダ属性を追加
指定したパスに対してリクエストを投げると、結果が確認できます。
http://127.0.0.1:5000/hoge?param=helloAPI(GET)
Response
http://127.0.0.1:5000/hoge(POST)
Body
Response
参照
【NW】イーサネット② イーサネットのフレームフォーマット
前置き
コンピュータ間で通信を行うとき、その通信はプロトコルと呼ばれる規約に沿ってデータのやり取りを行います。プロトコルの種類は多岐にわたりますが、現代ではほとんどの場合TCP/IP
と呼ばれるプロトコル群の中から利用されます。とはいっても利用されるプロトコルは一つではなく、複数のプロトコルをセットにして採用します。
プロトコルが複数選ばれるのには理由があり、それはTCP/IPが「階層モデル」と呼ばれるプロトコルのモデルを採用しているからです。階層モデルは通信に必要な処理を階層的に分類したモデルで、一番上の層ではアプリケーションに関する情報の受け渡しを担当、その下の層では通信の信頼性に関する情報の受け渡しを担当・・・といったように、通信に必要な処理を層ごとに分担しています(そして各層の処理を実現するプロトコルを決めます)。
この辺の話は以前の記事にもまとめたので、参照していただけると嬉しいです。
この階層モデルでは送信するデータを上位層から下位層へと受け渡していき*1、最終的に電気や光の信号として相手に送信するのですが、下位層にデータを受け渡すタイミングで追加のデータを付加していきます(下記記事参照)。このデータをヘッダと呼び、その階層(のプロトコル)で必要となる情報を含んでいます。ヘッダの含む情報を見ていけば、そのプロトコルが何をしているのかがわかるはずです。
そこで、今回はリンク層における規格の代表格であるイーサネットののヘッダを見ていこうと思います。 イーサネットはプロトコルでこそありませんが、物理媒体の仕様のみならず送受信するデータのフォーマットについてやフレームチェックについても規定しているので、実質プロトコルとして扱われている雰囲気を感じます。
イーサネットの種類
もともと、イーサネットはXerox社によって考え出された通信方式「Ethernet」でした。その後、Xerox社はEthernetの仕様を公開し、旧DEC社とインテル社を開発に加え「DIX」と呼ばれる仕様を策定しました。さらにその後、DIXが普及しIEEEによって規格化がなされました(IEEE802.3)。そのため、後者のイーサネットを「IEEE802.3 Ethernet」と呼ぶ場合があります。
イーサネットのフレームフォーマット
プリアンブル
イーサネットのフレームの先頭には、1/0が交互に並んだビット配列が付きます。これをプリアンブルと呼びます。プリアンブルはイーサネットフレームの開始を示し、末尾が「11」のSFD(Starg Frame Delimiter)と呼ばれるフィールドが来たらそれ以降がフレームデータの内容となります。プリアンブルのサイズは8オクテット(=8ビット×8)からなり、プリアンブルによって送信先ホスト(のNIC)が同期をとることが可能となります。
Ethernet(DIX)フレームフォーマット
Xerox社・旧DEX社・インテル社によるEthernetのフォーマットです。
Eathenetフレームフォーマットはヘッダ、データ本体、FCSからなります。
ヘッダ内部にはあて先MACアドレス、送信元MACアドレス、データ部で採用している上位層プロトコルのタイプの番号が入ります。
タイプ番号はこちらのページにまとめられています。
FCSはイーサネットフレームが壊れていないかどうかをチェックするためのフィールドです。イーサネットフレームがノイズなどの影響で壊れた場合、送信側・受信側で計算したFCSの値が異なってくるため、フレームの破損を検出することができます。
IEEE802.3(+802.2)フレームフォーマット(LLC+SNAP)
IEEEによって規格化されたEthernetのフォーマットです。
ヘッダにはあて先・送信元MACアドレスに加え、フレーム長、LLC、SNAPといった情報が含まれています。
フレーム長はその名の通り、フレームの長さを示しています。
LLCとSNAPは、データリンクに置ける「媒体アクセス制御」と「論理リンク制御」という概念に関わってきます。 データリンク層は、更に細かく分けると「媒体アクセス制御」と「論理リンク制御」の二層に分けることができます。媒体アクセス制御は、データリンクの種別(FDDIやイーサネットなど)によって独自に決まるヘッダ制御を指します。一方、論理リンク制御はデータリンクの種別を問わない、共通するヘッダ制御を指します。LLCやSNAPは、この論理リンク制御情報を含めるヘッダであり、上位層プロトコルなどの情報を含んでいます。
LLC
LLCは
- DSAP
- SSAP
- CTRL
の3つの情報からなります。
DSAP(Destination Service Access Point)
あて先のネットワーク層プロトコルを識別するためのフィールドです。
SSAP(Source Service Access Point)
送信元のネットワーク層プロトコルを識別するためのフィールドです。
CTRL(Controll)
データリンクレベルでのコネクション確立・フロー制御を行うためのフィールドです。
SNAP
SNAPヘッダは3オクテットのベンダコードと、2オクテットのタイプフィールドからなります。
タイプフィールドはDIXのタイプフィールドと同じ扱いをされます。
参考
*1:あくまで主流で、他のやりかたもあるかもしれない
【NW】TCP/IPに置ける通信処理
以前の記事で、TCP/IPプロトコル・スイートについて紹介を行いました。
今回は、TCPIPのプロトコルに則ってやり取りされるデータがどのようなものなのか、どのように処理されていくのかを追ってみます。
TCP/IPプロトコルによって扱われるデータ
わたしたちが遠くにすむ友人にものを送るとき、どうすればよいでしょうか。手紙を送るのであれば、手紙を封筒にいれ、切手を貼り、住所をしるし、郵便ポストにおくるのが良いでしょう。少し大きめの荷物を運ぶとするならば、配送物をダンボールで梱包し、宛先住所を貼って郵便局に送ってもらうのが良いかもしれません。このように、現実の世界では遠くの相手に物を送る場合は、送るものを保護する梱包や宛先情報などを送りたいものに付加する必要があります。
コンピュータ・ネットワークの世界も同様で、ホスト(コンピュータなどのネットワーク上の末端通信機器)間でメールやファイルなどの情報(コンテンツデータ)をやり取りするときには、通信を行うために必要な情報を付加する必要があります。ここで言う必要な情報とは、データのあて先アドレスや、データの送り主のアドレス等、プロトコルに則ってデータを送受信する上で必要な情報を指します。
ところで、TCP/IPでは通信に必要なプロトコルを階層構造でモデル化していました。上位のプロトコルは下位のプロトコルに支えられる形で存在します。最上位のプロトコル層であるアプリケーション層ではメールやファイルと言ったコンテンツデータが作成されます。このコンテンツデータが相手側ホストに送信されるとき、上位プロトコルから下位プロトコルへとデータが渡されてゆき、最終的に電気や光などの物理的な媒体を介して相手ホストに送信されます。
この上位から下位へとデータが渡される際に、各プロトコルで必要な情報を付加しています。この「必要な情報」は上位プロトコルのデータの先頭に付加されるため「ヘッダ」と呼ばれます。あたかも配送物を梱包材で包み、ダンボールに入れ、宛先住所を貼って郵便局に送るように、コンテンツデータも必要な情報を取り入れながら送信されていきます。
アプリケーション層ヘッダ
プロトコルが担うアプリケーションで必要となる情報をヘッダに含めます。
例えばメール転送を行うプロトコルであるSMTPであれば、送信元・あて先メールアドレスなどが含まれます。
トランスポート層ヘッダ
トランスポート層のヘッダには、主に接続するアプリケーションを識別するための送信元・あて先ポート番号を含んでいます。 例えば、代表的なトランスポート層プロトコルであるTCP/UDPはいずれもポート番号をヘッダに含んでいます。 またTCPの場合は再送制御を行うために通信コネクションを確立する必要があるのですが、コネクションの状態を確認するためのフラグ用ビット領域がヘッダに含まれています。
トランスポート層ヘッダのついたデータはセグメントと呼ばれます。
インターネット層ヘッダ
プロトコルがIPの場合、送信経路を決定するために必要な送信元・あて先IPアドレスを含みます。
その他、パケットがループしてしまったり、送信先ホストが見つからなかった場合に使用するパケット生存時間などの情報を含みます。
インターネット層ヘッダのついたセグメントはパケットと呼ばれます。
リンク層ヘッダ
通信する両ホストを一意に識別するため、送信元・あて先MACアドレスを含みます。 ちなみに、イーサネットを使用する場合フレームの整合性チェックのためのFCS(Frame Check Sequence)がパケットの付加されます。
リンク層ヘッダのついたパケットはフレームと呼ばれます。
参考
【NW】イーサネット① ケーブル規格
イーサネットとは
イーサネット(Ethernet)とは、OSI基本参照モデルのデータリンク層、TCP/IPにおけるリンク層に相当する 役割を果たすコンピュータネットワークの通信規格です。隣接するホスト間の通信や、通信のための物理媒体そのものについて規定しています。
イーサネットの規格では他の規格と比較して通信制御の仕組みが単純であるため、NICやデバイスドライバといったハードウェアが作りやすく、イーサネット準拠の製品が安価に市場に流通したという背景があります。そのため、イーサネット規格に準拠した製品は世の中に広く普及していきました。実際の現場で使われて広く普及していったという点では、実装重視のTCP/IPと共通しています。
イーサネットで用いられる物理ケーブル仕様
イーサネットには多くのケーブル規格が存在します。以下はおもなイーサネットケーブル規格についてまとめたものです。
規格名 | ケーブル最大長 | ケーブル種類 | 通信速度(最大) |
---|---|---|---|
10BASE2 | 185m | 同軸ケーブル | 10mbps |
10BASE5 | 500m | 同軸ケーブル | 10mbps |
10BASE-T | 100m | ツイストペアケーブル(UTPカテゴリ3~5) | 10mbps |
10BASE-F | 1000m | 光ファイバーケーブル(MMF) | 10mbps |
100BASE-TX | 100m | ツイストペアケーブル(UTPカテゴリ5/STP) | 100mbps |
100BASE-FX | 412m | 光ファイバーケーブル(MMF) | 100mbps |
100BASE-T4 | 100m | ツイストペアケーブル(UTPカテゴリ3~5) | 100mbps |
1000BASE-CX | 25m | 被シールド銅線 | 1Gbps |
1000BASE-SX | 220m/550m | 光ファイバーケーブル(MMF) | 1Gbps |
1000BASE-LX | 550m/5000m | 光ファイバーケーブル(UTPカテゴリ5/5e推奨) | 1Gbps |
1000BASE-T | 100m | ツイストペアケーブル(UTPカテゴリ5/5e推奨) | 1Gbps |
10GBASE-SR | 26m~300m | 光ファイバーケーブル(MMF) | 10Gbps |
10GBASE-LR | 1000m~2500m | 光ファイバーケーブル(SMF) | 10Gbps |
10GBASE-ER | 3000m/4000m | 光ファイバーケーブル(SMF) | 10Gbps |
10GBASE-T | 100m | ツイストペアケーブル(UTP/FTPカテゴリ6a) | 10Gbps |
仕様名称によって通信速度、ケーブルの最大長、ケーブルの種類が異なってきます。例えば、10BASE2は通信速度が10m、ケーブルの最大長が200mの同軸ケーブルであることを表します。一方で、10BASE-Tのように後ろに"T"を冠する規格ではツイストペアケーブルを使用していることを示しています。
ケーブルの種類
同軸ケーブル
一本の銅線を絶縁体で覆ったケーブルです。イーサネットでは10BASE2と10BASE5の2つの規格が存在し、10BASE2は細いケーブル(Thinケーブル)を使用し、10BASE5では太いケーブル(Thickケーブル)を使用します。後述するイーサネットと比較して柔軟性がなく、ケーブルが曲げにくいために敷設が少し困難であるという特徴を持ちます。
ツイストペアケーブル
導線を2本1組で撚り合わせた線(撚り対線)を4本内蔵したケーブルです。導線を撚り合わせることで、導線から発生する磁場を打ち消しノイズの影響を小さくしています。同軸ケーブルと比較し線に柔軟性があり、敷設が容易であるという特徴を持ちます。
ツイストペアケーブルはシールド保護の違いにより、UTPとSTP、FTPに分類できます。
UTP(Unshielded Twisted Pair)はシールド保護を持たないツイストペアケーブルを指します。シールド保護ありのものと比較して安価ですが、ノイズ対策は上記の撚り対線のみになるので、比較的ノイズの影響を受けやすいです。一方のSTP(Shielded Twisted Pair)はその逆で、シールド保護によるノイズ低減の恩恵を受けられますが、UTPケーブルと比較すると高価です。
光ファイバーケーブル
光ファイバーケーブルはプラスチックやガラスなどの材質を用い、光を媒体としてデータを伝送するケーブルです。同軸ケーブルやツイストペアケーブルではサポート不可能な遠隔地への接続を行う場合や、ノイズ障害から通信を保護しし、高速に伝送を行いたい場合に用います。その分、前述した2つのケーブルと比較して非常に高価であり、また敷設に専門の技術を要します。そのため国同士のネットワークを接続するときなど、主に品質が最優先されるようなネットワークに用いられます。
参考
【NW】TCP/IP
TCP/IPとは
TCP/IP(TCP/IPプロトコル・スイート)とは、インターネット上の通信に必要なプロトコルの寄せ集めたプロトコル群(プロトコル・スイート)の総称です。
TCP/IPでは寄せ集めたプロトコルを機能ごとに4つのグループに分類しています。また各グループの関係は階層構造で定義しており、この点においてOSI基本参照モデルと共通しています(階層モデル)。
そもそもプロトコルって何?という方はこちら。
OSI基本参照モデルって何?という方はこちら。
TCPの階層モデル
TCP/IPの階層モデルは以下の4つの階層からなります。
- アプリケーション層
- トランスポート層
- インターネット層
- リンク層
アプリケーション層
アプリケーションレベルの通信について定義します。
OSI基本参照モデルのアプリケーション層、プレゼンテーション層、セッション層がこの層に該当します。
この層に位置するプロトコルとして、Webドキュメントのやり取りを行うHTTPや、メール転送を行うためのSMTP、ファイル転送を行うためのFTPがあります。
OSI同様、アプリケーション内部でやり取りされるデータを中心とした通信について定義されます。したがって、通信そのものの信頼性や、送信元・送信先・通信経路の決定などは下位のプロトコルに任せられます。
一方、OSIと異なりプレゼンテーション層とセッション層に関する責務も持ちます。したがってコンテンツの文字コードや圧縮、通信の接続・切断やデータ送信順序・タイミングなどについてもこの層に位置するプロトコルが定義します。
トランスポート層
二点間通信の信頼性について定義します。
OSI基本参照モデルのトランスポート層に該当します。責務に関してはOSIと同様、通信の信頼性に関するものを担保します。代表的なプロトコルにはコネクションの確立と再送制御を行うTCP、コネクションレス型で再送制御を行わないUDP等が挙げられます。
通信の信頼性は通信速度とのトレードオフなので、あえて信頼性を捨てて通信速度を優先したプロトコルを採用する・・・といったことも可能です。
インターネット層
二点間の通信について定義します。
OSI基本参照モデルのネットワーク層に該当し、ネットワーク上の送信元・送信先情報、経路制御などに関する責務を持ちます。代表的なプロトコルとしてIPがあります(というか通常のインターネットであればIP一強だと思われます)。その他のプロトコルとしてネットワーク上のホストを監視するためのICMPや、パケットに暗号化処理・改竄検出の機構をもたせるIPsecなどが挙げられます。
リンク層
物理的に接続されたホスト間の通信について定義します。
OSI基本参照モデルのデータリンク層・物理層がこの層に該当し、論理的な通信方法だけでなく物理的な通信に関する定義も行います。代表的なプロトコルとしてMACアドレスとIPアドレスを変換するARPや、二点間通信のプロトコルであるPPP等が挙げられます。またプロトコルではありませんが、イーサネットと呼ばれる技術規格に則った有線LANがこのレイヤのプロトコルと組み合わせて使われることが多いです。
OSI基本参照モデルとの違い
階層構造である点はOSI基本参照モデルと共通しているのですが、大きく異なる点もあります。それは、 TCP/IPが実装重視の階層モデルであるということです。
OSI基本参照モデルは「コンピュータ間通信に置いて必要な機能は何か」という考えのもの作成されたのに対し、TCP/IPの階層モデルは「どのように実装されればコンピュータ間通信を実現可能か」を念頭に置いて作成されたと言われています。そのような背景から、TCP/IPでは実際のプロトコル実装を伴って階層モデルを定義しています。
また、TCP/IPではRFC(Request for Comment)と呼ばれるプロトコル仕様のドキュメントがあり、プロトコルの仕様はこのRFC上で決定されます。RFCを策定するメンバーは段階的にプロトコルの策定を行うのですが、このとき提案段階のプロトコルからすでに実装を開始していきます。提案からドラフト入りし、標準化される前に様々な意見を取り込み、仕様をアップデートさせていくのですが、それに合わせて実装もアップデートしながらテストしていくようです。そのため、完全に標準化される頃にはすでに世の中に出回っている状態になっていると言われています。実際、SMTPなどのメール関連のプロトコルは彼らのメーリングリスト内のやり取りに使われ、そのやり取りの中でプロトコル自体もアップデートしていったという逸話もあります。
参考
【NW】OSI基本参照モデル
OSI基本参照モデルとは
OSI基本参照モデルとは、コンピュータ通信に必要な機能を階層構造に分類したモデルです。国際標準化機構(International Organization for Standardization, 通称ISO)が策定しています。
前回の記事で、プロトコルとその階層性について紹介しました。
プロトコルは階層化することで、それぞれのプロトコルの機能が明確化され、また各機能間の関係が独立的になり実装時の保守が容易になるという特性を持ちます。
同様に、OSI基本参照モデルは「コンピュータ通信にとって必要な機能」を7つのレイヤに分類して階層化し、モデルとしています。このモデルに従うことで、プロトコルがどのレイヤに該当し、通信プロトコルとしてどのような役割を果たしているのかを明確にすることができます。
OSI基本参照モデルのレイヤ
OSI基本参照モデルで定義されるレイヤは下記の7つです。
アプリケーション層
アプリケーション層はメール転送やファイル転送など、アプリケーションレベルの通信内容を定義するプロトコルはこのレイヤに該当します。例えばメール転送のプロトコルであれば、タイトルや送信元・宛先メールアドレス、本文などの情報がやり取りされる・・といった具合です。逆に、通信の信頼性や通信データの送受信そのものに関する責務等はこのレイヤーには(通常)存在しません。これらの責務は後述するトランスポート層やネットワーク層に委譲されます。
プレゼンテーション層
データの表現形式・配布形式を定義します。例えば、アプリケーション層でやりとりされるコンテンツの文字コードや、暗号化の有無・圧縮するかどうかなど、コンテンツの内容自体は変化しないものの、その表現形式をどのようにするか定義します。
セッション層
一回の通信の接続・切断のタイミングや、アプリケーション層で定義した(複数の)コンテンツの送信順などをコントロールします。またコンテンツを直列に送信するのか、並列に送信するのかなどについても定義します。
トランスポート層
トランスポート層では、コンピュータ間の通信の信頼性について責務を持ちます。 具体的には、コンピュータ同士の通信における - 同じ送信元・送信先のデータでも、アプリケーションごとに通信を識別可能にするかどうか - データの送信に失敗したとき、再送制御を行うかどうか 等について定義を行います。 通信の信頼性について責務を持つ、と書きましたが、あえて「スピード重視で再送制御を行わない」という定義を行うプロトコルもあります(UDP)。トランスポート層に位置するプロトコルは必ずしも通信の信頼性を担保するものではなく、あくまで「通信の信頼性についてどうするか」を定義します。
ネットワーク層
コンピュータネットワーク上の送信元と送信先、2点間の通信そのものについて定義します。 送信元・送信先情報をどのように定義するか、どのような経路で送信先にパケットに届けるのかなど、ネットワーク上でデータ転送をどうやって行うかを決めるプロトコルがここに該当します。
データリンク層
隣接するコンピュータ間の通信について定義します。ネットワーク層で定義される通信の最小単位と解釈することもできます。ネットワーク層とは別の送信元・送信先情報を定義したり、送信するデータの整合性をチェックするための仕様等を定義します。
物理層
物理媒体の仕様を定義します。0/1のビット配列を電気や光といった物理媒体にどのような規則で変換するのか等を定義します。
レイヤ間の関係
先程も述べたとおり、各レイヤの機能は互いに独立した関係にあります。一方で、各レイヤが役割を分担しあうことで、ネットワーク上におけるコンピュータ間の通信が成立する用になっています。例えば、ネットワーク層ではネットワーク上の2点間の通信の方法を定義しますが、通信の信頼性については責任を持ちません。具体的に言うと、媒体障害などでデータが相手に届かないような状況でも、ネットワーク層はそれについて責任を持ちません。代わりに、トランスポート層がデータの再送制御について責任を持ってくれるので、データが届かなかった場合にどうすればよいのかの定義はトランスポート層が担ってくれます。
このように、各レイヤが相互に機能定義を補うことで、ネットワーク上の通信が成立するようなモデルとなっています。
参考
【NW】通信プロトコル
以前(というか4年前)にPPPに関する記事を書いて以来長らくネットワーク関連の記事を書いていなかったのですが、最近TCP/IPについて再勉強し始めたので今回はプロトコルについて軽くまとめてみたいと思います。
プロトコルとは
プロトコル(通信プロトコル)とは、コンピュータ同士が通信する際の規約を指します。コンピュータ間通信は、この規約に則って情報をやり取りしています。コンピュータはこの規約がないと、正しく相手に情報を送ることができません。
コンピュータ間の通信を、人間のコミュニケーションに例えてみましょう。AさんとBさんという二人の人物がおり、互いに挨拶をするとします。もしこのとき、Aさんが「こんにちは」Bさんが「مرحبا هناك」というように、互いに異なる(しかも相手には理解できない)言語で会話しようとすると、会話が成り立ちません。これは、互いの言語体系、すなわちコミュニケーション上の「ルール」が異なっているからです。
コンピュータも同じで、この「ルール」が異なっていると通信が成立しません。そのため、人間が扱う自然言語のようなコミュニケーション上のルールをコンピュータにも設けるために「プロトコル」という概念が考案されました。
もしAさんとBさんが「英語」という共通の言語を使用すれば、互いにコミュニケーションを取ることができます。
同様に、コンピュータ同士が同じプロトコルの上で通信を行えば、情報の交換を行うことができるというわけです。
プロトコルの階層
各プロトコルは、取り決める規約の種類によって階層構造に分類することができます。
再び人間のコミュニケーションに例えてみましょう。
AさんとBさんはコミュニケーションを取るとき、言語という共通のルールに従っていました。
ところで、「英語」というルールが決まっていれば、会話でなくてもコミュニケーションをとることができますね。もっともベーシックなのは口頭での会話ですが、ほかにも電話越しに話したり、LINEでチャットしたり・・・など様々方法があります。
このように、「話の内容をやり取りするためのルール」として英語があるのと同時に、実は「英文をやりとりするためのルール」が前提として存在します。この「英文をやりとりするためのルール」もコミュニケーションする者同士で一致させておく必要があります。
英文をやり取りするための手段にLINE(チャット)を用いたとしましょう。この場合、AさんもBさんも「LINEという共通のアプリを使ってその中で文字をうち、送信する」というルールの中で英文を交換することになります。AさんがLINEを使っている中、Bさんが別のアプリでメッセージを送ったとしてもAさんには届きません。このルールのもと、AさんとBさんは英語でやり取りをすることになります。
上の図のように、人間同士のコミュニケーション間のルールは単純に一つではなく、ルールの前提となるルールが階層的に存在していることがわかります。
コンピュータ間通信も同様です。あるプロトコルによるやり取りの前提として、別のプロトコルの存在があります。プロトコルは単一のものではなく、様々なプロトコルが縁の下の力持ちとなって上位のプロトコルを支える構造になっています。
このような階層化によって、いくつかのメリットが発生します。
まず1つに、プロトコル階層では各機能階層が独立している点が挙げられます。会話で例えば、「英語で話す」というルールは、口頭で話すか、電話で話すか、LINEで話すかというルールとは独立しています。どの手段をとっても、英語で話すことには変わらないはずです。
コンピュータ通信のプロトコルも同様に、あるレベルでの通信のプロトコルが、下位、あるいは上位のプロトコルに大きく影響を及ぼさない作りとなっています。これにより、あるプロトコルでの変更による他の階層のプロトコルへの影響を小さくでき、大きな変更にならずに済みます。
役割の明確化という点でも、階層化は役に立ちます。通信の信頼性を担保するプロトコルなのか、End to Endの通信規格だけを提供するのかなど、役割を明確にすることで実装に結びつけやすくなります。またコミュニケーションを取る際にも、「どの階層(のプロトコル)の通信までフィルタリングするか」といった具合に共通言語として扱うことができるのも階層化のメリットです。