Separate the tool from the protocol

The telnet command opens a TCP connection to a host and port. That is the feature that made it useful for looking at line-oriented protocols, and it is why the tool outlived its original job by decades.

If you connect to an HTTP server and type an HTTP request, the connection carries HTTP. The program is still a Telnet client, but the server is not a Telnet server:

telnet 127.0.0.1 8000

Nothing about this connection is “the Telnet protocol”, except maybe a few negotiation bytes the client sends at the start. The server ignores or chokes on those, and the rest is pure HTTP. Saying “I telnetted to the web server” describes the tool you used, not the protocol you spoke.

Where the tool gets in the way

The distinction sounds pedantic until it bites. Two things make a Telnet client an imperfect raw TCP tool.

First, it only works when the other protocol uses readable text and does not require TLS right away. Against an HTTPS port the session dies at the handshake, because you type text where the server expects TLS records. openssl s_client is the tool for that case.

Second, Telnet command handling interferes when the data contains byte 255. The client must treat 255 as IAC, so binary data passing through gets reinterpreted or mangled. Netcat has neither problem:

nc 127.0.0.1 8000

It writes exactly what you type and prints exactly what arrives. When you want a guaranteed-transparent pipe, prefer it. I reach for nc first and only use telnet when I want to see negotiation happen.

Know when to stop typing

Use the tool for learning and for small, authorized checks. Confirming a port answers, reading a banner, sending one test command: perfect fits.

For real work, use a protocol-specific client. It understands framing, validation, authentication, redirects, timeouts, and errors. Typing HTTP by hand teaches you what curl does. It does not replace curl, which handles chunked encoding, retries, and TLS without you thinking about any of it.

The mental model to keep: TCP carries bytes, a protocol gives the bytes meaning, and a client program is just how the bytes get typed. Any tool that can push bytes into a socket can speak any text protocol, badly or well. The next lessons put that to work against HTTP and SMTP.