OPERATOR REFERENCE · LAYER 6

Layer 6 Field Reference
Data Representation, Encoding & TLS

translate → encode → compress → encrypt — making bytes mean the same thing on both ends
APPLICATION DATA · JSON / text
encode + compress + encrypt
WIRE FORMAT · TLS-protected bytes

A note on scope: like Layer 5, Layer 6 is a formal OSI concept mostly absorbed into application-level libraries in real TCP/IP stacks — character encoding, serialization, compression, and TLS all do presentation-layer work even though we don't call them that day-to-day.

01 What the Presentation Layer Does

Translation

Converts between the application's native data format and a common wire format both ends agree on.

Compression

Reduces payload size before transmission — reversed by the receiver before handing data to the application.

🔒

Encryption

Transforms readable data into ciphertext so only the intended recipient can decode it back into something meaningful.

02 Character Encoding
EncodingSize per CharacterNotes
ASCII1 byte (7-bit)128 characters — English letters, digits, basic symbols only
UTF-81–4 bytes, variableBackward-compatible with ASCII, dominant encoding on the web
UTF-162 or 4 bytesCommon internally in Windows and Java
UTF-324 bytes fixedSimple indexing, rarely used due to size
Latin-1 (ISO-8859-1)1 byteLegacy Western European encoding, common source of mojibake

Mojibake

Garbled text ("’" instead of an apostrophe) happens when bytes are decoded with the wrong character set — always declare and match encoding explicitly.

03 Data Serialization Formats
FormatTypeNotes
JSONTextHuman-readable, ubiquitous for web APIs
XMLTextVerbose, schema-validated, common in legacy enterprise systems
Protocol BuffersBinaryCompact, schema-defined, fast to (de)serialize — common in gRPC
MessagePackBinaryJSON-like data model, binary-efficient encoding
ASN.1BinaryFormal notation used in TLS certificates, SNMP, LDAP
YAMLTextHuman-friendly, common for config files
04 Common MIME Types
T

Text

  • text/html
  • text/plain
  • text/css
A

Application

  • application/json
  • application/xml
  • application/octet-stream
M

Media

  • image/jpeg, image/png
  • audio/mpeg
  • video/mp4
05 Compression

Lossless

Original data fully recoverable — required for text, code, and structured data.

  • gzip / deflate
  • Brotli
  • zstd

Lossy

Some data discarded permanently for much smaller size — acceptable for media where perfect fidelity isn't required.

  • JPEG (images)
  • MP3, AAC (audio)
  • H.264, H.265 (video)
06 Encryption & TLS

Symmetric

Same key encrypts and decrypts — fast, used for the bulk data once a session key is agreed (AES-GCM, ChaCha20).

🔑

Asymmetric

Public/private key pair — used during the handshake to safely establish that shared symmetric key (RSA, ECDHE).

📜

Certificates

X.509 certs (ASN.1-encoded) bind a public key to an identity, signed by a trusted Certificate Authority.

07 TLS 1.3 Handshake (Simplified)
CLIENT SERVER ClientHello — supported ciphers, key share ServerHello + certificate + key share Finished — encrypted application data begins TLS 1.3: full handshake in 1 round trip
08 Common Codecs
CodecMediaNotes
H.264 (AVC)VideoWidely supported, good compression, hardware-accelerated almost everywhere
H.265 (HEVC)VideoBetter compression than H.264, licensing complexity limits adoption
VP9 / AV1VideoRoyalty-free, used heavily by YouTube and streaming platforms
AACAudioBetter quality-per-bit than MP3, standard for streaming
OpusAudioLow-latency, excellent for real-time voice (WebRTC)
09 What Happens — Browser Loads an HTTPS Page
1

TCP connection established

Standard 3-way handshake completes on port 443 (Layer 4 work is already done at this point).

Pre-TLS
2

TLS handshake negotiates encryption

Client and server agree on a cipher suite, exchange key material, and the server presents its certificate for identity verification.

Encryption setup
3

Certificate validated

Browser checks the certificate's signature chain up to a trusted root CA, confirms the domain name matches, and checks it hasn't expired or been revoked.

Trust verification
4

Symmetric session key derived

Both sides now share a symmetric key for the rest of the session — fast enough to encrypt/decrypt every byte of the page without the overhead of asymmetric crypto.

Key derivation
5

Request encoded and compressed

Browser sends an HTTP request declaring what formats it accepts (Accept-Encoding: gzip, br) and what character sets/content types it can handle.

Content negotiation
6

Server responds — compressed, then encrypted

Server compresses the HTML/JSON payload (per the negotiated encoding), then TLS encrypts the whole thing before it ever hits the wire.

Presentation transform
7

Browser decrypts, decompresses, decodes

On arrival: TLS layer decrypts first, then the declared Content-Encoding is reversed (gunzip/brotli), then bytes are decoded using the declared charset (usually UTF-8) into text the renderer can use.

Reverse transform
8

Application layer takes over

The now-plain HTML/JSON is handed up to the browser's rendering/application logic — presentation layer's job is done.

Handoff
10 Common Layer 6 Issues
SymptomLikely Cause
Garbled text (mojibake)Character encoding mismatch between sender and receiver
TLS certificate warningExpired cert, hostname mismatch, untrusted/self-signed CA
Media won't playUnsupported codec on the client device/browser
Response larger than expectedCompression not negotiated or not applied server-side
API parsing failureContent-Type mismatch — client expects JSON, server sent XML/text
CheckHow
Cert chain & expiryopenssl s_client -connect host:443
Response headerscurl -I https://host
Actual encoding usedInspect Content-Encoding / Content-Type response headers
Byte-level inspectionhexdump / file --mime-encoding