株式会社ジオデータ開発 ロゴ
株式会社ジオデータ開発GEO DATA DEVELOPMENT Inc.
DTLSUDPTLSTCPWebRTCQUIC暗号化ネットワーク

NETWORK SECURITY / SECURE DATAGRAMS

DTLSとは？
UDP・TLS・WebRTCの暗号化を体系的に理解する

公開日：2026-10-10

スマホのビデオ通話では音声を止めずに届けたい。一方、通信内容は盗聴されたくない。この両方を考える入口になるのがUDPとDTLSです。

この記事の学習ルート

身近な通信 → IP・TCP・UDP → 暗号化の役割 → TLS・DTLS → パケット構造 → WebRTCとSRTP → QUIC・IPsec・PPPの整理 → 操作ラボ → 導入時の設計。

1. どこで使う？ ブラウザ通信と音声通話で考える

ネット通販で注文するとき、ブラウザのHTTPSは通信の内容を守ります。一方、音声・映像のやり取りは『多少のデータが遅れたり欠けたりしても、今の声を早く再生したい』という特性があります。こうした通信で広く使われる土台がUDP（User Datagram Protocol）です。

技術役割・対象身近な例・留意点
ネット通販やネット銀行HTTPSでWebサーバーとの通信を暗号化一般的なHTTP/1.1・HTTP/2はTCP上のTLS。HTTP/3はQUICを利用
ブラウザ同士の音声・映像通話WebRTCのSRTPがメディアを保護DTLS-SRTPでSRTP用の鍵を確立する。音声パケット自体を常にDTLSで包むわけではない
WebRTCのデータチャネルSCTP over DTLSでデータを保護共同編集やリアルタイムメッセージ交換などに利用可能
IoTのセンサー通信UDP上のアプリケーション通信の保護にDTLSを検討対応製品と設計によって採用方式は異なる
オンラインゲーム低遅延目的でUDPを使用することがあるゲームだから必ずDTLSを使うわけではない。独自の暗号や別プロトコルも存在する

2. IP・TCP・UDP――まず何を運ぶのか

通信を住所に例えると、IP（Internet Protocol）は宛先のIPアドレスを使ってパケットを届ける仕組みです。その上のトランスポート層で、TCP（Transmission Control Protocol）は順序と到達を管理するバイトストリームを、UDP（User Datagram Protocol）はメッセージ単位のデータグラム配送を提供します。

ノード式：送り主から受け手へ
送信アプリ
IPネットワーク
受信アプリ
  1. アプリのメッセージをTCPのバイトストリーム、またはUDPデータグラムにする。
  2. IPパケットとしてルーターなどを経由する。途中で遅延・欠落・入れ替わりが起き得る。
  3. TCPなら受信側で再送や順序制御を行う。UDPは同じ保証を標準では行わない。
技術役割・対象身近な例・留意点
IP宛先アドレスを元にパケットを配送暗号化を必ず提供するわけではない
TCP接続指向、順序制御、失われたデータの再送WebブラウザーのHTTP/1.1・HTTP/2など
UDPメッセージ境界を保つ、順序・到達保証なしリアルタイムメディア、DNSなど
TLS一般的にはTCPなど信頼できるストリーム上で暗号化・認証・完全性を提供HTTPS（HTTP/1.1・HTTP/2）
DTLSデータグラムを前提に暗号化・認証・完全性を提供UDPアプリ、WebRTCの鍵確立・データチャネル

TCPとUDPの違いは『TCPは必ず速い／UDPは必ず安全性が低い』ではありません。どんな処理をトランスポート層が引き受けるかの違いです。UDP上でも上位のプロトコルが独自に再送や混雑制御を実装できます。

3. TLSとDTLSの名前を分解する

TLSはTransport Layer Security、DTLSはDatagram Transport Layer Securityの略です。Datagram（データグラム）は、区切りのあるメッセージを単位として送る性質を示します。『Dがつくと暗号強度が高い』のではなく、不確実な配送を前提に扱える形へ設計を変えたという意味です。

技術役割・対象身近な例・留意点
TLS 1.3暗号化・改ざん検知・通信相手の認証などRFC 8446。通常はTCP上のHTTPSに使われる
DTLS 1.3TLSに近いセキュリティ機能をデータグラム上で提供RFC 9147。アプリデータの配送順序・到達は保証しない
DTLS 1.2旧世代のDTLS仕様RFC 6347。バージョンごとの詳細動作は異なる

