Our adventure begins inside the smartphone of "the User," a young girl sitting in a cafe, using their WiFi to check her social media feed. You, our protagonist, are a new Internet packet created the moment the young girl taps on her device. She appears frozen on the other side of the screen, because, for you inside the device, time moves much slower (i.e., the entire journey only takes a fraction of a second in "human" time). You look around and interact with another fellow packet. He explains that you are a TCP/IP packet carrying a DNS request. The user has requested information from "socialmedia.com" and it's your job to find that info on the Internet and bring it back home to this device. You also meet the Network Manager, a daemon responsible for making sure the device is connected to the Internet so that all the apps that require Internet access can send their data to-and-fro.
A daemon is simply a program that runs in the background. Most of the programs you interact with have GUIs (graphical user interfaces) that you can click, swipe and interact with, but your device is always running programs in the background to manage all the other processes that keep things ticking (like our Network Manager).
A network packet is simply a file with text data (maybe an HTML page, maybe an email, maybe parts of a video you're watching) organized in a particular way. Like a letter traveling over the post, the first few lines of a network packet specify the "to" and "from" (IP) addresses of the recipient and destination computers, followed by a few lines used for error checking and reliability (TCP or UDP). After that, the data gets more specific and depends on the app that created the packet. If it was an email app, then we've got email data (POP/IMAP). If it was a browser, then we've got web data (HTTP), etc. These different sections of the packet are usually referred to as "layers."
You are a TCP/IP packet (the outer layers) carrying a DNS request (the inner application layer), which is a packet responsible for taking a domain name like "socialmedia.com" and finding a DNS server that can translate that into our "to" IP address of the destination computer where "socialmedia.com" is hosted. This is the first stage of a web request. Obviously these packets aren't tiny cubes with smiley faces; they are text files! Check out the diagram below to see what a DNS packet actually looks like.
In Part I, we don't specify whether the DNS request you are carrying (for socialmedia.com) originated from a web browser or another application (maybe socialmedia.com's mobile app). This is because it could have come from either; both use the Internet to send your data back and fourth between their servers and your device. You can think of a social media app on your phone as a browser that can only visit a single website: theirs. That would seem ridiculous on our laptops, but it's become the norm on mobile devices. The same is likely to happen to future devices like VR and AR headsets if we don't take note of this. These apps typically also need to be approved by the companies that control the app stores.
Today, you have a choice. You can choose to download specific apps for specific sites which have been approved of by a third party, or you can download a web browser and use any/every app hosted openly on the Web (no third party approval required). But, if as netizens we don't appreciate the choice we have today, and instead get lost wandering into the walled gardens of app stores, we could lose that choice for tomorrow. This raises the issue of "centralization". The Internet (the physical network of cables and computers) and the Web (the collection of websites made by anyone/everyone) are inherently decentralized.
The Web, especially, is owned and controlled by everyone, and is one of its most valuable and distinguishing characteristics. But app stores and websites-turned-mobile apps have shown us that the Web can in fact become centralized if we choose to go in that direction. App stores aren't the only centralizing force; lots of different web browsers compete for market share, which is great for users because competition breeds innovation. That said, these days one browser, Google Chrome, is starting to dominate. If we leave the walled gardens of app stores only to use a single web browser, we would have ended up centralizing the Web another way.
How can we avoid centralization? For starters, use the Web! This encourages app makers to place more effort in their web app (accessible on any device with a browser) over their native app (locked down to a single platform or system). Secondly, use more than one browser and try to support open source browsers, like Firefox, who want to keep the web decentralized, rather than proprietary browsers motivated by other goals (often attempting to centralize and control). Support new, innovative and experimental browsers by downloading them and giving the creators feedback. Check out browsers like Supermedium, which is experimenting with Virtual Reality, or the Beaker Browser, which is trying to make the web even more decentralized than it already is by using peer-to-peer technology! Lastly, diversify your activity online. Are you an Internet explorer, or do you stick to the same handful of sites? We'll discuss this issue some more in the last part of this series.
The Internet has no single inventor. Lots of different people contributed ideas, inventions and inspiration over many years before we got to where we are today. Even the core notion of an Internet "packet" had many different creators. If you look up the origins of TCP/IP packets, you'll quickly learn of its inventors: two of the Internet's founding fathers Vint Cerf and Bob Kahn. Their work on network packets was built on the work of another computer scientist named Leonard Kleinrock at MIT (later UCLA). The three of them were working together with others on the ARPANET (the proto-internet), including Larry Roberts, who, at a conference in the late 60s, was presenting their collaborative work on the ARPANET only to realize that another group of researchers where doing almost the same exact thing in the UK on a network called the NPL. In fact, it was from the NPLs research that the American researchers borrowed the term "packet." Because innovation always spawns from a tangled mess of inspirations, the NPL researchers, namely Donald Davies, based much of their work on another American researcher working at RAND named Paul Baran (who the ARPANET folks initially didn't know about).
Henry Ford once said, "I invented nothing new. I simply assembled the discoveries of other men behind whom were centuries of work... progress happens when all the factors that make for it are ready and then it is inevitable." The invention of the Internet is a great example of this. If not in the US with the ARPANET or the UK with the NPL, the Internet would have sprung up somewhere else (don't even get me started on the CYCLADES network in France happening more or less at the same time). Thankfully, today we have the Interent which can help avoid the doubling up of research and facilitate global collaboration (rather than relying on serendipitous conference rendezvous). For more info on the invention of the Interent, see the references below: