HTTP by hand

Open a connection to a web server and type the request yourself, like we used to do with telnet.

How this differs from real telnet

A web page cannot open a raw network connection. So this terminal checks what you type the way a server would, and then asks the browser to send the request for you. The data you get back from port 443 is real, but the browser stands in between:

Port 80 is simulated. A page loaded over https may not send plain http. You get the redirect to https that almost every site returns, marked [simulated].
Some headers are not yours to set. The browser always sends its own Host, Connection, Content-Length, Cookie and a few others. Yours are checked, but not sent.
The status line is rebuilt. The browser probably spoke HTTP/2 to the server and only reports the status code.
Not all response headers are visible, only the ones the site allows pages to read, and their names are shown in lowercase.
Redirects are followed for you. You see the final answer, with a note.
Many sites cannot be read at all. Unless a site sends an Access-Control-Allow-Origin header (CORS), the browser hides its answer from this page. Type hosts for sites that work.
ping uses HTTPS instead of ICMP. A page cannot send ICMP echo requests, so each ping is a small HTTPS request to port 443. The times are really measured, but include the server's handling of the request, and no IP address is shown.