WEBVTT

0:00:08.160000 --> 0:00:12.920000
 Good morning and welcome back to
 the Wire Shark Foundation class.

0:00:12.920000 --> 0:00:17.440000
 In this module we will talk about
 time stamps and time values.

0:00:17.440000 --> 0:00:23.400000
 Before we begin just a quick reminder
 from what we learned about yesterday.

0:00:23.400000 --> 0:00:27.580000
 When we use Wire Shark one of the key
 things we're using Wire Shark to

0:00:27.580000 --> 0:00:31.920000
 do is to analyze capture data.

0:00:31.920000 --> 0:00:37.600000
 Data that we capture specifically from
 strategic points on the network

0:00:37.600000 --> 0:00:44.020000
 so that we can analyze, assess it, review
 what's captured and try to figure

0:00:44.020000 --> 0:00:48.080000
 out isolation down to root
 cause of a problem.

0:00:48.080000 --> 0:00:53.760000
 One of the key things that we can do
 when doing this is to do relative

0:00:53.760000 --> 0:01:03.060000
 time and review the value of time from
 when you open a web browser to

0:01:03.060000 --> 0:01:09.360000
 a site or an application or your FTP
 or traffic or you're trying to figure

0:01:09.360000 --> 0:01:13.660000
 out why DNS queries might be slow.


0:01:13.660000 --> 0:01:22.400000
 Any of these things can be captured
 with Wire Shark and to look at for

0:01:22.400000 --> 0:01:27.180000
 example how long it took for something
 to get from a source to a destination.

0:01:27.180000 --> 0:01:31.560000
 So in this module what we will do is we will
 learn about how you can strategically

0:01:31.560000 --> 0:01:36.680000
 change things within Wire Shark, take
 a look at settings and figure out

0:01:36.680000 --> 0:01:41.980000
 how long it takes for something to
 get from a source to a destination.

0:01:41.980000 --> 0:01:45.580000
 So essentially what
 is a time stamp?

0:01:45.580000 --> 0:01:52.140000
 When you open up Wire Shark and you begin
 a capture each packet is marked

0:01:52.140000 --> 0:01:55.740000
 with the time that
 you're capturing.

0:01:55.740000 --> 0:02:01.040000
 Now this is not a time that's kept within
 Wire Shark it's actually using

0:02:01.040000 --> 0:02:05.500000
 your systems time to
 make that time stamp.

0:02:05.500000 --> 0:02:09.700000
 So what's important to understand is that
 if the time is off on your computer

0:02:09.700000 --> 0:02:14.980000
 for example your capture data
 is not going to be accurate.

0:02:14.980000 --> 0:02:19.400000
 So one of the things that you probably
 would like to do is check and make

0:02:19.400000 --> 0:02:24.440000
 sure that the time on your system is
 correct and one of the best ways

0:02:24.440000 --> 0:02:32.860000
 to do this is to use NTP and configure
 your system with a solid time source.

0:02:32.860000 --> 0:02:37.580000
 And when you do that you will at least
 know that what Wire Shark is capturing

0:02:37.580000 --> 0:02:40.580000
 and time stamping is accurate.

0:02:40.580000 --> 0:02:47.080000
 That being said time stamps are used
 to mark the capturing of your packets

0:02:47.080000 --> 0:02:51.520000
 and you can convert to different time
 formats which we'll do in this module.

0:02:51.520000 --> 0:02:55.960000
 We'll take a look at the difference
 between certain settings that you

0:02:55.960000 --> 0:03:00.600000
 can change and why you would use
 one over the other as an example.

0:03:00.600000 --> 0:03:05.940000
 So why are we actually doing this?


0:03:05.940000 --> 0:03:11.320000
 You are able to see the delta
 between time packet capture.

0:03:11.320000 --> 0:03:16.840000
 So if you let's say were to open up
 a web browser and try to access a

0:03:16.840000 --> 0:03:21.420000
 website you can see from when you start
 to when you finish in every activity

0:03:21.420000 --> 0:03:24.340000
 in between how long it takes
 to do certain things.

0:03:24.340000 --> 0:03:29.960000
 A good example would be if you were accessing
 a website and you were seeing

0:03:29.960000 --> 0:03:34.760000
 GET requests or you were doing posts
 and you were seeing a long period

0:03:34.760000 --> 0:03:40.040000
 of time to complete a function.

0:03:40.040000 --> 0:03:41.660000
 So what does that actually mean?

0:03:41.660000 --> 0:03:46.720000
 That means that as we learned yesterday
 in the other modules you could

