The question is regarding Web Socket connection establishment procedure.
from RFC 6455 , i understand that WebSocket technology was developed for browser based applications to establish full duplex TCP connection with the server.
My questions,
So when we Say browser based , the only way to establish web Socket connection is using javaScripts? i.e all browser based clients can establish webSocket connection using JS?
Can we use the WebSockets URL to render webPage on the borwser? Does browsers supports?
Like typing ws://www.sample.com/login in the address bar will display login page?
Does browser understands "ws" as protocol and establishes connection and display the page?
So for my question2 i understand as, to establish a WebSocket connection from Browser, We should already have a webPage and logic in that webPage will establish the WebSocket connection. Please correct me if i am wrong.
Thanks
Pradeep
For the WebSocket API, the client-side code must be JavaScript, yes. The server-side code can pretty much be whatever language you want.
To answer your other question, the WebSocket protocols (both ws and wss) cannot be used to load a web page directly. The WebSocket protocols can only be used to establish a connection with a server-side script, which upon a successful handshake, will upgrade the HTTP connection to a WebSocket connection to reduce the headers sent between the client and server.
So, yes, in general, you should already have a web page coded separately, and then add the WebSocket logic on top of that to establish a socket connection with the server as necessary.
Related
i want to make TCP server with Node.js and then connect it from browser without http , express and socket.io moudles. something like what i do in java or c# but this time from browser.
The browser does not contain the capability for Javascript in a regular web page to make a straight TCP socket connection to some server.
Browser Javascript has access to the following network connection features:
Make an http/https request to an external server.
Make a webSocket connection to an external server.
Use webRTC to communicate with other computers
In all these cases, you must use the libraries built into the browser in order to initiate connections on these specific protocols.
There is no capability built into the browser for a plain TCP socket connection. A webSocket (which can only connect to a webSocket server) is probably the closest you can come.
I am trying to create a multi room chat application in node.js using socket.io and express. I am confused between use of server port and websocket port. I understand server port is used by the client to connect to server. But not sure about use of websocket port.
Thanks & Regards..
webSockets can share the same port as your web server and this is a common configuration. The reason this works is because of how a webSocket establishes a connection (all webSocket connections are initiated with an HTTP request). It works like this:
Client makes an HTTP request to a web server with a header specifying that they want to "upgrade" to the webSocket protocol and sends a security-related header.
Web server sees the upgrade request and, if it has support enabled for webSocket connections, it will respond with a 101 request (switching protocols) and another security related header.
Client gets the accepted upgrade and both ends switch to the webSocket protocol and the original TCP socket that started out using the HTTP protocol is now using the webSocket protocol.
In this manner, the same port and webServer can be used for regular HTTP requests or webSocket connection requests.
For a chat application it is common to use a webSocket connection because it is a continuous connection that more easily allows the server to send information directly to the client which is often needed in a chat application.
To understand more about how a webSocket connection and server work, see this reference on MDN: Writing WebSocket servers which shows the step by step process for initiating a webSocket connection.
Server socket is used by server... that keeps listening to coming sockets request in a loop... and websocket sends a request to server socket and bound a connection between two devices...
If you have / want to have web clients, WebSocket is going to be required, because there is no access to 'regular' TCP (or UDP) sockets from browser-based JavaScript (and I assume you do not want Flash, SilverLight or Java Applets, in 2017). WebSocket is not special because of the port number, but it is special because of the protocol: a WebSocket connection starts as a regular HTTP connection, and protocol upgrade reconfigures it afterwards, it is designed for the browser-world, and even capable of traversing HTTP proxies. After establishing the connection, it provides a full-duplex, bi-directional message stream, very usable for chat applications.
And because of being a Web-thing, you could simply use port 80, if you are allowed to.
Say there are 5 open tabs in a single browser, and I am using Node.js and Socket.io. The client and server exchange packets to maintain (establish) communications.
Will connection with the client be lost if of one tab is closed?
How can I determine if the user closed the browser?
Yes, socket.io establishes a new connection with every tab. You're going to want to look into using session cookies to figure out which user the current socket.io connection is communicating with.
I basically want to know if its possible to use Socket.io using the server-side only with no client side? BUT I want to know if my server-side can instead connect with a different site that I cannot use Socket.io to connect to.
Use PhantomJS to load the third-party site and then inject your own javascript into the page to catch events and send those events back to your own server.
socket.io is a two-way connection. Client <--> Server. You must have a socket.io endpoint at both ends to even establish a connection in the first place. And, then once you establish the connection, you must have agreed upon messages that can be exchanged between the two ends for it to do anything useful.
It is not useful to have a server-side socket.io that doesn't actually connect to anything and nothing connects to it. It wouldn't be doing anything, just sitting there waiting for someone to connect to it.
It is possible to have two cooperating servers connect to one another with socket.io (one server just acts like a client in that case by initiating the connection to the other server). But, again both endpoints must participate in the connection for the connection to even be established and certainly for it to do anything useful.
If you just want to download the contents of a site for scraping purposes, then you would not use socket.io for that. You would just use the nodejs http module (or any of several other modules built on top of it). Your server would essentially pretend to be a browser. It would request a web page from any random web server using HTTP (not socket.io). That web server would return the web page via the normal HTTP request. Your receiving server can then do whatever it wants with that web page (scrape it, whatever).
I've just started learning SSL and boy is it confusing
Q1 - How long does SSL connection between a client and server persist? Until client surfs to some other URL or…?
Q2
A) Assume a client (browser) establishes a SSL connection with a IIS server.
Now how does IIS figure out on each postback that it is dealing with same authenticated client/browser and thus that it already has a SSL connection established with that client?
B) Assuming SSL connection isn’t lost if browser surfs to some other URL:
Suppose that moments after SSL connection is established, client surfs to some other URL, and shortly there after it again requests ( via https ) the original page ( one with which it has SSL connection established).
How will IIS server be able to figure out that current request for a page comes from a client that already has SSL connection established with that page and thus will use already established SSL connection?
thanx
EDIT:
Assuming browser surfs to some other URL and if on returning back to original page the SSL connection is still established, how will browser "remember" the value of symetric encryption key, which the two sides used for communicating?
I realize it depends on what browser you use, but with IE and Firefox, I assume when you close a browser, it sends Connection.Close() ( or something to that effect ) to the server and thus SSL connection is immediately closed?
But if you browse away to some other URL, then if browsers doesn't send any notification to the server, wouldn't then SSL connection remain established for quite some time ( even 10 or more minutes ) and thus browser could easily surf back to that page as if nothing happened?!
I appreciate it
Q1. The SSL connection is only good for a single TCP connection between the client and the server. Current browsers (anything with HTTP/1.1 support) can reuse a single connection for downloading multiple resources. Current browsers also make multiple TCP connections to a server in order to download multiple resources in parallel. Because of this, you'll see multiple SSL connections for one page view.
Q2A. If the browser still has a TCP connection open with that server, it can reuse that connection. Otherwise, a new TCP connection with SSL and IIS authentication is negotiated.
Q2B. Same as Q2A. You can't depend on this, but the TCP connections won't be disposed of immediately. There's a chance you could reuse an existing one depending on your browser.
A1. An SSL connection persists until either the client or server closes it. When that happens depends on the protocol being used. For HTTP, most modern clients will make a few parallel connections to the server to fetch the page and its resources, and reuse those connections until the page is loaded.
A2A. The client must authenticate itself on each request if the authentication uses HTTP auth. If the client is using SSL certificate authorization, then this is obviously maintained on a per-connection basis so that subsequent requests on the same connection retain the same credentials.
A2B. The server would know this because presumably the request would come in on that already established SSL connection.
post-edit answers:
What I think you may be missing is that SSL is linked intrinsically to TCP. You cannot have an SSL "connection" to the server that doesn't ride on top of a TCP connection. You break one, you break the other.
Most SSL implementations include "shortcut" negotiation where subsequent new connections can leverage the public key encryption that has already taken place and instead directly use the most recently negotiated symmetric key. The details of this, however, are hidden within the SSL implementation. From the point of view of the user and/or client software, the fiction is maintained that the entire negotiation took place just like it did on the first connection.
If the SSL connection is still established, then it follows that the symmetric key information is still maintained on both ends.
Yes.
Yes, although it would be improbable for the client to keep a connection to a server once it has navigated away to some other site.