Reference no: EM131240051

Troubleshooting and assesment: 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

1. 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?
2. 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?
3. 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 https://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 directorystructure, 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 atWikipedia'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 an easy (and ideally temporary) way 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 xxxx-xxxxx="refresh" content="5;url=https://www.bing.com" /> </head> <body> <h2>We're sorry, but that page has moved.</h2> <h3>The new URL is <a href="https://www.bing.com">https://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?