はじめに

Webエンジニアとして日々開発をしていると、「なぜHTTPSはSSL/TLSの上に成り立っているのか？」「TCPとUDPはどう違う？」「DNSって何をしているの？」といった疑問に直面することがあります。

フロントエンドやバックエンドの開発をする上で、ネットワークを深く知らなくても動くコードは書けます。しかし、トラブルシューティングの場面や、パフォーマンス改善・セキュリティを意識した設計をする場面では、ネットワークの基礎知識が非常に重要になってきます。

そこで今回は、ネットワーク入門書の定番中の定番である 「マスタリング TCP/IP 入門編（第6版）」 を読んで学んだことを、Webエンジニア目線で整理してまとめました。

「難しそう...」と敬遠していた方にも、読んで損はないと感じてもらえるよう、できるだけ噛み砕いて解説していきます！

この本を読もうと思ったきっかけ

開発をしていて、「なんとなく動いている」という状態が続いていることに気づきました。たとえば：

fetch()でAPIを叩いているが、裏側でどんなやり取りが起きているか知らない
CORSエラーが出たとき、なぜそれが起きているか仕組みから説明できない
HTTPSとHTTPの違いを「暗号化されている/いない」以上のレベルで説明できない

こうした「なんとなく」をなくしたくて手に取ったのが本書です。

ネットワークの基本：プロトコルって何？

プロトコルとは「通信のルール」

ネットワークで最初に出てくるキーワードが プロトコル（Protocol） です。

プロトコルとは、コンピュータ同士が通信するための取り決め（ルール） のことです。人間に例えるなら「日本語で話す」「最初に挨拶する」といった会話のルールに相当します。

コンピュータは機種やOSが異なっても、同じプロトコルに従えば通信できます。このプロトコルを標準化することで、世界中のコンピュータが通信できる インターネット が実現しています。

標準化機関の存在

ネットワークの標準化は主に以下の機関が担っています。

機関名	役割
IETF（Internet Engineering Task Force）	インターネットプロトコルの標準化（RFC発行）
ISO（国際標準化機構）	OSI参照モデルなどを策定
IEEE	有線・無線LANの規格（Ethernetなど）を策定

Webエンジニアが日常的に扱うHTTP、TLS、DNSなどはすべて RFC（Request for Comments） という文書で定義されています。気になる仕様があればIETFのサイトで原文を確認できます。

OSI参照モデルとTCP/IPモデル

OSI参照モデルとは

ネットワークの機能を 7つの層（レイヤー） に分けて整理したモデルです。

レイヤー番号	層の名前	役割の概要
7	アプリケーション層	HTTPやDNSなど、ユーザーに近い通信
6	プレゼンテーション層	データの形式変換・暗号化
5	セッション層	通信の開始・終了管理
4	トランスポート層	TCPやUDP、信頼性のある通信
3	ネットワーク層	IPアドレスによるルーティング
2	データリンク層	MACアドレスによる同一ネットワーク内通信
1	物理層	ケーブルや電気信号などの物理的な通信

TCP/IPモデルとの対応

実際のインターネットでは TCP/IPモデル（4層） が使われています。

OSI参照モデル          TCP/IPモデル
-------------------    -------------------
7. アプリケーション層  |
6. プレゼンテーション層 |→ アプリケーション層（HTTP, DNS, FTPなど）
5. セッション層        |
-------------------    -------------------
4. トランスポート層    →  トランスポート層（TCP, UDP）
-------------------    -------------------
3. ネットワーク層      →  インターネット層（IP, ICMP）
-------------------    -------------------
2. データリンク層      |→ ネットワークインターフェース層
1. 物理層              |   （Ethernet, Wi-Fiなど）
-------------------    -------------------

Webエンジニア目線のポイント
HTTPSを使うとき、実際には「HTTP → TLS → TCP → IP → Ethernet」という順番でデータが包まれて（カプセル化されて）送信されています。これを意識するだけで、ネットワーク周りのトラブルをどの層で起きているかに切り分けやすくなります！

