プロトコルとは、コンピューター同士が通信するための「取り決め」です。データをどんな形式で送るか、どんな順番でやり取りするか、エラーが起きたらどう対処するか——こうしたルールをあらかじめ決めておくことで、メーカーもOSも異なる機器同士が問題なく通信できます。TCP・HTTP・DNSなど、これまで学んできた技術はすべてプロトコルの一種です。

はじめに

これまでの記事で、TCP・UDP・HTTP・DNSといった技術を「通信の取り決め」として紹介してきました。しかし「取り決め」とは具体的に何を定めているのか、なぜ取り決めが必要なのかまでは掘り下げていません。

今回はプロトコルという概念そのものに正面から向き合います。次回のTCP/IPモデルを理解するための土台にもなります。

なぜ「取り決め」が必要なのか

通信とは、情報を相手に伝えて理解してもらう行為です。この「理解してもらう」ためには、送る側と受け取る側の間で共通のルールが必要です。

人間同士の会話で考えてみましょう。日本語しか話せない人と英語しか話せない人が向き合っても、会話は成立しません。音声は届いているのに、意味が伝わらないからです。「どの言語で話すか」という共通の取り決めがあって、初めて意思疎通ができます。

コンピューターの通信でも同じです。電気信号の記事で学んだように、ケーブルの中を流れているのは電気の高低——つまり0と1の並びだけです。この0と1の列をどう解釈するかが決まっていなければ、受け取った側はデータを復元できません。

そこで、通信を始める前に「こういうルールで送りますね」という約束を決めておきます。これが プロトコル です。

図：取り決めがなければ意味が伝わらない

通信にはさまざまな取り決めが必要になる

一口に「取り決め」といっても、その内容は多岐にわたります。実際の通信では、次のようなことを決めておく必要があります。

データをどこで区切るか

1011010011000001 という列が届いたとき、8ビットずつ区切れば2つの値、4ビットずつなら4つの値になります。区切り方が違えば、まったく別の情報として解釈されます。どこまでが宛先の情報で、どこからが本文なのかという境目も同様です。

ビットと文字をどう対応させるか

11000010 10100010 というビット列を、どの文字として扱うか。この対応表が 文字コード です。送信側と受信側で異なる文字コードを使うと、届いたデータは正しいのに読めない文字が並びます。文字化けはこの不一致で起こります。

返事を待つべきかどうか

データを送った後、相手からの返事を待つのか、そのまま次を送ってよいのか。これが決まっていなければ、双方が相手の返事を待ち続けて通信が止まることもあれば、受信側の処理が追いつかないままデータを失うこともあります。

エラーが起きたらどうするか

ノイズで一部のビットが反転したとき、受信側はそれに気づけるのか。気づいたとして、送り直しを要求するのか、諦めるのか。この判断基準も必要です。

通信をいつ終えるか

データを送り終えたことを、どうやって相手に伝えるのか。相手が受け取り終えたことを、どう確認するのか。

プロトコルが定めるのは基本的な枠組み

これらの取り決めのうち、 通信を成立させる土台となる部分 を体系的に定めたものがプロトコルです。

具体的には、データの形式・やり取りの手順・エラーへの対処・通信の開始と終了といった内容です。これらが決まっていなければ、そもそもデータをやり取りする行為が成り立ちません。

一方、文字コードのような個別の対応表は、プロトコルとは別に定められています。UTF-8やShift_JISは、ネットワーク通信とは独立して存在する符号化の方式です。ファイルをディスクに保存するときにも使われます。

ただし両者は無関係ではありません。HTTPには Content-Type: text/html; charset=UTF-8 というヘッダーがあり、「このデータはUTF-8で書かれている」と伝える仕組みが用意されています。つまり 「どの文字コードを使うかを伝える方法」はプロトコルが定めている という関係です。

次のセクションでは、プロトコルが定める4つの内容を詳しく見ていきます。

プロトコルが定めていること

プロトコルは具体的に何を決めているのでしょうか。主に4つの内容が定められています。

①データの形式（フォーマット）