4. 『UDPのペイロード』はパケットのどこ？

Payload（ペイロード）は、あるプロトコルが運ぶデータ部分です。UDPヘッダーには送信元ポート・宛先ポート・長さ・チェックサムなどがあり、後続のペイロードにDTLSレコードを載せられます。『UDPを暗号化する』という略した言い方より、『UDPに載るアプリケーションデータをDTLSで保護する』という表現が正確です。

UDPパケットの概念的な入れ子構造
IPヘッダー
UDPヘッダー（ポート番号など）
UDPペイロード：DTLSレコード
DTLS側のヘッダー ＋ 暗号化済みデータ ＋ 認証用情報など

概念図です。実際のレコード構造はDTLSのバージョン・保護状態で異なります。

DTLSは通常、IPヘッダーやUDPヘッダーまで暗号化する仕組みではありません。IPパケット単位の保護を担う技術としてはIPsecがあります。この『保護の範囲』の違いが重要です。

5. DTLSの開始から暗号化まで：ノード図で理解

DTLS通信：クライアント・ネットワーク・サーバー
クライアント端末
UDP / IPネットワーク
サーバー端末
  1. クライアントがDTLSのハンドシェイクを開始する。
  2. 暗号方式・鍵共有・必要な認証情報などを交渉し、通信に使う鍵を導出する。
  3. 暗号化済みDTLSレコードをUDPデータグラムに載せ、改ざん検知と必要な再送攻撃対策を行う。
  4. パケットが失われても、通常のアプリデータをDTLSが必ず再送するわけではない。

暗号化は『データを読めなくする』機密性、通信中の変更を検出する完全性、鍵交換時などの相手確認に関わる認証の組合せです。相手を認証する具体的な方式はプロトコルと利用環境によって異なります。

6. なぜパケットの番号や再送対策が必要？

UDPのパケットは順番が逆になったり、複製が届いたりすることがあります。DTLSはレコードに関わる番号情報などを利用して保護と再送攻撃対策を行います。ただし、攻撃によるリプレイの検出と『届いた音声を並べ直して途切れなく再生すること』は別の問題です。

技術役割・対象身近な例・留意点
パケット損失送ったデータグラムが届かないDTLSだけでアプリケーションデータを必ず再送するわけではない
順序入れ替わり3番の後に2番が届くアプリ・メディア層が順序や再生時刻を扱う
リプレイ攻撃過去に送った保護済みレコードを再度流すDTLSのアンチリプレイ機構で検出・拒否できる構成がある
ハンドシェイク途中の損失鍵確立の制御メッセージが届かないDTLS 1.3ではACKや再送を使って回復を試みる

7. WebRTCを分解する：音声とデータではDTLSの使い方が違う

ブラウザ同士のビデオ通話に使われるWebRTCには、通信相手を探すICE、音声や映像を扱うSRTP、アプリ向けのデータチャネルなど複数の技術があります。最も重要なのは、音声・映像はSRTPが保護し、DTLSはその鍵確立に利用されることです。

WebRTCメディア：DTLSで鍵を確立してSRTPで音声を保護
通話するブラウザA
ICEで確立した経路
通話するブラウザB
  1. シグナリングによって相手の接続情報や証明書フィンガープリントなどを交換する。
  2. ICEが通信可能な候補経路を決め、DTLSハンドシェイクを行う。
  3. DTLS-SRTPで共有した鍵を使い、SRTPパケットとして音声・映像を保護する。
WebRTCデータチャネル：SCTP over DTLS
データ送信アプリ
SCTP → DTLS → UDP
データ受信アプリ
  1. メッセージをデータチャネルに渡す。
  2. SCTPがメッセージの配送特性を扱い、DTLSが保護し、その下をUDPが運ぶ。
  3. 受信側でDTLSの保護を検証し、SCTPを通してアプリへ届ける。

8. 似た技術を横断整理：IPsec・QUIC・PPPoE・CHAP

通信の安全性は『どの層で、どのデータを、どんな方式で守るか』で整理すると混乱しません。特にQUICはUDPの上で動きますがDTLSそのものを使うわけではない点に注意しましょう。QUICはTLS 1.3のハンドシェイクを取り込み、パケット保護はQUIC自身の仕組みで実現します。

