HTTP Model for OPNET Final Presentation

1
HTTP Model for OPNET Final Presentation

• Alon Catz 304565773
• Dina Mesamed 312648074
• Guided by Nir Arad

2
Goals

• Learn and understand the HTTP protocol.
• Learn the OPNET environment.
• Expand the existing OPNET model for http traffic
  and make it more similar to the real thing.

3
HTTP Protocol Overview

• HTTP is the most used protocol over the internet.
• HTTP works over TCP.
• The most common use of HTTP is retrieval of HTML
  pages.
• HTML pages have inline objects which should
  also be retrieved via http
• There are also others, more advanced, uses of the
  protocol.

4
HTTP Protocol Overview

• HTTP Client
• Accepts a request from an application layer.
• Establishes a TCP connection to the host.
• Sends an http request for resource retrieval.
• Waits for an http response on the same TCP
  connection.
• Returns the response for the application layer.

5
HTTP Protocol Overview

• HTTP Server
• Listens on a known TCP port (usually 80) for
  client connections.
• Establishes a connection with a client.
• Accepts an http request and processes it.
• Sends an http response.

6
Client Server Models
7
OPNET model for HTTP

• OPNET has a quite complicated model for
  simulating http.
• OPNET http client
• Accepts most of the parameters concerning the
  request from layers above.
• Those parameters include the size of the response
  and the number of inline objects.
• Generates and sends the first page request.
• Generates and sends inline objects requests
  simultaneously.
• Dies.

8
OPNET model for HTTP

• OPNET http server.
• OPNET has a single server model for all kinds of
  applications including http, email, video etc
• It calculates the processing time based on the
  type of the application and the size of the
  response.
• The resulting job incorporates in the server
  load.
• When the job is done, a response packet is sent
  to the client.

9
Disadvantages of the existing model

• The existing model allows only statistical
  simulations.
• It can not model specific profiles of user
  operation.
• It can not model specific site structure and
  content.

10
Our Goal

• Using our project, a modeler who has a specific
  web site structure, and specific profiles of user
  operation, can get a much more precise view of
  his network and application behavior.

11
Our Enhancements

• Modeler can provide specific site structure and
  content.
• Server reads the requested page from disk and
  simulates CPU load based on its size.
• Server actually sends the requested resources
  back to the client.
• Client parses responses and retrieves inline
  objects.

12
Server Implementation

• Storage directory
• Serves as root for web content.
• Contains files with XML and other contents to be
  retrieved by the client.
• Can contain sub directories with similar content.

13
Server Implementation

• Serving HTTP requests
• Each HTTP request contains resource path.
• Resource path is a path for the desired
  resource relative to the storage directory.
• If the resource exists
• Processing time is modeled based on its size.
• Relevant response headers are set up.
• The file is read from disk and added to the
  response packet.
• If the resource does not exist
• Response packet with no content and HTTP status
  404 (resource does not exist) is sent.

14
Client Implementation

• Client node is configured to retrieve a specific
  page.
• The page is retrieved and parsed.
• The response is XML, which makes parsing easy.
• All inline objects are retrieved in the same
  manner.
• All the objects carry real information.

15
Response Structure

• Client accepts only well-formed XML.
• Otherwise the response will not be parsed and no
  inline objects will be retrieved.
• Values of all href attributes are considered to
  be URLs of inline objects.
• Example lta href/image.gif/gt.When the above
  XML element is encountered by the client, an
  attempt is made to retrieve /image.gif.

16
Packet Structure
17
Simulation

• The following slides will demonstrate the results
  of our work.

18
Simulation Scenario
19
Simulation Configuration
20
Simulation Log
21
Simulation Results
22
Summary

• Our model allows better and more precise HTTP
  traffic and load simulations.
• We verified model correctness by running OPNET
  simulations and analyzing results.