0:03:46.720000 --> 0:03:49.800000
 potentially be facing quite
 a few different things.

0:03:49.800000 --> 0:03:52.400000
 You can have latency
 on your network.

0:03:52.400000 --> 0:03:53.400000
 There could be I.O.

0:03:53.400000 --> 0:03:55.340000
 problems on the web server.

0:03:55.340000 --> 0:04:00.500000
 The client could have lack of memory
 to be able to handle the requests.

0:04:00.500000 --> 0:04:09.860000
 There are so many things that source
 to destination round trip time and

0:04:09.860000 --> 0:04:14.540000
 cause contention and or problems all the
 way from the client to the server.

0:04:14.540000 --> 0:04:18.700000
 So just remember that you put on your
 detective hat and you have to look

0:04:18.700000 --> 0:04:23.700000
 at all the things in between as well
 as the client and the server.

0:04:23.700000 --> 0:04:28.780000
 You want to make sure that you consider
 that the server could be N tier.

0:04:28.780000 --> 0:04:31.940000
 There could be multiple layers to that
 server especially with today's

0:04:31.940000 --> 0:04:33.660000
 web server technology.

0:04:33.660000 --> 0:04:36.360000
 Usually it's a front
 end web server.

0:04:36.360000 --> 0:04:38.260000
 It's N tier technology.

0:04:38.260000 --> 0:04:40.440000
 There's generally two
 to three tiers.

0:04:40.440000 --> 0:04:44.940000
 Sometimes it's split out into a middleware
 tier where you have application

0:04:44.940000 --> 0:04:48.540000
 specific functions taking place.

0:04:48.540000 --> 0:04:52.600000
 And most websites if they're complex
 enough and they're taking orders

0:04:52.600000 --> 0:04:58.180000
 or storing information have a database
 tier and that could also be what's

0:04:58.180000 --> 0:04:59.020000
 hanging things up.

0:04:59.020000 --> 0:05:02.920000
 So just remember it's
 not just the simple.

0:05:02.920000 --> 0:05:07.320000
 It can get into the complex.

0:05:07.320000 --> 0:05:12.080000
 So when you open up wire shark and
 we will take a look at this now.

0:05:12.080000 --> 0:05:16.740000
 You can see you can adjust
 the time display format.

0:05:16.740000 --> 0:05:20.780000
 We're going to get into what each of
 these values means but you can change

0:05:20.780000 --> 0:05:23.200000
 the time display format.

0:05:23.200000 --> 0:05:28.600000
 You can adjust it to seconds since
 time being in the capture.

0:05:28.600000 --> 0:05:29.200000
 You can see the time display.

0:05:29.200000 --> 0:05:31.440000
 Second since previous
 capture packet.

0:05:31.440000 --> 0:05:34.400000
 Second since previous
 displayed packets.

0:05:34.400000 --> 0:05:37.360000
 And each one of those things is going
 to show you something different.

0:05:37.360000 --> 0:05:41.520000
 So as an example we'll open up wire
 shark and we'll take a look.

0:05:41.520000 --> 0:05:46.400000
 One of the things that we did here
 was we did a simple capture.

0:05:46.400000 --> 0:05:51.260000
 And what I decided to do here
 is I just ran a basic capture.

0:05:51.260000 --> 0:05:56.800000
 I accessed the website and I wanted
 to see the differences between from

0:05:56.800000 --> 0:06:00.220000
 my client to the destination.

0:06:00.220000 --> 0:06:05.580000
 Basic time values here where how long
 it took me to do a simple request

0:06:05.580000 --> 0:06:09.920000
 of a web page. So as we were talking
 about before there's different ways

0:06:09.920000 --> 0:06:11.840000
 that you can adjust this.

0:06:11.840000 --> 0:06:19.440000
 And if you go into the view time display
 format it originally was second

0:06:19.440000 --> 0:06:27.260000
 since time. And then I wanted to change
 it to second since pre-order.

0:06:27.260000 --> 0:06:30.080000
 So I just went to the previous
 capture packet.

0:06:30.080000 --> 0:06:32.880000
 Now what this allows me to do is
 to look at each one of these.

0:06:32.880000 --> 0:06:36.380000
 I also looked at the stream but I wanted
 to see specifically how long

0:06:36.380000 --> 0:06:41.900000
 it was in between each function
 here in the capture.

0:06:41.900000 --> 0:06:47.760000
 So essentially that's one of the things
 that we want to do when we're

0:06:47.760000 --> 0:06:53.140000
 capturing data. We want to make sure
 that we are adjusting time to how

