高校情報I Webの要求と応答—通信の順序から暗号化で守れる区間を説明する｜武蔵野個別指導塾

予約画面の取得と申込の送信を二つの往復で追い、TLSの保護区間と入力・登録内容の確認を区別します。

よくあるのは、高校生が暗号化されたページなら記載内容も正しいと判断するという場面です。通信の途中を守ることと、書かれた内容が事実であることは別の条件です。予約画面を題材に、要求の送り手と応答の送り手、守られる区間、端末に残る内容を分けて考えます。

出方には、要求と応答の順番を並べる型、暗号化の範囲を図に書き込む型、通信が失敗した場合や届いた内容が誤っている場合を説明する型があります。どの型でも、まず誰が何を送ったかを具体的に示すと判断しやすくなります。

要求と応答の境界を描く

Webページを見るとき、利用者のブラウザはクライアントとして働き、情報を提供する側のサーバに要求を送ります。サーバは要求を受けて処理し、結果を応答として返します。クライアントとサーバは役割の名前です。サーバが常に正しい回答を持つという意味ではありません。

HTTPは、クライアントとサーバが要求や応答をやり取りするための取り決めです。要求には、何をしてほしいかや対象が含まれ、応答には処理の結果や内容が含まれます。ページを受け取る要求と、入力した予約内容を送る要求は別のやり取りとして考えられます。表示された画面だけでは、予約の処理が完了したかどうかまでは決まりません。

HTTPSでは、HTTPのやり取りをTLSによって保護します。TLSは通信相手の確認を行い、通信内容の盗み見や途中での改変を防ぐための仕組みです。サーバの証明書などを用いた確認が成功し、保護された通信が成立したという条件の下で考えます。警告が出た状態を成功と同じには扱いません。

図1のように、保護の範囲をブラウザと接続先のサーバの間に描きます。これは問題を考えるための簡略図であり、実際の構成に中継先がある場合は、その終点を確認し直す必要があります。

図1の矢印は要求と応答の向きです。TLSで保護された通信でも、クライアントで入力される前の内容や、サーバで復号された後の内容まで自動的に正しくなるわけではありません。端末に表示された内容を利用者が見間違えることや、サーバに誤った情報が登録されることは別に起こりえます。

サーバの確認と内容の真偽も区別します。期待する接続先との保護された通信が成立したとしても、その接続先の担当者が誤った日時を掲載していれば、誤った日時が保護されて届くことがあります。通信経路での保護は、内容を別の資料と照合する作業の代わりにはなりません。

成功と失敗の区別にも条件が必要です。送信操作をしただけでは、サーバが受信し処理したことは確定しません。応答が届かなかった場合も、サーバが処理しなかった場合と、処理後に応答が届かなかった場合の両方が考えられます。画面の表示、サーバの記録、再照会の結果など、何を根拠に結論を出すかを明示します。

基本例題：予約の往復を並べる

学習用の予約画面で、利用者は図書室の席を予約します。ブラウザと予約サーバの間でTLSによる保護が成立し、画面の取得と予約の送信はいずれも成功したとします。次の出来事を通信順に並べ、各要求と応答の送り手、内容、保護される区間を答えてください。

ア：サーバが予約の受付結果を返す。
イ：ブラウザが予約画面を要求する。
ウ：ブラウザが日時と席の予約を送る。
エ：サーバが予約画面を返す。

まず、利用者が入力する画面を受け取る必要があります。ブラウザが画面を要求するイが先です。次にサーバが画面を返すエが続きます。利用者が内容を入力した後、ブラウザが予約を送るウ、その結果をサーバが返すアの順です。

1行ずつ対応させると、次のようになります。

1. イ：ブラウザからサーバへ、予約画面の要求を送る。
2. エ：サーバからブラウザへ、予約画面を応答として返す。
3. ウ：ブラウザからサーバへ、日時と席の予約を要求として送る。
4. ア：サーバからブラウザへ、予約の受付結果を応答として返す。

