INFS2052 lecture 2.6

Connections and request pipelining in HTTP

Connection-oriented and connectionless services

Tanenbaum p. 23 ff (Comer is very light on this topic)

Connection-oriented communication - like telephone

  • make the call, recipient picks up to open
  • talk (both ways - possibly both at same time)
  • multiple messages can be exchanged - order is preserved
  • one or both hang up to close
    •

    Connectionless communication - like letters or telegrams

  • sender just sends letters
  • receiver can also send letters
  • no ordering preserved
  • no open/close
    •

    Quality of service

    Qualities of service may include: speed, reliability (loss of data), cost.

    Connection-oriented services normally are easier to include reliability.

    Connections may cost more, take longer:

    setup, error checking and recovery, (re-send if errors found)

    Choice of service

    choice depends on application:

    application may prefer fast transfers to error recovery reliabilty (video, audio vs. data files)

    Transport services

    Layer 4 in OSI protocol model - Transport layer.

    Hides internetworking routing and transformations
    provides two-way data stream or data packet delivery service
    to specific port (number) on specific host computer (IP address)

    Connection oriented transport service

    In TCP/IP suite the TCP (Transmission Control Protocol) is a connection oriented transport service.

    Reliable - preserves order of data streams, detects and recovers from errors of lost packets or corrupted data.

    Uses sliding window buffers for error detection and recovery, requires buffer space and copying data, is more efficient than most applications would want to write programs for.

    Used for HTTP, SMTP (email), FTP... many applications.

    Connectionless transport service

    IN TCP/IP suite UDP (User Datagram Protocol) is a connectionless transport service.

    Unreliable: no detection of lost packets, corrupted packets just dropped.

    Smaller buffer spaces, faster delivery - but datagrams may come out of order.

    Used for TFTP: expect highly reliable local network,
    simple error detection and recovery by application is acceptable.

    other applications might use to avoid cost and delays of reliable error recovery
    e.g. audio (short slinece) or video (drop lost frame from sequence, freeze frame or interpolate betwen frames on display)
    rather than jerky pause and then try to catch up by showing every frame

    HTTP and connections

    RFC 2068 HTTP/1.1 section 8.1

    Locality of requests, embedded images in document

    In using HTTP driven from HTML docuemnts by a browser

  • locality between documents:
    many request are followed by a request to the same server
    (with proxy server, nearly all requests are to the same server from client)
  • locality within documents:
    many embedded images are from same server as document,
    so display of document requires multiple requests to same server
    •

    In naive protocol every request is a new connection.

    In HTTP/1.0 (badly) and HTTP/1.1 (properly) a client and server can maintain a persistent connection for many requests and responses.

  • fewer open/close, less TCP overhead at client and server
  • fewer network packets for TCP open/close
    •

    Advantages of pipelining requests

    RFC 2068 HTTP/1.1 section 8.1.1

  • multiple requests can be pipelined and elapsed time reduced (a lot)
  • longer transmissions in TCP connection, hence more adaptive to traffic congestion
  • future evolution of protocol:
    better HTTP error handling becomes possible
    •

    Pipelined requests in HTTP/1.1

    RFC 2068 HTTP/1.1 section 8.1, section 19.7.1

    Non-pipelined

    Pipelined

    More than one request can be in transit or waiting at server for service.

    Responses can follow close on each other.

    Total elapsed time can be much reduced compared to non-pipelined case.

    Management of persistent connections

    RFC 2068 HTTP/1.1 section 8.1.4

    Timeout at server if connection inactive for some time (graceful close)

    Error recovery is more complex
    e.g. multiple requests, some may not yet responded to when connection is lost

    Server should stop sending data responses if connection goes into error status (broken somewhere, or client wants to stop and cancel requests)

    Client should remember whether (last) server is HTTP/1.0 or /1.1
    because mechanism is different.

    Lecture Notes Index Lecture 9 Lecture 7

    Last modified: Tue Mar 30 11:23:07 EST 1999
    Queries to : infs2052@iwaki.anu.edu.au