0:06:53.140000 --> 0:06:54.460000
 we want to see it.

0:06:54.460000 --> 0:06:58.020000
 And what does that really mean?

0:06:58.020000 --> 0:07:03.240000
 So absolute time the time of day
 when the pack packet is captured.

0:07:03.240000 --> 0:07:06.940000
 Essentially one of the things that we
 want to do is we want to make sure

0:07:06.940000 --> 0:07:14.340000
 that we pick the correct function and
 we want to pick the correct value

0:07:14.340000 --> 0:07:16.160000
 for what it is that
 we want to see.

0:07:16.160000 --> 0:07:18.320000
 And they're pretty
 self explanatory.

0:07:18.320000 --> 0:07:25.620000
 So if I look at the packet it's going
 to look at the time stamp from the

0:07:25.620000 --> 0:07:29.780000
 packet and then the very next one after
 that and show me the difference

0:07:29.780000 --> 0:07:34.060000
 or the delta. And essentially if I'm looking
 at each packet and each packet

0:07:34.060000 --> 0:07:38.280000
 is performing a function that will
 tell me how long it took to do each

0:07:38.280000 --> 0:07:40.480000
 one of these functions.

0:07:40.480000 --> 0:07:47.160000
 There's different ways
 that we can do this.

0:07:47.160000 --> 0:07:53.360000
 It's just a quick setting.

0:07:53.360000 --> 0:07:57.440000
 We just want to make sure that we understand
 what we want to look for

0:07:57.440000 --> 0:08:01.900000
 and we can adjust those
 as we see fit.

0:08:01.900000 --> 0:08:11.860000
 So let's go back to our capture.

0:08:11.860000 --> 0:08:33.720000
 And here we'll do
 a simple capture.

0:08:33.720000 --> 0:08:36.140000
 We're going to start.

0:08:36.140000 --> 0:08:40.200000
 And what we want to do is we
 want to go to our website.

0:08:40.200000 --> 0:08:42.080000
 I'm going to show you different
 tool here too.

0:08:42.080000 --> 0:08:44.140000
 So we can look at a couple
 of different things here.

0:08:44.140000 --> 0:08:49.840000
 But we will go to...

0:08:49.840000 --> 0:08:52.900000
 And we pull up the website as we can
 see there's a couple of different

0:08:52.900000 --> 0:08:54.720000
 things going on here.

0:08:54.720000 --> 0:08:57.300000
 These are a lot of get requests.

0:08:57.300000 --> 0:09:04.920000
 And then we're going
 to stop our capture.

0:09:04.920000 --> 0:09:09.680000
 And then we're going to look at
 specifically what we just did.

0:09:09.680000 --> 0:09:17.360000
 So in here we want to adjust the time display
 format to previously displayed.

0:09:17.360000 --> 0:09:25.540000
 And we can see from each function how
 long it took to do each action on

0:09:25.540000 --> 0:09:27.440000
 pulling the website.

0:09:27.440000 --> 0:09:32.540000
 So one of the things that we want to
 remember is when we're doing these

0:09:32.540000 --> 0:09:37.640000
 types of captures, what
 are we looking for?

0:09:37.640000 --> 0:09:41.620000
 Are we going to check the delta?

0:09:41.620000 --> 0:09:46.180000
 When you need to find latency in your
 network you would use this type

0:09:46.180000 --> 0:09:47.640000
 of time stamping.

0:09:47.640000 --> 0:09:48.460000
 You can check...

0:09:48.460000 --> 0:09:50.700000
 Check for application
 response time.

0:09:50.700000 --> 0:09:54.940000
 So we just did. We wanted to look at a
 website and see how fast it responded

0:09:54.940000 --> 0:09:56.220000
 to our requests.

0:09:56.220000 --> 0:10:00.020000
 We want to see if there's any errors
 in there like 400 errors.

0:10:00.020000 --> 0:10:04.880000
 To do this we may want to put wire
 shark on both sides of the capture.

0:10:04.880000 --> 0:10:07.240000
 This is a very simple capture.

0:10:07.240000 --> 0:10:09.780000
 But if we were doing something where
 we were looking at an end tier and

0:10:09.780000 --> 0:10:14.440000
 we wanted to see response on the database
 from the web tier, we may want

0:10:14.440000 --> 0:10:16.220000
 to put a capture in between that.

0:10:16.220000 --> 0:10:18.340000
 Otherwise we will not see...

0:10:18.340000 --> 0:10:23.320000
 Specifically the latency from
 one tier to the other.

0:10:23.320000 --> 0:10:28.120000
 And we might have to filter the data
 on both hosts as we just did.

