Intoduction to Dual Transport HTTP

INTRODUCTION

Today’s Web interactions are frequently short, which leads to an increasing number of responses carrying only control information and no data. Currently browser uses HTTP, which uses client-initiated TCP for all Web interactions. TCP is not always well suited for short interactions.
Client initiated TCP handicaps the deployment of interception caches in the network because of the possibility of disrupted connections when some client packets bypass the cache on their way to the server. This report explains a new transfer protocol for Web traffic, called Dual transport HTTP (DHTTP), which splits the web traffic between UDP and TCP channels. This protocol is proposed by Michael Rabinovich and Hua Wang. When choosing the TCP channel, it is the server who opens the connection back to the client. Among important aspects of DHTTP are

• Adapting to bottleneck shifts between a server and the network and coping with the unreliable nature of UDP. 
• By using server-initiated TCP, DHTTP also eliminates the possibility of disrupted TCP connections in the presence of interception caches thereby allowing unrestricted caching within backbones.

About HTTP:

Currently all the browsers use HTTP, which was conceived as essentially a protocol for transferring files. It is an application layer protocol. It was designed on top of a connection-oriented transport protocol such as TCP.
The HTTP protocol consists of two fairly distinct items

1. The set of requests by browser to server
2. The set of responses form server to browser

Following is the list of few built-in HTTP request methods 
a)    GET - Request to read a web page
b)    PUT - Requests to store web page
c)    HEAD - Request to read a Web page’s header
d)    POST - Append to a named resource
e)    DELETE - Remove the Web page
f)    LINK - Connects two existing resources
g)    UNLINK – Breaks an existing connection between two resources

Problems in HTTP:

 The current Web workload exhibits a large number of short page transfers, which results in more interactions for control purposes rather than data transfers. It was found that median response size that carries only data was found to be about 3,450 bytes. Establishing a TCP connection for such short response size lead to an unnecessary overhead. It also increases number of TCP connection setups and number of open connections at the server.
To address these overheads late versions of HTTP uses the concept of persistent connections and pipelining. Persistent connections allows client to fetch multiple pages from the same server using the same TCP connection. This reduces the TCP set-up overheads. Pipelining allows client to send multiple requests over the same connection without waiting for response for earlier request. The server will send a stream of responses back.

1.  Though these features reduce client latency and network traffic but it does not eliminate all overheads of TCP. In fact they introduce new performance penalties, especially when the bottleneck is at the server.
2. Persistent connections increase the number of open connections at the server, which may decrease the server throughput.Pipelining has a limitation that servers must send responses in their entirety and in the same order as the order of the requests in the pipeline. This constraint causes head of line delays when a slow response holds up all other responses in the pipeline.

 To avoid head of line delays, browsers often open multiple simultaneous connections to the same server, which further increasing the number of open connections and degrading the throughput of a busy server. To limit the number of open connections, servers close connections that remain idle for a persistent connection timeout period. Busy sites often use short connection timeouts, thereby limiting the benefits of persistent connections. Moreover, persistent connections that servers do maintain are often underutilized, which wastes server resources and affects the connection’s ability to transmit at proper rate since well-behaving TCP implementations shut down the transmission windows of idle connections.

FEATURES OF DHTTP

The Dual-transport HTTP protocol (DHTTP) splits the web traffic between Transport Layer Protocol (TCP) and User Datagram Protocol (UDP)

• Client normally sends all requests on UDP. Then server sends its response over UDP or TCP, depending on the size of the response and the network conditions. 
• By using UDP for short responses, DHTTP reduces both the number of TCP connection set-ups and the number of open connections at the server.
  The utilization of the remaining TCP connections increases because they are reserved for larger objects.
  DHTTP removes ordering constraints of pipelining.
• When choosing TCP, a DHTTP server establishes the connection back to the client, reversing in a sense the client/server roles in the interaction.

While having some implications with firewalls, this role reversal brings following benefits.

1. It avoids an increase (compared to the current HTTP) in the number of message round-trips before the client starts receiving the data over the TCP channel. 
2. It removes a bottleneck at the server that accepts all TCP connections.
3. It allows unconstrained deployment of interception caches in the network

DHTTP PROTOCOL

Working:
In DHTTP, both Web clients and servers listen on two ports, a UDP and a TCP. Thus, two communication channels exist between a client and a server

1. UDP channel
2.  TCP channel.

The client usually sends its requests over UDP. Only when uploading a large amount of data (e.g., using a PUT request) client may use TCP. By default, a request below 1460 bytes, that is Ethernet maximum transfer unit (MTU), is sent over UDP. This value is called as Size Threshold value. Virtually all HTTP requests fall into this category. For conceptual cleanness, the client itself initiates the TCP connections to send requests instead of reusing connections initiated by the server for data transfer.
When the server receives the request, it chooses between the UDP and TCP channels for its response. It sends control messages that consist of only responses and no data, as well as short (below 1460 bytes, one Ethernet MTU, by default) data messages, over UDP even if there is an open TCP connection to the client. This avoids the overhead of enforcing unnecessary response ordering at the TCP layer. A UDP response is sent in a single UDP packet since our default size threshold practically ensures that the packet will not be fragmented.
 For long data messages (over threshold value), the server opens a TCP connection to the client, or re-uses an open one if available. Figure 4.1 shows the message exchange of a current HTTP interaction and a DHTTP interaction with the response sent over UDP and TCP. It is important that even when choosing TCP, DHTTP does not introduce any extra round-trip delays compared to the current Web interactions. While it may appear counter-intuitive because in DHTTP, TCP establishment is preceded by an “extra” UDP request, the comparison of Figure 1a and 1c shows that data start arriving at the client after two roundtrip times (RTTs) in both cases. In fact, a possible significant advantage of DHTTP over current HTTP in this case is that the server may overlap page generation with TCP connection establishment.

