LASSIC Media らしくメディア

通信プロトコルとは

異なるメーカーの機器や、別々のチームが開発したソフトウェア同士が通信する場面では、送り方や書式の取り決めがそろっていないと、意味のあるやり取りは成立しません。通信プロトコルとは、こうした異なる機器・ソフトウェア同士が正しくデータをやり取りするために取り決められた、共通のルールや手順のことです。「どんな形式のデータを」「どの順番で」「どう送り、どう応答するか」をあらかじめ合意しておくことで、初めて通信が成り立ちます。

身近な例で言えば、電話をかけるときに名乗り、相手の応答を確認してから本題に入るのも一種の取り決めです。コンピュータの世界でも同様に、送信側と受信側が同じ手順で対話しなければ、データが届いても意味は通じません。通信プロトコルは、この「言語合わせ」と「送り方合わせ」を機械的に保証する仕組みだと捉えると理解しやすいものです。

取り決めがそろわないまま通信を行うと、送信側は正しくデータを送ったつもりでも、受信側では意図した形で解釈できず、通信エラーや処理の失敗という形で表面化します。あらかじめプロトコルという共通の約束事を用意しておくことで、こうした食い違いを事前に減らすことができるものです。システム同士の連携が増えるほど、この共通の取り決めがどこで交わされているかを把握しておく価値は大きくなります。

なお、Cookieやセッションによる状態保持の仕組み、HTTPステータスコードの意味は、アプリケーション層の中でも個別のテーマとして別記事で扱う内容です。本記事ではHTTPを代表的なプロトコルの一つとして紹介する程度にとどめ、通信プロトコル全体の枠組みと、その下層を支えるTCP・UDPの役割を中心に整理します。

通信プロトコルという考え方自体は、コンピュータネットワークの黎明期から積み重ねられてきた基本概念です。異なるベンダーの機器同士を相互接続する必要が生じた際に、共通の手順をあらかじめ定めておく発想が生まれ、現在のインターネットを支える仕組みへとつながっています。

プロトコルは層（レイヤ）で役割分担する

実際の通信は、一つのプロトコルがすべてを担っているわけではありません。物理的な信号のやり取りから、アプリケーション同士の対話まで、役割ごとに階層（レイヤ）へ分けて分担する設計になっています。各層は基本的に一つ下・一つ上の層とだけやり取りし、他の層の内部処理には関与しない構造です。この分担のおかげで、たとえば下位層をWi-FiからLTEに切り替えても、上位層のアプリケーションは影響を受けにくくなっています。普段使っているWebブラウザやアプリのコードを、通信回線の種類が変わるたびに書き直す必要がないのは、この層ごとの責務分離によるものです。

代表的な整理の仕方として、実務でよく使われるTCP/IPの4階層と、理論的なリファレンスとして知られるOSI参照モデルの7階層があります。両者の対応関係を表にまとめます。

層を分けて考える利点は、問題が起きたときの切り分けにも表れます。「通信自体が届いていないのか（下位層の話）」なのか「届いてはいるが応答内容がおかしいのか（上位層の話）」を区別できると、原因調査の範囲を絞り込みやすくなります。層という単位で考える習慣がないと、原因不明のまま関係者全員で同じログを眺め続ける、という進め方になりがちです。

この階層構造を支えているのが「カプセル化」という考え方です。上位層で作られたデータには、各層を通過するたびにその層用のヘッダー情報が付加され、送信側では上から下へ包み込むように、受信側では下から上へ開封するように処理が進みます。相手側の同じ層が同じ手順でヘッダーを解釈できるからこそ、複雑なネットワークを経由しても元のデータを正しく取り出せる仕組みです。

代表的なプロトコルと役割

通信プロトコルと一口に言っても、担っている役割はプロトコルごとに異なります。実務で名前を目にする機会が多いものを、層・役割・特徴の観点で整理しました。

これらは単独で使われるのではなく、組み合わさって初めて一つの通信が完成します。たとえばWebサイトを閲覧する際は、DNSでドメイン名をIPアドレスに変換し、TCPで接続を確立したうえで、HTTPのリクエストとレスポンスをやり取りするという流れが一般的です。HTTPS通信であれば、この間にTLSによる暗号化の手順が加わります。ブラウザにURLを入力するだけの操作の裏側では、名前解決・接続確立・暗号化・データ送受信という複数の手順が短時間のうちに実行されており、複数のプロトコルが層をまたいで連携して初めて画面表示までたどり着く仕組みです。TLSについても、初期のSSLから世代を重ねて仕様が更新されており、暗号化方式の強度は年々見直され続けています。

TCPとUDPの違い