IPアドレスとルーティング

IPアドレスとは

IP（Internet Protocol） は、インターネット上の住所にあたる仕組みです。現在は IPv4 と IPv6 が並行して使われています。

IPv4

32ビットで表現（例：192.168.1.1）
約43億個のアドレスが使える
しかしインターネットの普及でアドレスが枯渇しつつある

IPv6

128ビットで表現（例：2001:0db8:85a3:0000:0000:8a2e:0370:7334）
約340澗（かん）個のアドレスが使える（事実上無限）
現在普及が進んでいる

サブネットマスク

IPアドレスは ネットワーク部 と ホスト部 に分かれています。どこまでがネットワーク部かを示すのが サブネットマスク です。

IPアドレス：  192.168.1.10
サブネット：  255.255.255.0（= /24）

ネットワーク部：192.168.1
ホスト部：      10

同じネットワーク部を持つコンピュータは 同じネットワーク（サブネット） に属します。

ルーティング

異なるネットワーク間でデータを届ける役割を担うのが ルーター です。ルーターは ルーティングテーブル をもとに、次にどこへパケットを転送するかを決定します。

Webエンジニア目線のポイント
AWSやGCPのVPC（Virtual Private Cloud）の設定で出てくる「サブネット」「ルートテーブル」「インターネットゲートウェイ」は、すべてこのIP・ルーティングの概念が土台になっています。インフラ設定が苦手な方もここを理解すると一気に見通しが良くなります！

TCPとUDP：信頼性の違い

TCP（Transmission Control Protocol）

TCPは 信頼性のある通信 を実現するプロトコルです。

TCPの特徴

コネクション型：通信前に接続を確立する（3ウェイハンドシェイク）
順序保証：データが正しい順番で届くことを保証
再送制御：パケットが失われた場合は再送する
フロー制御・輻輳制御：ネットワークの混雑に合わせて送信量を調整

3ウェイハンドシェイク

TCPの接続確立は以下の3ステップで行われます。

クライアント           サーバー
    |                    |
    |---  SYN  -------->|   (1) 「接続したいです」
    |                    |
    |<-- SYN/ACK --------|   (2) 「OK、こちらも準備OKです」
    |                    |
    |---  ACK  -------->|   (3) 「了解しました、通信開始します」
    |                    |
    |===== データ転送 ===|

HTTPSでの通信フロー
Webブラウザがhttpsサイトを開くとき、実際には以下の順番で処理が走ります。

DNSでIPアドレスを解決
TCPの3ウェイハンドシェイク
TLSハンドシェイク（証明書の検証・暗号化方式の合意）
HTTPリクエスト送信

これを知っていると「ページ表示が遅い」ときの原因特定がしやすくなります。

UDP（User Datagram Protocol）

UDPは 高速性を優先した、信頼性を保証しない プロトコルです。

UDPの特徴

コネクションレス型：接続確立なしでデータを送信
順序保証なし：データが届く順番は保証されない
再送なし：失われたパケットは再送されない
高速：オーバーヘッドが小さい

TCPとUDPの使い分け

用途	使うプロトコル	理由
Webページ表示（HTTP/HTTPS）	TCP	データの正確性が必要
ファイル転送	TCP	欠損なく届ける必要がある
ビデオ通話・ゲーム	UDP	多少欠損してもリアルタイム性を優先
DNS問い合わせ	UDP（主に）	1往復で済む短いやり取りなのでTCPは不要
動画ストリーミング	UDP（QUIC）	遅延を最小化するため

HTTP/3とQUIC
最新のHTTP/3はTCPではなく QUIC（UDP上のプロトコル） を採用しています。TCPの3ウェイハンドシェイクとTLSハンドシェイクを統合することで、接続確立の遅延を大幅に削減しています。Webパフォーマンスを意識する上で注目の技術です！

