How Does WebSocket Compare to AJAX ?
Traditionally, when a web browser loads a web page, it follows these basic steps:
1.Open a short-lived connection to a web server.
2.Send one or more requests for a limited number of resources.
3.Receive resources from the server.
4.Close the connection to the web server.
This architecture was designed primarily for document retrieval, where web browsers load static web pages from web servers. However, web applications that require frequent, timely updates are not well served by HTTP's traditional document-centric design.
HTTP Problem 1: Unnecessary bandwidth consumption
Every single time the application sends or receives an HTTP request, lengthy HTTP headers are transmitted.
HTTP Problem 2: Server cannot push data to the client
The traditional design of HTTP forces client applications to poll the server for updates.To retrieve a server update, the client asks the server for data, then the server responds to the client.
WebSocket offers the following benefits:
Two-byte per-message overhead (no HTTP header), which translates to lower bandwidth and faster network communications.
Both the client and the server can initiate a data transfer at any time, which means applications can be built without polling (no Comet, no AJAX). Real-time applications, hence, become more responsive. Data can be delivered to clients instantly, without waiting for client requests.
Why was WebSocket implemented instead of updating HTTP protocol?
WebSockets is better for situations that involve low-latency communication especially for low latency for client to server messages. For server to client data you can get fairly low latency using long-held connections and chunked transfer.
for more details click here
Traditionally, when a web browser loads a web page, it follows these basic steps:
1.Open a short-lived connection to a web server.
2.Send one or more requests for a limited number of resources.
3.Receive resources from the server.
4.Close the connection to the web server.
This architecture was designed primarily for document retrieval, where web browsers load static web pages from web servers. However, web applications that require frequent, timely updates are not well served by HTTP's traditional document-centric design.
HTTP Problem 1: Unnecessary bandwidth consumption
Every single time the application sends or receives an HTTP request, lengthy HTTP headers are transmitted.
HTTP Problem 2: Server cannot push data to the client
The traditional design of HTTP forces client applications to poll the server for updates.To retrieve a server update, the client asks the server for data, then the server responds to the client.
WebSocket offers the following benefits:
Two-byte per-message overhead (no HTTP header), which translates to lower bandwidth and faster network communications.
Both the client and the server can initiate a data transfer at any time, which means applications can be built without polling (no Comet, no AJAX). Real-time applications, hence, become more responsive. Data can be delivered to clients instantly, without waiting for client requests.
Why was WebSocket implemented instead of updating HTTP protocol?
WebSockets is better for situations that involve low-latency communication especially for low latency for client to server messages. For server to client data you can get fairly low latency using long-held connections and chunked transfer.
for more details click here
No comments:
Post a Comment