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