text vs. binary protocols
When two programs exchange messages, the designer must choose how those messages look on the wire. One option is to make them human-readable text — lines of letters and digits you could print and read, like "GET /index.html" or "MAIL FROM:<[email protected]>". The other is a binary protocol, where messages are compact sequences of raw bytes with fixed-width fields and numeric codes that mean nothing to the naked eye but everything to the machine. This text-versus-binary choice runs through almost every protocol ever designed.
Text protocols (HTTP/1.1, SMTP, classic FTP) are wonderful to debug and learn: you can read the conversation with your own eyes, type commands by hand to test a server, and inspect a capture without special tools. The cost is efficiency — text is verbose. The number 1000000 takes seven characters as text but fits in four bytes as a binary integer; parsing text (finding line breaks, converting digits to numbers) also burns CPU. Binary protocols (HTTP/2, many database and gaming protocols) flip the trade-off: they are compact and fast to parse because fields are at known offsets with known sizes, but you cannot read them without a decoder, and a single misplaced byte can be far more confusing to diagnose.
The trend in modern protocol design is from text toward binary as systems mature and scale. HTTP began purely textual, then HTTP/2 reframed the very same methods and headers as a compact binary framing for speed and compression — keeping HTTP's text-era meaning but packing it in binary. The honest takeaway: text is not naive and binary is not always superior. Text wins for protocols meant for humans and easy interoperability; binary wins where bandwidth, latency, and parsing cost dominate. A good designer picks based on who and what the protocol must serve, and there are also middle grounds like JSON (text, structured) and Protocol Buffers (compact binary, schema-defined).
To debug a mail problem you can literally type SMTP by hand into a terminal and read every reply, because it is text. You cannot do that with HTTP/2: its framing is binary, so you need a tool like Wireshark to decode the bytes into something readable — the price HTTP/2 pays for being compact and fast.
Text: human-readable, easy to debug, verbose. Binary: compact, fast to parse, opaque without a decoder.
Text protocols are not automatically simpler or safer — text parsing has its own pitfalls (injection, ambiguous whitespace, encoding bugs). And binary is not automatically faster end-to-end; on a fast link the bottleneck may be elsewhere entirely.