Lab 03 - The strands of the Web: how the Internet is connected
When you check your Facebook, Google+, Tumblr or other social networking site,
you're interacting with more than just your social network. If we think of the
World Wide Web as the sites and services we use every day when we start up our web
browsers, the Internet is the connected network that delivers those sites and services.
By now we understand that much of this connectivity can be described in terms
of client and server interactions. Client computers
make requests or give directions to server computers, who answer or do
what is asked of them. For example, when you open up your web browser for the first
time, if you have a default or home page set, your computer becomes a client. As
a client, your web browser makes a request to the server where your home page is
stored, and asks the server to send the home page file back to you. If the server
sends the file back, your web browser displays it. But how exactly does it work?
And what happens when it doesn't work?
To consider:
- Think of a time or times when you expected to get to a web page or resource,
and it didn't work as you expected. How did you know something was wrong? What
information did you get that helped you understand what was happening?
- There are many kinds of resources that you can interact with on the Web -
editable forms, video players, games. Do you think they all get sent in the same
way that web pages that have only text are sent? Why or why not?
- Sometimes accessing the web is fast, and sometimes you experience a phenomenon
called "lag", where interactions like trying to view a video result in
very slow reponses. What do you think affects the speed of interactions? What
could you try as a client to improve the response time? As a server?
Troubleshooting and assessment: looking under the hood
In this third lab, you'll look at some tools that help make some of the client-server
interactions of using the Web more transparent. As you explore, review your answers
from the To consider: section above. Have you changed your mind
about any of them?
Learning more
- Between your client computer and the server computers responding to it, many
issues can impede the web browsing experience. Slow or incorrect responses can
come from browser-based, operation system-based, or network-based problems, to
name a few of the challenges in communication large bundles of information over
large geographical distances. One tool to eliminate client-based problems from
the mix is a site called
Down For Everyone Or Just Me. Can't login to Facebook, but your email seems to be
working fine? You can see if Facebook is down, or if the problem is on your end.
- Go to Down For Everyone Or Just Me and enter in a few URLs. Why
do you think the site gives you a link to the site you checked in its
response page?
- If Down For Everyone was down, what other sites could you use to see
if the problem you are having is on your end or not? What other things
could you try?
- Can Down For Everyone eliminate network issues as the problem? Why
or why not?
- How do you think Down For Everyone works? Do you think it could be
wrong about the site you're checking? Why or why not?
- Understanding what's happening behind the scenes of client-server interactions
can help you not only troubleshoot problems, but also understand the complex
network you are interacting with. Tracing the path the packets you send take
through the Internet's network of computers is one way to see what's happening.
A program called traceroute
or tracert can be run in a browser to see how long it
takes to get from your computer to other computers on the Internet.
- Go to traceroute.org.
Pick 3 different countries from the list of links, and choose a site from
each to run a tracert to uw.edu.
- What information do you get back? Is it in a format that's easy to
understand?
- Was the path with the most "hops" the most distant geographically?
If not, why do you think it wasn't?
- Use your web browser's Find feature (usually ctrl+F or cmd+F)
to find the link on the traceroute.org page for Visualware's Visualroute.
Perform the same traceroute to uw.edu. How is the interface different?
Was it easier to understand what information you were getting back? Why
or why not?
- If you visited the Wikipedia page for traceroute, what warnings did you see
at the top of the page? Do you think the information is still reliable?
How would you check?
You have probably seen error messages sent by servers when you are trying to
get to a web resource. One of them is called a 404: Not Found error after the code
the server sends back to the client. As you might expect, a 404 error occurs when a page or resource
is requested that doesn't exist in the server's file directory. Some web developers
enjoy making interesting 404 pages. Try going to your favorite website, and in the
address bar add a trailing slash (if one isn't already present)and some nonsensical filename.
For example, you can go to Larry Snyder's website at
http://www.cs.washington.edu/homes/snyder/. In the address bar, after the final slash character
type in a few additional characters and press Enter. The server will look for a
file in its file or directory structure, and when it doesn't find it, it returns a 404 error page.
- Take a look at some other 404: Not Found error pages. Here's one to
try: github.com.
Why do you think the people at GitHub spent so much time making a page
they hope you never see?
- Why do you think 404 error pages exist? What would you expect to
happen if they didn't and you went to a page that was not on the server?
- A 404 error page is only one of many HTTP status codes sent by servers.
A full list can be found at
Wikipedia's list of HTTP status codes page.
Before you looked at the list, did you know that servers also respond
with success statuses? Why do you think that's true?
- Why do you think you have seen some of these status codes many more times
than others? Do you think it's because you are not experiencing these
status changes? Why or why not?
- If a web page is moved or renamed, it would be better for client machines
to be automatically directed to the correct page or location, instead of
getting an error status. Redirects are pages that point the client
to the right place, even if the client has the wrong address. Making redirect
pages is one way (and should only be a temporary one) to do that.
Try IT: Making a redirect page
First, make sure you're connected to the Internet. Next, open up any
text editor, like Notepad. Copy and paste the code below:
<html>
<head>
<meta http-equiv="refresh" content="5;url=http://www.bing.com" />
</head>
<body>
<h2>We're sorry, but that page has moved.</h2>
<h3>The new URL is <a href="http://www.bing.com">http://www.bing.com</a></h3>
<p>You will be redirected to the new address in five seconds.</p>
<p>If you are not sent to the new page after 5 seconds, click the link above.
Don't forget to update your bookmarks!</p>
</body>
</html>
Save this file with a .html extension, so it will be recognized by your web
browser, then double-click on it to open it, then wait.
What happened after 5 seconds? What part of the code tells the browser to
send you to another page? Why do you think it worked, even though the
redirect page is on your computer and not on the Internet? Why do you think
it's recommended that using a redirect page like this one should only be a temporary solution?
Moving on
These are a few of the many tools available to help you understand what processes
and interactions take place that are usually invisible to a web-browsing end-user.
As you spend time online, begin to look at how the standards, protocols, structures,
hardware and software that support your experience work together - both successfully and
unsuccessfully.