データをどんな構造で並べるかという決まりです。「最初の6バイトは宛先MACアドレス、次の6バイトは送信元MACアドレス、その次から本文」といった具合に、各部分の位置と長さが定められています。

受け取った側はこのルールに従って0と1の列を区切ることで、必要な情報を取り出せます。決まった位置に決まった情報があるからこそ、機械的に処理できるのです。

②やり取りの手順（シーケンス）

どんな順番でメッセージを交換するかという決まりです。

入門編「TCP/UDP」で学んだスリーウェイハンドシェイクが好例です。「①通信できますか？ ②できます、あなたも大丈夫ですか？ ③大丈夫です、では始めます」という3ステップの手順が定められており、この順番を守ることで確実に接続を確立できます。

③エラーへの対処

通信が失敗したときにどうするかという決まりです。

TCPでは「一定時間内にACK（確認応答）が返ってこなければ再送する」というルールが定められています。入門編「CSMA/CD」で学んだ「衝突したらランダムな時間待ってから再送する」というバックオフも、エラー対処のルールの一種です。

④通信の開始と終了

いつ通信を始め、いつ終わるのかという決まりです。

TCPでは接続の開始にスリーウェイハンドシェイクを使い、終了時にも専用の手順が定められています。「もう送るデータはありません」「了解しました」というやり取りを経て、双方が接続を閉じます。

図：プロトコルが定めている4つのこと

図：プロトコルが定めている4つの内容

標準化 ― 世界共通のルールを作る

プロトコルは、特定の企業が勝手に決めるものではありません。世界中の機器が同じルールで通信できるよう、国際的な団体が 標準化 を行っています。

もし各メーカーが独自のプロトコルを使っていたら、A社のパソコンとB社のサーバーは通信できません。同じメーカーの製品同士でしか繋がらないネットワークでは、インターネットは成立しませんでした。

インターネットで使われるプロトコルの多くは、IETF（Internet Engineering Task Force） という団体が RFC という文書の形で公開しています。

RFCには通し番号が付けられており、たとえばHTTPやTCPの仕様もRFCとして誰でも閲覧できます。仕様が公開されているからこそ、どのメーカーでも準拠した製品を作れるのです。

なお、入門編「CSMA/CD」やハブの記事で登場した IEEE 802.3 や IEEE 802.1Q のように、IEEE（米国電気電子学会）が標準化しているプロトコルもあります。分野によって担当する団体が異なります。

身近なプロトコルの一覧

これまでの連載で登場したものを中心に、代表的なプロトコルを整理します。

こうして並べてみると、これまで学んできた技術のほとんどがプロトコルだったことがわかります。

プロトコルは組み合わせて使う

ここで重要なのは、 1つの通信で複数のプロトコルが同時に働いている という点です。

たとえばブラウザでWebページを開くとき、次のようにプロトコルが重なって動作しています。

• HTTP ：「このページのデータをください」という要求を組み立てる
• TCP ：そのデータを確実に届ける手順を担当する
• IP ：宛先のネットワークまで経路を決めて運ぶ
• Ethernet ：目の前のケーブルやスイッチを通じて実際に信号を送る

それぞれが別々の役割を持ち、上から下へとバトンを渡すように処理が進みます。この「役割ごとに分かれて重なっている」という構造こそが、次回学ぶ TCP/IPモデル の考え方です。

図：1つの通信で複数のプロトコルが働く

なぜ役割を分けるのでしょうか。理由は、変更に強い設計にするためです。たとえば有線から無線に切り替えても、変わるのは一番下のEthernetの部分だけで、HTTPやTCPはそのまま使えます。役割が分かれているからこそ、一部だけを差し替えられるのです。

まとめ

プロトコルとは、コンピューター同士が通信するための取り決めです。データの形式・やり取りの手順・エラーへの対処・開始と終了という4つの内容が定められており、送る側と受け取る側が同じルールに従うことで通信が成立します。IETFやIEEEといった国際団体が標準化を行い、RFCなどの文書で仕様が公開されているため、メーカーが異なる機器同士でも通信できます。1つの通信では複数のプロトコルが役割を分担して同時に働いており、この階層構造が次回学ぶTCP/IPモデルの考え方につながります。

用語表