YT YouTube2Text

YouTube2Text → Transcripts → Networking was HARD until I Learned these 20 Concepts

Networking was HARD until I Learned these 20 Concepts — Transcript

by Ashish Pratap Singh · 2,841 words · 452 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00In this video, I'll break down the 20
0:02most important networking concepts in an
0:04order that actually makes sense using
0:06simple visuals and real-world examples.
0:08If you're new to the channel, my name is
0:10Ashish. The networking concepts I'll
0:12cover today are the ones I've come
0:14across most often in interviews, system
0:16design, and throughout my 9+ years as a
0:18software engineer. Let's start with the
0:19framework that gives us a high-level
0:21view of how networking works and helps
0:24us understand where each concept fits,
0:26the OSI model. The OSI model is a
0:28conceptual framework that breaks network
0:31communication into seven layers. When a
0:32request is sent, the data moves down the
0:34network stack, and each layer adds the
0:36information it needs, such as headers
0:38for addressing, routing, or delivery. On
0:40the receiving side, the process happens
0:42in reverse. Each layer reads and removes
0:44its own information before passing the
0:46remaining data to the layer above. The
0:48OSI model is mainly conceptual. In the
0:51real world, the internet is usually
0:53described using the simpler TCP/IP
0:55model, which combines several OSI
0:57layers. But regardless of the model, we
0:59still need a way to efficiently move
1:01data across the network. That brings us
1:03to packets. When data travels across a
1:05network, it usually isn't sent as one
1:07large block. Instead, it is broken into
1:09smaller units called packets. For
1:11example, when you download an image, its
1:13data may be split across many packets.
1:15These packets can travel through the
1:16network independently and are combined
1:19again at the destination. Breaking data
1:21into packets also allows the network to
1:23carry traffic from many different
1:24devices over the same links, with their
1:26packets interleaved as they move through
1:28the network. Each packet contains two
1:30main parts, a header and a payload. The
1:32payload carries the actual data, while
1:34the header contains information needed
1:35to deliver it, such as the source and
1:37destination IP addresses. Let's
1:39understand IP addresses in more detail.
1:41An IP address identifies a device or
1:43network interface and helps the network
1:45determine where packets should be
1:46delivered. There are two main versions
1:47of IP in use today, IPv4 and IPv6. IPv4
1:51uses 32-bit addresses, giving us about
1:534.3 billion possible addresses. But
1:56that's not big enough for the modern
1:57internet. IPv6 uses 128-bit addresses
2:00and provides a significantly larger
2:02address space. Every device on the
2:03internet has an IP address, but a packet
2:05usually doesn't travel directly from the
2:07source to the destination address.
2:09Instead, it passes through multiple
2:11networks along the way. At each step,
2:13something has to decide where the packet
2:15should go next. That's the job of a
2:17router. A router connects different
2:19networks and forwards packets between
2:21them. When a packet arrives, the router
2:23looks at its destination IP address,
2:26checks its routing table, and decides
2:28where to send the packet next. On the
2:30internet, many routers repeat this
2:32process until the packet reaches its
2:34destination network. Your home router
2:36connects your local network to your
2:37internet service provider. Routers move
2:40packets between networks using IP
2:42addresses. But, nobody wants to type an
2:44IP address every time they visit a
2:45website. We want names like google.com.
2:48To translate those names into addresses,
2:50we use DNS. DNS, or the Domain Name
2:52System, translates human-readable domain
2:55names like algomaster.io into IP
2:57addresses that computers can use to
2:59connect to servers. When you enter a
3:01website in your browser, it first checks
3:03whether the IP address is already
3:04cached. If not, it sends a DNS query.
3:07That query may go through a DNS
3:08resolver, which can contact the root
3:10servers, the top-level domain servers,
3:12and finally the authoritative DNS server
3:14for that domain. The result is an IP
3:16address, which your browser can then use
3:18to connect to the correct server. But,
3:20reaching the right machine is only part
3:21of the journey. A single machine can run
3:23many applications and services at the
3:25same time. So, the operating system
3:27still needs to know which application
3:29should receive the incoming data. That's
3:30where ports come in. A port identifies a
3:33specific application or service running
3:35on a machine. The IP address gets the
3:37packet to the right machine. The port
3:39number then tells the operating system
3:41which application or service on that
3:42machine should receive it. You can think
3:44of the IP address as the building
3:45address and the port number as the
3:47apartment number inside that building.
3:49Ports range from 0 to 65,535,
3:52and multiple applications on a machine
3:54can communicate over the network at the
3:56same time by using different ports. So
3:58far, we've seen how devices communicate
4:00across public networks using IP
4:01addresses. But most devices in homes and
4:04offices don't have their own public IP
4:06address. Instead, they use private IP
4:09addresses and connect to the internet
4:11through a router.
4:12So, how can your laptop, phone, TV, and
4:14other devices all share a single public
4:16IP address and still receive the correct
4:18responses? That's where NAT, or network
4:21address translation, comes in. When your
4:22laptop sends a request to the internet,
4:25the router translates its private IP
4:26address and source port into the
4:28router's public IP address and typically
4:30a different port. It stores this mapping
4:32in a NAT table. When the response comes
4:34back, the router looks up that mapping
4:36and forwards the response to the correct
4:37device inside the private network. This
4:39allows many devices to share a single
4:41public IPv4 address, helping conserve
4:44the limited IPv4 address space while
4:46keeping private addresses hidden from
4:48the public internet. This setup works
4:50well for a small number of devices. But
4:52as a network grows to hundreds or
4:53thousands of devices, like in a data
4:55center, managing all those private IP
4:57addresses as one large network becomes
4:59difficult and inefficient. That's where
5:01subnetting comes in. Subnetting is the
5:03process of dividing a larger IP network
5:05into smaller networks called subnets to
5:07make the network easier to organize and
5:09manage. This helps organize devices,
5:11reduce unnecessary traffic, and control
5:13which parts of a network can communicate
5:15with each other. To describe the size of
5:17a subnet, we often use CIDR notation.
5:19For example, in a 24 subnet, the first
5:2224 bits identify the network while the
5:24remaining eight bits are used for
5:26addresses within that subnet. The larger
5:28the CIDR prefix, the smaller the subnet.
5:31For example, a 24 subnet contains 256
5:34IPv4
5:36a 16 subnet gives us a much larger
5:39network of more than 65,000 addresses.
5:41So, as the prefix gets smaller, the
5:43network can contain more IP addresses.
5:45Just a quick note, to keep this video
5:47short, I'm covering these topics at a
5:49high level, but if you want to go
5:51deeper, learn these topics in more
5:52detail, and practice commonly asked
5:54interview problems, check out my full
5:56networking resource at algomaster.io.
5:59Link is in the description. No matter
6:01how many devices are on a private
6:02network, each one needs an IP address.
6:05But, how does a device get that address
6:07in the first place? That's where DHCP
6:09comes in. DHCP, or Dynamic Host
6:11Configuration Protocol, automatically
6:13gives a device the network settings it
6:15needs when it joins a network. For
6:17example, when your laptop connects to
6:19Wi-Fi, it usually doesn't choose an IP
6:21address manually. Instead, it asks a
6:24DHCP server, which assigns an IP address
6:27along with other settings, such as the
6:29subnet mask, default gateway, and DNS
6:31server. In a typical home network, the
6:34DHCP server runs on the home router
6:36itself. This assignment is usually
6:38temporary and is called a lease. Before
6:40the lease expires, the device can
6:42request to renew it. So, DHCP removes
6:45the need to manually configure network
6:47settings on every device. But, an IP
6:49address isn't the only address involved
6:51in local communication. Technologies
6:53like Ethernet and Wi-Fi also use another
6:55identifier, the MAC address. A MAC, or
6:57Media Access Control, address identifies
7:00a network interface on a local network.
7:02It is typically assigned by the device
7:04manufacturer. While an IP address is
7:06used to route packets across different
7:07networks, a MAC address is used to
7:09deliver frames between devices on the
7:11same local network. MAC addresses
7:13operate at Layer 2, the data link layer,
7:16and are typically 48-bits long, looking
7:18something like this. IP addresses can
7:20change as devices move between networks,
7:22while MAC addresses usually stay the
7:24same, making them a more consistent
7:25identifier within a local network. But,
7:27there's a problem. Applications usually
7:29know the destination's IP address, while
7:31the local network needs a MAC address to
7:33deliver the frame. So, how do we map one
7:35to the other? That's where ARP comes in.
7:37ARP, or Address Resolution Protocol,
7:40finds the MAC address associated with an
7:41IP address on the local network. Suppose
7:44your laptop wants to send data to
7:45another device on the same network. It
7:47knows the destination IP address, but it
7:49still needs the destination MAC address
7:51for the Ethernet frame. So, it broadcast
7:53an ARP request, essentially asking, "Who
7:56has this IP address?" The device with
7:57that IP responds with its MAC address,
8:00and your laptop can store that mapping
8:02in its ARP cache, so it doesn't have to
8:03ask every time. So, ARP bridges the gap
8:06between IP addresses at layer three and
8:07MAC addresses at layer two. Now, imagine
8:09dozens of devices connected to the same
8:11local network. Once we know the
8:13destination MAC address, how does the
8:15frame actually reach the correct device
8:16without being sent to everyone? That's
8:18the job of a switch. Unlike a router,
8:20which forwards packets between different
8:22networks, a switch mainly forwards
8:24frames between devices on the same
8:26network. It does this using MAC
8:27addresses. When a frame arrives, the
8:29switch looks at the destination MAC
8:31address, checks its MAC address table,
8:33and forwards the frame to the correct
8:34device. This allows laptops, servers,
8:36printers, and other devices to
8:38communicate efficiently without every
8:40frame being sent to every device.
8:42Switches mainly operate at layer two,
8:43the data link layer. Most modern Wi-Fi
8:46routers have switches in-built. Now, we
8:48know how data reaches the correct device
8:49on the local network, but how do we make
8:51sure the data sent between applications
8:53actually arrives reliably and in the
8:55right order? That's where our first
8:57transport protocol, TCP, comes in. TCP,
9:00or Transmission Control Protocol,
9:01provides reliable, ordered communication
9:03between applications. Before sending
9:05application data, TCP first establishes
9:07a connection using the three-way
9:09handshake. The client sends a SYN packet
9:11to request a connection. The server
9:13responds with SYN-ACK to acknowledge the
9:15request and indicate that it is ready.
9:17Finally, the client sends an ACK back to
9:19the server. Once these three steps are
9:21complete, the TCP connection is
9:23established, and both sides can start
9:25exchanging data reliably. TCP breaks the
9:28data into smaller segments and uses
9:30sequence numbers and acknowledgements to
9:32make sure those segments arrive
9:34correctly and in the right order. If a
9:36segment is lost along the way, TCP
9:38detects it and retransmits it. TCP also
9:41provides flow control, which prevents
9:42the sender from overwhelming the
9:44receiver, and congestion control, which
9:46reduces the sending rate when the
9:47network becomes overloaded. All of this
9:49reliability adds some overhead, but it
9:51makes TCP a good fit for applications
9:53where correct delivery matters, such as
9:55web traffic, file transfers, emails, and
9:57database connections. But not every
9:59application needs all of those
10:00guarantees. In some cases, speed and low
10:03overhead matter more than making sure
10:05every packet arrives or arrives in
10:06order. That's where the next protocol,
10:08UDP, comes in. UDP, or User Datagram
10:11Protocol, is a simpler, connectionless
10:14alternative to TCP. It sends data
10:16without first establishing a connection,
10:18and it does not guarantee delivery,
10:20ordering, or retransmission. Because of
10:22that, UDP has less overhead and can be
10:24faster when low latency matters more
10:27than perfect reliability. It is commonly
10:29used for things like video calls, online
10:31gaming, live streaming, and DNS queries,
10:34where waiting to retransmit old data may
10:36be worse than simply moving on. TCP and
10:38UDP operate at the transport layer, but
10:40in most modern application development,
10:42we rarely work with them directly.
10:44Instead, we usually interact with
10:45higher-level application protocols built
10:47on top of them. One of the most
10:49important is HTTP, the protocol that
10:51powers most communication on the web.
10:53HTTP, or Hypertext Transfer Protocol, is
10:55the protocol used for communication
10:57between web clients and servers. When
10:59you open a website, your browser sends
11:01an HTTP request to the server, and the
11:04server returns an HTTP response. An HTTP
11:07request typically includes the method,
11:09URL, headers, and sometimes a body. The
11:12response usually contains a status code,
11:14headers, and the requested data. HTTP
11:17provides different methods for different
11:18types of operations. For example, GET is
11:20commonly used to fetch data, POST to
11:23create or submit data, PUT or PATCH to
11:25update data, and DELETE to remove it.
11:27HTTP itself does not encrypt the data
11:29being transmitted. Most modern systems
11:31use HTTPS, which is simply HTTP secured
11:34with encryption. So, the data exchanged
11:36between the client and server cannot
11:38easily be read or modified by someone
11:40intercepting the connection. And that
11:41security is provided by our next
11:43concept, TLS. TLS, or Transport Layer
11:45Security, secures communication between
11:47a client and server. When you connect to
11:49an HTTPS website, TLS starts with a
11:52handshake. During the handshake, the
11:54server presents a digital certificate to
11:56prove its identity. And the client and
11:58server agree on cryptographic settings
12:01and establish shared session keys. Once
12:03the handshake is complete, the actual
12:05data is encrypted using fast symmetric
12:07encryption. TLS gives us three important
12:09protections: encryption, so others can't
12:12read the traffic; integrity, so data
12:14can't be changed without detection; and
12:16authentication, so the client can verify
12:18that it is communicating with the
12:19intended server. So, TLS protects the
12:21data while it is in transit. But
12:23security isn't only about encrypting
12:24traffic. Sometimes, we also need to
12:27control which traffic is allowed in or
12:29out in the first place. That brings us
12:31to firewalls. A firewall controls which
12:33network traffic is allowed to enter or
12:35leave a system. It examines traffic and
12:37applies rules based on things like IP
12:39addresses, ports, protocols, and
12:41connection state. For example, a server
12:44might allow HTTPS traffic on port 443
12:48while blocking incoming traffic on other
12:49ports. Firewalls can run on individual
12:51machines, inside routers, or at the edge
12:53of an entire network. Next, let's look
12:55at how we can create a secure connection
12:57across an untrusted network using a VPN.
12:59A VPN, or Virtual Private Network,
13:01creates an encrypted tunnel between your
13:03device and a VPN server or private
13:06network. Instead of sending traffic
13:07directly over the public internet, your
13:09device first sends it through this
13:11secure tunnel. So, websites may see the
13:13VPN server's public IP address instead
13:15of your own. VPNs are commonly used to
13:17securely access a company's internal
13:18network from outside, or to protect
13:21traffic when using an untrusted network
13:23like public Wi-Fi. Next, let's look at
13:25another kind of intermediary that
13:27forwards requests on behalf of clients
13:29or servers, proxies and reverse proxies.
13:32A proxy, usually called a forward proxy,
13:34sits between clients and the internet.
13:36Instead of connecting directly to the
13:38destination server, a client sends its
13:40request to the proxy. The proxy then
13:42forwards that request on the client's
13:43behalf. As a result, the destination
13:45server sees the request coming from the
13:47proxy's IP address rather than directly
13:49from the original client. For example, a
13:51company might route employee traffic
13:52through a forward proxy to block certain
13:54web sites, enforce access policies, or
13:57cache responses. A reverse proxy works
13:59on the other side. It sits in front of
14:01one or more back-end servers and handles
14:03incoming request on their behalf.
14:05Clients connect to the reverse proxy and
14:07it forwards each request to the
14:09appropriate back-end. Reverse proxies
14:10are commonly used for TLS termination,
14:13caching, rate limiting, and hiding
14:15back-end infrastructure. They can also
14:17distribute traffic across multiple
14:19back-end servers. And that brings us to
14:21load balancers. A load balancer is often
14:23implemented as a reverse proxy that
14:25decides which back-end server should
14:26handle each incoming request. Its main
14:29job is to distribute traffic across
14:31multiple servers so that no single
14:32server gets overwhelmed. Load balancers
14:34also perform health checks. If a server
14:36stops responding, the load balancer can
14:38stop sending traffic to it and route
14:40requests to the healthy servers instead.
14:43To decide where each request should go,
14:45load balancers use algorithms like round
14:47robin, least connections, and IP hash. I
14:49have made a separate video that explains
14:51eight commonly used load balancing
14:53algorithms in detail. So, you can check
14:55that out after this one. I hope this
14:56video gave you a good overview of the
14:58important networking concepts. If you
15:00want to learn these concepts in detail
15:02and practice interview problems, check
15:04out my comprehensive networking resource
15:06at algomaster.io. You can find the link
15:08in the description. Subscribe for more
15:10such videos. Thanks for watching and I
15:12will see you in the next one.

About this transcript

This page contains the full transcript of Networking was HARD until I Learned these 20 Concepts by Ashish Pratap Singh, generated from the public captions YouTube serves with the video. The transcript has 2,841 words across 452 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.