技術役割・対象身近な例・留意点
IPsecIPレイヤーのパケット通信を保護拠点間VPNなど。DTLSより下の層を扱う
TLS一般にストリームを保護HTTP/1.1・HTTP/2のHTTPS
DTLSデータグラム通信を保護WebRTCの鍵確立・データチャネルなど
QUIC + TLS 1.3UDP上で信頼性・多重化・暗号化通信を組み合わせるHTTP/3。DTLSで包む方式ではない
PPP / PPPoEポイントツーポイント通信を規定・イーサネット上で運用インターネット接続方式の例。DTLSとは目的が異なる
CHAPChallenge-Handshake Authentication ProtocolPPPなどのチャレンジレスポンス認証。通信全体をDTLSで暗号化する技術ではない
# パケットを観察するときの識別例（概念）
IP → TCP → TLS → HTTP/2
IP → UDP → QUIC（内部でTLS 1.3を使う鍵確立・保護）→ HTTP/3
IP → UDP → DTLS → アプリケーションデータ
IP → UDP → SRTP（鍵確立にDTLS-SRTPを利用）

上の例は各技術の関係を整理したもので、すべての通信がこの構造になるという意味ではありません。UDPペイロードに載るメッセージが何かを見て判断します。

9. 操作ラボ：損失・逆転・再送攻撃を試す

暗号化と配達保証を混同しないため、5つのメッセージを送信する模型を操作します。DTLSを選んでも欠落が残ること、TLS over TCPと見え方が異なることを体験してください。

INTERACTIVE NETWORK LAB

パケットの欠落・順序入れ替わりを試す

この教材は暗号処理を実行しません。UDPのデータグラム特性とDTLSの保護対象を理解する概念シミュレーションです。

送信端末
アプリ
ネットワーク
UDP / TCP
受信端末
アプリ

STEP 1｜送信アプリが5個のメッセージを作成

送信する順序は 1 → 2 → 3 → 4 → 5。リアルタイム通話なら各番号が短い音声のかたまりに相当します。

覚えるポイント： DTLSはUDP上の保護を提供するが、通常のアプリケーションデータをTCPのように順序どおり再送するものではありません。ハンドシェイクには独自の再送・確認機構があります。

10. 設計・運用で確認する項目

技術役割・対象身近な例・留意点
認証通信相手が本当に正しいか証明書・鍵の検証方法やフィンガープリント照合を設計する
欠落・順序アプリがどの程度の損失を許せるか音声・センサー・制御命令では要求が異なる
再送攻撃過去のレコードの再投入をどう扱うかアンチリプレイ機構、アプリの冪等性などを確認
MTUと断片化UDPデータグラムの大きさ経路MTUを超えると配送が不安定になる可能性
DoS耐性ハンドシェイク処理や送信元偽装DTLSの対策とネットワークのレート制限を併用
バージョンDTLS 1.2 / 1.3の対応状況運用製品と相互接続先の仕様を確認

DTLSを採用するだけで『通信が必ず届く』『低遅延が保証される』『通信相手の身元が無条件で証明される』わけではありません。ネットワークとアプリケーションの要件を別々に定義することが必要です。

11. よくある疑問

Q. TLSとDTLSはどちらが安全？

A. DTLS 1.3はTLS 1.3を基に設計され、概ね同等のセキュリティ保証を目指します。ただしデータグラム特有の順序や再送の性質には違いがあります。単純な強弱ではありません。

Q. DTLSはUDP自体を暗号化する？

A. UDPヘッダーではなく、主にUDPペイロード上のDTLSアプリケーションデータを保護します。

Q. UDPなら必ずDTLS？

A. いいえ。DNS、オンラインゲーム、HTTP/3などはそれぞれ用途と保護方式が異なります。

Q. WebRTCのビデオ映像はDTLSで暗号化する？

A. WebRTCのメディア通信では通常SRTPで映像・音声パケットを保護し、DTLS-SRTPで鍵を確立します。データチャネルではSCTP over DTLSという構成を使います。

Q. QUICはDTLSの新しい版？

A. 違います。QUICはUDP上の別のトランスポートプロトコルで、TLS 1.3を取り込んだ暗号化方式を持ちます。

参考仕様・公式資料

プロトコルの細部はバージョンによって異なります。実装前には対応バージョンのRFCとアプリケーション固有の仕様を確認してください。