Message Format: 

    Responses to the requests may arrive on different channels and out of order with respect to requests, so the client must be able to match requests with responses. Consequently, a client assigns a randomly chosen request ID to each request. The request ID is reflected by the server in the response and allows the client to assign the response to the proper request. The request ID is unique for a given client and only across the outstanding requests that await their responses.

Request ID
Port Number
Flag
HTTP Request
4.2.a - Request
Request ID HTTP Request
4.2.b – Response
Fig 4.2 a shows format of the DHTTP message formats for sending the request and response given by the server.

Request ID         8      
Port Number      2      
Resent flag         1      
HTTP Request   -    
 Request ID:  Total eight bytes are allocated for the request ID, which is sufficient to safely assume no possibility of collision
Port Number: Two bytes are allocated for a client to specify port number. While sending response server must knows both the client port numbers that is TCP port and UDP port. To save the overhead we use the fact that source port number of the channel used by the request is included in the IP header already. So DHTTP request must contain the port number of the other channel only. Thus DHTTP request message has port number field, which contains client’s TCP port number if request is sent over UDP and UDP port number if the request is sent over TCP.
Resent flag: It is a byte flag, which is currently used to indicate duplicate request. Thus whenever client retransmits the request it send it with resent flag set. When server receives such request, it process such request accordingly.
HTTP Request: This field is similar to current HTTP request. While sending the response server appends the 8-byte request ID from the request to the normal HTTP response as shown in the Figure 4.2 b.
DHTTP request format adds eleven bytes to every request compared to standard HTTP request format. Similarly DHTTP response, which includes request ID adds only 8 bytes.

 Reliability:

UDP is not as reliable a protocol as TCP. Considering the Internet we must provide a reliability mechanism for transmission over UDP. An easiest way to provide reliability would be to make clients acknowledge every UDP packet received and servers resend unacknowledged UDP packets. This, however, would increase bandwidth consumption for acknowledgements and server overhead for storing unacknowledged UDP packets and for managing per-packet timeouts and retransmissions. These overheads would be paid whether or not a packet loss occurs.
This approach for providing reliability is never optimal. When packet loss is low, it imposes the unnecessary overheads. When it is high, TCP is preferable than using such approach over UDP. So, instead of trying to build reliability into the UDP channel, the DHTTP protocol simply stipulates that a client may resend a UDP request if the response does not arrive for a timeout period, with the resent flag set. Using a large request timeout (about 5 and 10 seconds) with a limited number of resends DHTTP can ensures that clients do not overwhelm a server with repeated resends. Clients could use more sophisticated strategies such as smaller initial timeouts followed by exponential backoff.
It is the server’s responsibility to efficiently deal with resent requests especially when there is a bottleneck. The server can achieve this by re-generating responses, or caching UDP responses in the buffers so that they can be re-transmitted quickly. However, DHTTP stipulates that a response to a resent request be sent over TCP for flow control
 Non-idempotent Requests:
    Non-idempotent Requests are those requests, which should not be re-executed. Examples of such requests include some e-commerce transactions, such as an order to buy or sell stocks. Currently DHTTP deals with non-idempotent requests by delegating them to TCP transport, instead of providing special support at the application level. In this method, the protocol portion of a URL prescribes the transport protocol to be used by clients. For instance,
We can have a convention that, for URLs of the form given below can be used indicate that channel used for communication must be TCP
While for URLs that start with “dhttp:”, it can use UDP. Then, all non-idempotent URLs would be given the “dhttpt:” prefix.

Flow Control:

DHTTP servers must avoid flooding a congested network with UDP messages. Instead of implementing its own flow control, DHTTP again leverages TCP by requiring that responses to any resent requests be sent over TCP. So, any time a packet loss occurs, the server switches to TCP with its flow control for this interaction.
An HTTP server using MTU sends packets of 1460 bytes over the Internet and has the initial TCP window for data transfer equal to two packets. Thus, DHTTP server could in principle send up to 2920 bytes by UDP without relaxing TCP’s flow control. Our current default threshold of 1460 bytes makes DHTTP servers even more conservative than HTTP servers in terms of flow control within one Web download.
DHTTP servers may still create traffic bursts by sending a large number of UDP packets belonging to distinct parallel downloads. However, short parallel TCP connections will create similar bursts in existing HTTP due to SYN and the first
data packets. So, it is only in the case of multiple short downloads to the same client reusing a persistent TCP connection in existing HTTP, where DHTTP may be more aggressive. Even in this case, when the fraction of resent requests becomes noticeable (indicating possible congestion), DHTTP servers starts using TCP almost exclusively.

this is not complete updating going on!!!!
But part 1 ends here

Share on Google Plus

About Unknown

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.