STUDY GUIDE · 期末 · 過去問2022–2025
インターネット
期末 教科書ノート
100点満点を70点に換算する過去問形式向け。入門で用語（約200字）を固め、本編で TCP・経路・WWW を統合し、演習で Dijkstra / AIMD / 記述を手で再現する。
出典: 講義PDF（0–9）＋過去問画像。模範・診断は AI整理（公式正解ではない）。個人情報なし。
Layer 0 · 直前地図
層のイメージ: アプリ/WWW → トランスポート(TCP/UDP) → ネットワーク(IP/経路) → リンク(ARP等)。
試験形式は「用語200字 / TCP説明 / 経路+Dijkstra / WWW・TLS」。
戦略: 年度で出題スロットは回るが、用語プールは共通 → プール完投＋関連知識ゼロ起点。
プール完投ルート（S → 大門スキル）
先に S ランクを答案骨子＋解答例まで潰し、足りない手順はドリルへ。
初見でドリル強制はしない。
| S用語 | 大門/形式 | つなぎ |
|---|---|---|
| End-to-End原則 | 用語200字 | 大門の前提・品質論の土台 |
| HLS / MPEG-DASH | 用語 | B3 |
| HTTPS / SSL・TLS | 用語+WWW | B4・D08 |
| TCP と UDP | 用語+TCP説明 | B1・D04 |
| 経路表エントリの増加 | 用語+論述 | B2・D06 |
| 静的ルーティングと動的ルーティング | 用語+経路 | B2・D05 |
| AIMD | 用語+図 | B1・D03 |
| Dijkstra法（OSPF） | 手計算 | B2・D01/D02 |
| パケット交換方式 | 用語200字 | 網の前提スロット |
まず優先するトピック（頻度上位）
- End-to-End原則 · 3/4 · S
- HLS / MPEG-DASH · 3/4 · S
- HTTPS / SSL・TLS · 3/4 · S
- TCP と UDP · 3/4 · S
- 経路表エントリの増加 · 3/4 · S
- 静的ルーティングと動的ルーティング · 3/4 · S
- AIMD · 2/4 · S
- Dijkstra法（OSPF） · 2/4 · S
| 形式 | まず読む |
|---|---|
| 用語（プール） | 入門 · 頻度表 |
| TCP/UDP・AIMD・handshake | B1 · D03 · 3-way |
| 経路+Dijkstra | B2 · D01 · D02 |
| WWW/TLS/QUIC | B3 · B4 · D08 |
出題頻度ランキング（2022–2025）
青ポチ=その年の過去問範囲で触れたと集計。
S/A/B は年数中心（Sは3年以上、またはTCP/経路/TLSなど応用の土台で2年以上にブースト）。
◇基礎は直接出題は薄いが、答案の土台として必須。
| 重要度 | 用語 | 年数 | 2022–25 | 読み方 |
|---|---|---|---|---|
| S ★★★ | End-to-End原則 | 3/4 | 2022202320242025 | 4年中3年で出現・最優先 |
| S ★★★ | HLS / MPEG-DASH | 3/4 | 2022202320242025 | 4年中3年で出現・最優先 |
| S ★★★ | HTTPS / SSL・TLS | 3/4 | 2022202320242025 | 4年中3年で出現・最優先 |
| S ★★★ | TCP と UDP | 3/4 | 2022202320242025 | 4年中3年で出現・最優先 |
| S ★★★ | 経路表エントリの増加 | 3/4 | 2022202320242025 | 4年中3年で出現・最優先 |
| S ★★★ | 静的ルーティングと動的ルーティング | 3/4 | 2022202320242025 | 4年中3年で出現・最優先 |
| S ★★★ | AIMD | 2/4 | 2022202320242025 | 4年中2年で出現・最優先 |
| S ★★★ | Dijkstra法（OSPF） | 2/4 | 2022202320242025 | 4年中2年で出現・最優先 |
| S ★★★ | パケット交換方式 | 2/4 | 2022202320242025 | 4年中2年で出現・最優先 |
| A ★★ | DHCP | 2/4 | 2022202320242025 | 4年中2年で出現・高 |
| A ★★ | DNS | 2/4 | 2022202320242025 | 4年中2年で出現・高 |
| A ★★ | HTML と CSS | 2/4 | 2022202320242025 | 4年中2年で出現・高 |
| A ★★ | ICMP / ICMPv6 | 2/4 | 2022202320242025 | 4年中2年で出現・高 |
| A ★★ | TCPが遅延・スループットを保証しない理由 | 2/4 | 2022202320242025 | 4年中2年で出現・高 |
| A ★★ | コネクションレス | 2/4 | 2022202320242025 | 4年中2年で出現・高 |
| B ★ | ARP（IP→MAC変換） | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | HTTP/2の課題とHTTP/3 | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | LPWA | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | NAT | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | OSI参照モデル | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | QUIC（HTTP/3） | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | SIP | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | TCP 3-way handshake | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | TTL（IPヘッダ） | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | Tail drop | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | WebAPI | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | hop-by-hop 経路制御 | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | ウィンドウ型フロー制御 | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | サブネットマスク（経路制御での役割） | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | ベストエフォート | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | 品質問題への対策の方向 | 1/4 | 2022202320242025 | 4年中1年・押さえる |
| B ★ | 認証局（CA）とPKI | 1/4 | 2022202320242025 | 4年中1年・押さえる |
基礎（出題が薄くても入れる）
| 区分 | 用語 | 年数 | マーク | メモ |
|---|---|---|---|---|
| 基礎 ◇基礎 | IPアドレス | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
| 基礎 ◇基礎 | MACアドレス | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
| 基礎 ◇基礎 | ルータとスイッチ | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
| 基礎 ◇基礎 | ポート番号 | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
| 基礎 ◇基礎 | パケットとヘッダ | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
| 基礎 ◇基礎 | TCP/IP 4層モデル | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
| 基礎 ◇基礎 | CDN | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
| 基礎 ◇基礎 | 輻輳 | 0/4 | 2022202320242025 | 過去4年は直接出題が薄いが答案の土台 |
入門編 · 用語カード（L0–L1）· ゼロ起点 Primer
各カードに 重要度（S/A/B/基礎） と 過去4年中の出題年数（青ポチ=その年）を付けた。⓪ 基礎は過去問の直接出題が薄くても、答案の床として必須。End-to-End・パケット交換・TCP/UDP・経路などをカードで押さえる。下の各カードが L1 金標準。並びは 出題頻度表 で切り替えられる。
⓪ 出題が薄くても必須の基礎
IPアドレス（アイピーあどれす）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
インターネット上で「どの端末（インタフェース）宛てか」を示すための論理番号。人間が覚えやすい名前（www…）ではなく、機械とルータが転送に使う住所。IPv4は32bit（例: 192.0.2.10 の4つに区切った表記）、IPv6は128bit。
別名 論理アドレス（アドレス空間上の番号）。対比のMACアドレス＝同じ線（リンク）上の機器シールに近い物理側の識別子。DNSが「名前→IP」に変換する相手がまさにこれ。
なぜ 郵便で言えば「市区町村〜番地」がないと配達できないのと同じで、パケットにも送る先と戻し先の番号が要る。ルータは宛先IPを見て「次にどの装置へ渡せばよいか」を決める。だからDNSで求めた結果・DHCPで借りた番号・NATで外へ出す番号も、最終的にはIPに落ちる。IPを抜かすと上位（DNS/経路/TCP）の説明が宙に浮く。
日常のたとえ：インターネット上の郵便番号＋番地。どの網のどのホストか。
人が読む名前
www.example.com
（覚えやすい・変わり得るラベル）
（覚えやすい・変わり得るラベル）
機械が使うIP
203.0.113.10
（パケットヘッダに載る番号）
（パケットヘッダに載る番号）
具体の一コマ：PC(自分=10.0.0.2)がサーバ(203.0.113.10)へ送るパケットの表紙には「差出=10.0.0.2／宛先=203.0.113.10」と書かれる。途中のルータは宛先だけ見て次の出口を選ぶ。
仕組み 網全体でホストやインタフェースを指す論理の届け先番号。IPv4は32bit、IPv6は128bit。パケットヘッダの宛先／送信元に載る。ルータは宛先IPを経路表で照合して次ホップを決める。DNSが名前から解決し、DHCPが端末へ配布するのもこの番号。
答案骨子 答案骨子（用語・土台説明）: ①インターネット上のホスト/インタフェースを示す論理アドレス ②IPv4=32bit／IPv6=128bitを一言 ③パケットに載り、ルータが宛先IPで次ホップを決める ④DNSは名前→IP、DHCPはIPの配布、という位置づけ。
解答例見本（目安150–220字・AI整理） IPアドレスはインターネット上のホストやインタフェースを識別する論理アドレスである。IPv4は32bit、IPv6は128bitで表され、パケットヘッダに載る。ルータは宛先IPを経路表で照合し次ホップを決める。DNSが解決しDHCPが配布するのも、この届け先番号である。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 「アドレス」が全部同じに見えて、MAC（近所のシール）と混ざる
NG IPは見た目のラベル／シールで、世界中で同じ一枚で済む物理スタンプだと思い込む
正しい見方 IPは網をまたいで使う論理の届け先。MACは同じリンク内の配送ラベル、と分けて書く
MACアドレス（マックあどれす）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
同じEthernetなどの「一本のリンク（LAN区間）」の中で、どのNIC（LANポート）宛てかを示すアドレス。世界地図の番地（IP）ではなく、同じ部屋の机札に近い。
別名 リンク層（L2）アドレス。ハードウェアアドレスと呼ばれることもある。対: IPアドレス（広い論理届け先）。
なぜ ルータやPCが「同じスイッチにつながる隣」へフレームを渡すとき、LAN上ではMAC宛先が要る。IPしか知らないと、同じ線上の誰に渡すか決められない。そこでARP（IPv4）などが「このIPは今どのMACか？」を解決する。
IP（大陸を跨ぐ住所）
東京の家 → 大阪のビル
ルータがIPで経路を選ぶ
ルータがIPで経路を選ぶ
MAC（その区間の机札）
同じスイッチに刺さった隣へ
フレーム宛先にMACを書く
フレーム宛先にMACを書く
一コマ：宛先IPは203.0.113.10のまま変わりにくくても、次ホップが変わるたび「いま渡す相手のMAC」は付け替わる。
仕組み 同じLAN区間でNICを名指しするリンク層の名札。Ethernetフレームの宛先に入り、スイッチの学習と転送の手がかりになる。IPが広域の論理届け先、MACが各ホップ区間の配送ラベル。ARPなどでIPと対応づける。
答案骨子 答案骨子: ①同一リンク上のインタフェース識別 ②L2フレームに載る ③ARPがIP→MACを解決 ④IP（エンドtoエンドの論理）と役割分担。
解答例見本（目安150–220字・AI整理） MACアドレスは同一リンク上でNICを識別するリンク層アドレスである。Ethernetフレームの宛先に使われ、スイッチの学習・転送の手がかりとなる。IPが網全体の論理届け先であるのに対し、MACは各ホップ区間の配送ラベルで、ARPなどでIPと対応づけられる。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 「グローバルに一意」の話と「どこまで届けられるか」を混ぜやすい
NG MACだけで大陸間到達できる／IPの代わり、と書く
正しい見方 届ける範囲はまずリンク内。網を跨ぐ判断はIP側、と書く
ルータとスイッチ（るーた／すいっち）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
スイッチはおもに同じLAN内でMACを見てフレームを中継する装置。ルータはIPと経路表を見て、異なる網のあいだでパケットの次ホップを選ぶ装置。どちらも「中継」だが、見る情報と跨げる範囲が違う。
別名 ざっくりL2機器 vs L3機器（実際の製品は機能が重なるが、試験の概念図では役割で切る）。
なぜ 経路制御やhop-by-hop、Dijkstra、経路表の話は『誰がIPで判断するか』が前提。スイッチとルータを同じハブ扱いすると、TTL・経路表・サブネットの論点が消える。
スイッチ
同じ建物のフロア内
MAC表でどのポートへ出すか
MAC表でどのポートへ出すか
ルータ
建物から外の網へ
宛先IP→次ホップを経路表で選択
宛先IP→次ホップを経路表で選択
仕組み スイッチは主にMACを見て同一LAN内でフレームを中継する。ルータはIPと経路表を見て異なるネットワーク間の次ホップを選ぶ。どちらも中継装置だが、見る層と到達範囲が違う。経路制御やDijkstraの議論ではルータが経路表の主体。
答案骨子 答案骨子: ①見る層と識別子（MAC/IP） ②跨ぐ範囲（LAN内/網跨ぎ） ③経路表を持つ主体はルータ側、と明記。
解答例見本（目安150–220字・AI整理） スイッチは主にMACアドレスを見て同一LAN内でフレームを中継する装置である。ルータはIPアドレスと経路表を見て異なるネットワーク間で次ホップを選ぶ装置である。中継は共通だが参照する層と到達範囲が異なり、経路制御の主体はルータ側である。層（MACかIPか）と到達範囲の違いを並べると対比が完成する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 箱が似ているので全部『中継機』で済ましてしまう
NG ルータ=ハブ／スイッチと同じ、とだけ書く
正しい見方 スイッチはMACとLAN内、ルータはIPと網跨ぎ、と役割を分ける
ポート番号（ぽーとばんごう）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
1台のマシン（1つのIP）の上で、どのアプリ／サービスの窓口かを示す番号。TCP/UDPヘッダに載る。例としてHTTPSはよく443が使われる（典型例）。
別名 トランスポート層のサービス識別子。IPが建物ならポートは部屋番号、と覚えると速い。
なぜ IPだけでは「そのPCの誰宛てか」が足りない。ブラウザ・メール・ゲームが同時に動くとき、戻りパケットを正しいプロセスへ返すためにポートがある。NAT/NAPTも内外をポート込みで対応づける。
IPだけ
「203.0.113.10へ届け」だけ
中の誰か不明
中の誰か不明
IP + ポート
203.0.113.10:443 → Webサーバ
同じIPの別番号 → 別サービス
同じIPの別番号 → 別サービス
仕組み 一つのIPの中で、どのプロセス／サービス宛てかを示す部屋番号。TCP/UDPヘッダに載る。HTTPSの443などが典型。IPがホスト、ポートがホスト内の窓口。セットでソケットになる。NAPTではアドレスとポートの組で内側を識別する。
答案骨子 答案骨子: ①トランスポート層 ②プロセス/サービス識別 ③IPとの役割分担（ホスト vs ホスト内） ④NATやTCP/UDP説明に触れるならポート対応を一文言及。
解答例見本（目安150–220字・AI整理） ポート番号は一つのIPアドレス上でどのサービスやプロセス宛てかを示すトランスポート層の識別子である。TCP/UDPヘッダに載り、HTTPSの443などが典型である。IPがホストを指しポートがホスト内の窓口を指す。NATではアドレスとポートの組で対応づける。ホスト内の多重サービス識別、と一言足すと役割が際立つ。
よくある誤解
なぜ起きるか IPの一部や『LANの穴』と混ざる
NG ポート番号=IPの下位ビット／物理コネクタだけ、と書く
正しい見方 同じIP上でサービスを分ける番号、と書く
パケットとヘッダ（ぱけっととへっだ）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
送りたい中身（ペイロード）に、宛先や制御のための前書き（ヘッダ）を付けた小包がパケット。網は中身を読まなくても、ヘッダだけで転送判断できる。
別名 ペイロード＝本体データ。層ごとにヘッダが積み上がる（カプセル化）。
なぜ パケット交換は『小分けして各自で運ぶ』方式なので、各小包に『どこへ／何番か』が必要。TTLやIPアドレス、ポートもヘッダの話。ヘッダが無いとルータもスイッチも届け先が分からない。
ヘッダ（表書き）
宛先IP・送信元IP・TTL …
ペイロード（中身）
WebのHTMLのかけら、画像の一部 など
送信時に外側から順にヘッダを付け、受信時に内側へ向かって剥がす、とイメージする。
仕組み ペイロードの前に付く伝票。宛先・送信元・TTL・プロトコル種別など。中継装置は中身を全部読まなくてもヘッダで次の動作を決められる。層が下がるほどヘッダが積み重なるカプセル化。分割転送と再組立の前提。
答案骨子 答案骨子: ①データ＋制御情報の転送単位 ②ヘッダに識別・制御 ③ペイロードは中身 ④分割転送・再組立やTTLの議論への橋渡し。
解答例見本（目安150–220字・AI整理） パケットは転送したいデータに、宛先や制御情報を含むヘッダを付けた転送単位である。ルータなどはヘッダを見て次ホップを決め、中身を読まなくても転送できる。各層でヘッダが積み重なるカプセル化により、分割転送と再組立が可能になる。中継はヘッダ参照が基本で、ペイロード検査は必須ではない。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 『データさえ載せれば届く』と思って制御情報を忘れる
NG ヘッダは飾り／中身だけ送ればよい、と書く
正しい見方 届け先と制御はヘッダが担う、と書く
TCP/IP 4層モデル（てぃーしーぴーあいぴー）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
いまのインターネットを、役割ごとに粗い4段に分けた実務寄りの地図。上からアプリ → トランスポート（TCP/UDP） → インターネット（IP） → リンク（Ethernet等）。OSIの7層より段が少なく、実装に近い。
別名 インターネット階層モデル。OSIとは対応づけて覚える（厳密1対1ではない）。
なぜ 「TCPはどこ？ IPはどこ？ HTTPはどこ？」を一枚の地図で固定するため。試験のOSI説明やTCP/UDP対比も、この位置関係が無いと用語が迷子になる。
上から仕事の流れ（送信イメージ）
①アプリがHTTPなどで要求を作る
②TCP/UDPがポート・信頼（有無）を付ける
③IPが届け先ホストを付ける
④リンクが隣のMACへ乗せる
①アプリがHTTPなどで要求を作る
②TCP/UDPがポート・信頼（有無）を付ける
③IPが届け先ホストを付ける
④リンクが隣のMACへ乗せる
OSI
7段の参照モデル
（用語の共通語）
（用語の共通語）
TCP/IP
4段で実装を見やすい
（試験は両方の対応が書けると強い）
（試験は両方の対応が書けると強い）
仕組み アプリ・トランスポート・インターネット・リンクなど役割を縦に重ねた実務モデル。上位は下位のサービスだけを使い、差し替えやすくする。TCP/UDPはトランスポート、IPはインターネット層に位置づけ。OSI七層と対応づけて説明すると試験で強い。
答案骨子 答案骨子: ①4層の名称（または役割） ②上位は下位を利用 ③OSIとの対応例を1つ ④TCP=トランスポート、IP=インターネット層、と位置を明示。
解答例見本（目安150–220字・AI整理） TCP/IPモデルはアプリケーション・トランスポート・インターネット・リンクなどにおおむね分けた実務寄りの階層モデルである。上位は下位のサービスを利用し、TCPはトランスポート、IPはインターネット層に位置する。OSI七層と対応づけて説明すると試験で整理しやすい。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか OSIと同じ7段と覚え込んでいる
NG TCP/IPも必ず7層、と断言する
正しい見方 4層（または5層表記）の実務モデルで、OSIと対応づける、と書く
CDN（シーディーエヌ）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
動画やWebのファイルを、本家サーバ1台だけからではなく、利用者の近くに置いたコピー（キャッシュ）から届ける配信網。Content Delivery Network の略。
別名 コンテンツ配信ネットワーク。ISP（回線事業者）そのものではない。
なぜ 本家が遠いと遅延と混雑が起きる。HLSや大きな静的ファイルは近くから取るほど体感が良く、本家の負荷も減る。期末の配信・WWWの『なぜ速い／分散するか』の背景知識。
CDNなし
全員が遠い本家1台へ殺到
遅延・輻輳しやすい
遅延・輻輳しやすい
CDNあり
近くの節点のコピーへ誘導
距離と本家負荷を下げる
距離と本家負荷を下げる
仕組み 人気コンテンツを各地のキャッシュに置き、利用者に近い点から返す。遅延と本家オリジンの負荷を下げる。動画や静的Webと相性がよい。HLSなどのセグメント配信とも相性がいい。ISP回線の別名ではなく、コンテンツ配置と誘導の仕組み。
答案骨子 答案骨子: ①地理分散キャッシュ ②利用者近傍から配信 ③遅延低減・本家負荷分散 ④HLS/Webなど大容量配信の文脈で触れると加点につながりやすい。
解答例見本（目安150–220字・AI整理） CDNはコンテンツを地理的に分散したキャッシュから配信するネットワークである。利用者の近くの節点から返すことで遅延と本家サーバ負荷を下げ、動画や静的Web配信と相性が良い。ISP回線そのものの別名ではなく、コンテンツ配置と誘導の仕組みである。オリジン負荷軽減と遅延短縮の二つの効果が主目的である。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか インターネットやISPと同一視しやすい
NG CDN=インターネットの別名／回線そのもの、と書く
正しい見方 コンテンツを近くから配るための分散キャッシュ網、と書く
輻輳（ふくそう）とは、
重要度メモ 過去4年は直接出題が薄いが答案の土台
· 出現年: 出題なし（基礎）
ある場所にトラフィックが集中し、キューが伸びて遅延が増え、最悪パケットが捨てられる状態。線が『完全に切れた』故障というより、高速道路の渋滞に近い。
別名 網の過負荷による品質劣化。ベストエフォート網では起きうる前提。
なぜ AIMD・窓制御・tail drop・ベストエフォートを説明する因果の中心。『なぜTCPは速度を上げ下げするか』の答えが「輻輳を検知して共有帯域を譲り合うため」。
空いているリンク
すぐ転送・待ち少ない
輻輳
出口が細いのに車が殺到
待つ（遅延）・溢れて破棄（ロス）
待つ（遅延）・溢れて破棄（ロス）
TCPはロス等を合図にウィンドウを下げ、開いたら少しずつ上げる（AIMD）—輻輳へのエンドツーエンドな反応。
仕組み リンクや装置に流入が集中しキューが伸び、遅延増・最悪は破棄が起きる過負荷。ケーブル断とは違う、共有帯域の混雑。Tail dropなどでロスが起き、TCPはAIMDで送り量を下げる反応をする。定義では遅延と破棄、原因は過剰流入をセットで。
答案骨子 答案骨子: ①集中により遅延・損失が増える状態 ②故障切断との区別 ③TCPは窓で反応／キュー破棄が合図になり得る ④AIMDやtail dropへ接続。
解答例見本（目安150–220字・AI整理） 輻輳とは、リンクや装置にトラフィックが集中しキューが伸びて遅延が増え、最悪パケット破棄が起きる過負荷状態である。物理的な断線とは異なり、共有帯域の混雑による品質劣化である。TCPは損失などを契機にウィンドウを下げ（AIMD）、輻輳にエンドツーエンドで反応する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 『つながらない＝壊れた』とだけ思い込む
NG 輻輳＝ケーブル切断・電源オフ、と書く
正しい見方 過負荷で待たされ・捨てられる状態、と書く
① 網の前提
パケット交換方式（ぱけっとこうかん）とは、
重要度メモ 4年中2年で出現・最優先
· 出現年: 2024、2025
送りたいデータを小さなパケットに分割し、各パケットがヘッダを持って網の中を独立に転送され、受信側で元のデータに組み立て直す通信方式。回線を通話時間まるごと占有する回線交換と対になる。
別名 パケット交換・ストアアンドフォワード型転送のイメージ。対: 回線交換（経路を専有してから通信）。
なぜ 1本の回線を時間で多くの通信が共有できるので、帯域の使い方が効率的。途中経路が壊れても別経路へ迂回しやすいなど、共有網上の頑健さにもつながる。現代インターネットの前提モデルそのものなので、他の用語説明の床になる。
回線交換
通話のあいだ経路を1組が占有
空いていても他は使えない
空いていても他は使えない
パケット交換
小包に分けて共有回線へ流す
空いたスロットを他通信が埋める
空いたスロットを他通信が埋める
一コマ：長い手紙を数枚のハガキに分け、それぞれ別便で投函→相手宅で並べ直す。各ハガキに宛名・枚数（ヘッダ）が要る。
仕組み 送信側がデータを小パケットに分割し、各パケットに宛先などのヘッダを付ける。各ルータは宛先を見て次ホップへ転送し、回線を時間で多数の通信が共有する。受信側が順序を手がかりに再組立する。経路は通信中に変わってもよい。回線交換（経路を時間占有）との対比が答案の締めになる。
答案骨子 答案骨子: ①データを小パケットに分割 ②ヘッダ付きで独立転送 ③回線を時間共有・受信側で再組立 ④回線交換との違いを1文。約200字なら「分割→独立転送→共有→再組立」を必ず埋める。
解答例見本（目安150–220字・AI整理） パケット交換方式とは、送信データを小さなパケットに分割し、各パケットがヘッダにもとづき網内を独立に転送され、受信側で再組立する通信方式である。回線交換のように経路を時間占有せず回線を共有できるため帯域利用が効率的である。現代インターネットの転送モデルの前提となる。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 「交換」という語だけで止まり、回線交換と何が違うか書けない
NG 電話の交換機と同じ仕組みだとだけ書く
正しい見方 分割して独立転送し共有回線を時間割する点が要点、と書く
End-to-End原則（エンドトゥエンドげんそく）とは、
重要度メモ 4年中3年で出現・最優先
· 出現年: 2022、2023、2024
信頼転送・暗号化など「正しさの保証」を要する機能は、網の途中装置に任せず通信の両端（エンドホスト／プロセス）で実現する、という設計原則。途中のIP網はできるだけ単純な転送に徹する。
別名 E2E原則・エンドツーエンド原則。対: 網内高機能（知能的ネットワーク）寄りな設計。
なぜ 途中ルータが壊れたり、途中だけが間違った保証をしても、両端が検査できれば誤りを検出・回復できる。中間層を単純に保てば多様なアプリを載せ替えやすい。「機能をどこに置くか」の話であり、物理的に直線でつながることではない。
日常のたとえ：手紙の正しさは郵便局ではなく差出人・受取人が検査する、という役割分担。
NGの置き方
途中ルータに再送や暗号を任せる
端は「信じ切る」
端は「信じ切る」
E2E
両端ホストが再送・確認・暗号
途中はベストエフォート転送
途中はベストエフォート転送
日常: 郵便屋に手紙の中身の正しさまで保証させず、差出人と受取人が内容確認する、に近い。
仕組み 要点は機能をどこに置くか。再送や暗号化など正しさの最終確認は、途中ルータではなく両端アプリ（ホスト）がやる。なぜか。途中装置が保証しても経路変更や故障で保証が崩れる。両端が検査すれば最後まで正しいと言える。IPは届いたらよい転送に徹し、TCPの再送やTLSの暗号は端点の仕事、という分け方になる。注意。物理的に一直線でつながること、という意味ではない。
答案骨子 答案骨子: ①機能は両端で実現 ②網（途中）はシンプル転送 ③理由（障害耐性・柔軟性・多様なアプリ） ④具体例を1つ（TCP再送やTLSなど）。
解答例見本（目安150–220字・AI整理） End-to-End原則とは、信頼転送や暗号化など正しさの保証を途中の網ではなく通信の両端で実現する設計方針である。途中装置に依存すると経路変更や故障で保証が崩れるため、IPは単純転送に留め、TCPの再送やTLSなどはエンドホストが担う。結果として多様なアプリを同じ網に載せやすくなる。物理的な一直線接続の意味ではない点に注意する。
よくある誤解
なぜ起きるか 「端から端までパケットが届く」という到達そのものと混同する
NG 物理的に一直線でつながること、と書く
正しい見方 機能配置の原則（どこで保証するか）と答える
コネクションレス（コネクションレス）とは、
重要度メモ 4年中2年で出現・高
· 出現年: 2022、2023
通信の前に経路や接続状態を確立する手続きをせず、各データグラム（パケット）を独立に送る通信の性質。IPやUDPが典型。対してTCPはコネクション指向。
別名 コネクションレス型通信。対: コネクション指向（ハンドシェイクで状態を共有してから転送）。
なぜ 確立手続きの往復を省略できるためオーバーヘッドが小さい。網側がフローごとの状態を持たなくてよく、大規模転送に向きやすい。その代わり、順序や到達保証は上位層やアプリの責任になる。
日常のたとえ：ハガキを出すのに前契約なしで投函する。届く保証は別の仕組み次第。
コネクション型
握手→状態共有→通信→切断
コネクションレス
そのまま投げる
到着保証は別層
到着保証は別層
仕組み 事前に状態を確立せず、各パケットを独立に送る転送モデル。IPやUDPが典型。握手が要らず軽い一方、順序や到達は保証されない。保証が必要ならTCPなど上位が後付けする。日常語の接続できないではなく、転送モデルの話。
答案骨子 答案骨子: ①事前コネクションなし ②パケット独立転送 ③状態を網が持たない ④例（UDP/IP）と対（TCP）を1文。
解答例見本（目安150–220字・AI整理） コネクションレスとは、通信開始前に接続確立の手続きを行わず、データグラムを独立に送る性質である。IPやUDPがこれに当たり、低オーバーヘッドで送信できる反面、順序や到達は保証されない。保証が必要ならTCPなどコネクション指向の上位プロトコルが担う、と対比して書くと答案が安定する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 「接続がない＝そもそも通信できない」と日常生活語に引きずられる
NG インターネットは常に接続なしで動かない、などと一般化する
正しい見方 転送モデルの説明としてTCPと対比する
ベストエフォート（べすとえふぉーと）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2022
網は「できる限り」パケットを転送しようとするが、遅延・帯域・損失率などの品質を契約として保証しないサービスモデル。IPの基本思想。 試験では定義・理由・対比を短くセットで書く。
別名 ベストエフォート型サービス。対: 厳密なQoS保証型（資源予約など）。
なぜ 保証の仕組みを網全体に持たせると複雑でスケールしづらい。多様なアプリが同じ共有網を使える単純さがインターネットの強み。品質が要る用途は端点設計や別技術で補う前提になる。
日常のたとえ：宅配便の「できる限り届ける」：遅延保証や必ず当日着、ではない。
保証型
帯域・遅延を契約で約束
ベストエフォート
可能なら届ける
混雑時は遅延・ロス増
混雑時は遅延・ロス増
仕組み 網はできる限り届けるが、遅延・帯域・損失を契約として約束しない。混雑するとキューが伸び、溢れると捨てられ品質がブレる。TCPの再送は最終的に届ける努力で、何ミリ秒以内の約束ではない。ベストが最高保証ではない点を答案で明示する。
答案骨子 答案骨子: ①努力はするがSLA保証なし ②遅延・スループット・損失を列挙 ③IPの性質／TCP信頼性との切り分け ④混雑で品質が変動する点。
解答例見本（目安150–220字・AI整理） ベストエフォートとは、網が可能な範囲でパケットを転送するが、遅延や帯域、損失を保証しないサービスモデルである。IPはこれを基本とし、混雑時には遅延増大や破棄が起こり得る。TCPの再送によって信頼性は上がっても、遅延やスループットの数値保証にはならない点を明示する。 ここを答案に書けば減点が減る。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 「最良」という言葉から最高品質保証と読む
NG 必ず最速・無損失で届くと書く
正しい見方 努力するが品質の数値保証はない、と書く
OSI参照モデル（オーエスアイさんしょう）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2022
通信に必要な機能を7つの層に整理し、層ごとに役割とインタフェースを明確化した標準的な参照モデル（物理〜アプリケーション）。実網ではTCP/IPモデルと対応づけて使う。
別名 OSI 7層参照モデル。TCP/IP 4層と並べて覚えると試験で強い。
なぜ 問題を層で切り分けられる（物理断か、経路か、アプリか）。下位を差し替えても上位仕様を再利用できる相互運用の共通語になる。
日常のたとえ：工場の工程表：材料→部品→組立…と役割を段に分けて検査しやすい。
要点：OSI参照モデル
上→下の記憶フック
アプリ — プレゼン — セション — トランスポート — ネットワーク — データリンク — 物理。試験は名称羅列より「なぜ分けるか＋1層の役割例」が効く。
アプリ — プレゼン — セション — トランスポート — ネットワーク — データリンク — 物理。試験は名称羅列より「なぜ分けるか＋1層の役割例」が効く。
仕組み 物理からアプリまで七段に役割を分け、層ごとにインタフェースを決める参照モデル。上位は下位のサービスを使い、送信では下へ向かってヘッダが増えるカプセル化。障害切り分けと相互運用の共通語になる。実網はTCP/IP四層と対応づけて説明すると点が取りやすい。
答案骨子 答案骨子: ①7層に役割分担 ②相互運用・切り分けの目的 ③代表層を1つ例示 ④TCP/IPとの対応に1文言及できると加点。
解答例見本（目安150–220字・AI整理） OSI参照モデルは通信機能を七層に整理し、各層の役割とインタフェースを標準化した参照モデルである。上位は下位のサービスを利用し、障害の切り分けと相互運用の共通語になる。たとえばトランスポート層は端点間の信頼性などを扱い、実網ではTCP/IPモデルと対応づけて理解する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 層名の暗記だけで「なぜ」がない
NG 層名を並べて終わり（混同しやすい）
正しい見方 役割分担の目的＋具体層の仕事を書く
NAT（ナット）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2022
私有IPアドレスとグローバルIPアドレスの対応を境界で変換し、複数の内側端末が限られたグローバルアドレスを共有できるようにする技術。実務ではポートも写すNAPTが主流。
別名 Network Address Translation。NAPT/IPマスカレードはポート変換付き。
なぜ IPv4アドレス枯渇への現実的対策であり、内側構成を外側に晒しにくくもする。家庭ルータの「外から見える1つのIP」の正体の多くがこれ。
日常のたとえ：マンションの受付が外線番号を共有し、内線表で誰の通話か戻す。
内側
192.168.x.x など私有
端末が多数
端末が多数
外側
グローバルIP＋ポート対応表
戻り通信を内側へ戻す
戻り通信を内側へ戻す
仕組み 玩具例。内側PCは 192.168.1.10（送信元ポート51000）、外側はルータの 203.0.113.5。外向きのときルータが送信元を外側のアドレスと別ポートへ書き換え、変換表に内側と外側の対応をメモする。外のサーバは外側アドレス宛てに返事を返し、ルータが表を見て元の内側へ書き戻す。多数端末が一つのグローバルIPを共有できる（NAPTはポートも使う）。VPNや暗号化本体ではない。
答案骨子 答案骨子: ①私有⇔グローバルの変換 ②対応表（NAPTならポート） ③アドレス節約の目的 ④暗号化技術ではない点を混同しない。
解答例見本（目安150–220字・AI整理） NATは私有IPとグローバルIPを境界装置で変換し、複数端末が少ないグローバルアドレスを共有する技術である。外向きは送信元を書き換え変換表に残り、戻りは表を見て内側へ戻す。実務ではポートも使うNAPTが主流である。IPv4節約と内側構成の隠蔽が目的であり、VPNや暗号化そのものではない。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか VPNや暗号化と名前が近く混同する
NG NAT＝VPN／通信を暗号化する本体
正しい見方 アドレス（とポート）の変換に限定して書く
② アドレスと名前
DNS（ディーエヌエス）とは、
重要度メモ 4年中2年で出現・高
· 出現年: 2023、2025
人が使うホスト名と、機械が使うIPアドレスなどを対応づける分散型の名前解決システム。問い合わせを階層的にたどり、A/AAAA等のレコードを返す。 試験では定義・理由・対比を短くセットで書く。
別名 Domain Name System。再帰リゾルバと権威サーバの役割分担。対比: DHCPは設定配布。
なぜ 人が覚えやすい名前でサービスを探せる。サーバのIPが変わっても名前側を更新すれば利用側を変えにくい。
日常のたとえ：電話帳：店名（ホスト名）から番号（IP）を調べる。番号を配る係ではない。
人
www.example.com
機械
203.0.113.10 など
電話帳: 名前を調べて番号（IP）を得る。番号を配るDHCPとは役割が違う。
仕組み 役割分担で覚える。ブラウザは本を取る係に一回頼むだけ。リゾルバがまずキャッシュを見る。無ければルート、次にTLD、次に権威サーバと案内をたどる。権威がAレコードなど最終答を返し、リゾルバが依頼元へ渡す。次回はキャッシュで速い。DHCP（アドレス配布）とは別仕事で、名前解決が本体。
答案骨子 答案骨子: ①名前→IP（等） ②階層構造 ③キャッシュ ④DHCPとの違い（割当ではなく解決）。
解答例見本（目安150–220字・AI整理） DNSはホスト名をIPアドレスなどに変換する、分散型の名前解決システムである。リゾルバがキャッシュを使い、無ければルートからTLD・権威サーバへ階層的に問い合わせ、AやAAAAなどのレコードを得る。人が覚えやすい名前でサービスに到達でき、アドレスを配布するDHCPとは役割が異なる。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか DHCPと役割を混同する
NG DNSが端末にIPを割り当てる、と書く
正しい見方 名前解決のみを書く（混同しやすい）
DHCP（ディーエイチシーピー）とは、
重要度メモ 4年中2年で出現・高
· 出現年: 2023、2025
端末にIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバなどネットワーク設定を自動配布するプロトコル。リース期限付きでアドレスを貸し出す。
別名 Dynamic Host Configuration Protocol。DORA（Discover-Offer-Request-Ack）が手順の骨格。
なぜ 手設定ミスを減らし、大量・移動端末を運用できる。アドレスの回収と再利用で管理コストを下げる。
日常のたとえ：チェックインで部屋番号・Wi‑Fi設定をその場で貸し出す。電話帳ではない。
要点：DHCP
DORA（概要）
Discover（探す）→ Offer（提案）→ Request（希望を伝える）→ Ack（確定）。試験は4手の流れが言えれば十分。
Discover（探す）→ Offer（提案）→ Request（希望を伝える）→ Ack（確定）。試験は4手の流れが言えれば十分。
仕組み DORAの四手で設定を貸し出す（DNSの名前解決とは別）。Discoverでサーバを探し、OfferでIP・マスク・ゲートウェイ・DNS・リースを提案する。Requestで希望を伝え、Ackで確定。期限後は更新や返却でプールを再利用する。手入力ミスを減らす自動化が本体。
答案骨子 答案骨子: ①自動設定の対象列挙（IP/マスク/GW/DNS） ②動的割当・リース ③手設定削減の意義 ④DNSとの対比1文。
解答例見本（目安150–220字・AI整理） DHCPは端末にIPアドレス、サブネットマスク、ゲートウェイ、DNSサーバなどの設定を自動配布するプロトコルである。Discover・Offer・Request・Ackの流れでリースを確定し、期限後は更新や回収をしてアドレスを再利用する。名前をIPに変えるDNSとは別の、ネットワーク設定を貸し出す仕組みである。
よくある誤解
なぜ起きるか DNSと「ネットが使えるようにする」一点で混同
NG 名前をIPに変える、と書く
正しい見方 アドレス等の設定配布、と書く
TTL（IPヘッダ）（ティーティーエル）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2023
IPヘッダの残り寿命フィールド。ルータを1ホップ通るたびに減り、0になるとパケットを破棄して無限ループを防ぐ。IPv6では Hop Limit が相当。
別名 Time To Live（現代では実質ホップカウント）。
なぜ 経路設定ミスなどでループしてもパケットが永遠に回らない。tracerouteはこの減算とICMP通知を利用して経路を観察する。
日常のたとえ：切手の有効回数：経由局ごとに消し込み、0で廃棄し無限巡回を止める。
送信時
TTL=64 などをセット
各ルータ
1減らし、0なら破棄＋通知
仕組み IPヘッダの残り寿命。経由ルータごとに値を減らし、0で破棄する。経路ループがあっても無限巡回しないようにする安全装置。現代実装では実質ホップ数制限。tracerouteはわざと小さくして応答を集める。「時間そのもの」だけが主題ではなく、ループ防止が定義の芯。
答案骨子 答案骨子: ①ループ防止 ②ホップごとに減少 ③ゼロで破棄 ④（任意）traceroute利用。秒数厳密主義にしない。
解答例見本（目安150–220字・AI整理） IPヘッダのTTLはパケットの残り寿命を表し、ルータを経由するたびに減算される。値0で破棄され、経路ループによる無限巡回を防ぐ。現代実装では実質ホップ数制限として働き、tracerouteなどの診断にも利用される。時間の秒数そのものより、ホップ数制限としての役割を強調する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 名前どおり「秒」だけだと覚える
NG 必ず1秒減る、と断言
正しい見方 実質ホップカウントでループ防止、と書く
ARP（IP→MAC変換）（アープ）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2023
同一リンク（同じEthernetなど）の中で、「次に渡したい相手のIP」に対応するMACアドレスを問い合わせ、L2フレームの宛先を決める仕組み。 試験では定義・理由・対比を短くセットで書く。
別名 Address Resolution Protocol。IPv6では Neighbor Discovery（ICMPv6）。対比: DNSは名前→IP。
なぜ IPという論理住所だけでは、同じ線上のどのNICにフレームを渡せない。次ホップのMACが分かって初めて、リンク層の配送が完成する。
日常のたとえ：同じ部屋で「3番席の人」の顔写真（MAC）をその場で尋ねる。
知っている
次ホップのIP
欲しい
その機器のMAC
部屋の中で「3番席の人」は知っているが「赤シャツの谁か」が要る、に近い。
仕組み 同じリンク内だけ。次ホップのIPは分かるが、Ethernetの宛先MACがまだ分からない。要求をブロードキャストし、該当ホストがMACを返してキャッシュする。以降そのMAC宛てにフレームを送る。DNS（広域の名前からIP）とは階層が違う。
答案骨子 答案骨子: ①同一リンクでのIP→MAC ②要求ブロードキャスト→応答 ③キャッシュ ④DNS（広域の名前解決）との違い。
解答例見本（目安150–220字・AI整理） ARPは同一リンク内で、宛先IPに対応するMACアドレスを解決するプロトコルである。要求をブロードキャストし、該当ホストがMACを応答してキャッシュし、その後のフレーム送信に用いる。インターネット全体の名前解決であるDNSではなく、リンク上の届け先決めである点を区別して書く。 答えにはリンク内と明示すると安全である。
よくある誤解
なぜ起きるか DNSと「解決」という言葉で混同
NG インターネット全体の名前解決、と書く
正しい見方 リンク内のIP↔MAC、と書く
ICMP / ICMPv6（アイシーエムピー）とは、
重要度メモ 4年中2年で出現・高
· 出現年: 2022、2024
IPの運用を助ける制御・エラー通知用プロトコル。到達不能通知、エコー要求/応答（ping）、TTL超過など。IPv6ではICMPv6が近隣探索なども担う。
別名 Internet Control Message Protocol。データ本体の転送プロトコルではない。
なぜ 網やホストが「届かない」「TTL切れ」などの状態を相手に伝え、診断と制御に使う。転送そのものではなく、転送を円滑にするための副信号。
日常のたとえ：網の案内・故障連絡票（ping）。荷物本体の配達書ではない。
要点：ICMP / ICMPv6
身近例: ping（Echo Request/Reply）。traceroute はTTLを意図的に小さくし、途中ルータからの Time Exceeded を手がかりに経路を知る。
仕組み データ本体ではなくIPの診断とエラー通知。pingのエコー、到達不能、TTL超過など。tracerouteはTTL超過を使う。ファイル転送ではない。IPv6ではICMPv6が近隣探索も含む点を一言添えられると加点。
答案骨子 答案骨子: ①制御・エラー通知 ②用途例（ping/到達不能/TTL超過） ③ファイル転送ではない ④ICMPv6ならNDに1言。
解答例見本（目安150–220字・AI整理） ICMPはIP通信の制御とエラー通知を行うプロトコルである。到達不能の報告、エコー（ping）、TTL超過通知などに用いられ、ファイルなどのデータ本体の転送ではない。IPv6ではICMPv6が近隣探索なども担当し、診断と制御の側の役割だとまとめる。 用途を具体例で一つ示せば十分である。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 転送プロトコル（TCP/UDP）と混同する
NG ICMP＝ファイル転送
正しい見方 診断・エラー通知と書く
③ 転送と信頼性
TCP 3-way handshake（スリーウェイハンドシェイク）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2024
TCP接続の確立時に SYN → SYN-ACK → ACK の3通で、双方の初期シーケンス番号などを合意する手続き（3-way handshake）。アプリデータの本送信はこの後。切断はFIN等の別手順。
別名 スリーウェイハンドシェイク・接続確立。
なぜ 双方向に順序制御・確認応答を始めるための共通の初期状態を安全に共有する。片方だけが「つながったつもり」になる半開状態を減らす。
日常のたとえ：握手の3往復で双方が「今から会話する共通ルール」を合意してから本編。
要点：TCP 3-way handshake
交換の骨格
①送: SYN(seq=x)
②受: SYN-ACK(seq=y, ack=x+1)
③送: ACK(ack=y+1)
→ 双方が相手の初期番号を確認した状態でデータ転送へ。
①送: SYN(seq=x)
②受: SYN-ACK(seq=y, ack=x+1)
③送: ACK(ack=y+1)
→ 双方が相手の初期番号を確認した状態でデータ転送へ。
仕組み 目的はデータ本体の前に、初期シーケンス番号と接続状態を双方で合意すること。送り側がSYNで自分の初期番号を出す。受け側がSYN-ACKで自分の番号を出し相手を確認する。送り側がACKで相手を確認して確立し、その後データ転送。三通でファイルを運び切る話ではなく、切断はFINなどの別手順。
答案骨子 答案骨子: ①3通の順 ②SYN/ACKとシーケンス・確認応答番号 ③目的は初期番号と接続状態の合意 ④アプリデータを3通で運ぶのではない。
解答例見本（目安150–220字・AI整理） TCPのスリーウェイハンドシェイクは、接続確立時にSYN、SYN-ACK、ACKの三通で双方の初期シーケンス番号などを合意する手続きである。これにより双方向の信頼転送の土台が共有され、その後にアプリデータの転送が始まる。三通でファイル本体を運び切るものではなく、切断はFINなどの別手順である。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 3パケットでアプリデータを運び切ると誤解
NG 握手＝短いファイル転送そのもの
正しい見方 接続状態と初期番号の合意、と書く
TCP と UDP（ティーシーピー／ユーディーピー）とは、
重要度メモ 4年中3年で出現・最優先
· 出現年: 2022、2023、2024
TCPはコネクション型で順序・再送など信頼転送と輻輳制御を提供する。UDPはコネクションレスでヘッダが軽く、到達・順序は保証しない。アプリ要件（正しさ vs 遅延）で選ぶ。
別名 トランスポート層の二大プロトコル。どちらもIPの上。
なぜ Webやファイルは欠落が困るのでTCP。通話や短い問合せは再送待ちが体感を壊すのでUDPが選ばれやすい。「UDPは劣る」ではなく用途適合。
日常のたとえ：書留（確実さ優先）と速達風ポスト（軽さ・速さ優先）の選択。
TCP
Web・メール・ファイル
欠落・順序乱れが困る
欠落・順序乱れが困る
UDP
DNS問合せ・VoIPの一部
遅延優先・損失はアプリで耐える
遅延優先・損失はアプリで耐える
仕組み 選び方の芯はトレードオフ。正しさ優先か、軽さや遅延優先か。TCPは接続のあと番号付け・ACK・再送で順序と到達を整える。Web・メール・ファイル向き。UDPは前契約なしで投げる。到達や順序は保証しない。DNSや通話で遅れを嫌う用途。TCPが信頼転送しても遅延や帯域の数値保証まではしない。
答案骨子 答案骨子: ①各々の性質を1行 ②用途例 ③なぜその性質が必要か ④対比表（接続/信頼性/用途）。用途だけ列挙は薄い。
解答例見本（目安150–220字・AI整理） TCPは接続型で再送や順序制御による信頼転送を行い、Webやファイル転送に向く。UDPはコネクションレスで軽量だが到達を保証せず、DNS問合せやリアルタイム通信など遅延を抑えたい用途に向く。優劣ではなくアプリ要件で選ぶ。TCPの信頼性は遅延や帯域の品質保証とは別である点に注意する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか UDPを劣ったTCPと書く
NG UDPは使われない／常に遅い
正しい見方 要件適合として用途と理由をセットで書く
ウィンドウ型フロー制御（うぃんどうがた）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2023
受信側が受け入れ可能なデータ量（受信ウィンドウ）を通知し、送信側がその範囲で未確認データを連続送信するフロー制御。スライディングウィンドウで効率とバッファ保護を両立する。
別名 ウィンドウ型フロー制御。輻輳ウィンドウ（cwnd）と目的が異なる点に注意。
なぜ ACK待ち1本ずつだと吞吐が伸びない。かといって無制限に送ると受信バッファが溢れる。受信能力の広告が両者のバランスをとる。
日常のたとえ：相手の机に置ける枚数だけ先に送る。机が満杯なら窓=0で待つ。
要点：ウィンドウ型フロー制御
イメージ: 送信可能な「窓」がデータ列の上を滑る。窓の中ならACK前でも送ってよい。窓=0なら送信停止。
仕組み 受信側が「いま何バイトまで受け取れるか」をウィンドウとして通知する。送信側はその範囲で未ACKデータを連続送信でき、1セグメント停止待ちを避ける。窓が0なら止まる。受信バッファ溢れ防止が目的。AIMDの輻輳ウィンドウ（網の混雑）とは別物と明記する。
答案骨子 答案骨子: ①受信能力の通知 ②窓内連続送信 ③溢れ防止と効率化 ④図の説明または窓=0の意味 ⑤AIMD（輻輳）と目的を混同しない。
解答例見本（目安150–220字・AI整理） ウィンドウ型フロー制御では、受信側が受け入れ可能なデータ量をウィンドウとして通知し、送信側はその範囲で未ACKデータを連続送信する。一セグメントごとの停止待ちを避けつつ受信バッファ溢れを防ぐ。輻輳制御のウィンドウとは目的が異なり、こちらは受信側の受け入れ能力が主題である。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 輻輳制御の話だけ書いてフロー制御と言い切る
NG AIMDと同義で片付ける
正しい見方 受信能力の通知が主題、と明記する
AIMD（エーアイエムディー）とは、
重要度メモ 4年中2年で出現・最優先
· 出現年: 2024、2025
輻輳ウィンドウ(cwnd)を、損失が無い間は加算で慎重に増やし、損失検知時は乗算で急減させる制御方式。Additive Increase Multiplicative Decrease の略。
別名 TCP輻輳制御の基本パターン（Reno系の教科書イメージ）。
なぜ 利用可能帯域をゆっくり探り、輻輳が起きたらすばやく負荷を下げる。複数フローが共有帯域を奪い合うとき、公平性と安定に寄与する古典的アルゴリズム。
日常のたとえ：水道の蛇口を少しずつ開け、溢れそうなら一気に半分まで閉める。
要点：AIMD
横軸=時間、縦軸=cwnd の鋸歯図が定番。緩やかな階段状の上昇（AI）と、ロスでの急落（MD）を答案に必ず描く・説明する。
仕組み 目的は共有回線で送り量を探りつつ、詰まったらすぐブレーキをかけること。AI（加算増）はロスが無いあいだ輻輳ウィンドウを少しずつ増やす。MD（乗算減）はロス時に半分などへ急減。時間軸では上昇と急落を繰り返す鋸歯になる。玩具は増やしてロス、戻してまた増やす。増加は緩め・減少は急。受信ウィンドウとは別物。
答案骨子 答案骨子: ①英語展開 ②AI=加算増 ③MD=乗算減 ④鋸歯図 ⑤なぜその非対称か（探る／即退場）。過去問は図指定が多い。
解答例見本（目安150–220字・AI整理） AIMD（Additive Increase Multiplicative Decrease）は、輻輳ウィンドウをロスが無い間は加算で増やし、ロス検知時は乗算で急減させる方式である。時間変化は緩やかな上昇と急落の鋸歯になり、帯域探索と輻輳時の即ブレーキを両立する。図と増減の向き、さらになぜ非対称かを答案に書く。
よくある誤解
なぜ起きるか 略語の暗記だけで増減の方向を逆にする
NG 図なし／増加が急・減少が緩やかと書く
正しい見方 増加は緩やか・減少は急、と理由付きで書く
Tail drop（テールドロップ）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2024
ルータの出力キューが満杯のとき、新しく到着したパケットを末尾から捨てる単純な破棄方針。実装は容易だが、複数TCPが同時にロスを検知して一斉に窓を縮める副作用がある。
別名 テールドロップ。対: REDなど早期ランダム破棄。
なぜ 満杯時の扱いを単純に決められる。ただしグローバル同期で利用率が波打つ問題が知られ、別アルゴリズムの動機になる。
日常のたとえ：行列が満杯のとき新規だけ末尾から門前払い。誰が「悪い客」かは見ない。
要点：Tail drop
満杯キュー ← 新規到着を捨てる → 多数フローが同時にロス検知 →各TCPがMDで一斉減速（グローバル同期）→ その後また一斉に増やす、という振動。
仕組み ルータの待ち行列が満杯のとき、新たに到着したパケットを末尾から破棄する単純策。誰のフローが悪い客かは見ず、溢れた瞬間の新規を門前払いする。多くのフローが一斉にロスして同期的に絞りやすくなる副作用があり得る。AIMDや輻輳の文脈で「破棄ポリシー」として書く。
答案骨子 答案骨子: ①満杯時に到着パケット破棄 ②単純実装 ③複数TCPの同時減速などの影響 ④優先制御そのものではない。
解答例見本（目安150–220字・AI整理） Tail dropは、ルータのキューが満杯のときに新規到着パケットを破棄する単純な廃棄方式である。フローの良し悪しを見ず末尾から門前払いするため実装は易しいが、多フローが同時にロスして同期的に絞る副作用があり得る。輻輳時の破棄ポリシーの一例としてAIMDとセットで理解する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 賢い優先制御があるように書いてしまう
NG 悪いパケットだけ選んで落とす、と書く
正しい見方 単純FIFOの満杯破棄とその副作用を書く
TCPが遅延・スループットを保証しない理由（てぃーしーぴーとほしょう）とは、
重要度メモ 4年中2年で出現・高
· 出現年: 2022、2023
TCPはベストエフォートのIP上で信頼転送（届ける努力）を行うが、網資源を予約しないため遅延上限やスループット下限などのQoSは保証しない。 試験では定義・理由・対比を短くセットで書く。
別名 信頼性 ≠ 品質保証（QoS）。E2Eとベストエフォートが論拠。
なぜ 共有網では混雑でキュー遅延やロスが起き、TCPは再送・窓縮小で反応する。結果として「いつまでに・常にXMbps」は約束できない。
日常のたとえ：再送はあるが「何ms以内に届く」約束はIPがしていない。
要点：TCPが遅延・スループットを保証しない理由
届く順序や損失回復は頑張るが、「何ms以内」「常にXMbps」は約束しない。保証しない理由を『3-wayが無いから』と書くのは誤り。
仕組み TCPは番号付け・ACK・再送で「届ける」努力はする。だが下位のIPはベストエフォートで、帯域や遅延の数値を契約しない。混雑時はウィンドウを下げキュー遅延も伸び、到達保証と遅延保証は別物になる。答案の決め台詞は「信頼性≠遅延・スループット保証」。
答案骨子 答案骨子: ①IPはベストエフォート ②TCPは予約しない ③混雑で遅延・実行スループットが変動 ④信頼性はあるがQoS保証はない、と明言。
解答例見本（目安150–220字・AI整理） TCPは再送や順序制御により信頼転送を実現するが、下位のIPがベストエフォートであり資源予約をしないため、遅延やスループットを数値として保証しない。輻輳時はウィンドウを下げキューイング遅延も増える。信頼性の提供とQoS保証は別概念である。「届く努力」と「遅延の契約」を分けて述べると答案が明確になる。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか TCP＝完全品質保証と書いてしまう
NG TCPは遅延ゼロ保証
正しい見方 信頼性はあるが遅延・帯域の保証はない
品質問題への対策の方向（きょーえすたいさく）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2022
体感品質を上げる方向として、アプリ側（バッファ・適応ビットレート）、網側（優先制御・容量増設）、配置（CDN）など複数レイヤの対策がある。完全保証とは限らない。
別名 QoS/QoE改善の提案問題向け。具体技術名が得点源。
なぜ ベストエフォートのままではリアルタイム要求を満たしにくい場面がある。過去問は「提案せよ」なので手段名＋1行理由が必要。
日常のたとえ：優先レーンや予約枠で品質を足す方向（基本は保証なし）。
要点：品質問題への対策の方向
例: 適応ビットレート、受信バッファ、DiffServ等の優先、冗長経路、エッジキャッシュ。精神論（頑張る）は不可。
仕組み ベストエフォートを前提に品質を底上げする方向の話。アプリ側は適応ビットレートやバッファで揺らぎを隠す。網側は優先制御や容量増、CDNで配信点を近づける。絶対保証とは限らない点を忘れない。
答案骨子 答案骨子: ①問題設定を受ける ②対策を2つ以上・技術名 ③各1行理由 ④トレードオフに1言あるとよい。
解答例見本（目安150–220字・AI整理） 品質改善の方向として、アプリ側では適応ビットレートやバッファリングで揺らぎを隠す、網側では優先制御や容量増設、CDNで配信点を利用者に近づける、などが挙げられる。いずれもベストエフォートを前提にした改善であり、絶対保証とは限らない。ベストエフォートを捨てる話ではなく、上乗せ改善の方向である。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 具体技術を挙げず精神論だけで終える
NG 頑張って品質を上げる、だけ
正しい見方 具体技術名を複数挙げる
再訪: connectionless
再訪: best-effort
再訪: congestion
④ 経路
静的ルーティングと動的ルーティング（せいてき／どうてき）とは、
重要度メモ 4年中3年で出現・最優先
· 出現年: 2022、2023、2024
静的ルーティングは管理者が経路を手で固定設定する方式。動的ルーティングはOSPFやBGPなどのプロトコルがトポロジ変化を交換し経路表を自動更新する方式。
別名 静的=手動ip route等。動的=リンクステート/パスベクタ等。
なぜ 小規模で変化が少ない網は静的が単純で制御トラフィックも少ない。大規模・障害・変更が多い網は人手では回らず動的が現実的。
日常のたとえ：固定案内板 vs リアルタイム渋滞アプリで道順を変える。
静的
人手が書く・単純
障害時は手修正
障害時は手修正
動的
自動更新・追随
複雑・制御メッセージ
複雑・制御メッセージ
仕組み 静的は手固定で単純だが障害時は手修正が要る。動的は自動更新で変化に強いが複雑。小規模固定なら静的、大規模や変化が多いなら動的。境界で併用もある。動的の計算例がDijkstra（リンクステート系）につながる。
答案骨子 答案骨子: ①定義対 ②長所短所対 ③使い分け軸（規模・変化・運用） ④動的=常に最適安全、と断定しない。
解答例見本（目安150–220字・AI整理） 静的ルーティングは管理者が経路を固定し単純だが、障害や拡張のたびに手修正が必要になりやすい。動的ルーティングはプロトコルが経路表を更新し変化に追随できるが、仕組みが複雑で負荷や設定リスクがある。網の規模と変化の多さで使い分け、動的の計算例としてDijkstraにつながると応用が書きやすい。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 動的なら常に最適で安全と断定する
NG 動的に短所なしと書く
正しい見方 トレードオフ表で書く
hop-by-hop 経路制御（ホップバイホップ）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2025
各ルータが自分の経路表だけを見て「次ホップ」を決め、パケットを順にリレーする経路制御の基本形。送信者が全経路を最初から指定しなくても、インターネット規模で届く。
別名 ホップバイホップ転送。対: ソースルーティング（送り主が経路明示）。
なぜ 各装置が局所情報だけで転送判断できるためスケールしやすい。経路計算の主体が分散しているインターネットの前提。
日常のたとえ：各交差点の看板だけで次を選ぶ。出発地が全ルートを指定しない。
要点：hop-by-hop 経路制御
S→a→b→D のとき、aは「Dへは次b」だけ知っていればよい。全体地図を全ルータが共有しなくても、リンクステート等で各自が表を持てば届く。
仕組み 各ルータは全体ルート固定ではなく、経路表だけで次ホップを決めてリレーする。マスクでプレフィックス照合し、最長一致でエントリを選ぶ。送信者が全経路を指定しなくてもスケールする。
答案骨子 答案骨子: ①各ホップが独立に次を決める ②経路表参照 ③全経路固定でなくてよい ④マスク/最長一致と接続できると強い。
解答例見本（目安150–220字・AI整理） hop-by-hopとは、各ルータが経路表だけを見て次ホップを決めてリレーする転送方式である。サブネットマスクはプレフィックスとして照合単位を与え、最長一致により転送先が選ばれる。送信者が全経路を固定指定しなくてもスケールする点が、インターネットの転送モデルの要点である。 マスク照合とセットで書くと点になる。
よくある誤解
なぜ起きるか 1台の中心が毎回全ルートを決めると考える
NG 中心制御のみ、と書く
正しい見方 分散的な次ホップ決定、と書く
サブネットマスク（経路制御での役割）（サブネットマスク）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2025
IPアドレスのどのビット列までがネットワーク（プレフィックス）部かを示すマスク。経路制御では経路エントリの照合単位（プレフィックス長）となり、最長一致の材料になる。
別名 例: /24 = 255.255.255.0。試験は「割当」より「経路照合」寄りの説明が加点になりやすい。
なぜ 宛先がどの網に属するか、どの経路表エントリにマッチするかを決める。マスクが無いとアドレス空間を塊として扱えず、集約も照合もできない。
日常のたとえ：郵便番号の何桁までが「地区」かを示す定規。照合の粒度。
要点：サブネットマスク（経路制御での役割）
アドレス AND マスク → ネットワーク番号。表に /16 と /24 があれば、より長い（細かい）/24 が優先されることが多い（最長一致）。
仕組み IPの何ビットまでがネットワーク部かを示す定規（プレフィックス長）。ルータは宛先IPと経路表をマスクで照合し、最長一致のエントリで次ホップを選ぶ。アドレス設計や経路集約の単位にもなる。hop-by-hop転送の照合道具としてセットで覚える。
答案骨子 答案骨子: ①ネットワーク部の境界 ②プレフィックス長 ③経路照合・最長一致 ④暗号やセキュリティそのものではない。
解答例見本（目安150–220字・AI整理） サブネットマスクはIPアドレスのネットワーク部とホスト部の境界を示し、経路制御ではプレフィックス長として機能する。ルータは宛先を経路表と照合し、最長一致するエントリの次ホップへ転送する。アドレス設計や経路集約の単位にもなる。hop-by-hopの照合と最長一致の道具として位置づける。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか セキュリティや暗号の話に逃げる
NG マスクは暗号や鍵の仕組みだ、と書く
正しい見方 ネットワーク部と経路照合の単位、と書く
経路表エントリの増加（けいろひょうのぞうか）とは、
重要度メモ 4年中3年で出現・最優先
· 出現年: 2022、2024、2025
インターネットコアなどで経路表のエントリ数が増え続け、メモリ・探索処理・更新トラフィック・装置コスト・運用ミスが増大する問題。 試験では定義・理由・対比を短くセットで書く。
別名 経路爆発・経路表肥大。DFZのスケーラビリティ議論と関連。
なぜ ルックアップが重くなり遅延や電力が増す。更新も増え収束や運用が難しくなる。過去問で高頻度の論述テーマ。
日常のたとえ：住所録が肥大すると検索も更新も重い。まとめて1行にする。
要点：経路表エントリの増加
対策の方向例
経路集約（summary）、階層化、デフォルト経路、アドレス設計の整理、必要に応じたアーキテクチャ議論。問題だけで終わらず策を1つ以上。
経路集約（summary）、階層化、デフォルト経路、アドレス設計の整理、必要に応じたアーキテクチャ議論。問題だけで終わらず策を1つ以上。
仕組み 経路が一件増えるごとに、メモリと最長一致の照合負荷、更新のやり取りが増える。装置コストや設定ミスのリスクも上がる。対策の芯は経路集約（短いプレフィックスにまとめる）。デフォルト経路や階層で見える範囲を狭める。答案は問題（肥大の害）と対策をセットで書く。
答案骨子 答案骨子: ①問題（容量・速度・更新・コスト・運用）を列挙 ②対策を具体名で1つ以上 ③なぜ効くかを1行。
解答例見本（目安150–220字・AI整理） 経路表エントリの増加は、メモリ消費や最長一致探索の負荷、更新トラフィック、装置コストを押し上げる。対策の中心は経路集約で複数の行き先を短いプレフィックスにまとめることである。デフォルト経路や階層化で可視範囲を限る方法も併用され、運用ミス低減にもつながる。定義を先に置き、仕組みを続け、誤解しやすい点で締める。用語の境界（何が対象で何ではないか）を一文で明示すると減点が減る。
よくある誤解
なぜ起きるか 問題列挙だけで対策がない
NG ルータを高速化するだけ、と精神論で終わる
正しい見方 集約など具体策を書く
Dijkstra法（OSPF）（ダイクストラ）とは、
重要度メモ 4年中2年で出現・最優先
· 出現年: 2022、2024
辺のコストが非負のグラフで、ある始点から各ノードへの最短経路（木）を求めるアルゴリズム。リンクステート型のOSPFなどが経路計算に用いる。 試験では定義・理由・対比を短くセットで書く。
別名 ダイクストラ法・最短経路優先。確定集合を広げラベルを緩和する。
なぜ 全リンクのコスト地図が分かれば、ループのない最短経路を体系的に得られる。過去問では手順表と最終経路・コストが本点。
日常のたとえ：未確定の街からいちばん近い街を広げて最短距離ラベルを更新する。
要点：Dijkstra法（OSPF）
各ノードに距離ラベル（初期: 始点0・他∞）。未確定で最小のノードを確定→その隣接を min で更新（緩和）、を繰り返す。1ホップがいつも最小とは限らない点に注意。
仕組み 始点距離を0、他を無限大に置く。未確定の点のうち距離が最小のものを確定する。その点から出る辺で隣接の距離を短くできれば更新（緩和）する。これを繰り返す。非負コスト前提。リンクステート系（OSPFのイメージ）の最短路計算の代表。試験は段階表か最終コストと経路を明示。
答案骨子 答案骨子: ①初期化 ②未確定最小の確定と緩和を段階表示 ③最終経路と総コスト ④「隣の最小だけ辿る」誤手順を避ける。
解答例見本（目安150–220字・AI整理） Dijkstra法は非負コストのネットワークで、始点から各点への最短経路を求めるアルゴリズムである。始点距離を0・他を無限大とし、未確定点のうち距離最小を確定して隣接を緩和する操作を繰り返す。OSPFなどリンクステート系の最短路計算の代表で、試験では段階と最終コスト・経路を明示する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか その場その場の最小辺だけを欲しがる貪欲誤手順
NG 1ホップ最小を繰り返すだけ、と書く
正しい見方 距離ラベル更新の表を書いて示す
⑤ アプリ・配信
HLS / MPEG-DASH（エイチエルエス／ダッシュ）とは、
重要度メモ 4年中3年で出現・最優先
· 出現年: 2022、2023、2025
動画を数秒単位のセグメントに分割し、HTTPで順次取得する適応型ストリーミング。HLSとMPEG-DASHは同種の分割＋HTTP配信の代表。帯域に応じて画質を切り替えられる。
別名 HTTP Live Streaming / Dynamic Adaptive Streaming over HTTP。
なぜ 既存のCDNとHTTPインフラをそのまま配信経路に使える。回線の太い・細いが変わるモバイルでも、再生を止めにくく品質を落とせる。
日常のたとえ：長いドラマを数分のファイルに切って順番に取り、回線が細ければ画質を落とす。
1本ファイル
最初から最後まで固定品質の大ファイル
セグメント配信
短い片をHTTPで取得
次の片から品質変更可
次の片から品質変更可
仕組み 長い動画を数秒のセグメントに切り、プレイリストで順番と品質候補を示す。クライアントが帯域を見て品質を選び、HTTPのGETで片を順に取る。回線が細ければ次の片から画質を落とせる適応配信。CDNキャッシュと相性がよい。H.264などのコーデック名説明にすり替えない。本体は分割＋HTTP＋適応。
答案骨子 答案骨子: ①セグメント分割 ②HTTP取得 ③適応ビットレート ④利点（CDN親和）と欠点（遅延等）を各1。
解答例見本（目安150–220字・AI整理） HLSやMPEG-DASHは、動画を短いセグメントに分割しHTTPで順次取得する適応型ストリーミングである。プレイリストが品質候補を示し、クライアントが帯域に応じて画質を切り替える。既存のCDNとHTTPインフラを使える一方、セグメント境界によりライブ遅延が大きくなり得る。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 映像コーデック名の説明にすり替わる
NG H.264の説明だけ書く
正しい見方 分割配信と適応取得の仕組みを書く
SIP（シップ）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2022
IP電話などで「誰と・どのメディアで」セッションを開始・変更・終了するための信号制御（シグナリング）プロトコル。音声パケットそのものはRTPなどが運ぶことが多い。
別名 Session Initiation Protocol。制御とメディアの分離が要点。
なぜ 通話の制御メッセージと実際の音声メディアを分け、柔軟にセッションを組み替えられる。VoIPの「電話帳・呼び出し」側を標準化する役割。
日常のたとえ：電話の呼び出し係：相手を呼び接続を決め、声そのものは別回線で流す。
制御（SIP）
INVITE 等で通話を確立・終了
媒体
実際の音声は別チャネル（RTP等）
仕組み 誰とどのメディアで話すかを決める呼び出しまわり（シグナリング）が仕事。INVITEなどでセッションを開始・変更・終了し、合意後にメディアが流れる。音声パケット本体はRTPなど別プロトコルが運ぶことが多い。制御とメディアの分離を答案の軸にする。
答案骨子 答案骨子: ①セッション制御 ②VoIPの呼制御 ③メディア本体ではない ④例（開始・終了）を1つ。
解答例見本（目安150–220字・AI整理） SIPはIP電話などでセッションを開始・変更・終了するためのシグナリングプロトコルである。通話の制御メッセージを扱い、音声データ本体はRTPなど別プロトコルが運ぶことが多い。制御とメディアを分離することで、柔軟な呼制御が可能になる。メディア本体の転送と混同しないことが得点の分岐点になる。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 音声データをSIPが運ぶと誤解する
NG SIP＝音声パケット本体
正しい見方 シグナリング（制御）と明示する
WebAPI（ウェブエーピーアイ）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2025
HTTPなどを通じ、プログラムがWeb上の機能やデータに機械可読な形でアクセスするインタフェース。人向けHTMLページとは別に、JSON等で資源を操作する形が典型。
別名 Web API / REST API 等。
なぜ サービス同士を疎結合につなぎ、機能を再利用・自動化できる。スマホアプリや他社連携の裏側で多用される。
日常のたとえ：窓口メニューを決めておくと、別アプリからも同じ手続きを呼べる。
人間向け
HTMLページを読む
プログラム向け
JSON等のAPI応答
仕組み 人がブラウザでHTMLを見るのとは別に、プログラム同士がHTTPなどで機能やデータを呼ぶ窓口。URLとメソッド、JSONなどの機械可読な応答で資源を操作する。サービス連携や自動化を疎結合にできる。HTMLページ公開そのものではなくインタフェース設計の話。
答案骨子 答案骨子: ①機械可読な操作口 ②HTTPベースの例 ③人間向けUIとの違い ④ブラウザの見た目そのものではない。
解答例見本（目安150–220字・AI整理） WebAPIはHTTPなどを用いてプログラムがWeb上の機能やデータへアクセスするためのインタフェースである。人がHTMLを閲覧するのとは異なり、JSON等の機械可読な形式で資源を操作する。サービス連携や自動化を疎結合に実現できる。人が見るHTMLページ配信そのものとは別物である。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか GUIや画面デザインの話だけになる
NG WebAPI＝ブラウザの見た目
正しい見方 プログラム間連携の口、と書く
LPWA（エルピーダブリュエー）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2025
低消費電力で広域をカバーすることを狙った無線通信の総称（Low Power Wide Area）。IoTセンサなど、電池寿命と到達距離が重要な用途向け。高速大容量は不得意。
別名 例: LoRaWAN, NB-IoT など。
なぜ Wi-Fiや通常の携帯データ通信は電力・コストの面で常時センサに向かない場面がある。間欠・低速でも遠くへ届く折り合いが要る。
日常のたとえ：電池で長く遠く少しだけ送るセンサー網（大容量映像向きではない）。
Wi-Fi/携帯
高速だが電力・基盤が大きくなりがち
LPWA
狭帯域・長距離・低電力
仕組み 低消費電力で遠くまで、少量データを間欠送信する無線の総称。電池駆動のセンサなど広域監視に向く。レートを抑えて電力を稼ぐ。高速・大容量の映像配信向きではないトレードオフ。用途（IoT）と向かない用途を対で書くと答案が締まる。
答案骨子 答案骨子: ①低電力 ②広域 ③低速/低容量 ④用途例1つ ⑤5G万能論にすり替えない。
解答例見本（目安150–220字・AI整理） LPWAは低消費電力で広域をカバーする無線の総称で、電池駆動センサなどIoTの広域監視に向く。データレートを抑え間欠通信することで電力を節約する一方、高速大容量通信には適さない。用途に応じたトレードオフとして理解する。大容量映像向けではない、という否定側もセットで書く。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 5GやWi-Fiと同じ「速い無線」にすり替える
NG 常に高速、と書く（混同しやすい）
正しい見方 低電力・広域・低速の三点をセットで書く
QUIC（HTTP/3）（クイック）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2025
UDP上に実装された伝送プロトコルで、ストリーム多重、内蔵の暗号化（TLS相当）、接続IDなどを備え、HTTP/3の搬送に使われる。 試験では定義・理由・対比を短くセットで書く。
別名 HTTP/3 = HTTP semantics over QUIC。
なぜ TCP+TLSの握手往復や、TCPのヘッドオブラインブロッキングを緩和したい。損失が1ストリームに閉じやすく、体感レイテンシを改善し得る。
日常のたとえ：UDP上に運びと暗号・多重をまとめた高速な引越し用コンテナ。
HTTP/2 over TCP
1ロスが接続全体に波及しうる
QUIC
ストリーム単位で回復しやすい
仕組み UDPの上に、多重ストリーム・暗号化・損失回復などをまとめた伝送プロトコル。HTTP/3の土台。TCP＋TLSの二重握手や、TCPロス時のヘッドオブラインを緩和する狙い。生の到達保証なしUDPではなく、QUIC層が信頼性を足す。答案は「UDP上＋多重＋暗号内蔵」を三点で。
答案骨子 答案骨子: ①UDP上 ②多重・TLS統合 ③TCPベースHTTPとの差 ④信頼性はQUICが担う（単なる生UDPではない）。
解答例見本（目安150–220字・AI整理） QUICはUDP上に実装された伝送プロトコルで、ストリーム多重や暗号化を内蔵しHTTP/3の土台となる。TCP上のHTTP/2で問題になりやすいヘッドオブラインや握手遅延を緩和し、ストリーム単位の損失回復を狙いやすくする。到達保証がない生UDPそのものではなく、QUIC層が信頼性を提供する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか ただの高速で信頼なしUDPと断定する
NG QUIC＝信頼性ゼロ
正しい見方 信頼性はQUIC層が担う、と書く
HTTP/2の課題とHTTP/3（エイチティーティーピー）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2025
HTTP/2はTCP上で多重化するが、TCPの損失復旧により同接続の他ストリームも止まりうる（HOL）。HTTP/3は意味論をQUICに載せ替え、ストリーム単位の扱いと握手効率を改善する。
別名 Head-of-line blocking が対比のキーワード。
なぜ 1パケットロスでページ全体が止まったように見える問題への処方箋が求められた。バージョン番号ではなく課題→解決の対応が答案の核。
日常のたとえ：2は1本の道で多重、3は道の作りが違い1本破損で全部止まらない狙い。
要点：HTTP/2の課題とHTTP/3
課題例: TCP HOL、ハンドシェイク往復、中間機器の ossification。HTTP/3: QUIC上でストリーム分離・TLS統合。
仕組み HTTP/2は一つのTCP接続上でストリームを多重化する。TCPのロス復旧待ちが他ストリームにも波及しうるヘッドオブラインが課題。HTTP/3はHTTPの意味論をQUIC（UDP上）に載せ、ストリーム単位の回復と握手効率化を狙う。優劣の宣言より、問題点と載せる土台の違いを対比する。
答案骨子 答案骨子: ①HTTP/2の課題を具体に ②HTTP/3/QUICの対応策 ③「新しいから速い」で終わらない。
解答例見本（目安150–220字・AI整理） HTTP/2はTCP上でストリームを多重化するが、TCPの損失復旧によりヘッドオブラインブロッキングが残り、ひとつのロスが他ストリームにも影響しうる。HTTP/3はHTTPの意味論をQUIC（UDP上）に載せ、ストリーム単位の回復と握手の効率化によりこれらの課題を緩和する。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか バージョン番号だけ挙げて課題が無い
NG 単に新しいから速い（混同しやすい）
正しい見方 具体課題と解決を対応づけて書く
⑥ WWWと安全
HTML と CSS（エイチティーエムエル／シーエスエス）とは、
重要度メモ 4年中2年で出現・高
· 出現年: 2023、2024
HTMLはウェブページの文書構造（見出し・段落・リンク等）を表し、CSSは色・余白・レイアウトなど見た目を構造から分離して指定する。 試験では定義・理由・対比を短くセットで書く。
別名 HyperText Markup Language / Cascading Style Sheets。
なぜ 構造と装飾を分けると、同じHTMLに別デザインを当てたり、一括変更やアクセシビリティがしやすくなる。WWWの表層技術として過去問に出る。
日常のたとえ：骨組み（HTML）と見た目の化粧（CSS）を分けて書く。
HTML
見出し・段落・リンク（骨組）
CSS
色・余白・レイアウト（見た目）
仕組み HTMLは見出し・段落・リンクなど文書の骨組み（構造）を書く。CSSは色・余白・配置など見た目を別ファイルや別規則で指定する。構造と装飾を分けるとデザイン変更や再利用が楽になる。CSS自体は通信プロトコルではなく、Webページ記述の役割分担。
答案骨子 答案骨子: ①役割分担 ②分離の利点（再利用・保守） ③欠点や注意（複雑化・互換）を1つ ④通信プロトコルではない。
解答例見本（目安150–220字・AI整理） HTMLは文書の構造を記述し、CSSは見た目を別規則として指定する言語である。構造と装飾を分けることでデザインの一括変更や再利用、保守性が高まる。CSSは通信プロトコルではなく、Webページにおける役割分担の話である点に注意する。通信階層のプロトコル名そのものではない点を混同しない。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか HTMLだけで装飾も全部と混同、または通信の話にすり替える
NG CSSが通信プロトコル
正しい見方 表現の構造とスタイルの分離、と書く
HTTPS / SSL・TLS（ティーエルエス）とは、
重要度メモ 4年中3年で出現・最優先
· 出現年: 2023、2024、2025
HTTPSはHTTPをTLSの上で運ぶ形。TLSは相手認証（証明書）、鍵合意、その後の対称暗号による機密性・改ざん検知を提供する。 試験では定義・理由・対比を短くセットで書く。
別名 HTTPS = HTTP over TLS。SSLは歴史的前身呼称。
なぜ 平文HTTPは盗聴・改ざん・なりすましに弱い。Webの機密と真正性を端到端で守るために必須級の土台。
日常のたとえ：相手の身分証を確認し鍵を合わせてから、手紙を封筒に入れて送る。
要点：HTTPS / SSL・TLS
大枠
握手: パラメータと乱数の交換 → サーバ証明書提示と検証 → 鍵材料の共有 →以降のHTTPデータを対称暗号で保護。
握手: パラメータと乱数の交換 → サーバ証明書提示と検証 → 鍵材料の共有 →以降のHTTPデータを対称暗号で保護。
仕組み HTTPSはHTTPをTLS上に載せる。盗聴・改ざん・なりすまし対策。Hello交換、証明書をCA鎖で検証、鍵合意、その後対称鍵で本文を暗号化する。TCPのスリーウェイとは別レイヤ。答案は認証・鍵・暗号化の三点を並べる。
答案骨子 答案骨子: ①認証＋鍵合意＋暗号化 ②証明書/PKI ③HTTPSの位置づけ ④課題を1つ。暗号だけの説明は減点されやすい。
解答例見本（目安150–220字・AI整理） TLSはサーバ証明書による認証と鍵合意のうえで通信を暗号化し、HTTPSとしてHTTPを保護する。握手ではパラメータ交換、証明書検証、鍵の共有が進み、以降の本文は対称暗号で守られる。TCPの接続確立とは別レイヤであり、課題例として証明書の信頼設定ミスなどを一文添えるとよい。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 暗号化だけ書いて認証がない
NG HTTPS＝圧縮（混同しやすい）
正しい見方 機密性・真正性・完全性を揃えて書く
認証局（CA）とPKI（にんしょうきょく）とは、
重要度メモ 4年中1年・押さえる
· 出現年: 2024
認証局（CA）が公開鍵証明書を発行・管理し、PKI（公開鍵基盤）の信頼連鎖によって「この公開鍵はこの主体のもの」と保証する枠組み。 試験では定義・理由・対比を短くセットで書く。
別名 Certificate Authority / Public Key Infrastructure。問題文のKPIはPKI誤記想定あり。
なぜ 見知らぬWebサーバの公開鍵を、あらかじめ信頼するルートに連なる署名で信じられる。TLSのサーバ認証の土台。
日常のたとえ：身分証を発行する役所の鎖。末端の証を根の役所までたどる。
要点：認証局（CA）とPKI
ブラウザの信頼ストア（ルート）→ 中間CA → サーバ証明書、という鎖。鎖のどこかが切れると検証失敗。
仕組み CAは主体と公開鍵の対応を証明書として発行する役所。クライアントはサーバ証明書を、中間を経て信頼するルートまで鎖でたどって検証する。PKIはその公開鍵基盤全体。TLSのサーバ認証の根拠になる。CA自身が通信本文を暗号化する役ではない。
答案骨子 答案骨子: ①CAの役割（発行・信頼点） ②証明書の中身概略 ③鎖による検証 ④CAが通信を暗号化する本体ではない。
解答例見本（目安150–220字・AI整理） 認証局（CA）は公開鍵証明書を発行し、PKIのもとで公開鍵と主体の対応を保証する。クライアントはルートCAまでの証明書鎖を検証し、サーバの身元と公開鍵を信頼する。TLSにおけるサーバ認証の根拠であり、CA自身がペイロードを暗号化するわけではない。証明書鎖の検証がサーバ認証の根拠になる流れを短く示す。定義を先に置き、仕組みを続け、誤解しやすい点で締める。
よくある誤解
なぜ起きるか 暗号アルゴリズム名だけ挙げて役割が無い
NG CAが通信を暗号化する本体
正しい見方 公開鍵の身元保証、と書く
本編ハブ · 試験形式4本柱
目次だけで終わらない。各柱に L2 要約とドリルリンクがある。
B1 TCP/UDP と品質
Transport はアプリの要件（確実さ vs 遅延）に合わせて選ぶ。TCP は信頼転送と輻輳制御を端点で行い、UDP は軽量だが損失・順序はアプリ側。重要な…
B2 経路制御各ルータは経路表に基づき next hop を選ぶ（hop-by-hop）。静的は人手・単純、動的はトポロジ変化に強いが複雑。OSPF などはリンクコストから …
B3 WWW / HTTPHTML が構造、CSS が見た目。HTTP/2 は TCP 上の多重で HOL が残りうる。HTTP/3 は QUIC（UDP上）でストリーム単位の回復と握手…
B4 セキュリティ・IDHTTPS は TLS 上の HTTP。握手で認証・鍵合意しデータは対称暗号。証明書の信頼は CA を頂点とする PKI の鎖で支える。…
B1 TCP/UDP と品質
Transport はアプリの要件（確実さ vs 遅延）に合わせて選ぶ。TCP は信頼転送と輻輳制御を端点で行い、UDP は軽量だが損失・順序はアプリ側。重要な区別: 信頼性 ≠ 遅延・帯域の保証（ベストエフォートIPの上）。
AIMD のイメージ（詳細は D03）。
B2 経路制御
各ルータは経路表に基づき next hop を選ぶ（hop-by-hop）。静的は人手・単純、動的はトポロジ変化に強いが複雑。OSPF などはリンクコストから Dijkstra で最短経路木を作る。表の肥大はメモリと探索の問題。
B3 WWW / HTTP
HTML が構造、CSS が見た目。HTTP/2 は TCP 上の多重で HOL が残りうる。HTTP/3 は QUIC（UDP上）でストリーム単位の回復と握手効率化を狙う。配信では HLS/DASH のようにセグメント＋HTTP が頻出。
演習 D10
B4 セキュリティ・ID
HTTPS は TLS 上の HTTP。握手で認証・鍵合意しデータは対称暗号。証明書の信頼は CA を頂点とする PKI の鎖で支える。
演習 D08
演習編
手計算 · Dijkstra
Dijkstra 2022（S→D）
求めるもの 始点Sから終点Dへの最小コスト経路と総コストを、距離ラベルの更新順で示せ
使う考え方 Dijkstra（非負コスト最短経路・確定集合を拡張）
番号付き途中式
- 初期化: d(S)=0、他ノードは ∞。確定集合 F=∅。先行 pred は未定義。表: (S,a,c,b,d,D)=(0,∞,∞,∞,∞,∞)。
- 型: 未確定のうち d 最小の u を確定。隣接 v について d(v)=min(d(v), d(u)+w) 、更新なら pred(v)=u。
- S 確定。緩和: d(a)=0+1=1（pred←S）、d(c)=0+2=2（pred←S）。表=(0,1,2,∞,∞,∞)。F={S}。
- 未確定最小 a(1) を確定。緩和: d(d)=1+1=2（←a）、d(b)=1+3=4（←a）。表=(0,1,2,4,2,∞)。F={S,a}。
- 未確定最小は c(2) と d(2)。先に c 確定。緩和: d(b)=min(4,2+2)=4（更新なし）。表そのまま。F={S,a,c}。
- d(2) 確定。緩和: d(D)=2+1=3（←d）。表=(0,1,2,4,2,3)。F={S,a,c,d}。
- b(4) 確定。d(D)=min(3,4+1)=3（更新なし）。次に D 確定。最終表=(0,1,2,4,2,3)。
- 復元: D←d←a←S → 経路 S→a→d→D、総コスト 3。答案には「各回の確定ノード＋表の1行」を残すと強い。
- 検算: S–c–b–D=2+2+1=5、S–a–b–D=1+3+1=5 ＞ S–a–d–D=3。別経路より小さいことまで書く。
最終答え 経路 S → a → d → D、総コスト 3
答案文 Dijkstra 法により、最短経路は S–a–d–D、総コストは 3 である。
部分点 初期化・各回の確定と緩和・最終経路/コスト・検算のいずれかで部分点。経路だけ正解で手順なしはやや減点され得る。
なぜ今この計算か リンクステートからループのない最短経路を体系的に得るため（OSPFイメージ）。
Dijkstra 2022 · Fade（途中を埋めよ）
求めるもの 始点Sから終点Dへの最小コスト経路と総コストを、距離ラベルの更新順で示せ
使う考え方 Dijkstra（非負コスト最短経路・確定集合を拡張）
番号付き途中式
- 初期化: d(S)=0、他ノードは ∞。確定集合 F=∅。先行 pred は未定義。表: (S,a,c,b,d,D)=(0,∞,∞,∞,∞,∞)。
- 型: 未確定のうち d 最小の u を確定。隣接 v について d(v)=min(d(v), d(u)+w) 、更新なら pred(v)=u。
- S 確定。緩和: d(a)=0+1=1（pred←S）、d(c)=0+2=2（pred←S）。表=(0,1,2,∞,∞,∞)。F={S}。
- 未確定最小 a(1) を確定。緩和: d(d)=1+1=2（←a）、d(b)=1+3=4（←a）。表=(0,1,2,4,2,∞)。F={S,a}。
- 未確定最小は c(2) と d(2)。先に c 確定。緩和: d(b)=min(4,2+2)=4（更新なし）。表そのまま。F={S,a,c}。
- d(2) 確定。緩和: d(D)=2+1=3（←d）。表=(0,1,2,4,2,3)。F={S,a,c,d}。
- b(4) 確定。d(D)=min(3,4+1)=3（更新なし）。次に D 確定。最終表=(0,1,2,4,2,3)。
- 復元: D←d←a←S → 経路 S→a→d→D、総コスト 3。答案には「各回の確定ノード＋表の1行」を残すと強い。
- 検算: S–c–b–D=2+2+1=5、S–a–b–D=1+3+1=5 ＞ S–a–d–D=3。別経路より小さいことまで書く。
- S確定後の d(a), d(c) は？
- a確定後に更新される d(d) は？
- 最終経路とコストは？
最終答え 経路 S → a → d → D、総コスト 3
答案文 Dijkstra 法により、最短経路は S–a–d–D、総コストは 3 である。
部分点 初期化・各回の確定と緩和・最終経路/コスト・検算のいずれかで部分点。経路だけ正解で手順なしはやや減点され得る。
なぜ今この計算か リンクステートからループのない最短経路を体系的に得るため（OSPFイメージ）。
足場かけ（Dijkstra）
Dijkstra 2024（S→D・別数値）
求めるもの 始点Sから終点Dへの最小コスト経路と総コスト（2022とは辺集合が異なる）
使う考え方 Dijkstra（非負コスト最短経路・確定集合を拡張）
番号付き途中式
- 初期化: d(S)=0、他 ∞。F=∅。2022との差: c–b が無く c–d:3 がある。表 (S,a,c,b,d,D)=(0,∞,∞,∞,∞,∞)。
- S 確定 → d(a)=1（←S）、d(c)=2（←S）。表=(0,1,2,∞,∞,∞)。
- a(1) 確定 → d(d)=1+1=2（←a）、d(b)=1+3=4（←a）。表=(0,1,2,4,2,∞)。
- c(2) 確定 → d(d)=min(2, 2+3)=2（c–d は更新せず）。※c–b が無いので b へは跳べない。表同じ。
- d(2) 確定 → d(D)=2+1=3（←d）。表=(0,1,2,4,2,3)。
- b(4) 確定 → d(D)=min(3, 4+1)=3。D 確定。最終表=(0,1,2,4,2,3)。
- 復元: D←d←a←S → 経路 S→a→d→D、コスト 3。
- 検算: S–c–d–D = 2+3+1=6 ＞ 3。答えの数字が2022と同じでも、途中の緩和表（c–d）を省略しない。
最終答え 経路 S → a → d → D、総コスト 3
答案文 最短経路は S–a–d–D（コスト3）。c–d 経由は長く、結果コストは2022と同値でも緩和の途中が異なる。
部分点 別経路候補とのコスト比較ができていれば部分点の余地。
なぜ今この計算か リンクステートからループのない最短経路を体系的に得るため（OSPFイメージ）。
Dijkstra L4 solo（別数値）
求めるもの S→D の最短経路とコストを表で導け（答え合わせ前に自分で表を書け）
使う考え方 Dijkstra（非負コスト最短経路・確定集合を拡張）
番号付き途中式
- （自力）初期化: d(S)=0、他∞。ノード集合 {S,a,b,c,D}。
- （自力）S 確定後の d(a), d(b) を書け。
- （自力）a 確定後の d(b), d(c) を書け（a–b で改善できるか）。
- （自力）次に確定するノードと d(D) の更新を書け。
- （自力）経路を pred から復元し、別候補 S–a–c–D と比較して検算。
- 答え合わせ: 初期→Sで d(a)=2,d(b)=5 →aで d(b)=min(5,2+1)=3,d(c)=5 →b(3)で d(D)=5 →cで更新なし → 最短 S–a–b–D コスト5。
最終答え 最短経路 S → a → b → D、総コスト 5（S–a–c–D=6 は劣る）
答案文 最短は S-a-b-D、コスト5。S-a-c-D は6で長い。
部分点 表の途中行が合っていれば部分点。経路だけ正解で表なしはやや減。
なぜ今この計算か リンクステートからループのない最短経路を体系的に得るため（OSPFイメージ）。
記述ドリル
D03 AIMD を図付きで説明せよ
求めるもの Additive Increase / Multiplicative Decrease の定義・挙動・鋸歯図・なぜその非対称かを答案にする
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- 定義: AIMD = Additive Increase Multiplicative Decrease（英語を展開して書く）。
- AI: ロスが無い間、RTTごとなどにおよそ +1MSS で cwnd を加算増加（帯域を慎重に探る）。
- MD: タイムアウトや三重重複ACK等でロス（輻輳）とみなし、cwnd を半分などへ乗算減少（負荷を即下げる）。
- 玩具数値: 例 cwnd=1→2→3→4 でロス検知 → MDで2 → 再び 3→4→5…。増加は階段、減少は急落。
- 図: 横軸=時間、縦軸=cwnd。緩やかな階段状上昇と急落を繰り返す鋸歯を描き、AI/MDをラベルする。
- 理由: 共有帯域の公平な探索と、輻輳時の迅速な退場。増加が急・減少が緩、は逆。
- 締めの一文: 「緩やかに増やし急に減らす窓制御」を明示。受信ウィンドウ（フロー制御）と混同しない。
核（採点キーワード） AIMD＝加算増＋乗算減。鋸歯図必須。公平探索と輻輳即応が目的。数値1例と図の両方があると強い。
答案の一文（完成文） AIMD（Additive Increase Multiplicative Decrease）は、輻輳ウィンドウをロスが無い間は加算的に増やし、ロス検知時は乗算的に急減させる方式で、時間変化は鋸歯状になる。
部分点 英語展開のみ／図のみ／増減の向き逆は大きく減点。図＋向き＋理由で高得点。
D04 TCP / UDP の用途と理由
求めるもの 各プロトコルについて典型用途と「なぜその性質が必要か」をセットで述べる
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- TCPの性質を1行: 接続型・順序・再送・輻輳制御による信頼転送（確立は3-way）。
- TCP用途+理由: Web/HTTP・メール・ファイルなど、欠落や順序乱れが困るから。
- UDPの性質を1行: コネクションレス・軽量・到達/順序は保証しない。
- UDP用途+理由: DNS問合せ・VoIP/ゲームの一部など、再送待ちより遅延や単純さが重要な／損失耐性があるから。
- 対比1行: 正しさ重視 vs 遅延・軽量重視。優劣ではなく要件適合。
- 注意: 「TCPは遅延も保証」と書かない（best-effort IP上）。信頼性≠QoS。
核（採点キーワード） 用途＋理由がセット。性質→例→なぜ、の三段。
答案の一文（完成文） TCPは信頼転送が要るWebやファイル転送に、UDPは低遅延や軽量が要るDNS問合せやリアルタイム通信の一部に選ばれ、アプリ要件に応じて使い分ける。
部分点 用途列挙だけ・理由なしは薄い。一方だけ書けば半分程度。
D05 静的 vs 動的ルーティング
求めるもの 定義・長所短所・使い分け軸を対で書く
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- 静的: 管理者が経路を固定。長所=単純・制御トラフィック少。短所=障害/拡張で手修正・人的ミス。
- 動的: プロトコルがトポロジを交換し表を更新。長所=変化に追随。短所=複雑・CPU/制御負荷・設定事故。
- 使い分け: 小規模固定リンク→静的、大規模・変化多→動的、境界でデフォルト静的+内部動的の併用も。
- 例を1つ: OSPF等（名前だけでよい）を動的側に置けると良い。
核（採点キーワード） トレードオフ表＋判断軸（規模・変化・運用コスト）。
答案の一文（完成文） 静的は人手で単純固定、動的は自動追随だが複雑。網の規模と変化頻度で選ぶ。
部分点 長所だけ／短所なしは減点。使い分けが無いと応用点が弱い。
D06 経路表増加の問題と対策
求めるもの 肥大が起こす問題を列挙し、具体的対策名を理由付きで述べる
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- 問題: メモリ増、最長一致ルックアップ負荷/遅延、更新トラフィック、装置コスト、運用ミス。
- 対策1: 経路集約（複数プレフィックスを短い1本に）→件数と更新を抑える。
- 対策2: デフォルト経路・階層化で可視範囲を制限。
- 対策3: アドレス設計の整理（議論として新アーキに1言してもよい）。
- 締め: 問題＋対策が両方揃って完成。
核（採点キーワード） 問題だけでは不足。集約など具体策を1つ以上＋効く理由。
答案の一文（完成文） 経路表肥大は資源と運用を圧迫するため、経路集約や階層化などでエントリ数と更新負荷を抑える。
部分点 問題のみは半分。対策名だけで理由なしはやや減点。
D07 対話型リアルタイムにUDPを使う理由
求めるもの 音声通話などでUDPが選ばれやすい理由を、TCPの性質と対比して書く
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- 要件: 対話音声は遅延が体験を大きく左右する。
- TCPの不利: 再送や順序待ち・HOLで「古いパケット」が遅れ、リアルタイム性を壊しやすい。
- UDPの有利: 軽量でアプリがすぐ次のサンプルを送れる。少しの損失はコーデックやPLCで隠蔽しうる。
- 結論: 完全性より即時性。損失耐性設計とセット。
核（採点キーワード） 低遅延優先＋損失許容。TCP再送が体感を悪化させ得る点を明示。
答案の一文（完成文） 対話型リアルタイム通信では遅延が致命的なため、再送待ちで古くなるTCPより、多少の損失を許容して軽量に送るUDPが選ばれやすい。
部分点 「UDPが速い」だけは薄い。再送と遅延の因果が要る。
D08 HTTPS / TLS の手順概略
求めるもの 握手の流れと、認証・鍵合意・暗号化の三点を答案にする
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- 位置づけ: HTTPS = HTTP over TLS。平文HTTPの盗聴・改ざん・なりすましへの対策。TCPの3-wayとは別レイヤの握手。
- 握手: ClientHello/ServerHello でパラメータと乱数を交換。
- 認証: サーバ証明書提示 → クライアントが CA/PKI 鎖で検証。
- 鍵: 鍵交換で共有秘密 → セッション鍵。以降は対称暗号でHTTPデータを保護。
- 課題: 証明書運用ミス、性能、中間終端などから1つ。
核（採点キーワード） 認証＋鍵合意＋暗号化転送。暗号だけにしない。TCP 3-wayと混同しない。
答案の一文（完成文） TLSは証明書でサーバを認証し鍵合意したうえで通信を暗号化し、HTTPSとしてHTTPを保護する。課題として証明書の信頼設定ミスなどが挙げられる。
部分点 暗号化のみで認証なしは減点。手順ゼロは薄い。
D09 hop-by-hop とサブネットマスク
求めるもの 二語を定義し、経路照合と転送判断としてつなぐ
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- hop-by-hop: 各ルータが経路表だけ見て次ホップを決めリレーする。
- サブネットマスク: ネットワーク部（プレフィックス長）を示し、照合の単位になる。
- 接続: 宛先IPをマスクで網判定し、最長一致でエントリ選択 → その next hop へ出す。
- 意義: 全経路を送り主が指定しなくてもスケールする。
核（採点キーワード） 分散転送＋照合単位。2語を別々に述べてから1文で接続。
答案の一文（完成文） hop-by-hopでは各ルータが経路表で次ホップを決め、サブネットマスクはプレフィックスとして照合単位を与え、最長一致により転送先が選ばれる。
部分点 片方だけの定義は半分。接続文が無いと統合点が弱い。
D10 QUIC / HTTP/3 と HTTP/2 課題
求めるもの HTTP/2の課題を挙げ、HTTP/3/QUICがどう緩和するかを対応づけて書く
答案の骨組み 定義 → 理由 → 対比/図 → まとめ文
番号付き手順
- HTTP/2: TCP上多重 → TCP損失復旧により同接続の他ストリームも詰まりやすい（HOL）。
- QUIC: UDP上の伝送。ストリーム多重、TLS相当の暗号化統合、接続ID等。
- HTTP/3: HTTP意味論をQUICに載せる。握手RTT削減・ストリーム単位回復を狙いやすくする。
- 注意: 「ただの速いUDPで信頼性なし」ではない。信頼性はQUIC層が担う。
核（採点キーワード） 課題→解決の対応表。バージョン自慢で終わらない。
答案の一文（完成文） HTTP/2のTCPヘッドオブライン等の課題に対し、HTTP/3はQUIC上でストリームを扱い損失影響を分離し、握手も含め体感遅延を改善しやすくする。
部分点 HTTP/3が新しいから速い、だけでは不足。
年度別索引（リンクのみ・二重執筆なし）
| 2022 | 用語8題 · TCP/UDP・品質 · 経路・Dijkstra |
| 2023 | 用語・DHCP/DNS/TTL · ARP・ルーティング · TCP窓・WWW/TLS |
| 2024 | 用語・3-way/CA · UDP通話・AIMD・tail drop · 経路・Dijkstra別図 |
| 2025 | 用語・LPWA/WebAPI等 · HLS/DASH・AIMD · QUIC/HTTP3 · hop-by-hop・マスク・表肥大 |
診断 · 用語（D11）
確信度つき。自信あり×不正解を優先復習。AI整理
Q1. End-to-End原則が置く機能の場所は？
自信度:
Q2. ベストエフォートで保証されないものは？
自信度:
Q3. DNSの主目的は？
自信度:
Q4. DHCPの主目的は？
自信度:
Q5. TTLが0になると？
自信度:
Q6. ARPが解決するのは？
自信度:
Q7. TCP 3-way で共有するのは？
自信度:
Q8. AIMDのMDは？
自信度:
Q9. リアルタイム通話でUDPが選ばれやすい理由は？
自信度:
Q10. hop-by-hop とは？
自信度:
Q11. 経路表肥大の対策例は？
自信度:
Q12. NATの役割は？
自信度:
Q13. HLSの特徴は？
自信度:
Q14. CAの役割は？
自信度:
Q15. HTTP/3の下位に近いのは？
自信度:
Q16. 静的ルーティングの短所は？
自信度:
Q17. TCPが遅延を保証しない主因は？
自信度:
Q18. サブネットマスクの経路上の役割は？
自信度:
Q19. Tail drop の影響は？
自信度:
Q20. Dijkstraが求めるものは？
自信度:
間違いノート
まだなし
品質・covered 表
判定は HTML 実測ベース。ハブ目次だけの covered は禁止。出典: materials/internet_final 講義PDF＋過去問画像（AI整理）。
| 年 | 形式 | 判定 | 根拠 |
|---|---|---|---|
| 2022 | 用語8 | covered | 入門カード |
| 2022 | TCP/UDP+品質 | covered | B1+D04+D08系 |
| 2022 | 経路+Dijkstra | covered | D01 worked |
| 2023 | 用語6 | covered | 入門 |
| 2023 | ARP・静的動的 | covered | B2 |
| 2023 | 窓・WWW/TLS | covered | B1/B3/B4 |
| 2024 | 用語5 | covered | 入門 |
| 2024 | UDP/AIMD/tail | covered | D03 D07 |
| 2024 | Dijkstra別図 | covered | D02 |
| 2025 | 用語6 | covered | 入門 |
| 2025 | HLS/AIMD | covered | B1 |
| 2025 | QUIC/HTTP3 | covered | D10 |
| 2025 | hop/mask/表 | covered | D06 D09 |
Browser Phase4 で PASS/FAIL を記入