WebSocket: the future is here!
Today, I will briefly talk about WebSocket technology, the prerequisites for its emergence, current problems and their solutions.
Since the HTTP protocol has been designed, a lot of water has flowed away, and the time has passed when Javascript was used only for falling snowflakes in the background. Soon there was a need for additional data exchange with the server, for this they invented AJAX (first through the tags iframe and script, then invented XMLHttpRequest). However, all of these methods imply that data transfer must be initiated by the client. Of course, everyone knows the chats on infinitely loaded frames, but these are all only crutches, which also created a heavy load on the server, due to the imperfection of the tools that were used in the development. Each user ate the process on the server for themselves.
Due to security measures imposed by browser developers, iframe and XMLHttpRequest do not allow sharing data with domains other than the current document's domain. There are hacks like XhrIframeProxy, which forms the flow of data between documents using History. However, it is all sewn with white thread.
A good option is long-polling, a method in which the browser sends consecutive requests, and each request hangs until a data packet arrives in it. However, an impressive disadvantage is a large overhead in traffic and number of connections.
The main disadvantage of these methods is the complexity and dreary of the final design, which is a mixture of useful logic and low-level noodles. Thus, a person who does not have solid knowledge cannot implement data transfer initiated by the server without complications.
And so, came 2009, April 23. A draft document called “The Web Sockets API” appeared, which marked the beginning of the end of all troubles. It described an object accessible from Javascript, which has the following features:
- Origin-based cross-domain policy (security policy based on the transfer of Orgin) - that is, we can connect from any page to any server, and he will decide on his own from Orgin (document address) whether he needs this happiness.
- Low overhead traffic.
- Ability to use one connection to perform data transfer in both directions
- At the moment, is natively supported only in Google Chrome 4+ stable and Safari 5, promised in Mozilla Firefox 3.7 and IE 9.
Options:
')
1. Flash emulator (http://github.com/gimite/web-socket-js)
Cons: UG code, not everyone has a flash, some have flashblock plugins.
2. Use iframe (endless iframe loading) and long-polling (wait-re-request, ....).
Cons: Implement three different transport at the application level and to establish inter-process communication - a very non-trivial task.
Having considered the situation, I decided that I needed a framework that meets the following requirements:
- Abstraction of API from different transports (native websocket, flash websocket, comet, long-polling) both on the server and on the client.
- Asynchrony: 1 process on the server must simultaneously support multiple connections to clients.
- Javascript client should automatically adapt to the browser, the presence of Flash, the type of user connection (direct, proxy, etc.).
It was evening, there was nothing.
An example of what happened - http://loopback.su/websocket/ (if you fall, do not judge, stands under the table at home).
Server application here .
Works in all browsers up to IE 6. Server implementation - modules to phpDaemon . All together you can pull with github .
The main advantage of this approach is that you do not need to think about what kind of browser the client has, when you write a client-server application, you just write as if everyone’s WebSocket is native.
If desired, the server part can be rewritten in other programming languages.
Prerequisites
Since the HTTP protocol has been designed, a lot of water has flowed away, and the time has passed when Javascript was used only for falling snowflakes in the background. Soon there was a need for additional data exchange with the server, for this they invented AJAX (first through the tags iframe and script, then invented XMLHttpRequest). However, all of these methods imply that data transfer must be initiated by the client. Of course, everyone knows the chats on infinitely loaded frames, but these are all only crutches, which also created a heavy load on the server, due to the imperfection of the tools that were used in the development. Each user ate the process on the server for themselves.
Due to security measures imposed by browser developers, iframe and XMLHttpRequest do not allow sharing data with domains other than the current document's domain. There are hacks like XhrIframeProxy, which forms the flow of data between documents using History. However, it is all sewn with white thread.
A good option is long-polling, a method in which the browser sends consecutive requests, and each request hangs until a data packet arrives in it. However, an impressive disadvantage is a large overhead in traffic and number of connections.
The main disadvantage of these methods is the complexity and dreary of the final design, which is a mixture of useful logic and low-level noodles. Thus, a person who does not have solid knowledge cannot implement data transfer initiated by the server without complications.
Was ist das?
And so, came 2009, April 23. A draft document called “The Web Sockets API” appeared, which marked the beginning of the end of all troubles. It described an object accessible from Javascript, which has the following features:
- Origin-based cross-domain policy (security policy based on the transfer of Orgin) - that is, we can connect from any page to any server, and he will decide on his own from Orgin (document address) whether he needs this happiness.
- Low overhead traffic.
- Ability to use one connection to perform data transfer in both directions
- At the moment, is natively supported only in Google Chrome 4+ stable and Safari 5, promised in Mozilla Firefox 3.7 and IE 9.
What are the alternatives to support all browsers?
Options:
')
1. Flash emulator (http://github.com/gimite/web-socket-js)
Cons: UG code, not everyone has a flash, some have flashblock plugins.
2. Use iframe (endless iframe loading) and long-polling (wait-re-request, ....).
Cons: Implement three different transport at the application level and to establish inter-process communication - a very non-trivial task.
Chip and Dale to the rescue
Having considered the situation, I decided that I needed a framework that meets the following requirements:
- Abstraction of API from different transports (native websocket, flash websocket, comet, long-polling) both on the server and on the client.
- Asynchrony: 1 process on the server must simultaneously support multiple connections to clients.
- Javascript client should automatically adapt to the browser, the presence of Flash, the type of user connection (direct, proxy, etc.).
It was evening, there was nothing.
An example of what happened - http://loopback.su/websocket/ (if you fall, do not judge, stands under the table at home).
Server application here .
Works in all browsers up to IE 6. Server implementation - modules to phpDaemon . All together you can pull with github .
The main advantage of this approach is that you do not need to think about what kind of browser the client has, when you write a client-server application, you just write as if everyone’s WebSocket is native.
If desired, the server part can be rewritten in other programming languages.
Source: https://habr.com/ru/post/94921/
All Articles