Ok, we're back to continue on modules on HTTP.
And in this module, we will be discussing
how to address a poorly performing website
and get a little bit deeper into the possible issues that you may have
when you're using Wireshark and trying to analyze
a performance issue on a HTTP based or web based client to server communication.
So one of the things to consider first is why does a site perform poorly?
There are so many reasons why a website can perform poorly.
I could probably fill up this entire module just with that explanation.
So I think to summarize, we can start with
the tip of the hour, so you have the client,
you have the possible lack of resources on the client.
So you may be trying to do something very intensive.
And the client cannot handle it so you go to a website which is very graphic oriented.
Or you don't have the correct plug ins
or you have some type of requests for job or you don't have the correct version.
There's just so many reasons why a client could have a porblem.
So, your website performing poorly ,
it's, it's incredibly important to first start with the client and
to make sure that the client is responding correctly.
Obviously, you would want to ask them
to or try yourself to try a different web browser.
There's many, there's Chrome, there's Safari, there's IE,
Firefox, there's quite a few out there, Opera,
and try the different browsers and see if you get a different response.
There's different versions with Internet Explorer.
You will find that some applications do not
work or not coded to work with newer versions of IE.
For example 10, and it may ask you to use 8.
Luckily, with the browsers of today, especially with Internet Explorer, you can hit F12 key.
And you could switch your browser version, you could try that.
Then there's the web server itself,
and it could suffer from the same issues.
it could have lack of resources, it could be overwhelmed.
It could be part of a pool and one of the servers is having an issue.
It could be end tier and it could have a middle ware or database tier issue.
There are the same types of I/O issues such as read-write to disc, that could be an issue.
Not enough memory, there could be so many things that could be wrong with it.
One of the things that we haven't talked about until now, it could be on a VM,
and the host could be having an issue, the guest could be having an issue.
There's a lot of reasons why the site may perform poorly,
as well as the fact that it could just be coded poorly.
It could be problems in the code. There are quite a few things.
Then there's the path in between where the firewall can be breaking something.
It could just be latency to the site, you might not have enough band width.
So there's, there's many reasons but when you use Wireshark it will allow you
to capture the data. You can look at source to destination data.
You can review the TCP information.
You can analyze the response time, the roundtrip time,
look at a bunch of different things that may give you a clue or some insight into
why this site may be performing poorly.
But regardless, just remember that there are
numerous reasons as to why and Wireshark may be giving you some insight into what it is
but just again, just remember, that there's quite a few things that could go wrong.
So, one of the things that I wanted to highlight was
if you look insde the Expert, there's a couple of things that you may find.
Before we get into that, let's take a quick look at actual capture. I pulled up a bad cap.
This one has a specific problem in it.
Actually, there was 2 problems in it and
I wanted to highlight both of them and show them, show you
how they actually showed me what the issue was.
So on this one, I was able to pull an actual problem.
I got a 401 unauthorized there and as you could see it clued me into
why somebody was having a problem with the site.
Now how I'd not pulled this information,
it may not have been shown on the client but
regardless, it was able, I was able to pull packet and find that
there was an issue of something was unauthorized.
And reason why I wanted to show in the Expert
is because it flagged it right in the Expert
where I could have pulled it up and then drilled into this packet
to figure out exactly what's going on.
But here, I have a 401 error and it's because it's unauthorized.
And the Microsoft IIS server was responding with that 401 error.
There could be many reasons why that's an issue.
Maybe there was a, it wasn't configured in the right pool or there's a permissions issue.
But again, I used Wireshark to capture the data
so that I was able to find this particular error.
And then drill down into where that could be coming from.
And in this instance, I was able to see
specifically that it was coming from the server itself.
Then if I actually look into the, specifically in here
into the Expert, I also found a handful of packets
where the window is full or zero window and
what that tells me is that, I may have a buffering issue
where I may have to increase the window size on some of these devices
'cause it's not able to handle the amount of traffic.
And where I've seen this issue is you're using a very intense application
or a very data intensive application and it just wasn't able to get the data
to and from in time and it was causing
what the client saw as performance issues where
the screens seem to freeze up on them.
It was not responsive and or switching between different items or tabs, or
or windows within the web browser, seem to be very choppy or slow.
So again, that was something where when I was running a capture,
I was able to pull that information directly out of the capture packets.
And again, this is something where if you want to look at the stream,
it'll tell you very quickly, you did a get request.
It basically said no, you're unauthorized, I am not doing anything for you.
So that was another quick way to see where the problem may be stemming from.
So as we continue to drill down into Wireshark,
it's very, it should be coming very apparent to you that
by doing this type of analysis, it's coming quicker or easier to you that
by using certain tools within it, you are able to look at the data
and start to organize it in a way where you can
figure out what it is that you want to look for.
And as a, as a reminder here, the tools that you're using within Wireshark
is your data, so you're filtering on it.
You want to just see HTTP. Maybe you want to see that DNS was an issue here.
Maybe you were trying to request the DNS,
was trying to query a DNS server and it wasn't responsive.
Therefore, I wasn't able to access the website if it was poorly performing.
Maybe as we showed before, there was reason.
Something was in the website, you tried to move to a different tab.
And it was choppy. Maybe there was something causing it to perform horribly.
Or you weren't authorized to see certain parts of the sites so you don't even pull up the page.
You can look at the flow graph, which we looked at in earlier module.
You can look at the Expert. This will give you some clues as to what may be the problem,
and other tools, such as tools that are integrated directly into the browsers themselves
or snap-in plug ins or third party plug ins.
What we could see here is that if we use a tool such as
HTTP watch, fire bug or the development tool within Internet Explorer,
we could also use these in tandem with Wireshark
to get an understanding of what may or what may not be a problem.
So as we see here, we can pull up a web browser,
we can hit the F12 key, we can look at specifically
some of the tools within, here
and I would like to click on the network and start capturing.
And if I go to s website, it will show me
some information about the response time for the website and this will help to also show me
possible poor performance. Actually in this case and not because it's just the INE website
it actually responded extremely quick. It pulled up everything very quickly.
And aside, aside for, and commonly the quick first request and the pulling of the cascading
style sheet, everything came down lightning quick.
So, if you want to pull up a site that may not perform as well,
this may give you a clue as to what page may be hanging it up,
or what else could be an issue.
And then, you can look and filter for that information back in Wireshark
to see specifics of what that page or that content may have been hanging or
or causing performance degradation to the website itself.