Hi, I'm Carrie Anne, and welcome to CrashCourse Computer Science.

Over the past two episodes, we've delved into the wires, signals, switches, packets, routers and protocols that make up the internet.

Today we're going to move up yet another level of abstraction and talk about the World Wide Web.This is not the same thing as the Internet, even though people often use the two terms interchangeably in everyday language.

The World Wide Web runs on top of the internet, in the same way that Skype, Minecraft or Instagram do.

The Internet is the underlying plumbing that conveys the data for all these different applications.

And The World Wide Web is the biggest of them all - a huge distributed application running on millions of servers worldwide, accessed using a special program called a web browser.

We're going to learn about that, and much more, in today's episode.

INTRO The fundamental building block of the World Wide Web - or web for short - is a single page.

This is a document, containing content, which can include links to other pages.

These are called hyperlinks.

You all know what these look like: text or images that you can click, and they jump you to another page.

These hyperlinks form a huge web of interconnected information, which is where the whole thing gets its name.

This seems like such an obvious idea.

But before hyperlinks were implemented, every time you wanted to switch to another piece of information on a computer, you had to rummage through the file system to find it, or type it into a search box.

With hyperlinks, you can easily flow from one related topic to another.

The value of hyperlinked information was conceptualized by Vannevar Bush way back in 1945.

He published an article describing a hypothetical machine called a Memex, which we discussed in Episode 24.

Bush described it as "associative indexing ... whereby any item may be caused at will to select another immediately and automatically."

He elaborated: "The process of tying two things together is the important thing...thereafter, at any time, when one of those items is in view, the other [item] can be instantly recalled merely by tapping a button."

In 1945, computers didn't even have screens, so this idea was way ahead of its time!

Text containing hyperlinks is so powerful, it got an equally awesome name: hypertext!

Web pages are the most common type of hypertext document today.

They're retrieved and rendered by web browsers which we'll get to in a few minutes.

In order for pages to link to one another, each hypertext page needs a unique address.

On the web, this is specified by a Uniform Resource Locator, or URL for short.

An example web page URL is thecrashcourse.com/courses.

Like we discussed last episode, when you request a site, the first thing your computer does is a DNS lookup.

This takes a domain name as input - like "the crash course dot com" - and replies back with the corresponding computer's IP address.

Now, armed with the IP address of the computer you want, your web browser opens a TCP connection to a computer that's running a special piece of software called a web server.

The standard port number for web servers is port 80.

At this point, all your computer has done is connect to the web server at the address thecrashcourse.com The next step is to ask that web server for the "courses" hypertext page.

To do this, it uses the aptly named Hypertext Transfer Protocol, or HTTP.

The very first documented version of this spec, HTTP 0.9, created in 1991, only had one command - "GET".

Fortunately, that's pretty much all you need.

Because we're trying to get the "courses" page, we send the server the following command - GET /courses.

This command is sent as raw ASCII text to the web server, which then replies back with the web page hypertext we requested.

This is interpreted by your computer's web browser and rendered to your screen.

If the user follows a link to another page, the computer just issues another GET request.

And this goes on and on as you surf around the website.

In later versions, HTTP added status codes, which prefixed any hypertext that was sent following a GET request.

For example, status code 200 means OK - I've got the page and here it is!

Status codes in the four hundreds are for client errors.

Like, if a user asks the web server for a page that doesn't exist, that's the dreaded 404 error!

Web page hypertext is stored and sent as plain old text, for example, encoded in ASCII or UTF-16, which we talked about in Episodes 4 and 20.

Because plain text files don't have a way to specify what's a link and what's not, it was necessary to develop a way to "mark up" a text file with hypertext elements.

For this, the Hypertext Markup Language was developed.

The very first version of HTML version 0.a, created in 1990, provided 18 HTML commands to markup pages.

That's it!

Let's build a webpage with these!

First, let's give our web page a big heading.

To do this, we type in the letters "H 1", which indicates the start of a first level heading, and we surround that in angle brackets.

This is one example of an HTML tag.

Then, we enter whatever heading text we want.

We don't want the whole page to be a heading.

So, we need to "close" the "h1" tag like so, with a little slash in the front.

Now lets add some content.

Visitors may not know what Klingons are, so let's make that word a hyperlink to the Klingon Language Institute for more information.

We do this with an "A" tag, inside of which we include an attribute that specifies a hyperlink reference.

That's the page to jump to if the link is clicked.

And finally, we need to close the A tag.

Now lets add a second level heading, which uses an "h2" tag.

HTML also provides tags to create lists.

We start this by adding the tag for an ordered list.

Then we can add as many items as we want, surrounded in "L i" tags, which stands for list item.

People may not know what a bat'leth is, so let's make that a hyperlink too.

Lastly, for good form, we need to close the ordered list tag.

And we're done - that's a very simple web page!

If you save this text into notepad or textedit, and name it something like "test.html", you should be able to open it by dragging it into your computer's web browser.

Of course, today's web pages are a tad more sophisticated.

The newest version of HTML, version 5, has over a hundred different tags - for things like images, tables, forms and buttons.

