HTTP 1.1 Persistent Connection Pipelining
This message flow simulates an HTTP transaction that retrieves three simulated web pages from a server, and is intended to allow pipelined HTTP traffic between the MN and the Network Host node. The HTTP 1.1 Persistent Connection message flow simulates a simple request/response exchange.
When control plane protocols are used, the TCP connection is established after Data Start Delay timer expires. The MN initiates the TCP connection, using the Client Port and Server Port defined in the message flow.
HTTP pipelining occurs when the client continues to send request messages without waiting for a response from the server. Pipelining can be allowed in an HTTP message flow by clearing the Wait for Response checkbox for the request message in each command. This enables the DMF to continue generating the GET requests without waiting for the 200 OK responses.
-
The client begins the message sequence by issuing the first GET request and the server responds with a 200-byte message that includes the response headers.
-
The client sends a second GET request and the server responds with a 215-byte message that includes the response headers.
-
The client sends a third GET request and the server responds with a 300-byte message that includes the response headers. The Wait for Response box for this request is checked to ensure that the message flow waits for a response before starting a new transaction.
In the default configuration, the message flow will repeat once per second while the MN session is active. This assumes that the entire flow can be completed in one second. The flow must complete before the next iteration can begin, even if this results in a slower transaction rate.
Modifying the Message Flow
Since HTTP is a text-based protocol, you can easily modify the HTTP headers or the simulated web page content, or import a file to use as the web page. If you do modify the message, keep the following rules in mind:
-
Pipelining is not supported in HTTP 1.0. Although the test will execute properly with a 1.0 header, it is not a valid protocol configuration.
-
The response headers and the web page content are always separated by a blank line.
To simulate non-persistent HTTP, clear the Persistent Connection checkbox. The TCP connection will be torn down at the end of each message flow, and re-established for the next iteration.
You can specify that random port numbers, in the IANA specified dynamic range of 49152 — 65535, be used by the client by entering a 0 for the Client Port.