Networking Basics: IP, Ports, TCP/UDP and Firewalls

Concept

Every computer that talks over the internet needs three things. First, an address (the IP address). Second, a door on that address (the port). Third, an agreed language for the talk (the protocol, such as TCP or UDP). A protocol is a set of rules for how two computers talk. When your browser opens yourapp.com, it connects to something like 52.66.12.9:443 and speaks HTTPS over TCP. Everything else in networking is built on this one idea.

Why this matters

On Vercel, making your app reachable was automatic. You never thought about it. On EC2, you decide three things. Which port does your app listen on? Which ports may the outside world reach? Does traffic arrive directly, or through a proxy (a program that receives requests and passes them on to your app)?

If you get this wrong, you will see a common beginner problem. Your app runs well, and curl localhost:3000 works on the server itself. But the browser on your laptop waits and then times out. This is a networking problem, not a code problem. This lesson helps you find the cause in minutes instead of hours.

Key terms, explained simply

Think of your server like an office building

Before the technical diagram, here is a simple picture. Keep it in mind. Every term above matches something in this story.

• IP address is the building's street address. Every building needs one so the post can find it.
• Port is the door number of one room. Door 22 leads to the security room (SSH). Door 80 leads to reception (website). Door 443 leads to the secure reception (HTTPS website). Door 5432 leads to the record room (your database). One building has many rooms and many doors. Each room does a different job.
• Security Group is the guard at the main gate. By default, the guard says no to everyone. Nobody enters until you give an instruction, such as “let people through door 80 and door 443 only.” Every other door stays locked, even if something useful is behind it.
• localhost is a room that only someone already inside the building can reach. 0.0.0.0 is a room open to the whole building network. But the guard at the gate still decides whether outsiders can enter the building at all.
• Nginx is the receptionist. It is a web server program that receives requests and passes them to your app (a reverse proxy). Visitors do not walk straight to any room. They knock on the receptionist's door (80/443, the only doors the guard allows). The receptionist then walks them to the real room inside: your Next.js app on door 3000. Outsiders can never reach that room directly.

Architecture — the full request flow

Here is the same journey as a technical diagram. Port 3000 does not appear anywhere on the path from the outside. Only Nginx is exposed. Real production servers are set up this way.

Common ports you'll actually use

TCP vs UDP — why it matters for your stack

• TCP is like a phone call where you keep asking “did you hear that? OK, next sentence.” It is slower, but nothing is missed. It is used for websites, databases and logins, where losing data is not acceptable.
• UDP is like shouting instructions to someone who is walking away. It is fast, but if they miss a word, nobody repeats it. It is used for video calls, quick DNS lookups and live games, where speed matters more than perfection.

Your web app (HTTP requests, database connections, SSH) uses TCP. UDP mainly appears in DNS lookups (Lesson 3) and in live video or voice features, if you add them. (Newer HTTP/3 also uses UDP, but you can ignore that for now.) For almost everything you build, TCP is the one that matters.

Security Groups — in detail

A Security Group is a virtual firewall (a firewall made of software) that you attach to your EC2 server's network connection. In the building story, it is the guard at the main gate. The guard checks every visitor before they can knock.

Outbound traffic is allowed by default. Outbound means your server calling out to the internet, for example to download npm packages. So your server works normally, and the outside is still locked out.

Security Groups are “stateful”

“Stateful” means the firewall remembers connections. If you allow an inbound request on port 443, the response to that request is allowed back out automatically. You do not need a separate outbound rule. The guard remembers who came in and lets the reply go back to that same visitor.

AWS also has a second firewall called a Network ACL (Lesson 6, VPC). It works on a whole subnet (a part of your network), not on one server. It is stateless, so you must write rules for both directions. Security Groups are simpler, and you will use them most of the time.

Every rule has four parts

A real, production-style setup for your Next.js app server

A different setup for your RDS PostgreSQL database