And there are other technologies we're not going to discuss, like Cascading Style Sheets or CSS and JavaScript, which can be embedded into HTML pages and do even fancier things.

That brings us back to web browsers.

This is the application on your computer that lets you talk with all these web servers.

Browsers not only request pages and media, but also render the content that's being returned.

The first web browser, and web server, was written by (now Sir) Tim Berners-Lee over the course of two months in 1990.

At the time, he was working at CERN in Switzerland.

To pull this feat off, he simultaneously created several of the fundamental web standards we discussed today: URLs, HTML and HTTP.

Not bad for two months work!

Although to be fair, he'd been researching hypertext systems for over a decade.

After initially circulating his software amongst colleagues at CERN, it was released to the public in 1991.

The World Wide Web was born.

Importantly, the web was an open standard, making it possible for anyone to develop new web servers and browsers.

This allowed a team at the University of Illinois at Urbana-Champaign to create the Mosaic web browser in 1993.

It was the first browser that allowed graphics to be embedded alongside text; previous browsers displayed graphics in separate windows.

It also introduced new features like bookmarks, and had a friendly GUI interface, which made it popular.

Even though it looks pretty crusty, it's recognizable as the web we know today!

By the end of the 1990s, there were many web browsers in use, like Netscape Navigator, Internet Explorer, Opera, OmniWeb and Mozilla.

Many web servers were also developed, like Apache and Microsoft's Internet Information Services (IIS).

New websites popped up daily, and web mainstays like Amazon and eBay were founded in the mid-1990s.

A golden era!

The web was flourishing and people increasingly needed ways to find things.

If you knew the web address of where you wanted to go - like ebay.com - you could just type it into the browser.

But what if you didn't know where to go?

Like, you only knew that you wanted pictures of cute cats.

Right now!

Where do you go?

At first, people maintained web pages which served as directories hyperlinking to other websites.

Most famous among these was "Jerry and David's guide to the World Wide Web", renamed Yahoo in 1994.

As the web grew, these human-edited directories started to get unwieldy, and so search engines were developed.

Let's go to the thought bubble!

The earliest web search engine that operated like the ones we use today, was JumpStation, created by Jonathon Fletcher in 1993 at the University of Stirling.

This consisted of three pieces of software that worked together.

The first was a web crawler, software that followed all the links it could find on the web; anytime it followed a link to a page that had new links, it would add those to its list.

The second component was an ever enlarging index, recording what text terms appeared on what pages the crawler had visited.

The final piece was a search algorithm that consulted the index; for example, if I typed the word "cat" into JumpStation, every webpage where the word "cat" appeared would come up in a list.

Early search engines used very simple metrics to rank order their search results, most often just the number of times a search term appeared on a page.

This worked okay, until people started gaming the system, like by writing "cat" hundreds of times on their web pages just to steer traffic their way.

Google's rise to fame was in large part due to a clever algorithm that sidestepped this issue.

Instead of trusting the content on a web page, they looked at how other websites linked to that page.

If it was a spam page with the word cat over and over again, no site would link to it.

But if the webpage was an authority on cats, then other sites would likely link to it.

So the number of what are called "backlinks", especially from reputable sites, was often a good sign of quality.

This started as a research project called BackRub at Stanford University in 1996, before being spun out, two years later, into the Google we know today.

Thanks thought bubble!

Finally, I want to take a second to talk about a term you've probably heard a lot recently, "Net Neutrality".

Now that you've built an understanding of packets, internet routing, and the World Wide Web, you know enough to understand the essence - at least the technical essence - of this big debate.

In short, network neutrality is the principle that all packets on the internet should be treated equally.

It doesn't matter if the packets are my email or you streaming this video, they should all chug along at the same speed and priority.

But many companies would prefer that their data arrive to you preferentially.

Take for example, Comcast, a large ISP that also owns many TV channels, like NBC and The Weather Channel, which are streamed online.

Not to pick on Comcast, but in the absence of Net Neutrality rules, they could for example say that they want their content to be delivered silky smooth, with high priority...

But other streaming videos are going to get throttled, that is, intentionally given less bandwidth and lower priority.

Again I just want to reiterate here this is just conjecture.

At a high level, Net Neutrality advocates argue that giving internet providers this ability to essentially set up tolls on the internet - to provide premium packet delivery - plants the seeds for an exploitative business model.

ISPs could be gatekeepers to content, with strong incentives to not play nice with competitors.

Also, if big companies like Netflix and Google can pay to get special treatment, small companies, like start-ups, will be at a disadvantage, stifling innovation.

On the other hand, there are good technical reasons why you might want different types of data to flow at different speeds.

That skype call needs high priority, but it's not a big deal if an email comes in a few seconds late.

Net-neutrality opponents also argue that market forces and competition would discourage bad behavior, because customers would leave ISPs that are throttling sites they like.

This debate will rage on for a while yet, and as we always encourage on Crash Course, you should go out and learn more because the implications of Net Neutrality are complex and wide-reaching.

I'll see you next week.