0:10:28.120000 --> 0:10:31.740000
 We want to just see the HTTP traffic
 so we can limit what we see in the

0:10:31.740000 --> 0:10:38.680000
 capture and not cause
 any confusion.

0:10:38.680000 --> 0:10:43.540000
 And essentially we're going to do this type
 of filtering just to see specifically

0:10:43.540000 --> 0:10:49.500000
 how long it took to travel from source
 to destination in milliseconds.

0:10:49.500000 --> 0:10:54.800000
 We can refine that but essentially we
 want to see from source to destination

0:10:54.800000 --> 0:11:03.780000
 how long it took to pull up a web
 page and how quickly it responded.

0:11:03.780000 --> 0:11:05.620000
 Question about time.

0:11:05.620000 --> 0:11:10.560000
 When you capture it is generally
 in milliseconds.

0:11:10.560000 --> 0:11:13.860000
 There are... You can bring
 it down to nanoseconds.

0:11:13.860000 --> 0:11:16.620000
 One of the common things
 is not all capture files.

0:11:16.620000 --> 0:11:18.700000
 We'll be able to show this format.


0:11:18.700000 --> 0:11:22.340000
 So when you're capturing data and you're
 sending it from place to place

0:11:22.340000 --> 0:11:26.280000
 and you're sharing it, if somebody
 opens it up in a different type of

0:11:26.280000 --> 0:11:30.420000
 packet analyzer, they may not be
 able to specify what's going on.

0:11:30.420000 --> 0:11:33.160000
 So you can specifically read everything
 that you're sending them.

0:11:33.160000 --> 0:11:34.940000
 So just be aware of that.

0:11:34.940000 --> 0:11:37.760000
 Another concern is time zones.

0:11:37.760000 --> 0:11:41.080000
 If it does consider time zones.

0:11:41.080000 --> 0:11:45.820000
 So if you're sending it around, it will
 be something that they can read.

0:11:45.820000 --> 0:11:49.540000
 Just be aware that if you're capturing
 something in a different time zone

0:11:49.540000 --> 0:11:53.120000
 to make sure that you understand it is
 from a different time zone so that

0:11:53.120000 --> 0:12:01.100000
 you can read it and readjust it manually
 for yourself when you're troubleshooting

0:12:01.100000 --> 0:12:06.020000
 with it. Okay, I was looking in the
 chat forum and it was a couple of

0:12:06.020000 --> 0:12:07.720000
 questions that were asked.

0:12:07.720000 --> 0:12:09.700000
 Let me just review.

0:12:09.700000 --> 0:12:15.040000
 Okay, so back with
 the time stamps.

0:12:15.040000 --> 0:12:20.120000
 So the question was, you know, when you're
 doing this stuff, can you troubleshoot

0:12:20.120000 --> 0:12:22.060000
 the entire transaction?

0:12:22.060000 --> 0:12:28.060000
 Yes. When we get more into the flow
 graph, we can see the TCP handshake

0:12:28.060000 --> 0:12:29.400000
 and how all that stuff works.

0:12:29.400000 --> 0:12:32.040000
 And we'll be able to look at
 the timing in between that.

0:12:32.040000 --> 0:12:38.380000
 But just as a general rule of thumb, if
 you pull up your wire shard capture.

0:12:38.380000 --> 0:12:45.040000
 And you look at it, as we did before,
 you can see in the left-hand side

0:12:45.040000 --> 0:12:48.340000
 here of the window,
 the time column.

0:12:48.340000 --> 0:12:52.880000
 And you can see as you're doing each
 piece of the transaction, here's

0:12:52.880000 --> 0:12:56.260000
 a get. So obviously it's
 a doing a request.

0:12:56.260000 --> 0:13:01.720000
 And you can see when it goes through
 in posts, you can check to see how

0:13:01.720000 --> 0:13:03.480000
 long it's taken.

0:13:03.480000 --> 0:13:10.780000
 And generally anything, you know, over,
 let's say, 40 or 50 milliseconds

0:13:10.780000 --> 0,169
when it goes through and post

170
00:13:00,184 --> 00:13:03,419
so you can check to see how long it's taking.

171
00:13:03,419 --> 00:13:08,358
And, generally, anything, you know, over let's say,

172
00:13:08,358 --> 00:13:14,166
forty or fifty milliseconds to post something is probably 

173
00:13:14,150 --> 00:13:19,548
not very good depending on your connection.
That was also another consideration.

174
00:13:19,548 --> 00:13:25,969
So one of the other tools that we were looking at
before we, we closed out this session was

