通信の信頼性：誤りや欠落に備える

指導者向けの公開補足

学習本文に加えて、指導の視点・背景・授業での確かめ方を示します。どなたでも読めます。

指導の焦点

誤りの検出と訂正・再送を区別する。パリティで異常を検出できても、元の正しい値を常に復元できるわけではない。

一歩踏み込んだ背景

一つのパリティビットでは、偶数個の反転を見逃す場合がある。TCPの再送等も、アプリケーションの目的が必ず達成される保証とは別である。

授業での確かめ方

一ビットと二ビットを反転させて、検出結果の違いを確かめる。追加データ量・遅延・信頼性のトレードオフを説明させる。

制度・規格等は本文末尾の参考資料も確認してください。

この単元でできるようになること

通信中にデータが誤ったり失われたりする可能性を説明できる。
誤り検出、確認応答、再送の役割を区別できる。
TCPの信頼性と、相手側の処理成功を区別できる。

通信中の誤りや損失

通信路には電波の干渉や機器の故障、混雑などがあり、受信データが変化したり、パケットが届かなかったりすることがある。送った内容と受け取った内容が同じかを確かめる手がかりが必要になる。代表例の一つが誤り検出で、送信側が計算した検査情報をデータに加え、受信側でも計算して不一致を見つける。

検査情報は、データが変わった可能性を見つけるために使う。検査値が一致しても、あらゆる誤りが必ず見つかるとは限らない。また、検出した誤りを自動で元のデータへ直せるわけでもない。方式によっては訂正機能を持つが、検出と訂正を同じものとみなさないようにする。

応答を使って届いたか確かめる

送信側が受信側から確認応答を受け取る方式では、一定時間内に応答が来ない場合に、送信データが届かなかった可能性を考えて再送できる。受信側が順序番号を使えば、どの部分を受け取ったかを把握しやすくなる。受信側からの応答自体が失われる可能性もあるため、再送時に同じデータを二重に扱わない工夫が重要になる。

状況	送信側が確認できること	考えられる対応
データも応答も到着	受信側からの応答がある	次のデータを送る
データが失われた	応答が返らない	時間をおいて再送する方式がある
応答だけが失われた	受信状況を断定できない	再送と重複処理への備えが必要

この表は説明のために単純化した架空の通信である。現実のプロトコルには、ウィンドウ制御やタイムアウトの調整、混雑への対応などがある。

TCPの信頼性と、その範囲

TCPは、通信するアプリケーション間に、順序を整えたバイト列を届けるためのトランスポート層プロトコルだ。受信確認や再送などを使い、アプリケーションから見たデータの欠落や順序の入れ替わりに対処する。これを「信頼性のある通信」と説明することがあるが、ネットワーク経由の送信が最終的な成功まで保証されるという意味ではない。

相手の電源が切れたり、経路が長く使えなくなったりすれば、接続は失敗し得る。TCPで送信できても、相手アプリケーションが要求を正しく処理したか、保存したか、利用者が意図した相手だったかまでは保証しない。アプリケーションは必要に応じて受領確認、重複を避ける仕組み、処理結果の確認を別途設計する。

用語

用語	意味
誤り検出	受信データが変化した可能性を検査情報などで見つけること
確認応答	受信側がデータの受け取りを知らせる応答
再送	応答がないなどの条件で、データをもう一度送ること
TCP	順序や再送などを扱うトランスポート層プロトコル
タイムアウト	応答を待つ期限を超えたと判断すること

確認問題

誤り検出と誤り訂正の違いを説明しよう。
確認応答だけが失われた場合に、再送で問題が起き得る理由を説明しよう。
TCPで通信できたとしても、注文処理の完了を別に確認する必要があるのはなぜか。

問1の解答例を見る

誤り検出は、届いたデータに誤りがあることを見つける処理である。誤り訂正は、付加された冗長な情報などを使って、誤ったデータを正しい値へ直す処理である。

問2の解答例を見る

データ自体は届いていても、送信側は確認応答がないため再送することがある。受信側で重複を区別しないと、同じデータを二度処理してしまう可能性がある。

問3の解答例を見る

TCPによるデータ転送の成功と、アプリが注文を受け付け保存したことは別である。注文番号や注文履歴など、アプリ側の処理結果を確認する。