GUI: TCP flow direction, duration, and throughput

Introduction

In the ByteBlower GUI, the user does not configure HTTP clients and servers directly. Instead, the user defines a TCP flow in the Flow View, whose traffic flows between a source port and a destination port.

TCP flow direction (configuration)

Note that in the background, an HTTP client and HTTP server are still created. Based on the HTTP Request Method field in the TCP Flow Template view (AUTO, GET, or PUT), the client and server are created on the correct port. This ensures the bulk of data flows from the configured source port to the destination port.`

Consider two ports SRC_PORT and DST_PORT.

HTTP Request Method GET

Configured port	SRC_PORT		DST_PORT
Created HTTP application	HTTP server		HTTP client
SYN message direction		<<<<<<<
Data flow direction		>>>>>>>

HTTP Request Method PUT

Configured port	SRC_PORT		DST_PORT
Created HTTP application	HTTP client		HTTP server
SYN message direction		>>>>>>>
Data flow direction		>>>>>>>

AUTO direction

The default case (AUTO) normally results in the GET situation. However, if the configured source port is a NATted port (as configured in the Port view), GET is likely not to work. In this case, the SYN message would flow from the destination port towards the source port. If the source port is behind a NATbox however, it will typically drop that SYN message. That's why ByteBlower switches to PUT in that case.

HTTP Request Method AUTO
no SRC_PORT NAT

Configured port	SRC_PORT		DST_PORT
Created HTTP application	HTTP server		HTTP client
SYN message direction		<<<<<<<
Data flow direction		>>>>>>>

HTTP Request Method AUTO
SRC_PORT NAT

Configured port	SRC_PORT		DST_PORT
Created HTTP application	HTTP client		HTTP server
SYN message direction		>>>>>>>
Data flow direction		>>>>>>>

TCP duration and throughput (report)

In the report, the duration and average throughput results are presented to the user. Their values are based on the API calls described above.

Timing and throughput values are always measured on the receiving side. This is the HTTP client for GET and the HTTP server for PUT.
Duration is based on Time.Data.Packet.First and Time.Data.Packet.Last.
Throughput is based on AverageThroughput.

This results in the following formulas:

	Duration formula	Throughput formula
GET	T3 - T2 (C-B)	ClientRXbytes / duration
PUT	T2 - T1 (E-D)	ServerRXbytes / duration

In addition, the report also includes more detailed Timing information. An example is shown below.

Time To First Byte (TTF): Is the time it takes for the first TCP payload byte to reach the client. This matches the T2 timestamps mentioned earlier.
Minimum RTT: Is the shortest round-trip time throughout the lifetime of the session.
Average RTT: The average round-trip time throughout, again over the whole lifetime of the TCP session.
Maximum RTT: Finally, the longest round-trip time encountered during the session.

The above statistics are over the whole lifetime of the TCP flow. Intermediate results are shown in the TCP graphs. An example is shown below, more information about this graph is available in this KB article.