As browsers and servers implement Http3, a lot of TCP communication will move over to UDP (QUIC).
However, it is not clear to me whether the UDP based communication primitives will be available from within the browser itself. Meaning, like one can do Ajax requests today through javascript, will browser javascript support UDP requests? Or better, large messages over UDP reliably (with necessary encryption built on top of UDP via the wrapping QUIC of course)?
This will simplify peer to peer browser communication and open up many innovative applications. Today these need to take the cumbersome STUN/TURN and WebRTC (which also uses UDP underneath) routes.
But then direct UDP has other issues, especially security concerns.
Thanks in advance.
... like one can do Ajax requests today through javascript, will browser javascript support UDP requests?
Ajax is still HTTP and not plain TCP. Ajax will continue to work and will transparently use HTTP/3 if available.
... Or better, large messages over UDP reliably (with necessary encryption built on top of UDP via the wrapping QUIC of course)?
Similar, large messages which until now used HTTP/1 or HTTP/2 over TCP will now transparently use HTTP/3 over UDP.
This will simplify peer to peer browser communication and open up many innovative applications. Today these need to take the cumbersome STUN/TURN and WebRTC (which also uses UDP underneath) routes.
No, it will not help with this. HTTP/3 will not provide plain UDP connections the same as HTTP/1 and HTTP/2 did not provide plain TCP connections.
Related
Aside from Java Applet, is there anyway we can read from an UDP socket?
I know websockets are TCP sockets, but I need to communicate with a server via udp sockets, anything in HTML5, or anything at all?
I have looked at this post from: two years ago and this one as well again from two years ago no UDP.
I was wondering if there is any new way now that we are in 2013 to use the browser to communicate with a server via udp socket?
What you are looking for can't be done with in Javascript due to security constraints such as Distributed Denial of Service (DDOS) attacks. The closest technology available (that I know of) for client-side JS is WebRTC.
With WebRTC you can use DataChannels over SRTP and ICE as a possible solution.
See Also:
How to send a UDP Packet with Web RTC - Javascript?
Can I use WebRTC to open a UDP connection?
You can use both TCP and UDP connections with the chrome.socket API, but this is only for Packaged Apps (i.e. apps that are bundled in a container to be run as desktop apps).
The API was available for a while for Chrome extensions, when it was in experimental status (see this answer, from a user who works at Google and was co-presenter for Packaged Apps at Google I/O 2012)
How can I know which type of method uses websocket on Node js? UDP or TCP? And how can I change this? Or it depends on something else?
I'm using server on node.js and client on javascript. I don't which type of protocol uses my connection. I want to UDP, because this is game-server.
Thanks
Websockets are TCP. Here's a discussion of this issue in relation to gaming. There he covers websockets, webrtc (a possible choice for UDP, but complicated), quic (only in google chrome), and his netcode.io.
Is there anyway to send a UDP packet to a local port (and receive UDP packets from a local port) with Javascript?
I don't want to have to run node.js, although there is a datagram object there. I'm using IE, so can't use the Mozsockets or chrome.udp.sockets objects.
Could I host a swf in an iFrame and use flash to send from javascript (via Flash) to a local port, for example? That's the only think of so far.
Short answer: No, there is no way to do this in Javascript for security reasons.
Long answer: Some plugins support UDP communications. For example, you could use Flash's Adobe AIR's DatagramSocket. If you are interfacing with an existing API which you cannot change, this might be your only option.
However, if you are building this app from scratch and intend to deploy it on the web, I would strongly suggest that you consider a different mode of transport. Take a look at LocalStorage or Shared Workers for browser-based IPC, Websockets for asynchronous client-server communication and WebRTC for peer-to-peer communication (although support for this standard is still a work in progress). This will allow you to support Apple devices and Linux as Adobe drops flash support on the platform, as well as provide better security guarantees than Flash or Java applets.
Aside from Java Applet, is there anyway we can read from an UDP socket?
I know websockets are TCP sockets, but I need to communicate with a server via udp sockets, anything in HTML5, or anything at all?
I have looked at this post from: two years ago and this one as well again from two years ago no UDP.
I was wondering if there is any new way now that we are in 2013 to use the browser to communicate with a server via udp socket?
What you are looking for can't be done with in Javascript due to security constraints such as Distributed Denial of Service (DDOS) attacks. The closest technology available (that I know of) for client-side JS is WebRTC.
With WebRTC you can use DataChannels over SRTP and ICE as a possible solution.
See Also:
How to send a UDP Packet with Web RTC - Javascript?
Can I use WebRTC to open a UDP connection?
You can use both TCP and UDP connections with the chrome.socket API, but this is only for Packaged Apps (i.e. apps that are bundled in a container to be run as desktop apps).
The API was available for a while for Chrome extensions, when it was in experimental status (see this answer, from a user who works at Google and was co-presenter for Packaged Apps at Google I/O 2012)
How do you send a UDP Packet using Web RTC?
You can't send a UDP packet directly with WebRTC. That would violate the basic security constraints required by the browser.
You can send SRTP to an ICE-enabled host. That is probably not what you are looking for.
If a browser permitted sending arbitrary UDP packets, then malicious applications could send packets to any host.
This might not sound so bad, after all, hosts on the Internet need to be able to deal with that right? The problem is that some browsers are in protected environments where access to the network is restricted. Within those networks, some hosts are far less protected than a host on the public Internet might be. This would be OK, since access to the network is controlled.
If it were possible for a browser to send arbitrary packets, a user on a browser in that environment could be convinced to send specifically crafted packets to one of these poorly protected hosts. Likely, that would result in the network operator banning the browser, which is something browser-makers want very much to avoid.
WebRTC only sends certain types of UDP packet under specific conditions. If the host that you are interested in talking to understands ICE and is able to consume RTP with SRTP or SCTP over DTLS (unlikely methinks). Then perhaps you could force the browser to send something.
You should check sipml5, http://code.google.com/p/sipml5/
get the code and look into the folder:
sipml5/src/tinySIP/src/transports
#Martin Thomson has explained the problem very well. By taking
motivation from his post, this post might provide guidance to some
geeks and newbies.
It is being said that WebRtc is Real-time, Bi-directional, Secure communication between two or more peers. I will more focus on the word: Secure.
Security policies of enterprise networks typically require filtering of incoming unsolicited traffic, blocking certain protocols, and doing application-level filtering and scanning for spam, malware, and intellectual property.
Now two new questions come to mind;
Why is TCP traversal not problematic?
Why is UDP traversal problematic?
Why is TCP traversal not problematic?
TCP clearly indicates two things;
The beginning of a flow (SYN) and,
The end of a flow (FIN or RST).
This is used by firewalls to open and close pinholes. Exceptionally, a TCP connection that has received no traffic for a long time also has its pinhole closed (to accommodate network topology changes or failure of both TCP peers). Firewalls also perform protocol validation to clean up problems with
Out-of-window TCP segments and,
Overlapping TCP segments
This allows the firewall to protect the network and protect hosts from
several attack vectors (replay attacks, host IP address probing, DDOS
attack, etc.).
Why is UDP traversal problematic?
For UDP flows, the first outgoing packet on a 5-tuple will be used by the firewall as a start-of-session indicator. But UDP does not have an end-of-session indicator, so the firewall has only two ways to close a pinhole:
Timing out the pinhole after the interior host does not send traffic
for several seconds or
The interior host generates a fatal ICMP error.
Because there is no reliable way to determine that a session is being stopped, the firewall has a much harder job. It could implement an Application-level Gateway (ALG) and be aware of whatever semantics are imposed by the higher-level code on top of UDP.
It could also rely on a set of well-known application servers to inform it of sessions as they start and end, but that suffers from many challenges as application servers are hosted independently of the network on which they are used.
Using an ALG, a firewall can determine when the call is terminated and
close any dynamic mappings created for the media session. But the
problem is session signaling between the WebRTC application running in
the browser and the Web server that could be using TLS, in which case
the ALG no longer has access to the signaling.
Conclusion:
So, at the Application-Level Gateway, Webrtc utilizes a combination of SDP and ICE. WebRtc basically wraps UDP in such a way that
For Audio, Video Channels, WebRtc uses combinations of RTP, RTCP, SRTP over DTLS.
For Data Channels, webrtc uses the Stream Control Transmission Protocol (SCTP), defined in RFC 2960.
SCTP is a transport layer protocol that was intended as an alternative
to TCP or UDP. For WebRtc, we use it as an application layer
protocol that runs over our DTLS connection.
These protocols also come with some new protocols such as STUN, TURN. For the basic implementations of WebRtc Please follow;
WebRtc Experiments by Mauz Khan
WebRtc Experiments by Muhammad Usman Bashir
I hope this explanation might help some of the geeks. Thanks