Common Mistakes I See Students Make

Why these mistakes happen, and how to fix each one

The list above is short. Let us take each mistake, see it with a real example, and learn the fix you can say in an interview.

Mistake 1: wrong layer order, or TCP at the network layer

TCP lives at Layer 4, Transport. IP lives at Layer 3, Network. A simple way to remember: IP gets the packet to the right computer. TCP gets the data to the right program on that computer, using a port number.

Everyday analogy. An address on a letter (city, street, building) is like IP. "Flat 302, attention Mr Patil" is like the port. Both are needed.

A mnemonic from Layer 1 up: "Please Do Not Throw Sausage Pizza Away" = Physical, Data link, Network, Transport, Session, Presentation, Application.

Mistake 2: "a switch works at Layer 3"

A normal switch forwards frames using MAC addresses, so it works at Layer 2. A router forwards packets using IP addresses, so it works at Layer 3. "Layer 3 switches" do exist in enterprise networks. They are switches with routing built in. In an interview, say: "A basic switch is Layer 2. Some enterprise switches also route at Layer 3."

Indian company example. Suppose we are a junior network engineer at TCS, setting up a new floor. Every desk cable goes into an access switch (Layer 2). The floor switches connect to a core device that routes between the office network and the data-centre network (Layer 3).

Mistake 3: "HTTPS is a different layer from HTTP"

HTTPS is simply HTTP sent inside a TLS-encrypted connection. HTTP is still the Layer 7 protocol. TLS is the encryption around it. In the OSI model it is often placed at Layer 6, while TCP/IP treats it as part of the application layer. HTTPS uses TCP port 443 by default, and HTTP uses port 80.

Global app example. Open any site in Chrome and click the site-information icon in the address bar. It shows that the connection is secure and lets you view the certificate. That certificate is what the TLS layer checks. The web page itself is still plain HTTP inside.

Mistake 4: forgetting DNS in the "what happens when I type a URL" answer

Before any HTTP request, the browser must turn ravindrabagale.com into an IP address. That is DNS, usually over UDP port 53. Try it yourself:

$ nslookup example.com
Name:    example.com
Address: 93.184.215.14   (the IP you see may differ)

A good interview answer runs in this order: DNS lookup → TCP handshake → TLS handshake → HTTP request → response → page renders.

Mistake 5: "ping fails, so the server is down"

Ping uses ICMP, a Layer 3 protocol. On AWS, a security group allows only what you add, and most people add SSH (22) and HTTP/HTTPS (80/443), but not ICMP. So the website can be perfectly fine while ping times out.

What you would see:

$ ping 13.234.x.x
Request timeout for icmp_seq 0
$ curl -I http://13.234.x.x
HTTP/1.1 200 OK

The fix: test the actual service with curl, or use nc -zv host 443 to test a port. Only allow ICMP in the security group if you really need it.

Try it yourself

1. Run nslookup google.com and note the IP.
2. Run curl -I https://google.com and note the status line.
3. Draw the 7 layers from memory and place DNS, TCP, IP, TLS and HTTP on them.

Common services, their ports and their layers

Interviewers love asking "which port, which layer?" for real software. Every one of these runs over TCP at Layer 4, with its own protocol at Layer 7.

sudo ss -tlnp | grep -E ":80|:443"

LISTEN 0 511 0.0.0.0:80  users:(("nginx",pid=812))

curl -I http://localhost:8080

HTTP/1.1 200

nc -zv 10.0.2.20 3306

Connection to 10.0.2.20 3306 port [tcp/mysql] succeeded!

pg_isready -h 10.0.2.21

10.0.2.21:5432 - accepting connections

mongosh "mongodb://10.0.2.22:27017" --eval "db.runCommand({ping:1})"

{ ok: 1 }

redis-cli -h 10.0.2.23 PING

PONG

dig +short example.com

93.184.215.14

Summary

More real examples

Indian company example (sample data). Suppose we are a junior engineer at an IRCTC-style booking site on AWS. The security group for the web tier allows 443 from anywhere. The database tier allows 3306 only from the web tier's security group. A student who "fixes" a connection problem by opening 3306 to 0.0.0.0/0 has created a serious risk. The right fix is to check the source security group.

Global example. Internet-wide scans regularly find thousands of MongoDB, Redis and Elasticsearch servers exposed with no password. Many data leaks reported in the news started exactly this way.

Everyday analogy. A building (the IP address) has many doors with numbers (ports). The reception (443) is open to visitors. The server room (3306) should open only for staff with a badge.