答えはイ、エ、ウ、アです。図2のように、矢印の向きは要求で右向き、応答で左向きになります。2往復を分けることで、画面の取得が成功したことと予約の受付が成功したことを混同せずに済みます。

図2の4本は、条件で成立したブラウザとサーバの間のTLSで保護されます。入力前に利用者が選んだ日時が希望と違っていれば、その誤りは暗号化されても直りません。応答で受付結果を見たら、返された日時と席を元の希望に戻して照合します。

失敗時も同じ順序で考えます。例えば画面取得の要求を送った後、画面の応答が届かなければ、その画面を使った予約送信が成功したとはいえません。別の経路で送信した可能性は、この条件だけでは判断できません。通信の失敗箇所を勝手にサーバ内部と決めず、実際に確認できた最後の出来事を記録します。

標準例題：応答が届かない予約

展示の入場枠を申し込む画面で、ブラウザは保護された通信を確立し、枠Aの予約要求を送信しました。その後、待っても受付結果が表示されません。サーバの処理状況は見えていないものとします。予約が成立したかを判断し、次に確認することを2つ、理由とともに答えてください。

まず、要求を送った事実と、受付結果を受け取った事実を分けます。問題で確認できるのは前者です。サーバが要求を受け取れなかった可能性があります。一方、サーバが予約を受け付けた後に応答が届かなかった可能性もあります。どちらも条件と矛盾しないので、成立したとも成立しなかったとも断定できません。

次に、予約一覧などの照会手段があれば枠Aの記録を確認します。受付済みの記録があれば、画面に返らなかった結果を別の形で確認できます。ただし一覧の更新状況なども条件に依存するため、表示が空であることだけで直ちに未受付と決めないようにします。

さらに、画面や運営側が示す確認方法を使い、重複申込の有無を確認します。結果が不明なまま再送すると、仕組みによっては同じ希望が複数回受け付けられる可能性があります。再送すれば必ず重複するという意味でもありません。再送の扱いが問題で与えられていないため、まず状態を調べるのです。

例えば、照会で枠Aの受付済み記録が1件見つかったとします。この記録は最初の要求が処理された可能性を支えますが、同じ利用者と枠を表すか照合する必要があります。逆に、照会自体が時間切れになった場合は記録の有無が確かめられません。照会の失敗を、予約がないという答えに変えてはいけません。

発展例題：守られた通信と誤った案内

行事の案内サーバには、開催日を誤って入力したページが保存されています。ブラウザは正しいサーバとのTLSによる接続を確立し、そのページを要求しました。通信中の改変はなく、サーバは保存されたページを返し、ブラウザも受信した内容をそのまま表示したとします。表示された開催日が正しいといえるか、通信区間と内容の2点に分けて答えてください。

1. ブラウザがページを要求します。
2. サーバは保存されたページを応答します。
3. 条件により、通信の途中では内容が改変されません。
4. ブラウザは受信したページをそのまま表示します。
5. ただし、サーバに保存された開催日は最初から誤っています。

したがって、表示された開催日は正しいとはいえません。保護された区間の条件と、掲載内容が事実と一致する条件は別です。元の条件へ戻すと、誤りは通信途中ではなく保存済みの内容にあるので、途中で改変されなかったという条件とも矛盾しません。

今度は接続先の確認に失敗した場合を考えます。警告が出たのに、そのまま入力した内容が期待する相手に安全に届いたと断定することはできません。入力を進める前に接続先と警告の意味を確認し、解消できなければ通信を中止します。ページの文章がもっともらしく見えることは、接続先を確認できた根拠にはなりません。

また、端末側で表示や入力が第三者に見られる状態なら、通信経路が保護されてもその端末上の情報が守られるとは限りません。サーバ側でも、復号後の情報をどのように保存し扱うかは別の問題です。図の線の内側にある性質を、線の外側に広げないことが説明の要点です。

誤答を区間に戻して直す