DNS：ドメイン名とIPアドレスの変換

DNSとは

DNS（Domain Name System） は、人間が読みやすいドメイン名（例：example.com）を、コンピュータが扱うIPアドレス（例：93.184.216.34）に変換する仕組みです。

名前解決の流れ

https://example.com にアクセスするとき、裏側では以下の流れで名前解決が行われます。

1. ブラウザのDNSキャッシュを確認
        ↓（キャッシュになければ）
2. OSのDNSキャッシュを確認
        ↓（キャッシュになければ）
3. フルサービスリゾルバー（プロバイダや8.8.8.8など）に問い合わせ
        ↓
4. ルートDNSサーバーに問い合わせ
        ↓
5. TLDサーバー（.comを管理）に問い合わせ
        ↓
6. 権威DNSサーバー（example.comを管理）に問い合わせ
        ↓
7. IPアドレスが返ってくる → ブラウザがHTTPリクエストを送信

主なDNSレコードの種類

レコード種別	役割
A	ドメイン → IPv4アドレス
AAAA	ドメイン → IPv6アドレス
CNAME	ドメイン → 別のドメイン（エイリアス）
MX	メールサーバーの指定
TXT	テキスト情報（SPF, DKIMなど）
NS	ドメインのネームサーバーの指定

Webエンジニア目線のポイント
独自ドメインをVercelやNetlifyにデプロイする際、「CNAMEレコードを追加してください」という手順が出てきますよね。これはDNSの仕組みを理解していれば「ドメインに別名（エイリアス）を設定しているんだな」とすぐに理解できます。

HTTPとHTTPS：Webの土台

HTTP（HyperText Transfer Protocol）

HTTPはWebブラウザとWebサーバー間の通信プロトコルです。

HTTPのバージョン比較

バージョン	特徴
HTTP/1.0	1リクエストごとにTCP接続を切断
HTTP/1.1	Keep-Aliveで接続を維持（デフォルト）、パイプライン化
HTTP/2	マルチプレキシング（1つのTCP接続で複数のリクエストを並行処理）、ヘッダー圧縮
HTTP/3	QUICベース、TLSと統合、接続確立の高速化

HTTPのリクエスト/レスポンス構造

【リクエスト】
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

【レスポンス】
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234

<!DOCTYPE html>
<html>...

HTTPS（HTTP Secure）

HTTPSは TLS（Transport Layer Security） によってHTTP通信を暗号化したものです。

TLSが実現する3つのこと

暗号化：通信内容を第三者に盗聴されても解読できない
認証：通信相手が本物のサーバーであることを証明書で確認できる
完全性：通信中にデータが改ざんされていないことを保証できる

TLSハンドシェイクの概要

クライアント                        サーバー
    |                                  |
    |-- ClientHello（使える暗号方式） -->|
    |<-- ServerHello（選んだ暗号方式） --|
    |<-- Certificate（サーバー証明書） --|
    |<-- ServerHelloDone ---------------|
    |                                  |
    |-- 証明書の検証（CAによる署名確認）  |
    |                                  |
    |-- ClientKeyExchange（鍵交換） --->|
    |-- ChangeCipherSpec -------------->|
    |<-- ChangeCipherSpec --------------|
    |===== 暗号化通信スタート =========|

証明書エラーへの理解
ブラウザで「この接続はプライベートではありません」と表示されるのは、TLSの証明書認証で問題が発生したときです。証明書の有効期限切れ・CAに信頼されていない自己署名証明書などが原因です。TLSの仕組みを知っていると、このエラーの意味が正確に理解できます。

NATとポート番号

NATとは

NAT（Network Address Translation） は、プライベートIPアドレスをパブリックIPアドレスに変換する技術です。

家庭内のルーターは代表的なNAT機器です。

【家庭内ネットワーク（プライベートIP）】
192.168.1.2（PC）  ─┐
192.168.1.3（スマホ）─┤→ ルーター（NAT） → グローバルIP: 203.0.113.1 → インターネット
192.168.1.4（タブレット）─┘

