How am I able to telnet to HTTP port 80?

Question

After searching in google I found out that we can telnet to web-server to its http port and use GET to retrieve a html page.

For ex:

$ telnet web-server-name 80

But I am not able to understand how is this possible ?

I thought that if port 80 is for http server, then port 80 will only listen for http requests. But how am I able to telnet to an HTTP port ?

Aren't telnet and HTTP two different protocol ?

Answer 1

Congratulations, you've just delved into the concept of networking layers by realizing that ports and protocols are not directly connected with each other. As others are saying, telnet can be used to connect to any TCP port. However to understand why this is possible you need to understand a bit about networking layers. If you've ever heard of the OSI 7 layer model this is what allows you to use telnet to connect to another port. Although on the Internet, they only concern themselves with 4 of the layers and its called the Internet Protocol Suite. Without layers of networking, each program would not only need to understand its own protocol, but would have to define its own IP addressing scheme and port system, which means each router would need to understand how to route these schemes and different protocols would be much harder to learn and diagnose. To put it simply, the Internet wouldn't work nearly as well without layers.

What you are concerned with are the transport layer and the application layer. At the transport layer we have Internet protocols like TCP and UDP with port numbers ranging from 1 to 65535 on each. At the application layer we have protocols such as HTTP, SMTP and DNS. Usually each Internet standards document that defines a protocol specifies a default TCP or UDP port that the protocol should use by default. Such as TCP port 80 for HTTP, TCP port 25 for SMTP, UDP port 53 for DNS and TCP port 23 for Telnet. The telnet program actually speaks the TELNET protocol, which is a standard protocol, but mostly an ancient one by current standards. Because its protocol sequences are made from 8-bit characters, you rarely see the protocol itself and its mostly transparent when compared with other more modern protocols like HTTP and SMTP that use human visible words in ASCII such as GET, POST, HELO, LOGIN, etc.

Because its protocol isn't generally visible, telnet made for a decent tool for connecting to other TCP ports and allowing the user to type in protocols manually. Some network administrators use this technique in order to diagnose problems with servers. However because the telnet program still has its own protocol and may send extra bits of data sometimes, you can still experience problems with this technique. When you use telnet you really are "making a connection" at the application layer as well as the transport layer. It just happens that other application layer protocols may work ok through it for most diagnostics and won't interfere with the telnet protocol. There is a better program for doing this through called nc (Net Cat. It gets its name from being a Network based version of the cat command).

$ nc www.stackexchange.com 80

The nc program doesn't speak any application layer protocol and when you make a connection with it you are "making a connection" only at the Internet layer (IP address) and Transport layer (TCP or UDP). What that means is that you control what application layer protocol is used. Almost anything is fair game, even binary protocols. This also allows you to do useful things like transfer files without them being corrupted and listen on ports for incoming traffic:

nc -l 9000 < movie.mp4  (Your friend runs this)

nc friends.computer.hostname 9000 > movie.mp4  (you run this)

And then movie.mp4 is transfered over the network using no application layer protocol (such as FTP) at all. The application protocol is actually your friend telling you that they are ready for you to run your command.

nc can also handle UDP packets and UNIX-domain sockets. Using it to listen can also be interesting.

nc -l 12345

Now in your web browser visit http://localhost:12345/ and in your nc session you should see the browser's GET / HTTP/1.1 request. At this point you can type something in and press Ctrl-D and it should show up in your browser in plain text (If you want HTML to show up, you have to send it back the proper HTTP protocol response followed by HTML code).

Sometimes, programs which natively speak one protocol like HTTP can connect to other ports that are meant for a different protocol. You typically can't do this in a GUI browser anymore because they have restricted them from connecting to some ports, but if you use a program like curl to connect to port 25 (SMTP for sending mail) you'll probably see a couple of errors about breaking protocol.

$ curl yourispsmtpserverhost.com:25
220 yourispsmtpserverhost.com ESMTP Postfix
221 2.7.0 Error: I can break rules, too. Goodbye.

This happens because curl normally speaks the HTTP protocol, so after it establishes a TCP handshake, it starts sending data like this:

GET / HTTP/1.1
Host: yourispsmtpserverhost.com:25
User-agent: curl

But what the SMTP server is expecting is SMTP, which is more like this:

HELO myhomecomputername.local

At which point the server sends back its identification line:

250 yourispsmtpserverhost.com

So you see that there is nothing that prevents curl from establishing a transport layer connection with the SMTP server, it just can't speak the protocol. But you can speak the protocol yourself with a program like telnet or more preferably nc.

Answer 2

telnet is a tool that can connect to any tcp port.

By default, it connects to the telnet port (23), but you can tell it to connect to the http port (80) or smtp port (25) or whatever instead.

You need to know how to "speak" the protocol that the remote server is listening for on that port, though.

For example, if you want to get the headers of a web site (domain names etc changed to protect the guilty):

$ telnet www.example.com 80
Trying xxx.xxx.xxx.xxx...
Connected to www.example.com.
Escape character is '^]'.
HEAD http://www.example.com/ HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 30 Oct 2015 09:28:58 GMT
Server: Apache/2.4.17 (Debian)
Last-Modified: Sun, 14 Nov 2010 06:30:26 GMT
ETag: "843-494fd75830480"
Accept-Ranges: bytes
Content-Length: 2115
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

Connection closed by foreign host.

The HEAD line is what i typed into the connection. Note that the http protocol requires you to send a blank line to indicate the end of your HEAD or GET or whatever request. That's the blank line immediately after the HEAD request.

Answer 3

The initial negotiation for both protocols uses text-commands, so you can connect and start to enter commands. This is true of other old protocols such as SMTP, and telnet has long been used to troubleshoot connections to the respective services.

For example

• HTTP Help: How to test HTTP using Telnet
• XFOR: Telnet to Port 25 to Test SMTP Communication

The protocols are independent of the port on which they communicate. Almost all implementations can be configured to listen on any port.

Some protocols (such as HTTPS) do not use text commands for negotiation. You can however (usually) connect to the port on which the server listens, but do nothing useful.

Answer 4

Some of your understanding is correct and some isn't. Port 80 is generally reserved for HTTP, but that's just a convention; any program can listen on any open port on the system. If there's a webserver listening on port 80 on the system you're connecting to, you do need to use HTTP to communicate with it.

telnet isn't a protocol at all, it's a program that lets you send raw text to any host on any port. The remote host has no idea what program is connecting to it; all it can see are the packets being sent to it. Any program that sends packets that comply with the protocol the remote host is expecting will work, so you can use telnet to communicate over any text-based protocol.

You sent something along the lines of GET /path/to/a/file HTTP/1.1, which is a valid HTTP 1.1 command and looks the same as a request that would be sent by a web browser, so it works fine.