|
When analyzing packet traces, I like to view as much as possible in the one-line summary display, drilling down into the decodes only when necessary. For example, to follow the TCP layer, most analyzers have an option to display only up to the TCP layer in the summary line.
When analyzing an application protocol using TCP such as HTTP, browsers will use two or more simultaneous TCP sessions to download web content. Trying to analyze simultaneous sessions can be confusing because consecutive HTTP packets may have nothing to do with each other unless they contain the same set of ports (and are thus part of the same TCP session). I recommend filtering packets by ports (don't forget both directions) to view the packet sizes, turn-around time, and other TCP and client/server dynamics one session at a time.
Analyzing throughput of FTP or another file transfer protocol (such as a Windows file drag-an-drop SMB session)? The maximum throughput of TCP is often limited not by bandwidth but by the round-trip delay between client and server. Maximum theoretical throughput (assuming no congestion from other traffic) = the TCP window size divided by the round-tip delay. For example 8760 bytes divided by 0.100 seconds = 87,600 bytes/seconds, or roughly 45 percent of a T1 indicating that we may wish to set a higher window size across the WAN. Similar situations can also arise even in low latency LANs, especially at Gigabit and higher speeds. Try the math. You may be surprised.
|