複数の機器が1つのグローバルIPアドレスを共有できるため、IPv4アドレスの枯渇問題の緩和にも役立っています。

ポート番号

IPアドレスが「家の住所」なら、ポート番号は「部屋番号」に相当します。1台のサーバーが複数のサービスを同時に提供できるのはポート番号のおかげです。

よく使われるポート番号

ポート番号	プロトコル	用途
80	HTTP	Webサーバー（暗号化なし）
443	HTTPS	Webサーバー（TLS暗号化あり）
22	SSH	リモートログイン
25 / 587	SMTP	メール送信
3306	MySQL	データベース
5432	PostgreSQL	データベース
6379	Redis	KVSキャッシュ

この本を読んで感じたこと・学び

1. 「なんとなく」が「なるほど」に変わる

毎日使っているHTTPS通信やDNSの仕組みを、ちゃんと理解していなかったことに気づきました。本書を読むことで、「なんとなく動いている」状態から「なぜ動いているのかが分かる」状態になれた気がします。

2. トラブルシューティングの切り口が増える

ネットワーク関連のエラーが出たとき、「どの層で何が起きているのか」を考えながら原因を絞り込めるようになりました。例えばDNSの名前解決に失敗しているのか、TCPの接続が確立できていないのか、HTTPのレスポンスに問題があるのか、それぞれ調査の手順が変わります。

3. クラウドインフラへの理解が深まる

AWSのVPC設定（サブネット、ルートテーブル、セキュリティグループのポート設定など）が、TCP/IPの知識と直結していることが分かりました。「なぜポート443を開けるのか」「セキュリティグループで0.0.0.0/0を許可するとどうなるか」が腑に落ちるようになりました。

改善点・難しかった点

正直、難しかった部分もある

データリンク層（Ethernet、ARP、MACアドレス）あたりは、Webエンジニアの日常業務との接点が薄く、少し退屈に感じることもありました
全部を一度に覚えようとするより、「今の仕事に関係する部分から読む」という読み方が合っていると感じました

おわりに

「マスタリング TCP/IP 入門編」は、1989年の初版から版を重ねてきた名著です。内容は基礎的でありながら、Webエンジニアが現場で必要とする知識が体系的に整理されています。

ネットワークの知識は、すぐに開発スピードが上がるような即効性はありませんが、トラブルシューティング・セキュリティ設計・インフラ理解 という形で、じわじわとエンジニアとしての地力になってくれます。

「ネットワークは難しそう」と感じている方にこそ、ぜひ手に取ってほしい一冊です。最後まで読んでいただきありがとうございました！

参考文献・リンク

タイトル	URL
マスタリング TCP/IP 入門編第6版（Ohmsha公式）	https://www.ohmsha.co.jp/book/9784274224478/
RFC 793 - TCP（IETF）	https://datatracker.ietf.org/doc/html/rfc793
RFC 9293 - TCP（最新版）（IETF）	https://datatracker.ietf.org/doc/html/rfc9293
RFC 9110 - HTTP Semantics（IETF）	https://datatracker.ietf.org/doc/html/rfc9110
DNS のしくみ（Cloudflare Learning Center）	https://www.cloudflare.com/ja-jp/learning/dns/what-is-dns/
TLS/SSL とは（Cloudflare Learning Center）	https://www.cloudflare.com/ja-jp/learning/ssl/what-is-ssl/
HTTP/3 とは（Cloudflare Learning Center）	https://www.cloudflare.com/ja-jp/learning/performance/what-is-http3/
OSI参照モデル（Cisco）	https://www.cisco.com/c/ja_jp/support/docs/ibm-technologies/logical-link-control-llc/12247-45.html
IPv4アドレスの枯渇問題（JPNIC）	https://www.nic.ad.jp/ja/newsletter/No43/0800.html