175
00:13:25,958 --> 00:13:27,428
And I'll pull this up now...

176
00:13:27,428 --> 00:13:30,917
was other tools that you can use to validate

177
00:13:30,917 --> 00:13:35,789
specifically, what is being done and 
what pages are being done?

178
00:13:35,789 --> 00:13:39,102
So, there's tools out there that will allow you

179
00:13:39,102 --> 00:13:42,984
to, you know, pull down
the entire cascading style sheet.

180
00:13:42,984 --> 00:13:49,046
There's things that will allow you 
to accelerate your, your service

181
00:13:49,032 --> 00:13:52,306
 so you're not pulling down a ton of little packets.

182
00:13:52,306 --> 00:13:55,639
There's things that can be done to accelerate this,

183
00:13:55,644 --> 00:13:58,307
to reduce the amount of gets.

184
00:13:58,304 --> 00:14:04,316
So, there's things that can be done 
to increase the performance here.

185
00:14:04,316 --> 00:14:07,643
But just in Wireshark, the realm of wireshark

186
00:14:07,643 --> 00:14:12,541
if you want to look at the actual data
and check out and see what's happening here

187
00:14:12,541 --> 00:14:18,560
you can validate from one step to the next
exactly how long it's taking with timestamps.

188
00:14:18,560 --> 00:14:24,303
So, it's important to understand timestamps.

189
00:14:24,303 --> 00:14:28,622
It's something that will help you 
when you're troubleshooting because

190
00:14:28,622 --> 00:14:35,791
as an example, let's say, you're looking at 
a transaction from a client to a server.

191
00:14:35,791 --> 00:14:37,791
One of the things that you could do is

192
00:14:37,791 --> 00:14:41,124
run a Wireshark capture at the client, like we did here.

193
00:14:41,124 --> 00:14:43,723
If you have access, you can run one at the server

194
00:14:43,723 --> 00:14:45,487
and you can do a compare.

195
00:14:45,487 --> 00:14:51,038
And take a look to see exactly what's going on
within a specific set of time

196
00:14:51,038 --> 00:14:54,052
so that you can see where the hang up might be 

197
00:14:54,042 --> 00:14:57,410
or where the performance hit may be.

198
00:14:57,427 --> 00:15:01,310
We were talking again about that performance hit.

199
00:15:01,310 --> 00:15:04,626
One of the key things that we were discussing

200
00:15:04,626 --> 00:15:08,674
and we were talking about, 
one of this I posted in the forum, was that

201
00:15:08,674 --> 00:15:13,902
IO is a big thing. So if you're, let's say,
 you have a disc drive on the local server

202
00:15:13,897 --> 00:15:16,731
wherein the read-write times are poor

203
00:15:16,731 --> 00:15:23,997
that will potentially show as slow performance
when you're accessing a website

204
00:15:23,997 --> 00:15:28,260
if it's, if the system doesn't have enough memory.

205
00:15:28,260 --> 00:15:32,919
If the NIC card is having an issue, 
let's say, it's not on a gig

206
00:15:32,919 --> 00:15:38,312
and it's on a fast ethernet and 
you see a lot of problems

207
00:15:38,312 --> 00:15:40,825
where it's actually buffering that traffic.

208
00:15:40,825 --> 00:15:43,394
There's a lot of things that you would look at to see 

209
00:15:43,404 --> 00:15:47,793
specifically if you had a performance issue outside.

210
00:15:47,808 --> 00:15:53,852
But this in Wireshark, 
this example is one of those things

211
00:15:53,852 --> 00:15:58,274
where you may be able to get an understanding
of where you need to look.

212
00:15:58,274 --> 00:16:03,742
So as we had mentioned before,
 if you see long periods of time

213
00:16:03,742 --> 00:16:08,462
or you see tons of get requests, 
it might be something where

214
00:16:08,462 --> 00:16:15,369
it's just not able to provide you the paging time
 or it's sending way too much traffic

215
00:16:15,369 --> 00:16:19,188
and you're not getting it back in time.

216
00:16:19,188 --> 00:16:22,563
So, those are some of the things that you can check.

217
00:16:22,563 --> 00:16:27,130
Not only capturing it in Wireshark 
and giving you clues to where to look

218
00:16:27,130 --> 00:16:30,530
but specifically, do you have a problem with a client?

219
00:16:30,530 --> 00:16:32,449
Do you have a problem on the server?

220
00:16:32,449 --> 00:16:37,409
You know, do you have problem in between on the network?

221
00:16:37,409 --> 00:16:46,458