アプリケーション層の一つ下、トランスポート層で対照的な役割を担うのがTCPとUDPです。どちらもIPの上で動きますが、設計思想が異なります。TCPは通信を始める前に送信側と受信側が合図を送り合い、接続を確立してから本題のデータをやり取りする「コネクション型」のプロトコルです。一方のUDPは、こうした事前の合図を挟まず、データを送りたいときにすぐ送り出す「コネクションレス型」の設計になっています。

TCPは「多少時間がかかっても、抜け漏れなく確実な形で届ける」ことを重視するのに対し、UDPは「多少の欠落があっても、途切れずに速く届ける」ことを重視します。動画配信で一瞬コマ落ちしても再生を止めずに進む挙動や、オンラインゲームで最新の位置情報が届けば古い情報の再送を待たない挙動は、UDPの特性を活かした設計です。逆にTCPを使う処理で再送や順序制御をアプリ側で肩代わりしようとすると、実装が複雑になりやすい点も実務上の判断材料になります。どちらが優れているというより、要件に応じて使い分けるものだと捉えるのが妥当でしょう。実際のシステムでは一つのサービスの中でもTCPとUDPを併用する場合があり、たとえばオンライン会議アプリが参加者リストや文字チャットにはTCP、映像・音声の伝送にはUDPを使い分けるのが典型的な例になります。

実務での関わり

システム間連携やAPI設計、社内外のネットワーク設計に携わる際、通信プロトコルの理解は選定や制約の把握に直結します。代表的なプロトコルとポート番号の対応も、ファイアウォール設定やアクセス制御の確認時によく参照する情報です。

設計時にこうした対応関係を一覧にしておくと、ファイアウォールやセキュリティグループの許可設定を検討する際に、どのポートを開ければよいか判断しやすくなります。逆に、想定外のポートが開いていないかを棚卸しすることも、セキュリティ設計の基本作業の一つです。

• プロトコル選定：リアルタイム性を重視する機能なのか、確実な到達を重視する機能なのかによって、TCPベースの通信を使うかUDPベースの通信を使うか判断が分かれます。
• ポートとファイアウォールの制約：TCP・UDPはポート番号で通信の宛先を区別しており、ファイアウォールやセキュリティグループの設定はこのポート単位で行われるのが一般的です。想定しているプロトコルとポートが開放されているかどうかは、設計段階で確認しておきたい点です。
• トラブル時の切り分け：「そもそも接続できないのか」「接続はできるが応答が遅い、または内容がおかしいのか」を分けて考えると、ネットワーク層の問題かアプリケーション層の問題かの見立てがつけやすくなります。
• レビューの観点：要件で求められている即時性や確実性に対して、選ばれているプロトコルやその設定が合っているかどうかは、設計レビューで確認しておきたい観点の一つです。
• プロトコルバージョンの考慮：IPには実務で広く使われているIPv4と、アドレス空間を拡張したIPv6があり、双方が混在する環境では対応状況の確認も設計項目の一つに含まれます。

まとめ

通信プロトコルは、異なる機器やソフトウェア同士がデータをやり取りするための共通の取り決めです。役割ごとに層を分けて分担する設計になっており、IPが経路選択、TCP・UDPが転送方式、HTTPやDNSがアプリケーションレベルのやり取りを担います。TCPは確実性、UDPは速さを優先するという対照的な特性を持ち、用途に応じて使い分けられています。システム連携やネットワーク設計に関わる際は、こうした層構造とプロトコルごとの特性を踏まえて選定・設計・トラブル対応にあたることが土台になるはずです。仕様書やインフラ構成図に登場するプロトコル名やポート番号の意味を押さえておくと、関係者間の認識合わせもスムーズになるものです。

相談するメリット

LASSICでは、ネットワーク・システム連携の設計やプロトコル選定、通信トラブルの切り分けについて、ニアショア開発体制を活かした受託支援を行っています。要件に対してどの層で問題が起きているのかを整理したい場合や、TCP・UDPどちらの特性が適切か判断に迷う場面など、設計初期の相談から実装・検証まで伴走することも可能です。社内に専任の担当者を置きにくい体制でも、必要な工程だけを切り出して依頼できる点も相談しやすいポイントです。既存システムの構成図や通信仕様が整理されていない状態からでも、現状把握を含めて相談を受け付けています。プロトコル選定の理由や制約が文書化されていないまま運用が続いているケースの整理も、支援対象に含まれます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ネットワーク設計や通信トラブルのご相談

プロトコル選定やネットワーク構成、システム連携時の通信トラブルについて、設計段階からの壁打ちや切り分け支援が必要な際は、LASSICまでお気軽にお問い合わせください。

お問い合わせはこちら

出典

• 通信プロトコル – Wikipedia
• HTTP の概要 – MDN Web Docs
• Transmission Control Protocol – Wikipedia
• User Datagram Protocol – Wikipedia

Tweet