When we access specific data on the internet, we use something called a URL to do so.
Once you have the URL for the resource you want, you can call that URL from an HTTP communication program like a browser to get the response.

Whether you're a developer or not, if you look into related information you'll often come across the term URI.
Because of the subtle visual similarity between I and L, some people mistake URI for URL outright, while others assume it's simply a typo.
But URL and URI, while similar in meaning, are actually slightly different.

Let's take a look at URL, which everyone knows; URI, which is somewhat ambiguous; and URN, which is unfamiliar to most.

URI, URL, and URN are structurally related to one another.

URI stands for Uniform Resource Identifier. It's a broader concept that encompasses both URL and URN mentioned above, and can be described as an identifier that distinguishes a resource that exists on the internet. Essentially, any means of identifying a resource on the web can be considered a URI.

URL translates to Uniform Resource Locator, but in everyday use, when people say "address" on the internet, 99% of the time they mean this URL. It was defined in RFC-1738 in 1994.
True to the keyword Locator, URL can be described as an identifier that indicates the location of a resource on the internet. Pay attention to the keyword location here. Because a URL holds positional information about a resource, if the resource's location changes for any reason, the URL can no longer find the resource, nor can it track the resource's new location. The HTTP error you get in that case is the well-known 404 Not Found.
If I were to change even a single character in this post's name right now, every existing URL pointing to it would become completely useless, and users would no longer be able to reach this post through that URL. Nor could the original post's URL be logically inferred from this new URL.

URN stands for Uniform Resource Name. As sharp readers may have guessed, URN is an identifier that represents the name of a resource on the internet. Since a resource's name has a unique value, it can be used to identify one specific resource among the countless resources on the internet.
URN is likely unfamiliar to most people compared to the two concepts above. That's understandable, since URN emerged much later than both of those concepts. It was defined in RFC-2141 in 1997 — three years after URL — so it has a relatively short history by comparison.

A critical shortcoming of URL is that it stores no information other than location. So what happens if you need to find that resource under such circumstances? Unfortunately, a URL alone won't let you find it — unless you get lucky searching for it on Google.
What about using URN instead? No matter how much the location changes, since it's found via the resource's unique name, you should be able to find it easily as long as the resource hasn't been completely deleted from the web.

I personally like to understand difficult concepts by connecting them to something in the real world. If I map the three concepts above onto the process of identifying a specific person in real life, it might look something like this.

※ Since a URN is meant to be a unique value for any resource, when mapped to a person, a unique value like a resident registration number is more appropriate than a name, which could be duplicated.

Suppose my information is as shown above. Since both my home address and my resident registration number are ways (URI) of confirming my identity, they're both suitable for finding me.
If you tried to find me via my address (URL), and I move (the resource relocates), there would be nothing left at that address, and you wouldn't be able to find me (a 404 HTTP error). Nor could you infer my new address just from my old one.

On the other hand, if you find me via my resident registration number (URN), you can identify me by finding the person matched to that number. In this process, it doesn't matter at all where I happen to be. As long as my resident registration number itself isn't cancelled (the resource deleted), my identity can be confirmed no matter where I am or what I'm doing.

Now let's take a look at what these actually look like. Since URI is the overarching concept referring to resource identifiers as a whole, it doesn't really have a structure of its own. Let's look at its subordinate concepts, URL and URN.

A URL is made up of the structure below. It should look very familiar.

https://rwb0104.github.com:443/posts?category=WEB&page=1

Each part is color-coded, and they're described below in order.

The https part of the URL.

This refers to the communication protocol. As of this writing, there are many protocols across various layers, but for web communication, there are broadly two.

These days, the use of HTTPS is essentially mandatory, ranging from major business sites like portals and shopping malls to small and mid-size personal sites like blogs and cafes. In particular, business sites that involve e-commerce must apply it without exception. What's more, if you access a site that doesn't have HTTPS applied (excluding localhost), the browser will display a security warning message, so regardless of scale, HTTPS is typically applied as a matter of course when running a website.

The rwb0104 part of the URL.

It's attached before the domain, and a subdomain allows multiple services to be provided under a single domain. A single domain can have multiple subdomains created under it, and besides the familiar www, various strings such as dev, admin, or m can also be assigned depending on their purpose.

The above are subdomains of Naver's services, showing how each provides a different service centered around the domain naver.com.

The github part of the URL.

This is the central part of the URL, and it also serves as the identity of the web service being provided. As a result, the domain usually contains the name of that web service.

Most services use their service name as the domain.

The com part of the URL.

A top-level domain can be thought of as the company or organization that manages the subdomain and domain mentioned above.
The concepts described above can be freely set by the user as long as there's no duplication. But for a top-level domain, you must select and register one from among the currently operating companies or organizations. Once you choose a top-level domain, your domain ends up managed by whoever operates that top-level domain.

Top-level domains are divided into two types depending on who operates them.

A top-level domain representing a country.

As shown in the table above, a ccTLD follows the country code format and is directly managed by each country's governing body. In other words, every domain with .kr is managed by South Korea's KISA (Korea Internet & Security Agency).

A top-level domain used depending on the nature of the site or the organization that owns it.

As shown above, gTLD comes in various types, and you've likely encountered several of them. You might wonder why government agencies show up here — that's because ccTLD is strictly limited to country codes. Sub-national government agencies, military organizations, and the like are classified as gTLD.
Likewise, each top-level domain is managed by the organization or company that owns that particular top-level domain.