誤答の例は「HTTPSで予約したので、予約の日時は必ず正しく登録される」です。図3のように、この答えは通信の途中の保護から、入力と登録の正しさまで一息に結論しています。入力した日時が希望と違う場合や、サーバが誤った内容を記録する場合を見落としています。

修正すると「TLSによる保護が成立した区間の通信は守られるが、入力や登録の正しさは受付結果などで別に確認する」となります。図3の区切りを指しながら、いつ、どこで誤りが入りうるかを言葉にします。受け取った応答が希望と一致するかを照合すれば、利用者が入力を間違えた場合にも気づける可能性があります。

別の誤答は「応答が来なかったので予約は必ず失敗した」です。理由は、応答が届かなくてもサーバ側の処理が済んでいる場合があるからです。修正後は「処理結果は不明なので、照会などで確認する」です。逆に、送信ボタンを押しただけで成功と決めるのも、サーバの処理を確かめていない点で誤りです。

練習：通信の記録を読む

以下は学習用に作った場面です。指定された形で答え、成立を仮定した条件と未確認の部分を区別してください。

1. 写真展示の案内を取得するとき、ブラウザが案内を要求し、サーバが案内を返しました。2つの出来事を順に、送り手と受け手を含む短文で答えてください。
2. 工作会の申込画面で、正しい接続先とのTLS保護が成立し、入力した人数がサーバに届きました。入力前に希望人数を読み違えた場合、保護だけで誤りが直るか、理由を1文で答えてください。
3. 貸出の延長を要求した後、結果の表示前に通信が途切れました。サーバの処理は不明です。処理について考えられる状態を2つ挙げ、確認方法を1つ答えてください。
4. 案内ページを要求すると接続先の確認に失敗する警告が出ました。希望する相手との安全な通信が成立したと判断できるか、次の行動とともに答えてください。
5. 展示室の閉室日を誤って登録したサーバから、保護された通信でページを正しく受信しました。閉室日を事実と判断できるか、通信と内容の観点から2文で答えてください。

練習の答えと照合

1. ブラウザがサーバへ案内を要求し、サーバがブラウザへ案内を返します。要求が先、応答が後です。元の場面に戻すと、返されたのは要求された写真展示の案内であり、矢印はそれぞれ逆方向です。応答を先に置くと、この要求への返答という関係が崩れます。

2. 直りません。TLSの保護が成立しても、利用者が入力前に読み違えた希望人数を自動で修正するわけではないからです。人数が入力されたまま届いたという条件に戻すと、経路の途中で変更されたと考える必要はありません。希望と送信内容の照合が別に必要です。

3. サーバが延長を処理していない状態と、処理したが結果が届かなかった状態が考えられます。貸出状況の照会などで延長後の記録を確認します。照会にも失敗したなら結果は引き続き不明です。記録が確認できた場合は、対象の貸出と延長内容が一致するかも見ます。

4. 判断できません。警告の原因と接続先を確認し、確認できなければ入力を進めず中止します。警告が出たという条件では、成功した接続を前提に入力内容を守れるとはいえません。画面に案内が表示されても、それ自体は相手の確認が成功した証拠にはなりません。

5. 保護された通信でページを受信したことと、閉室日が事実に合うことは別です。登録時点で閉室日が誤っているため、表示された日を正しいとは判断できません。条件へ戻すと、通信中に改変がなくても元の誤りがそのまま届きます。別の信頼できる案内と照合する必要があります。

覚えておくこと

• 要求はクライアントから、応答はサーバから送られます。
• HTTPSではHTTPの通信をTLSで保護します。
• 保護の成立、接続先、区間を条件として確かめます。
• 内容の真偽や端末での誤りは別に調べます。
• 応答がないときは処理結果を断定せず照会します。

矢印を反対に書く人は、各文の主語と送る内容を先に丸で囲みます。保護の範囲を広げすぎる人には、入力前、通信中、受信後のどこで誤りが生じたかを個別指導で確認します。応答がない場面では、処理済みと未処理の両方を図に戻して説明できるかを見ます。予約の結果は、通信の成否と受付内容をそれぞれ確かめて判断します。