How my message reaches the other side of the world

A network is "computers far apart trading signals to talk." First you link two computers and make a path, by wire or wireless. The words they trade turn into signals of 0 and 1 to cross over. When it's not just two but many computers tied like a web, you can talk with anyone. Far apart, by signal, in a web: those three are all a network is.

Big data cannot be sent all at once. So we cut it into small pieces called packets. Each piece gets a tag saying which number it is and where it is going. The pieces travel separately, so if one road is blocked they can take another. At the destination they are joined back together in order of their numbers into the original data. Split, tag, and reassemble. That is a packet.

An IP address is "a unique address given to every computer connected to the internet." Like a house address, there should be only one in the world so nothing gets confused. It is written as numbers split by dots (for example 203.0.113.5). A packet reads the destination address and finds that exact computer. If two devices shared one address, it would not know which to go to, so each address must be unique.

Data on the internet (a packet) does not go to its destination in one jump. It passes through several stations (routers) and arrives step by step. Each station briefly receives the packet, then hands it to the next. Receive, then send again. Repeat that at every station and, no matter how far, it gets one step closer each time until it arrives. That is how a screen on the other side of the planet reaches yours.

A network doesn't do everything at once, it splits into layers and each layer does only its own job. When sending, you wrap the message layer upon layer. The paper (the content), the inner envelope (did it all arrive correctly), the outer envelope (an address, where to go), and finally the mail bin (the real signal of 0s and 1s). This is called encapsulation. On the receiving side you do the reverse, peeling off the outer envelope first, one layer at a time, until you reach the message inside. Splitting into layers means each layer can ignore the ones above and below and just do its own job well, which keeps it simple and sturdy.

Routing is finding the way by handing a packet from station to station all the way to its destination. Each station (router) reads a routing table. For each destination it says who to hand the packet to next. If there are several ways, it picks the fastest one. The most important thing is that there is no central control tower. Each station decides on its own. So even if one station goes down, the others find a detour and the letter keeps going. Thanks to this being distributed, the internet rarely breaks.

People find number addresses hard to memorize. So we use easy names (domains), and DNS turns each name into the number address computers know. DNS is like a giant phone book full of name-and-address pairs. Ask for a name and it tells you the address. And once a name is looked up, it is briefly remembered (cached), so asking the same name again skips the book and is much faster. Thanks to that, we only have to remember names, not numbers.

Packets can get lost or arrive out of order on the way. TCP quietly patches that up. When one arrives, the receiver sends back an acknowledgment (ACK); if no ACK comes, the sender resends that piece (retransmit); and the pieces are put in order by the number attached to each. So the receiver always gets it complete and in order. Not just fast, but a promise to send reliably, that is TCP.

TCP sends everything without loss, using acknowledgments (ACK) and resends. Accurate, but it waits for that. UDP skips that check. It does not ask whether a piece arrived; it just fires them off fast in a row, and even if some drop it keeps going without stopping. So it fits things that must not be late, like games, video calls, and live broadcasts, where a missing piece or two is barely noticeable. If accuracy comes first, TCP; if speed comes first, UDP. Both exist because their goals differ.

An IP address finds the building (the computer). But one building has many rooms, that is, many apps. Each room's number is a port. So the full destination is "IP address plus port number": find the building, then the room inside. Common apps have well-known room numbers. Web is 80, secure web (HTTPS) is 443. An arriving packet reads the port number and enters that numbered room, that is, the right app.

Devices inside your home each have a home address, but to go outside they pass through the router and leave as one public address. That is NAT. The router writes down in a table which device sent to where, and when a reply comes back, it reads that table and returns it to exactly the right device. So many can share one address without confusion. On top of that, a connection started from outside has no matching entry in the table, so it is simply blocked. Only what started inside can come back. Thanks to this, NAT also acts as a natural firewall.

The web moves in request-and-response pairs. The browser asks "give me this" (request) and the server hands it back with "here" (response). Each request carries an action like GET (please give) or POST (please take this), telling what it wants to do. One page is usually assembled from many request-response rounds, gathering text and image pieces. And HTTP is terribly forgetful. It treats every request like a first-time guest, so on its own it cannot remember who just did what. How we patch that weakness, we meet in the next lesson.

People look at web pages (HTML) with their eyes, but apps trade data, not screens. The agreed window that trades that data in a fixed format is the API. Send an agreed request (like "Seoul weather?") and it answers not with a picture but with clean data (names and values like temperature 23, sunny). So another app can use that data right away. And combining several APIs makes a new service. Lay a weather API over a map API and weather appears on the map. Many apps we use are really pulling data from several windows and combining it for us.

HTTP is forgetful, so it meets us as a first-time guest on every request. Left alone, that means a login should drop each time. Cookies and sessions are what solve this. On your first visit the server hands you one small pass, a cookie. On each later visit the guest shows that pass again. The server reads the number on the pass and goes, "Ah, that person!" Keeping the thread that this is the same guest is the session. Thanks to it, you do not have to log in again every time. Recognizing who you are by a pass number leads on to the story of authentication, which checks that you really are that person.

Plain HTTP sends content in the clear, so anyone in between can peek. HTTPS locks the content (encryption) so even if it is seen on the way it is scrambled and unreadable. The core idea has two parts. One: a public key is a lock you can hand to anyone, yet what it locks opens only with your private key. Two: a certificate first checks that the other side really is that site. So you can send a card number over the internet with peace of mind. That is HTTPS.

When you type an address, the things you learned in this area happen in order. First DNS turns the name into a number address (IP), then packets find their way to that address. TCP gives the trust that it all arrives complete and in order, and HTTPS locks the channel so no one else can read it. On top of that, HTTP says "give me this page, here it is" and exchanges the page. Packets, addresses, routes, and layers are all inside this one flow. The internet, in the end, is one giant postal system where these promises hold hands and turn together.