That last row is an important pattern in real AWS setups. Instead of an IP address, the source is another security group's ID. It means “allow traffic only from servers in that other group.” If your app server's IP changes, the rule still works. The database stays hidden from the public internet.

Managing security groups

You create a security group, then add one rule per door: HTTPS from anywhere, SSH only from your own /32. You can do this in the console or in the CLI. Lesson 6 builds the real ones step by step, so there is nothing to run yet.

Real example — a debugging story

You deploy your Next.js app. You open the browser on your laptop and type the server's address. Nothing loads. Here is how to think it through, step by step.

1. “Is anyone actually in the room?”

   SSH into the server and check if the app process is even running.

   On the serverCopy all

   • ps aux | grep nodeCopy

     Is a node process alive at all?

   • sudo ss -tulpn | grep 3000Copy

     Is anything listening on port 3000?

   If nothing shows up, the app is not running. Fix that first, before you touch networking.

2. “Is the room locked to insiders only?”

   Check which interface the app is actually listening on.

   On the serverCopy all

   • sudo ss -tulpnCopy

     127.0.0.1:3000 = only the server itself can reach it · 0.0.0.0:3000 = open to the network (if the firewall allows)

   In production, keep the app on 127.0.0.1 and put Nginx in front. This is the safer and correct way.

3. “Did the guard even let me near the door?”

   From your own laptop, test whether the port is reachable at all.

   From your laptopCopy all

   • nc -zv <your-ec2-public-ip> 3000Copy

     nc (netcat) tries to connect to a port. Two different answers mean two different problems:

   • “Connection refused” — you reached the door, and the server said nobody lives here. Nothing is running on that port.
   • “Connection timed out” — you are not even allowed near the door. The Security Group blocks you before you get close. This is the most common beginner mistake.

Practice task before Lesson 3

You still do not need EC2. Your laptop can act as a server too. It has an IP, ports, and a process listening on one of them. Run your Next.js app and inspect it as you would a real server.

npm run dev &                 # Next.js on port 3000
curl -I http://localhost:3000 # from inside — expect HTTP/1.1 200
nc -zv 127.0.0.1 3000         # expect "succeeded"
nc -zv 127.0.0.1 3001         # nothing there — expect "Connection refused"

Then work out, on paper, how many addresses are in 10.0.0.0/16, 10.0.1.0/24 and 103.45.12.8/32. (Hint: an IPv4 address has 32 bits, and the number after the slash is how many bits are fixed.)

Then answer these in your own words:

1. nc says “Connection refused” on 3001, but it would say “timed out” on a locked EC2 port. Why are the two messages different? Which one points at the Security Group?
2. Your app listens on 127.0.0.1:3000. Nginx listens on 0.0.0.0:443. Which of the two needs a Security Group rule? Why is that enough?
3. Why is the RDS rule's source a security group ID instead of the app server's IP address?
4. Write the three inbound rules (type, port, source) for your own app server. If any source is 0.0.0.0/0, say why that is safe there.

Conclusion

Networking on AWS is not hard once you remember the one idea from the top of this lesson: address, door, language. An IP finds the machine. A port picks the service on it. TCP carries the talk reliably. Everything else is a rule about who may knock on which door.

• Public vs private: only Nginx on 80/443 is public. Your app on 127.0.0.1:3000 and your database on 5432 always stay private.
• Security Groups: they block all inbound traffic by default, allow only what you list, and are stateful, so replies come back on their own. Allow SSH from your IP with /32, never from 0.0.0.0/0.
• Group-to-group rules: the database allows the app server's security group, not an IP. So it stays hidden from the internet even when servers come and go.
• The three-check debug order: Is the process running (ps, ss)? Which interface is it listening on? Can you reach the port from outside (nc -zv)? “Refused” means nothing is listening. “Timed out” means the firewall blocked you.

You now know what Vercel did for you every time you deployed. You can do it yourself, with the doors you choose.

End of Lesson 2. Next: Lesson 3 — DNS Deep Dive.