Assume I have a simple ASP.NET MVC application with an Index view that just shows some static data.
Considering the fact that the web is stateless, when a browser requests for this index.cshtml, a HTTP Get request is made and the server sends the contents of the page to the client.
In Such case is there an entity called connection? If so when can we say that connection is established?
Hope my question is clear.
A connection is established between the client (browser) and the underlying web server (IIS) prior to any invocation of your MVC application.
If you get a request in your web application, then a TCP connection has already been established and an HTTP request has been sent to the server over TCP. With keep-alive semantics, multiple requests may use the same connection, and of course multiple actions could even be called for the same request.
So basically, the establishment of a connection is not something that is particularly useful for a web application to indicate or track, if that is what you are trying to do.
The connection is estabished to the IIS Server/Process and then forwarded to .NET, so the moment IIS receives it, it's 'established'
The HTTP protocol is based on the TCP protocol. Before the GET request is made, a TCP connection must be made.
"The connection is closed" happens when the TCP connection is closed, usually after a single request/response interaction.
The connection may be kept open by using Keep-Alive.
Related
As I understand:
A port designates a program on the server.
When we say to share a port, it actually means to have the requests processed by the same program listening on that port.
The WebSocket handshake resembles the HTTP format, so it can be understood by the server program that handles HTTP protocol. So it's OK to send the handshake request to port 80.
But after the handshake, the WebSocket data format is totally different from HTTP format, how could it still be sent to port 80? Such as via URL like below:
ws://somehost:80/chat
How does it work out?
My guess:
Does the HTTP program see that the incoming request on port 80 cannot be handled as HTTP, and then it will pass it to WebSocket program to process it. If so, what if there's some other protocol that wants to share port 80, say WebSocket2, how could HTTP program know which protocol to pass on to if there's not a way to identify the protocol being used.
ADD 1
Based on jfriend00's reply, I draw the following diagram:
So WebSocket and HTTP traffic in the same browser are actually carried out through different socket connections. Though they both start by connecting to server's port 80.
I think if the word WebSocket doesn't contain a socket in it, it will be easier to understand it as just another application level protocol over TCP protocol.
ADD 2
I refined the above diagram to below based on jfriend00's further comments.
What I want to show is how WebSocket communication and HTTP communication to the same server coexist in a browser.
ADD 3
After reading this thread, I recalled that the server port doesn't change when server accept a connection: Does the port change when a TCP connection is accepted by a server?
So the diagram should be like this:
The TCP connection for HTTP and the TCP connection for WebSocket should be using different client ports.
When a server listens on a given port, it is listening for incoming connections. When a new incoming connection arrives, it is given its own socket to run on. That socket provides the connection between the two endpoints. From then on, that socket runs completely independently from all other sockets that might also be connected.
So, one incoming http request can specify the "upgrade" header and get upgraded to webSocket and then both ends agree to talk the webSocket protocol from then on. Meanwhile, other incoming http requests without that upgrade header are treated only as normal http requests.
In case you don't quite understand how the webSocket protocol works, you can get a full look at how it connects here.
Here are the main steps:
The client requesting a webSocket connection, sends an HTTP request to the server on port 80.
That HTTP request is a perfectly legal HTTP request, but it has a header included on it Upgrade: websocket.
If the server supports the webSocket protocol, then it responds with a legal HTTP response with a 101 status code that includes a header Connection: Upgrade.
At that point, both sides then switch protocols to the webSocket protocol and all future communication on that socket is done using the data format for the webSocket frame.
Any other incoming HTTP requests that do not contain the upgrade request header are treated as normal HTTP requests.
Does the HTTP program see that the incoming request on port 80 cannot
be handled as HTTP, and then it will pass it to WebSocket program to
process it.
No, the first request IS a legal HTTP request (just with a special header in it) and the response sent back is a legal HTTP response. But, after that response, both sides switch protocols to webSocket. So a custom header is used to tell the web server that this incoming HTTP request is meant to be the first step in establishing a webSocket connection.
If so, what if there's some other protocol that wants to share port
80, say WebSocket2, how could HTTP program know which protocol to pass
on to if there's not a way to identify the protocol being used.
This upgrade mechanism could be used to support other protocols too by just specifying a different protocol name Upgrade: someOtherProtocol though I'm not aware of any others that have been standardized.
Because the browser use a new port to connect and send/receive messages to/from the server.
I am building an application that is using websockets. I am only going to allow authenticated users to open a websocket connection with the server after they have logged in and have been granted a session id.
Once I have opened a websocket connection with an authenticated user, the current "page" then holds the details of the open websocket connection. At this point, is this connection relatively safe? Or should I really be checking some token on every message within my own application level protocol that comes in over the websocket?
Are there any known cross-site forgery type security issues? Where someone could coop an open websocket by getting the authenticated user to execute some javascript in some manner - resulting in the ability to exploit the open websocket connection?
1) The connection is safe, when you make it safe on the server side. So you have to send a session ID via WebSockets, verify on the server side that it is correct and mark the connection as valid. Authentication is more difficult with HTTP, because HTTP is stateless ( unlike raw TCP ). Of course it is still possible to hijack TCP connection, but it's not that easy ( see for example this article ) and if it happens, then nothing ( except for TLS ) can help you.
2) Well, if you wrap your WebSocket connection with an anonymous function like that:
(function() {
var ws = new WebSocket("ws://localhost:1000");
// some other stuff
})();
then no external JavaScript will be able to access it, so you don't have to worry about that.
I am trying to understand the purpose of websocket multiplexing extension, the main purpose what the document states is to use a single same origin physical websocket connection to the server while each browser tab uses a logical connection multiplexed on top of physical connection. I see another alternative using which we can accomplish this behavior today, the approach is to launch a shared web worker which opens the websocket connection and let each browser tab send and receive message to/from this worker. i have not tried this yet and i wonder will this work at all.
Your question reflects a misunderstanding of the problem the WebSocket Multiplexing Extension is trying to solve.
The base WebSocket spec (RFC 6455) defines a protocol for bi-directional exchange of data over TCP/IP. A WebSocket starts as a normal HTTP request / response. In this exchange, the client and server negotiate to switch to the WebSocket protocol. After the switch, the client and server exchange data frames over the TCP/IP connection. This creates a bi-directional data stream between client and server.
A drawback of the base protocol is that it supports only a single stream of data flowing in each direction. The multiplexing extension augments the base protocol, by allowing the client and server to create multiple "channels" over the same TCP/IP connection.
So the purpose of the multiplexing extension is to allow multiple WebSocket channels to run over the same TCP/IP connection. That's all.
Having multiple browser tabs (or web workers) share a single TCP/IP connection is just an example of how multiplexed websockets might be used. In standards terminology, it's just "informative" (descriptive), not "normative" (a required part of the spec).
I am would like to create a websocket server. I understand that the client will make a request and that a partially encrypted response needs to be sent back to the client. My question is does that connection need to stay open to handle the websocket messages after the connection is made. Or does the client establish a new connection after receiving the response from the server?
Thanks,
-ren
Here's an article on the websockets handshake.
And, a sample implementation of a websockets server in PHP.
The socket stays open.
The whole protocol is described in RFC 6455.
I already have a server with port and want to write a web app to get the information form the port. Will this be possible with WebPorts?
The Client doesn't even need to talk back to the server, which is the whole point of websockets I would imagine, but since I already have the ports setup, I might be easier and cleaner to just connect and get the info without having to refresh.
WebSockets are not intended as clear TCP channels over which other existing protocols can be implemented.
WebSockets are designed to allow messages to be sent between a client and server, where an event is raised each time a message is received.
Hence a WebSocket client cannot simply connect to an existing TCP server - that server also has to speak the WebSocket protocol.
You could of course write a WebSocket-based server that does nothing but act as a proxy to existing network services.
I think you want websockify which is a WebSocket to plain TCP socket bridge/proxy. It also allows sending and receiving of binary data with the older version of the WebSocket protocol which hadn't yet added direct binary data support.
Disclaimer: I created websockify.