There&#x27;s an RFC that goes over it but basically, you open a connection, send a pathname, and then the server responds with the file, which is basically the original HTTP spec (without the GET&#x2F;DELETE&#x2F;etc verbs).<p>Oh, but it also differentiates between text and binary files. Binary files are sent as-is, text files are sent line by line with a \r\n terminator.  .\r\n indicates the end of file. Leading .s must therefore be doubled. And then directories are sent in another format (type&#x2F;name, path, hostname, port -- tab separated).<p>Which means the client has to know before hand if it&#x27;s a text or binary file or directory.  How does it know that? Well, there&#x27;s a 1-character code at the start of the filename which gives the filetype. 0 is a file, 1 is a directory, 9 is a binary file. There are also other filetypes which will make you reminisce about the 80s (Unencoded file, BinHexed file, n3270 session, etc.<p>HTTP (once headers and mime types were added) is a better protocol.  Maybe people pine for the days when you didn&#x27;t need 2 megabytes of javascript to punch the monkey, but that&#x27;s not due the underlying transport protocol.<p><a href="https:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc1436.txt" rel="nofollow">https:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc1436.txt</a>