В Wireshark cуществует опция "Allow subdissector to reassemble TCP streams", она помогает оценить длительность HTTP загрузки

Как осуществляется инкапсуляция, когда HTML страничка "длинная"?  Её, естественно разбивают на фрагменты, каждый из фрагментов затем запихивают в область данных TCP контейнера. Здесь короткие видеоролике о том, как построить график длительностей загрузок

Мои замечания о том, как контейнеры HTTP располагаются в контенейрах TCP¶

Как осуществляется инкапсуляция, когда HTML страничка "длинная"? Её, естественно разбивают на фрагменты, каждый из фрагментов затем запихивают в область данных TCP контейнера.
Таким образом, заголовок HTML вместе с началом старницы размещается в первом TCP пакете, а во втором TCP контейнере сразу после заголока размещаются байты второго фрагманта HTML.
Все вроде бы логично..., но как отследить время загрузки последнего фрагмента? В Wireshark для этого предусмотрены свои фирменные "Time stamps" (покруче, чем в стандрте), но это еще не все.
Существует опция "Allow subdissector to reassemble TCP streams" - она включена по умолчанию. Когда приходит последний фрагмент HTTP, то из всех предыдущих пакетов TCP выбираются HTTP фрагменты и из них собирается вся HTML страница (или другой файл, который был внутри контейнеров HTTP.

Я повторил упражнение из первого видео, стало ясно, что правильнее оперировать "искуственным" HTTP ответом (при включенной опции). Ниже результаты моих экспериментов:

In []:

# При отключенном реассемблинге мы видим в 56 фрейме
Request in frame: 54

HTTP response 1/1
Time since request: 0.048213000 seconds

In []:

# При отключенном реассемблинге мы видим в 87 фрейме
Request in frame: 54
HTTP response 1/1
Time since request: 0.138645000 seconds

Поначалу я отфильтровал данные по потоку tcp.stream == 5 (Этот поток соответствовал загрузке одной страницы proglive.ru) и посмотрел в последнем сегменте время tcp.time_delta, то оказалось, что весь поток "проистекал" около 10 секунд.
Оказалось, что 9 секунд ушло на паузы при закрытии соединения.
Так что оперировать длительностями TCP процессов надо осторожно...

Wireshark Tip 3: Graph HTTP Response Times¶

Опубликовано: 20 июля 2013 г. When troubleshooting HTTP communications, first you need to properly set the TCP Preferences (see Tip 1), then consider adding a column for http.time and then graphing this value.
http.time tcp.time_delta

In []:

0:01hi this is Laura Chappell and this is where shark tips three
0:05now if you wanna follow along with the where shark tip series you can follow me
0:08on twitter
0:09at work chapel in this tip I'm gonna show you how to graph
0:14HTTP dot time that's HTTP response time
0:18which is a new feature that came out with Wireshark 1.2 10
0:21so open up a trace file called HTTP down schwere shark download dot P cap
0:28Angie and you can see in the strays found we have a GET request
0:32to to download the page called
0:35download on HTML now if he didn't look back it took number one you might want
0:40to do that because I'm gonna change the setting for TCP
0:42I actually want to see the response code right here in the packet in which
0:47actually occurs rather than way down here
0:50the response code is actually right here in frame number six here
0:53I can actually see it down the packet bites pain to make that change I'm going
0:57to select the TCP header
0:59right mouse click protocol preferences and
1:02and check allow some Thai sector to reassemble TCP streams
1:06now we can see
1:10the response code in the infocomm so here's the new field came out with
1:14Wireshark one-dot
1:1510 and you can find the new field where and you expand the
1:20HTTP header section in the detail window
1:23Sosa go down to the bottom we will see
1:26HTTP response 1 of 1 and fear is our
1:30HTTP time field and you can see when you highlight that line that
1:34down on the status bar where schork tells us the display filter syntax
1:37and display filters are what we use in our graphs
1:41so I'll be using that to graph my HTTP response
1:45times we can also
1:49right mouse click on that line and add it as a column which is a great thing to
1:52do for HTTP analysis
1:54all right mouse click and choose apply as column
1:58and now I have a new column that says time since request
2:03I can click on it twice to sort from high to low
2:07and then go to the top up the list to see the highest response codes and we
2:11can see that there are some
2:12pretty bad response times I mean I would expect to see times faster than this
2:17202 almost 203 milliseconds
2:21just for the server to come back and say okay
2:24when I made a request for a simple get file so now I'm going to build a graph
2:31that will show me where I have spikes in the HTTP response times
2:35got to statistics and I O Graph
2:39and of course the default I O Graph is to show us all of the traffic and I
2:43really don't care about that something to turn off graph
2:46number one in graph number two
2:49I will simply enter in the filter HTTP got
2:52time and then turn on that graph
2:55and this shows me that there's a spike in time right up towards the beginning
3:00at the trace file I can move that
3:06down a little bit out of the way and we can also apply this
3:10to other trace files and and remember that this is summarized for the one
3:14second interval so we may wanna move in just a little further
3:17to see a more granular you up response time delays
3:21so here we can see we have a number of delays
3:25that are showing up at the beginning of the streets fun than four seconds into
3:28the trace file
3:29we start seeing some more delays I'm going to leave this graph window open
3:34don't close the I O Graph window when you move from trees found
3:38trace file where triple automatically recreate this graph based on the next
3:42race value open
3:43so open up trees for the day know has got some
3:47pretty serious delays the trace file is called
3:51HTTP docs Facebook and this is one of the trees files that you can get from
3:56the Wireshark book dot com website
3:58so here is
4:02and I can already see in my time since request column I've got a pretty high
4:06number here
4:07I'm in a toggle over to my graph and then looking through the graph I can't
4:12see the point where I have
4:14some higher delays in this crap and we can see that supply the graph to
4:20HTTP docs Facebook top
4:23Capen G
4:26remember you can always sort any column that you add so if I go to the top
4:30I can see this packet right here I'm frame number eleven
4:35up I didn't meet with that money that Bachmann my source com
4:39frame number eleven shows up with a tremendously high delay here 3.4 seconds
4:44before the server turned around and said 200 okay
4:49let me give you a warning here on graphing this information
4:54when I first started showing you this
4:58this process in Wireshark I mention I set my
5:02TCP reassembly of
5:06we take you to that first race father had opened HTTP
5:09dash Wireshark download
5:15and we can see in the strays father Cincinnati cock there's the GET request
5:18there's the ac
5:19and there's the 200 okay notice the time diet a little over forty four
5:24milliseconds
5:27I will turn on that TCP reassembly selling
5:31which is the default for Wireshark and bring it down a little bit circus
5:37up there so go back to the default setting in Wireshark to allow some
5:42dissect
5:42reassemble TCP streams
5:46now this will change the results that I get in my graphs
5:50so it's important that you turn off that setting if the setting is on this is
5:54what I see
5:55I'll see the GET request I'll see the AAC
5:58and then I see TCP segment ever reassembled protocol data unit or PTO
6:03this is actually the packet that contains the 200 okay
6:06that's the packet that contains my response code though my 200 response
6:10code
6:11and that's the packet that I would like to have time stamped as the response
6:14packet
6:16but instead because I have reassembly enables here I can see that
6:20Wireshark shows me TCP segment reassembled protocol data unit keep
6:24going keep going
6:24accurately and then the last packet the download for that item
6:29that page is the one that is time stamped
6:32so that would give me and artificially high
6:36TC her HTTP response time
6:39if I left that setting that way so make sure when you're analyzing HTTP traffic
6:45that you have your TCP preference setting
6:49for allow some die Sektor to reassemble to be streams
6:53of and that will give you and accurate
6:56HTTP round trip time
6:59if you'd like to follow along with this where shark to series as I release the
7:03tips
7:03on Twitter you can follow me outdoor chapel
7:07for more Wireshark tips and training the chapel you dot com

Wireshark Tip 1: TCP Reassembly Setting¶

In [1]:

from IPython.display import Image
Image(filename='C:\\Users\\kiss\\Pictures\\pythonR\\tip3_1.png')

Out[1]:

Опубликовано: 20 июля 2013 г.
Tired of seeing [TCP Segment of a Reassembled PDU] on your HTTP traffic? .
Change this one TCP setting to view the true HTTP Response Codes in your Info column.
This will speed up your troubleshooting process and provide a more accurate view of HTTP traffic.

In []:

0:01hi this is Laura Chappell and I'd like to provide you with an example of how to
0:05use Wireshark to number one that I tweeted
0:07now if you wanna stay up on the Wireshark tip series:
0:10you can follow me at Laura Chappell worshipped at number one
0:15is to turn of the TCP preference
0:19for reassembly when you're working with HTTP
0:22this way you could see the response code in the correct packet
0:26let me take you out to a trace Fallon show you
0:30why you want to implement this tip I've opened a basic trace file
0:36where i have a web browsing session taking place I can see a DNS query for
0:41an
0:41a record in ipv4 address and response and then a DNS Cherie for an
0:46AAA a record or an ipv6 address and
0:49response coming back there's my TCP handshake
0:53and there's by get request for the main page after you make a GET request to an
0:58HTTP Server
0:59you should get a numerical code back and hopefully will be a two hundred
1:04indicating that everything's okay
1:05but with this default configuration
1:09white shark is not showing me the 200
1:12okay even though I know that that value is sitting in packet number nine
1:17if I scroll down in the packet bites pain
1:20here we can see exactly what's being sent down to us
1:25and we can see that two hundred okay right at the top where it says
1:29to there's the 00 next line okay
1:32but I'd like to be able to see this in my infocomm
1:35I certainly don't have to go back all the time to my packet bites paint see
1:39that
1:39so we're going to change the TCP
1:42reassembly setting if
1:46the packet has a response code in it and there's
1:49data piggybacked on that response code by default my shirt will put up this
1:54line that says
1:55TCP segment ever reassembled PD you or protocol data unit
1:59I don't wanna see that I wanna see the response code right there
2:03in the packet in which contained there are two ways of changing the setting
2:08there's the long way Anders the quick short way
2:12so the long way would be to click on the
2:15edit preferences but numb upon the main toolbar but I want you to get used to
2:19using Wireshark in the most efficient way possible
2:21so instead of using edit preferences button let's go ahead and just select a
2:27TCP header
2:28in the packet details pane and then right mouse click on that her
2:32this will bring up window it
2:35are a menu that expands and we can see that there's a line says protocol
2:38preferences
2:39this is the setting that I want to disable
2:43allow someday sector to reassemble TCP streams
2:46in the background I a packet number nine highlighted
2:50and I want you to pay attention to that packet because this is going to change
2:53in just a moment
2:54I will I'm check that setting
2:57and now packet number nine shows me money
3:01response code this is great because I can also sort the info column to put all
3:06the response codes together and it's pretty easy to see that
3:09yes a lot 404 in there I'll sort back on the original
3:13order again so why would you not want to change that setting
3:18well if you work with reassembly
3:21in other words you want to reassemble all the objects that were transferred
3:25using HTTP
3:26if you left Wireshark and its
3:29default allowing the reassembly then
3:33when you want to select File export objects and HTTP
3:38you would see that my shark would reassemble
3:42all love these identical file names into a single line
3:47allowing you to save them separately honestly
3:50that's not a feature that I do a lot with Wireshark I think they're better
3:54tools out there for doing free assembly
3:56such as maybe
3:59network minor that's just not wear shorts strong point but if you do want
4:04to use that file
4:05export objects HTTP
4:09you'll need to turn that setting back on
4:14you can keep up with the wear short tips that I'm releasing on Twitter
4:17if you follow me at at or chapel for more Wireshark training and tips
4:23you can visit chapel you dot com

Посты чуть ниже также могут вас заинтересовать