When I analyze a trace file with a client, I always look for the beginning of the TCP connection or application.
The reason is quite simple, there are many items that you can only see at the beginning of the capture. Sure you can make assumptions if you don’t have the beginning captured, but life is so much easier if you had it.
A great example is the TCP 3 way handshake that has many nuggets of info that you can’t obviously see later in the trace. Something as simple as the MSS is easily identified during the 3 way handshake as MSS=, sure if you have a bunch of data packets and the TCP LEN is maxed out with a value of 1212, you can assume the MSS is 1,212 bytes but either end can restrict this. Without the handshake, you will be guessing and need to do more testing.
In this video I cover some of the basics that you can use for baselining, protocol education and troubleshooting. A very important term that I used is “TCP Connect Time” which is the time it takes to send a SYN ACK back to the initial SYN. If you have a system that reports this, you might want to check if that product is working properly. Scenarios such as packet loss/retransmissions can through some of the application reporting tools for a loop.
Measuring the TCP Connection time is a lot better and more accurate than any ping will ever be. Then you can use the same methodology for HTTP or any other application command/response scenarios.