タイトル: プレゼンテーション層(第6層)
SEOタイトル: OSI 第 6 層 プレゼンテーション層完全ガイド
| この記事の要点 |
|
プレゼンテーション層とは
OSI 7 階層のうち、上から 2 番目（第 6 層）。アプリケーション層 (L7) とセッション層 (L5) の間に位置し、「アプリが扱うデータをネットワークに流せる形に整える」のが役割です。
| 機能カテゴリ | 具体例 |
|---|---|
| データ形式変換 | ASCII ↔ EBCDIC、エンディアン変換 |
| 文字コード変換 | UTF-8 / UTF-16 / Shift_JIS / EUC-JP |
| データ表現 | JSON / XML / YAML / Protocol Buffers / MessagePack / ASN.1 |
| データ圧縮 | gzip / deflate / Brotli / zstd |
| 暗号化・復号 | TLS の AES-GCM / ChaCha20-Poly1305 |
| シリアライゼーション | Java のシリアライズ / .NET BinaryFormatter |
| メディア形式 | JPEG / PNG / MP4 / MP3 / WebP |
具体的な機能
1. 文字コード変換
送信側が UTF-8、受信側が Shift_JIS でも同じ文字列を扱えるよう、文字エンコーディングをネットワーク上で揃えるのがプレゼンテーション層の仕事。
POST /api HTTP/1.1
Host: example.com
Content-Type: application/json; charset=utf-8 ← プレゼンテーション層情報
{"name":"佐藤太郎"}2. データ圧縮
ペイロードのサイズを小さくして転送効率を上げる。HTTP の Content-Encoding / Accept-Encoding ヘッダで交渉。
# リクエスト
GET /large.json HTTP/1.1
Accept-Encoding: gzip, br, zstd, deflate
# レスポンス
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: br ← Brotli で圧縮
Content-Length: 1024 ← 圧縮後
[Brotli 圧縮されたバイナリ]3. 暗号化
TLS の暗号スイートはプレゼンテーション層機能として扱われます（ただし OSI 厳密対応ではなく、議論あり）。
| 暗号スイート | 用途 |
|---|---|
| AES-128-GCM / AES-256-GCM | ★ 標準。ハードウェア支援 (AES-NI) |
| ChaCha20-Poly1305 | モバイル端末。AES-NI 無し CPU で高速 |
| 3DES / RC4 | 非推奨 (TLS 1.3 で削除) |
4. シリアライゼーション
オブジェクトをバイト列に変換し、ネットワーク経由で送ったあと、受信側でオブジェクトに戻す。
# JSON (テキスト、可読、サイズ大)
{"id":1,"name":"Alice","age":30} → 35 byte
# XML (テキスト、冗長)
<user><id>1</id><name>Alice</name><age>30</age></user> → 50 byte
# Protocol Buffers (バイナリ、コンパクト)
0a 05 41 6c 69 63 65 10 1e ... → 9 byte
# MessagePack (バイナリ、JSON 互換)
83 a2 69 64 01 a4 6e 61 6d 65 ... → 14 byteMIME (Multipurpose Internet Mail Extensions)
本来はメール用に作られましたが、HTTP / IMAP 等でも広く使われるプレゼンテーション層の標準です。
| Content-Type | 用途 |
|---|---|
text/html; charset=utf-8 | HTML |
application/json | JSON API |
application/xml | XML API / SOAP |
application/x-www-form-urlencoded | HTML フォーム |
multipart/form-data | ファイルアップロード |
image/jpeg / image/png / image/webp | 画像 |
application/pdf | |
application/octet-stream | 不明バイナリ |
TCP/IP モデルでの扱い
実装ベースの TCP/IP モデル (RFC 1122) では独立した「プレゼンテーション層」は存在せず、これらの機能はアプリケーション層に統合されています。
| OSI | TCP/IP | 実装例 |
|---|---|---|
| L7 Application | Application | HTTP メソッド・SMTP コマンド |
| L6 Presentation | JSON 直列化、TLS 暗号化、gzip | |
| L5 Session | TLS セッション、HTTP/2 ストリーム |
現代の例: HTTP/2 HPACK / HTTP/3 QPACK
HTTP/1.1 は毎回大量のテキストヘッダ（Cookie 等）を送るため非効率。HTTP/2 ではプレゼンテーション層相当のヘッダ圧縮アルゴリズム HPACK (RFC 7541) が導入され、HTTP/3 では QUIC の特性に合わせた QPACK (RFC 9204) に進化しました。
# HTTP/1.1 ヘッダ (毎回フルテキスト)
Cookie: session=abc123; lang=ja; theme=dark; uid=1234
User-Agent: Mozilla/5.0 (Macintosh; Intel ...)
Accept: text/html,application/xhtml+xml,...
→ 数百〜数 KB
# HTTP/2 HPACK 後 (静的・動的辞書 + Huffman 符号化)
Index 1: :method = GET
Index 14: cookie = session=abc123
...
→ 数十 byte歴史的なプロトコル
- ASN.1 (Abstract Syntax Notation One): ITU-T が定めた抽象構文。SNMP / LDAP / X.509 証明書で現役
- XDR (External Data Representation, RFC 4506): NFS / RPC で使用
- NDR: DCE/RPC のデータ表現
- BER / DER / PER: ASN.1 のエンコーディング規則 (DER が証明書で利用)
FAQ
Q: TLS はプレゼンテーション層、それともセッション層？
A: OSI に厳密に当てはまらず議論あり。一般的には「L4 (Transport) と L7 (Application) の間で暗号化 = L6、セッション管理 = L5」と説明されます。実装上は単一ライブラリ (OpenSSL 等) でまとめて提供されます。
Q: JSON / Protocol Buffers は L6 か L7 か？
A: 表現形式そのものは L6 (Presentation)。それを使うアプリ仕様 (どの URL に POST するか等) は L7 です。
Q: 圧縮はトランスポート層でやってはダメ？
A: 必ずしも 6 層で行う必要はありません。TLS にも圧縮機能はありましたが、CRIME 攻撃のため TLS 圧縮は廃止され、現代では HTTP 層 (L6/L7) でのみ圧縮するのが安全とされています。