I understand that WebSockets are built on TCP sockets and provide more user-friendly interfaces in terms of messages completion (see for instance this SO question: Differences between TCP sockets and web sockets, one more time ).
But could this alone justify choosing websockets over TCP sockets in a context where no web browser involved? Would such a design choice make sense or should WebSocket use be restricted to 'Web' environnents only?
The main point of WebSockets is that they can be integrated into the typical HTTP infrastructure, i.e. they start with a HTTP handshake (or HTTPS with wss://) and are also designed to deal with HTTP proxies, look (initially) like HTTP and can use the same ports so that they can pass through firewalls ...
If these properties are needed than WebSockets are a good choice even outside of browsers. If these are not needed less complex protocols might be sufficient instead.
WebSockets have an advantage over a custom TCP/IP solutions, since WebSockets experience less connectivity issues.
This is especially true for TLS + WebSockets (wss://) over port 443, and it's a benefit that isn't browser (or HTTP) specific.
This is because many firewalls, bridges and other intermediaries block different TCP/IP ports or allow limited traffic to pass through. Traffic over the HTTP and HTTPS ports (80 and 443) is often allowed even in stricter environments, which improves the chance of establishing (and retaining) a connection.
Related
This is a purely curiosity-driven question about some subtle issue on the border between HTTP and TCP. I have no concrete problem to solve.
An HTTP request is done over a TCP connection, and a single TCP connection can be used for multiple HTTP requests in a row.
In principle, this means that the client can send a request on a connection before the response for the previous one arrived.
The interesting part is that such multiple requests can really end up being in the same IP packet, and theoretically even the multiple responses could be - de facto batching the requests.
I've come accross this topic while looking at the Techempower benchmarks which include a "plaintext" benchmark where 10 such requests are batched together in one send operation (the use the wrk tool to do this).
I'm wondering if this is a purely artificial hack or whether this actually happens, for instance when a browser requests mutliple resources from the same server.
Also, can one do this with the HTTP clients of common programming languages, or would one have to go to TCP sockets to get that behavior?
Sending multiple HTTP/1.1 requests without waiting for the response is known as HTTP pipelining (wikipedia link).
As you can read on wikipedia, the technique is promising but it is not enabled by default in browsers "due to several issues including buggy proxy servers and HOL blocking." Nevertheless there is support for it in major HTTP clients and servers.
The technique is not applicable to later versions of the protocol: HTTP/2 uses the TCP connection in a fundamentally different way, and HTTP/3 does not even use TCP.
We have an application that connects to a server and sends it position every 15 seconds. Now our client has asked to "upgrade" our current TCP/IP connection into WebSocket. The reason for this is he heard it used less bandwidth and he wants to diminish the 15 seconds to 1 second. (not a public application so battery drain is not really a problem)
I have already done some research and many WebSockets vs HTTP comparisons but only 2 or 3 comparisons of WebSocket vs TCP/IP.
I've already found out that :
WebSockets are basically the same as TCP/IP but TCP/IP works on a lower layer than WebSockets.
WebSockets might use less bandwidth because its protocol might be more efficient than our current protocol.
WebSockets use more resources on the server side.
My question is: is it worth it to change our existing code and make use of WebSockets instead of the good ol' TCP/IP sockets?
As you appear to know already, a webSocket IS built on top of a TCP/IP connection. It's a specific protocol built on top of TCP.
My question is: is it worth it to change our existing code and make
use of WebSockets instead of the good ol' TCP/IP sockets?
If your code already works with a TCP socket and you don't need to interoperate with a browser client and you don't need any specific features built into webSockets, then there is no reason to rewrite perfectly functioning TCP socket code.
We have an application that connects to a server and sends it position
every 15 seconds. Now our client has asked to "upgrade" our current
TCP/IP connection into WebSocket. The reason for this is he heard it
used less bandwidth and he wants to diminish the 15 seconds to 1
second. (not a public application so battery drain is not really a
problem)
Whether or not a webSocket would be more bandwidth efficient than your existing TCP connection depends entirely upon what protocol you're running now on the TCP connection. If your existing protocol is very inefficient, then you would benefit from using a more efficient protocol whether that be webSocket or something else. I'd be surprised if switching to a webSocket would reduce anything from 15 seconds to 1 second unless the implementation of what you have now is just really inefficient.
We could only really comment further on a comparison between the two protocols if we could see exactly how your existing code/protocol works. If what you have now is really bad, then switching to a professionally designed system like webSockets might help you, but there's nothing innate in webSockets that makes them more efficient than some other well designed protocol.
Some of the reasons to use a webSocket over a plain TCP connection with some other protocol on it are as follows:
When you want a browser to be able to connect to you (browsers support plain http requests and webSocket connections - that's it).
When you specifically want the message passing type of paradigm that a webSocket offers and you don't already have a specific protocol to use over TCP (in other words when webSocket saves you from having to implement your own protocol).
When you want to connect to some other type of client that can more easily and quickly use a webSocket connection than it can some other protocol or your custom protocol.
When you're trying to share a port with a web server. By their nature of being initiated via an HTTP connection that is then switched over to the webSocket protocol, webSockets can operate on the same port as an HTTP server (sharing it with the web server).
When you want the interoperability with proxies and other network infrastructure that http and webSockets provide.
What is the difference between a TCP server/Net server in vertex and HTTP server?
What are the use cases for each?
I tried googling and went through the official website, none of them have a clear explanation.
First off, in General Networking, there are 2 common types of handling connections. This can be done either over TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). The most import difference between these two is that UDP will continuously send out streams/buffers of bytes without checking to see if the network packets made it to the other side of the line. This is useful in situations where security isn't much of an issue and where speed is important. Most VoIP services (Skype, Hangouts), XMPP (chat) and even YouTube (I think) use UDP for their streaming, as it has huge gains on performances and it doesn't matter all that much if a frame made it to the other side of the line, as the person could simply repeat themselves.
TCP on the other hand, is "secure" by default. It performs several handshakes on a regular basis with the endpoint so maintain connectivity and make sure that all packets are received on the other side of the line.
Now, there are a LOT of protocols out there in the Wild Wild West called Internet.
List of TCP and UDP port numbers
As you can see, a lot of protocols support either TCP or UDP. HTTP on it's own is a TCP protocol with port 80 (as you might know). Therefore, HTTPServer is pretty much just an extension of a TCPServer, but with some add-ons such as REST. These add-ons are much welcome as HTTP processing is a pretty common use case. Without HTTPServer, you would need to declare loads of functions on your own.
There are many articles online explaining the difference between HTTP and TCP, so here is: http://www.differencebetween.net/technology/internet/difference-between-tcp-and-http/
Vert.x naturally offers the capacity to do "raw" networking at TCP level or at HTTP-level, the latter offering facilities to deal with the protocol, including decoding TCP packets into HTTTP requests, supporting the creation of HTTP responses, ...
I am having a hard time figuring the motivation behind websockets. From what I've read around the web, regular sockets are still faster and more efficient, so in short, why would I want to use websockets, when and where?
And regarding why to bother with websockets:
It's mainly because browsers only support the Websocket API in their Javascript APIs and do no provide direct TCP socket support.
This was done to prevent (possibly malicious) Javascript apps to create any kind of TCP connections which could provide them confidential information and forward it to the internet.
With Websockets Webapps can only connect to websocket servers. The websocket protocol uses an obfuscation mechanism that prevents that webapps can send any kind of raw TCP data.
Sockets are a lower level. They can work with any type of netwroking. Websockets are at a higher level. They power web servers, and drive web apps. A websocket can be made via plain sockets. It is jsut a lower/higher level thing. Websockets are more of a convience thing. They require you to write less code
I'm building web app that needs to communicate with another application using socket connections. This is new territory for me, so want to be sure that sockets are different than websockets. It seems like they're only conceptually similar.
Asking because initially I'd planned on using Django as the foundation for my project, but in the SO post I linked to above it's made very clear that websockets aren't possible (or at least not reliable, even with something like django-websockets) using the preferred Django setup (Apache with mod_wsgi). Yet I've found other posts that casually import Python's socket module for something as simple as grabbing the server's hostname.
So:
Are they really different?
Is there any reason not to use Django for a project that relies on establishing socket connections with an outside server?
To answer your questions.
Even though they achieve (in general) similar things, yes, they are really different. WebSockets typically run from browsers connecting to Application Server over a protocol similar to HTTP that runs over TCP/IP. So they are primarily for Web Applications that require a permanent connection to its server. On the other hand, plain sockets are more powerful and generic. They run over TCP/IP but they are not restricted to browsers or HTTP protocol. They could be used to implement any kind of communication.
No. There is no reason.
Websockets use sockets in their implementation. Websockets are based on a standard protocol (now in final call, but not yet final) that defines a connection "handshake" and message "frame." The two sides go through the handshake procedure to mutually accept a connection and then use the standard message format ("frame") to pass messages back and forth.
I'm developing a framework that will allow you to communicate directly machine to machine with installed software. It might suit your purpose. You can follow my blog if you wish: http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html
WebSocket is just another application level protocol over TCP protocol, just like HTTP.
Some snippets < Spring in Action 4> quoted below, hope it can help you understand WebSocket better.
In its simplest form, a WebSocket is just a communication channel
between two applications (not necessarily a browser is
involved)...WebSocket communication can be used between any kinds of
applications, but the most common use of WebSocket is to facilitate
communication between a server application and a browser-based application.
You'd have to use WebSockets (or some similar protocol module e.g. as supported by the Flash plugin) because a normal browser application simply can't open a pure TCP socket.
The Socket.IO module available for node.js can help a lot, but note that it is not a pure WebSocket module in its own right.
It's actually a more generic communications module that can run on top of various other network protocols, including WebSockets, and Flash sockets.
Hence if you want to use Socket.IO on the server end you must also use their client code and objects. You can't easily make raw WebSocket connections to a socket.io server as you'd have to emulate their message protocol.
WebSocket is a computer communications transport protocol (like TCP, HTTP 1.0, HTTP 1.1, HTTP 2.0, QUIC, WebRTC, etc.)
Socket is an endpoint for sending and receiving data across the network (like Port number)
Example of Socket:
(TCP, 8.8.8.4, 8080, 8.8.8.8, 8070)
where:
(protocol, local address, local port, remote address, remote port)
Regarding your question (b), be aware that the Websocket specification hasn't been finalised. According to the W3C:
Implementors should be aware that this specification is not stable.
Personally I regard Websockets to be waaay too bleeding edge to use at present. Though I'll probably find them useful in a year or so.