File Transfer, Randall Munroe,https://xkcd.com/949, Creative Commons Attribution-Non Commercial 2.5In this comic, the concept of an ordinary person having a FTP server is quickly dismissed. And yes, it's not common. To the average computer user, the idea that someone could just… connect to your computer feels exotic, or even dangerous — see the very common ironic fear of your IP address being known to other people on the internet.

If you take someone who's "good with computers" but not a networking person, their mental model of The Internet probably involves a definition of "servers" or "the cloud" that distinguishes them from personal computers in some meaningful way. True peer‐to‐peer, if they ever think about it, is an endeavor: Web RTC, STUN, TURN, ICE, what have you. Given that we live in a world of NAT, CGNAT, and restrictive ISPs, this isn't entirely wrong, but it breaks the elegant design of the original Internet.

Why you don't have a FTP server Network address translation (NAT) was first formally proposed in RFC 1631 in 1994. In its abstract, it says: The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long‐term and short‐term solutions to these problems are being developed.

The short‐term solution is CIDR (Classless Inter Domain Routing). The long‐term solutions consist of various proposals for new internet protocols with larger addresses. Classless interdomain routing is not the point of this post, but basically we started giving people more options for network sizes, and while complex in implementation, it was philosophically virtually uncontroversial.

RFC 1631 proposed a second short‐term solution to IP address depletion and scaling in routing: NAT. While it is not exactly the same type of NAT omnipresent on home routers today, the basic idea is the same: it allows multiple devices to share an IP address (from the perspective of a device on the other end of a routing device) by modifying the network address information in the IP packet headers while transferring the packet across a traffic routing device. We then later reserved certain addresses for private use, and these things are used in conjunction on most IP networks — private addresses within the network, NATing to one public address at the router.

On your typical home router, here's how you usually connect to an external server with NAT1: Your computer sends a packet like this: Source IP10.11.70.21Source Port50413 Destination IP67.215.249.229Destination Port70It hits your router, and it modifies it to this: Source IP146.7.15.85Source Port60612 Destination IP67.215.249.229Destination Port70The server replies: Destination IP146.7.15.85Destination Port60612 Your router rewrites it back: Destination IP10.11.70.21Destination Port50413 If you've thought this through, you might be asking: in the situation that an external server wants to talk to you first, how does that happen? It sends a packet to 146.7.15.85, and your router…Oh no. It has no idea where to send it. Working around it Naturally, people noticed this was a problem almost immediately, because people have wanted to run game servers, FTP servers, and web servers from their bedrooms since roughly the beginning of time.

So a whole ecosystem of workarounds grew up around NAT, none of which restore the fundamental intention of the internet, and none of which work for everything. Port forwarding The most direct fix is to just tell your router "hey, when a packet comes in on port 60612, send it to 10.11.70.21 on port 50413, no questions asked." This is port forwarding, and it's the workaround to NAT that the most people are aware of. One of the problems with port forwarding, conceptually, is that one public IP+port can still only map to one device at a time, which means that two devices can't operate a service on the same public IP+port at the same time.

This is more of a problem than it sounds like; on big enterprise or university networks that choke down ….