TULIP - Free protocol Simulator

HTTP

1) Protocol presentation

HTTP is an application layer protocol used in the internet to transfer data between a client and a server. The protocol is described within RFCs 1945 (1.0) and 2616 (1.1).

The diagram below describes the different uses of this protocol:

Tulip allows simulating each of these four network elements:

- HTTP client: simulates one or more HTTP clients, using the same IP address. The HTTP clients may be internet browsers or any other client (e.g. SOAP client). Tulip allows sending requests and receiving replies.

- HTTP proxy: simulates a HTTP proxy used as a relay between a HTTP client and HTTP server. The requests received are processed according to the request-uri.

- HTTP server: simulates a server receiving HTTP requests and sending replies in return.

The scenarii only describe the applicative payload, the layers underneath are handled by TULIP and the operating system.

2) Transport specifics

Le HTTP client will be the entity which will send the first packet (request, like GET, POST). The HTTP server is expecting a request. The supported transport protocol is TCP, which also has the client/server notion. Therefore, the HTTP server will also be TCP server, and HTTP client will be TCP client.

The TRANSPORT parameter permits to position the client/server behaviour of TCP.

- CLIENT: the application will initiate the connexion when sending the first message since the source socket(s).

Example:

</ENVIRONMENT>

- SERVER: the application is waiting for connexions from clients, and will accept connections only from some IP/ports (it is possible to specify a port range or to accept all IPs). These IP/ports are specified within the configuration file.

Example:

</ENVIRONMENT>

Tulip only supports multi-socket mode : the HTTP messages are sent from several TCP sockets, one per traffic agent. The port range is specified within the configuration file.

Example:

</ENVIRONMENT>

- Repetitions

The HTTP messages are sent over TCP, so the application relies on TCP stack acknowledge/repetition mechanisms to ensure the reception of the message by the other end.

- Paquets routing

Tulip does not perform any URL based routing, but dispatches the incoming packets to the correct traffic agent/responder based on the TCP socket which received the packet.

3) Specific protocol commands

The HTTP library implements the following functions:

EXPECTED: message reception command, specified in text or hexa mode according to the chosen format in the configuration file. The TAM attribute contains the number of seconds in receiving state before a traffic error is raised.

The text enclosed between beginning and ending anchors may contain on or more jokers, variables, constants, traffic parameters. If a variable is in format ~(variable)~, then Tulip considers the variable as a joker, and tries to position the matched string into the variable. Tulip will automatically insert line jokers at the end of each line, to allow for more flexibility (no need to specify all HTTP headers, only the order is important).

Example:

GET / HTTP/1.1

Accept-Language: ~(langage)~

Accept-Encoding: gzip, deflate

Host: localhost

Connection: keep-alive

Agent: ~ID~

</EXPECTED>

Example:

<TEST_RECEIVE TAM="5">

HTTP/1.1 200 OK

Expires: -1

Cache-Control: private, max-age=0

Content-Type: text/html; charset=UTF-8

Content-Encoding: gzip

Server: gws

Agent: ~agent~

Content-Length:

X-XSS-Protection: 0

~(gzip_content)~

</TEST_RECEIVE>

MESSAGE: command used in responder scenario in order to match an incoming packet. The enclosed content is in text or hexa depending of the format chosen in configuration file, and can contain one or more jokers/constants/variables/traffic parameters. If a variable is in format ~(variable)~, then Tulip considers the variable as a joker, and tries to position the matched string into the variable. Tulip will automatically insert line jokers at the end of each line, to allow for more flexibility (no need to specify all HTTP headers, only the order is important).

Example:

HTTP/1.1 200 OK

Content-Encoding: gzip

~(gzip_content)~

</MESSAGE>

SEND: sends a HTTP packet described between the beginning and ending anchors. The text may contain variables, traffic parameters, constants.

Exemple:

<SEND>

HTTP/1.1 200 OK

Content-Type: image/gif

Last-Modified: Thu, 25 Mar 2010 09:42:43 GMT

Date: Sat, 27 Mar 2010 17:06:57 GMT

Expires: Sun, 27 Mar 2011 17:06:57 GMT

X-Content-Type-Options: nosniff

Server: sffe

Agent: ~agent~

Content-Length:

Cache-Control: public, max-age=31536000

Age: 103

X-XSS-Protection: 0

~logo_gif~

</SEND>

TEST_SEND: sends a HTTP packet described between the beginning and ending anchors into the test pipeline (see corresponding section for more details). The text may contain variables, traffic parameters, constants.

Example:

<TEST_SEND PIPELINE="INPUT">

HTTP/1.1 200 OK

Content-Type: image/gif

Last-Modified: Thu, 25 Mar 2010 09:42:43 GMT

Date: Sat, 27 Mar 2010 17:06:57 GMT

Expires: Sun, 27 Mar 2011 17:06:57 GMT

X-Content-Type-Options: nosniff

Server: sffe

Agent: ~agent~

Content-Length:

Cache-Control: public, max-age=31536000

Age: 103

X-XSS-Protection: 0

~logo_gif~

</TEST_SEND>

4) Example scénarii

Below, some example HTTP scenarii:

1) Client HTTP /samples/http_Client_Google

This test package provides an illustration of the use of an HTTP client scenario, which performs HTTP Get query to the local IP address (specified withing the configuration file). The rate is fixed to 100 queries per second.

Included scenario files:

tulip.xml: configuration file.

GO_HTTP.xml : launcher scenario, starts the traffic agents.

CLIENT_HTTP.xml : test scenario, which sends a http Get query and expects a 200 OK in reply.

The test topology is « OTHER only ».

2) HTTP server /samples/http_Server_Google

This test package simulates a http Google server, which replies to Get requests with as a reply some compressed HTTP content (binary file with gzip format) as well as a GIF picture.

It is possible to execute this scenario from an internet browser (ex Firefox).

Included scenario files:

tulip.xml: configuration file.

GO_HTTP.xml : launcher scenario, starts the responder agent.

RESPONDER_HTTP.xml : responder file, receives GET requests and sends as reply 200 OK messages (one for the compressed HTML, one for the GIF logo).

gzip_content : compressed HTTP content.

logo.gif : transmitted image file.

The test topology is « launcher + responder».

3) HTTP test responder /samples/HTTP_TEST_RESPONDER

This package allows simulating http traffic between several http clients and a test responder.

Included scenario files:

tulip.xml : configuration file.

GO_HTTP.xml : launcher scenario, starts the responder.

TEST_RESPONDER_HTTP.xml : responder file, receives GET requests from test pipeline, and sends as a reply 200 OK messages (one for compressed content, one for the logo GIF file).

CLIENT_HTTP.xml : HTTP client which sends a http request towards the output pipeline and expects a reply in return.

gzip_content : compressed HTML content.

logo.gif : transmitted image file.

HTTP