Video summary

8 ГЛАВЫХ ВОПРОСОВ ПРО СЕТИ НА СОБЕСЕДОВАНИИ

Main summary

Key takeaways

Technology

Overview

The video from the Simply Devops channel is a guide for surviving networking interview questions. The speakers collected roughly 340 unique questions and found that ~90% of interviews focus on the top 8 most common networking topics. The goal is to answer concepts with clear “what/why” explanations and connect earlier topics into the final full request lifecycle question.

1) TCP vs UDP

Both are transport-layer protocols for delivering data between processes, but they make different tradeoffs.

TCP

  • Connection-oriented
  • Uses a 3-way handshake before data transfer
  • Sends ACKs per packet and retransmits on loss
  • Handles out-of-order packets via reordering
  • Provides delivery, ordering, and integrity
  • Tradeoff: more overhead from handshake/ACKs and potential delays

UDP

  • Connectionless
  • No handshake or ACKs
  • Sender transmits a datagram and does not wait
  • Minimal latency
  • If packets are lost or out of order, the application must handle it

Typical use cases

  • TCP: HTTP, SSH, databases, file transfer (loss of even a single byte matters)
  • UDP: video calls, online games, DNS (fresh data is more important than retransmitting old data)

QUIC-like idea (mentioned)

  • “Quick” runs on top of UDP, but adds reliability at the application level (associated with HTTP/3).

2) TLS/HTTPS handshake (and why each step exists)

Terminology clarification

  • People often say SSL, but in modern practice it’s TLS
  • SSL has effectively been unused since ~2015
  • TLS evolved from SSL

Classic SSL/TLS handshake structure

  • Client Hello
    • Client proposes encryption algorithms and sends randomness
  • Server Hello
    • Server selects algorithm/version
    • Server sends the certificate (with public key)
  • Key agreement
    • Client encrypts a random secret using the server’s public key from the certificate
    • Server decrypts it using its private key
    • Both compute the same symmetric session key
  • Certificate verification (client side)
    • Integrity checks
    • Signed by a trusted CA
    • Domain name matches
  • Begin session encryption
    • Both sides exchange Finished messages to confirm matching keys

Why symmetric crypto afterward?

  • Asymmetric/public-private encryption is slow
  • It’s used mainly for key exchange
  • Bulk communication uses symmetric encryption for performance

mTLS (mutual TLS)

  • Server verifies client certificates too
  • Example contexts mentioned:
    • Kubernetes service-to-service communication
    • A promised “MHSH” service example (per the video)

3) Subnet mask and CIDR

Subnet masks split a 32-bit IPv4 address into:

  • Network part
  • Host part

Example: /24

  • First 24 bits = network
  • Remaining 8 bits = hosts
  • Total addresses: 256
  • Usable addresses: 254 (excluding network and broadcast)

Why practice host counting?

The video emphasizes learning to compute host counts quickly, describing it as a formula/process derived from the mask length—because it’s “needed almost everywhere.”

4) OSI layers (name + purpose)

A recommended interview answer format:

  • Layer number + name + “what it’s for” + examples

Layer-by-layer

  1. Physical
    • Bits/signaling (cables, optics, radio)
  2. Data Link
    • MAC addresses, frames
    • Switches operate within a segment
  3. Network
    • IP, packets, routing
    • ARP/ICMP live here
  4. Transport
    • Ports
    • TCP/UDP segments
    • Delivers data to processes
  5. Session
    • Session management (RPC/JRPC conditionally included)
  6. Presentation
    • Encoding/formats, encryption
  7. Application
    • HTTP, DNS, STP, SSH, etc.

Special note: SSH

  • SSH spans multiple responsibilities (session establishment, encryption, terminal), even if placed at L7.

5) Diagnosing port/service availability (scenario-based)

A practical troubleshooting workflow split into server side and client side.

Server checks

  1. Is the service running and listening?
    • Use ss-style tooling (video mentions ss-tulip, intended as ss -tulp-like) to see listening ports and owning processes
    • Verify the listen address
      • e.g., localhost won’t accept external connections
    • Confirm correct port and check for conflicts (wrong/occupied port)
  2. Firewall rules
    • Check iptables/ufw for drops of incoming traffic
  3. Cloud security groups
    • Even with OS firewall correct, cloud SGs may block the port

Client checks

  • Test reachability to the server port:
    • ping (mentioned, but insufficient for port openness)
    • tnet ip port (likely telnet-style: telnet <ip> <port>) to infer if a TCP port is open/connected
    • Interpret common outcomes:
      • Connection refused → host reachable, service closed
      • Timeout/stuck → packets dropped somewhere (network/firewall)
    • Mention of netcat for similar testing
  • Application-level checks:
    • curl to test HTTP/HTTPS and validate behavior conceptually (including TLS + HTTP flow)
  • If it fails in-between:
    • Use traceroute to identify where it breaks

Key decision points

  • Is the service listening on the correct address/port?
  • Is it blocked by firewall or security groups?
  • Can the client reach it externally?

6) DNS basics + record types

  • DNS translates domain names → IP addresses
  • Common record types mentioned:
    • A (IPv4)
    • AAAA (IPv6)
    • CNAME (alias)
    • MX (mail servers)
    • NS (authoritative name servers)
    • TXT (arbitrary text)

7) HTTP status codes (important interview errors)

The video notes multiple classes, but highlights the ones to remember.

4xx (client errors)

  • 400 bad request
  • 401 unauthorized
  • 403 forbidden (insufficient rights)
  • 404 not found
  • 429 too many requests

5xx (server errors)

  • 500 internal server error
  • 502 bad gateway (proxy can’t reach backend)
  • 503 service overloaded
  • 504 timeout

Emphasis: it’s more effective to remember the specifics and understand them together rather than only memorizing “families.”

8) “What happens when you type a URL in the browser?” (full integrator question)

The video frames earlier topics as fragments of the end-to-end flow (claimed to be asked in ~80% of interviews).

  1. DNS lookup
    • Browser OS cache → system cache → /etc/hosts → DNS server (provider)
    • If needed: root servers → TLD/zone server → authoritative DNS (e.g., Google)
    • DNS response is cached
  2. TCP handshake
    • 3-way handshake to establish the connection
  3. TLS handshake (for HTTPS)
    • Client Hello (algorithms + SNI)
    • Server Hello (certificate + selection)
    • Key exchange, session key derivation, Finished messages
  4. HTTP request
    • Browser sends an HTTP GET with headers over the encrypted channel
    • Request may go through a load balancer or directly (depending on architecture)
  5. HTTP response
    • Server returns status such as 200 OK with HTML
  6. Rendering + parallel asset fetch
    • Browser parses HTML, discovers CSS/JS/images, and makes parallel HTTP requests

Final takeaway: understand the mechanism, not rote memorization—so you can answer variants (the video mentions possible additional topics like BGP and VLANs).

Main speakers / sources

  • Speaker: the host(s) from Simply Devops (the tutorial channel)

Original video