STT is one of many protocols for network communication. This chapter provides factual comparisons with common alternatives to help you understand when STT is the right choice and when other protocols may be more suitable.
STT's Unique Position: Agnostic binary transport with zero assumptions. Unlike HTTP (assumes documents/requests), WebRTC (assumes media), or BitTorrent (assumes files), STT works for ANY binary use case. YOU define semantics.
HTTP (HyperText Transfer Protocol) is the protocol used for web browsing. HTTPS adds TLS encryption.
Architecture: Client-server
Model: Request-response
Transport: TCP
Encryption: TLS (optional in HTTP, standard in HTTPS)
| Aspect | HTTP/HTTPS | STT |
|---|---|---|
| Model | Client-server | Peer-to-peer |
| Pattern | Request-response | Bidirectional streaming |
| Connection | Can be stateless (HTTP/1) or persistent (HTTP/2) | Always stateful session |
| Encryption | TLS (standard crypto) | STC (probabilistic crypto) |
| Browser Support | Universal | None |
| Latency | Higher (request-wait-response) | Lower (continuous streaming) |
| Overhead | Text headers (HTTP/1) or binary (HTTP/2) | Binary frames |
| Authentication | Various (Basic, OAuth, etc.) | Pre-shared seed only |
- Web applications accessed through browsers
- RESTful APIs
- Simple request-response patterns
- Need universal client support
- One-way data flow (client requests, server responds)
- Content delivery (websites, APIs, downloads)
- Direct peer-to-peer communication
- Bidirectional streaming data
- No browser requirement
- STC cryptography is requirement
- Real-time continuous data flow
- Multiple simultaneous streams needed
HTTP/HTTPS:
- Website: User requests page, server sends HTML
- API: App requests data, server sends JSON
- Download: Client requests file, server sends file
STT:
- Video call: Both peers send/receive video simultaneously
- File sync: Devices exchange file changes continuously
- Sensor network: Devices stream data to each other
gRPC is a modern RPC (Remote Procedure Call) framework by Google.
Architecture: Client-server
Model: RPC with streaming support
Transport: HTTP/2
Serialization: Protocol Buffers
Encryption: TLS
| Aspect | gRPC | STT |
|---|---|---|
| Model | Client-server RPC | Peer-to-peer streaming |
| Streaming | Unary, server, client, bidirectional | Multiplexed streams |
| Serialization | Protocol Buffers | STT binary format |
| Code Generation | Required (protobuf compiler) | Not required |
| Transport | HTTP/2 over TCP | UDP or WebSocket |
| Encryption | TLS | STC |
| Language Support | Many languages | Python (currently) |
- Service-to-service communication in microservices
- Need strong typing and code generation
- Client-server model fits your architecture
- Want HTTP/2 benefits (multiplexing, header compression)
- Need broad language support
- Peer-to-peer applications
- STC cryptography requirement
- No need for code generation
- UDP transport preferred (lower latency)
- Custom binary protocol needed
WebRTC (Web Real-Time Communication) enables peer-to-peer communication in browsers.
Architecture: Peer-to-peer (with signaling server)
Model: Real-time media streaming
Transport: UDP (with SRTP/DTLS)
Use Cases: Video/audio calls, data channels
| Aspect | WebRTC | STT |
|---|---|---|
| Peer-to-Peer | Yes (requires signaling server) | Yes (direct) |
| Browser Support | Excellent | None |
| Media Focus | Optimized for A/V | General binary data |
| NAT Traversal | Built-in (ICE/STUN/TURN) | Not implemented |
| Encryption | DTLS-SRTP | STC |
| Setup Complexity | Higher (signaling needed) | Lower (direct if IPs known) |
| Data Channels | Limited | Multiple streams native |
- Browser-based applications
- Video/audio conferencing
- Need NAT traversal without manual config
- Standardized protocol important
- Interoperability with existing WebRTC clients
- Non-browser applications
- Binary data streaming (not just media)
- STC cryptography requirement
- Direct peer connections (IPs known)
- Custom protocol control needed
QUIC is a modern transport protocol by Google, now standardized as HTTP/3's transport.
Architecture: Client-server or peer-to-peer
Model: Stream-multiplexed
Transport: UDP-based
Encryption: TLS 1.3 integrated
| Aspect | QUIC | STT |
|---|---|---|
| Transport | UDP | UDP or WebSocket |
| Streams | Multiplexed | Multiplexed |
| 0-RTT | Supported | Not supported |
| Encryption | TLS 1.3 | STC |
| Connection Migration | Supported | Not supported |
| Standardization | IETF standard | Not standardized |
| Adoption | Growing (HTTP/3) | Limited |
- Need fast connection establishment (0-RTT)
- Connection migration important (mobile)
- Want IETF standardization
- HTTP/3 benefits needed
- Standard TLS encryption sufficient
- STC cryptography required
- Simpler implementation preferred
- Custom protocol requirements
- No need for connection migration
- Not using HTTP
Direct use of TCP or UDP sockets without application protocol.
| Aspect | Raw TCP/UDP | STT |
|---|---|---|
| Abstraction | Low-level | High-level |
| Encryption | None (you implement) | Built-in (STC) |
| Framing | You implement | Built-in |
| Sessions | You implement | Built-in |
| Streams | You implement | Built-in |
| Complexity | High (DIY everything) | Lower (protocol provided) |
- Need absolute control over protocol
- Implementing a new custom protocol
- Performance critical (no abstraction overhead)
- Very specific requirements
- Need encryption without implementing crypto
- Want session/stream management handled
- Binary protocol with framing needed
- Focus on application logic, not protocol
BitTorrent is a peer-to-peer file-sharing protocol.
Architecture: Peer-to-peer swarm
Model: Distributed file sharing
Focus: Efficient file distribution
| Aspect | BitTorrent | STT |
|---|---|---|
| Model | Many-to-many (swarm) | One-to-one and server mode (manual peer connections) |
| Purpose | File distribution | General binary streaming with STC encryption |
| Chunking | File pieces | Frame-based streaming |
| Redundancy | High (many sources) | Session-based reliability |
| Encryption | Optional | Always (STC) |
- Distributing large files to many users right now
- Mature ecosystem with existing infrastructure
- File sharing is primary use case
- Standard tooling widely available
- Binary transmission applications requiring encryption
- STC encryption integration (content-addressed hashing)
- Real-time streaming with session continuity
- Need encrypted peer-to-peer communication
- Multi-stream multiplexing required
- Building a web application or API
- Client-server model fits
- Need browser compatibility
- Simple request-response adequate
- Microservices architecture
- Need typed contracts (protobuf)
- Client-server RPC pattern
- Want HTTP/2 benefits
- Browser-based peer-to-peer
- Real-time audio/video primary use case
- Need NAT traversal
- Standard protocol important
- Need fast connection setup
- Connection migration important
- Want latest HTTP benefits
- Standard TLS encryption sufficient
- STC cryptography is required or preferred
- Direct peer-to-peer communication
- Bidirectional streaming of binary data
- Multiple simultaneous streams needed
- No browser requirement
- Custom binary protocol acceptable
- Pre-shared seed distribution is feasible
It's important to understand what STT does NOT provide:
STT is not a web protocol. Cannot be used directly in web browsers.
No public-key infrastructure. Peers must exchange seeds out-of-band before connecting.
STT requires manual network configuration (port forwarding) for peers behind NAT.
Compromise of shared seed allows decryption of all past and future sessions. Key rotation provides limited protection.
Currently Python only. Other language implementations needed for broader adoption.
STT is not an IETF standard. Protocol changes are possible between versions.
- STT: Low (UDP option, binary protocol)
- HTTP/1.1: Medium (TCP, text headers)
- HTTP/2: Low-Medium (TCP, binary, multiplexing)
- WebRTC: Very Low (UDP, optimized for real-time)
- QUIC: Low (UDP, 0-RTT option)
- STT: High (binary, efficient framing)
- HTTP/1.1: Medium (text overhead)
- HTTP/2: High (binary, compression)
- WebRTC: High (UDP, media-optimized)
- QUIC: High (UDP, stream multiplexing)
- STT: ~400ms (2 RTT over internet)
- TLS 1.3: ~200ms (1 RTT)
- TLS 1.2: ~400ms (2 RTT)
- QUIC 0-RTT: 0ms (with prior connection)
STT is best suited for:
- Applications requiring STC cryptography
- Direct peer-to-peer binary streaming
- Multiple simultaneous data streams
- Non-browser environments
- Cases where pre-shared seed distribution is acceptable
STT is NOT suitable for:
- Web browsers (use WebRTC or WebSocket)
- Public web APIs (use HTTP/HTTPS)
- Wide deployment without seed management
- Cases requiring public-key authentication
- Need for IETF standardization
Choose the protocol that best fits your requirements. STT's unique value is STC integration for peer-to-peer streaming with pre-shared trust.
Continue to Chapter 15: Design Decisions and Trade-offs to understand why STT was designed the way it is.
Review Questions:
- What is the main architectural difference between HTTP and STT?
- Which protocol is best for browser-based video calls?
- What is STT's main limitation compared to WebRTC?
- When would you choose gRPC over STT?
- What does STT offer that raw TCP/UDP doesn't?