You can check the currently operating top-level domains at IANA.

As a side note, you can't register a duplicate domain under a given top-level domain. For example, suppose I try to register the URL aaa.com.
First, I would need to register the domain aaa with whatever company manages .com. But if someone has already registered aaa.com, I can't own the aaa.com domain until that owner gives up ownership.
Of course, I could still register it under .kr or .net instead of .com. But if a domain was constructed with semantic meaning tying together both the domain and top-level domain — like socket.io — such a situation wouldn't be welcome at all. That's why incidents similar to the previously controversial "deokjuk" trademark squatting case sometimes occur.

The 443 part of the URL, always preceded by a :.

Every device connected to the internet is assigned an IP on the network it's using. All communication for every process running on that device happens within the assigned IP. A port is the channel through which a process's data flows in and out. Each process is assigned its own unique port, and a single port is always matched 1:1 with a single process. On the other hand, a single process can be assigned multiple ports.
To communicate with a specific process, data must always be sent to the port assigned to that process. Because of this, in port communication, which port the data is sent from doesn't matter much — what matters is which port it's sent to.

The default ports for web communication are as follows.

You may be seeing these numbers for the first time, since most website URLs don't show a visible port. When a site is served over the default port of its protocol, the port can be omitted from the URL. In other words, https://naver.com's port is 443, but since 443 is HTTPS's default port, it's omitted. If a service is provided on an arbitrary port other than 443, such as 8080 or 9200, the port must be explicitly specified and cannot be omitted. In that case, the URL would be https://naver.com:8080.
For this reason, most websites use the default port corresponding to the protocol they serve.

A port ranges from 0 to 65535, and can be broadly divided into three categories.

Ports in the range of 0 to 1023. These ports are by default assigned to major processes commonly used on computers, and are controlled by ICANN (Internet Corporation for Assigned Names and Numbers).

These are only the ports assigned by default, so they can later be changed to any other available port according to the user's intent. In other words, they're just default values, not enforced requirements.

Ports in the range of 1024 to 49151. These ports aren't core processes of the computer itself, but are ports registered with ICANN by major programs that want to use them by default. Just like well-known ports, these can be changed to any other available port according to the user's intent through program settings.

Mostly registered here are development-related programs like databases.

Development-related programs, by their nature, need consistent communication behavior at all times. What would happen if a database's port kept changing every time it started up? Whenever the DB restarts, for whatever reason, the developer would have to track down the arbitrary port the DB happens to be using and update the program's DB communication code — an extremely unreasonable situation.

By comparison, general-purpose programs like games or IDEs don't necessarily need consistent communication behavior. That's because the moment a request is sent to a server, the server naturally learns the requester's communication information anyway. The server simply needs to return data back along the path the request came from. This is why it doesn't matter much which port sends the request.

Ports in the range of 49152 to 65535. Most programs don't have a fixed default port. Such programs automatically occupy any available, unused port from among the dynamic ports. As a result, ICANN doesn't manage these, and no specific program is registered to a unique port here. Think of it like open seating.

The posts part of the URL. This refers to a website's subpath. A path is delimited by /, and entering a path lets you access the desired resource within the server.

• https://blog.itcode.dev
  • posts
    • index.html
    • a1000
      • index.html
    • a1001
      • index.html
    • uri-url-urn
      • index.html
  • project
    • index.html
  • index.html

The tree above is a partial example of this blog's directory structure. To access this particular post, the path could be constructed as /posts/uri-url-urn/index.html. Since index.html can be omitted, you can also access it via /posts/uri-url-urn.

Did you know?
index.html refers to the default HTML file for a given path. If no further subpath is specified, the server responds with that path's index.html.

Since a path is determined by the server's structure, it varies widely from site to site.

The ?category=WEB&page=1 part of the URL. This is used to send arbitrary data along with the given path.
It's structured as key=value pairs, where each key is called a parameter. The first parameter starts with ?, and subsequent parameters are separated by &. In other words, it takes the form ?key1=value1&key2=value2&key3=value3.

Arbitrary keywords can be passed to control the behavior of a page. This is the part of the URL where user needs are most actively reflected. Since a query string requires defining the role of each key, it only has meaning once a developer has written the logic that handles each parameter's key.

We've covered URL in quite a lot of detail so far, but URN has a shorter history than URL. Since URL had already become the standard within that three-year gap, URN remains a minority option to this day, and the reality is that there aren't many implemented examples of it.
URL's weakness — that it becomes unreachable the moment its location changes — can actually be useful in certain situations, such as concealing the underlying data being served. In other words, URL's weakness isn't necessarily a bad thing across the board. This also supports the argument that URN's advantages aren't compelling enough to justify overhauling the currently established URL system.

A URN is made up of the structure below, with each element separated by :.

urn:isbn:1234567890

The urn part of the URN. If it starts with urn, you can consider it part of the URN scheme.

The isbn part of the URN. This denotes the store where the resource is kept.
isbn refers to the Korean bibliographic information distribution support system, a repository that stores information about book serial numbers. In other words, specifying isbn as the NID allows book-related resources to be identified.

The 1234567890 part of the URN. This is a unique value that identifies the resource.
Since the NID is set to isbn, this can be seen as a URN that identifies the book whose ISBN serial number is 1234567890.