Hello I was wondering during the development, what are the differences between the types of protocols that I can use for my endpoint? the latest SDK had, HTTP, HTTPS, UDP and TCP. I certainly understand what the differences between the http and Https, I also understand the differences between the TCP and UDP.
what I don't understand what are the differences between TCP and HTTP from the development perspective?
TCP / UDP are lower level protocols in the OSI model than HTTP/ HTTPS. Actually HTTPS is combining two thing, HTTP over SSL.
Have a read through the Wikipedia article describing the Osi Model
HTTP is a layer 7 (Application) protocol and as such has a strict set of rules governing how the messages are constructed and what are considered valid responses. It is not concerned with how the actual connection takes place or how the messages are routed.
TCP and UDP are layer 5 which means they are concerned with addressing, establishing connection, packetization and sequencing. Things that are needed to exchange a series of bytes (payloads) between two endpoints.
Usually when developing software you want to implement open and established protocols that simplify the task of integrating with systems from other vendors or opening up end points for others to consume. In this scenario, HTTP or HTTPS make sense.
If your system is a closed one where you control both the client and server applications or where performance is of paramount importance then TCP might be a good choice. Operating at this level means you have to concern yourself with issues of defining your own payload structure, security, packet loss etc.
Related
I have recently been trying to learn the basics of the TLS protocol, and I am unsure about how TCP packets containing TLS data can be differentiated from those that don't.
Can someone please provide an explanation?
TCP - the Transmission Control Protocol - is the underlying protocol of many higher level protocols; it doesn't specify what it transports. It turns a best effort packet protocol (IP) into a two way connection that can transport any stream of data.
TLS - the Transport Layer Protocol - provides security on top of a protocol such as TCP. It has a specific protocol description where the handshake records can easily be distinguished.
However, as indicated, TCP may transport any data. So if you have a protocol that is, say, one bit different from TLS then it won't be easy to detect this small change. However, tools such as WireShark are pretty capable of detecting protocols with high certainty.
Separate data records are harder to detect, as encrypted data packets don't contain much distinguishing features. Encrypted data itself looks like random data by definition. So if you just have a few packets then you have just some structure and otherwise random data. Now such random data is probably encrypted, but other than that it isn't much use for determining the protocol.
I am having trouble understanding the difference between net.createserver and http.createserver in node.js.
I have read the documentation for both methods located at these two urls
https://nodejs.org/api/net.html#/net_net,
https://nodejs.org/api/http.html#/http_class_http_server.
I understand that http.createserver creates an http server. However, the documentation says that net.createserver creates a tcp server. I understand that tcp is the transmission protocol that http is on top of and that http servers are set up to read http request headers. I also understand the concept of even emitters in node.js pretty well. However, I don't understand this notion of a tcp server and why one would be made in node.js. The context is I am coding a chat application example in the "node.js in action" book.
http.createServer() sets up a server that handles the HTTP protocol, which is indeed transmitted over tcp. net.createServer() creates a server that simply understands when a TCP connection has happened, and data has been transmitted, and so on, but doesn't know anything about whether a valid HTTP request has been received, etc.
If you are writing a web server, favor http.createServer() over net.createServer() as it will save you a lot of work. If you are writing some other kind of server, do not use http.createServer().
I don't know much of a Node.js, but I know something about networks. HTTP is a protocol that works on 7th (Application) layer of model OSI. TCP is protocol that works on 4th (Transport) layer of model OSI. As you said, yes HTTP works on top of the TCP. The option of creating HTTP server by http.createServer() is there so you don't have to implement it by yourself by using net.createServer(). The protocol TCP might by used by lot of applications, you might create your own, or implement some different protocol than HTTP, for example: FTP, DNS, SMTP, Telnet and much much more.
Straight from the Node Net documentation. NET is the basic bare-bones server you can create. It's particularly useful for setting up a cluster of servers and allows simple connections but on that you'll want communication protocols, namely HTTP, which HTTP is in fact a NET server at it's core.
The net module provides an asynchronous network API for creating stream-based TCP or IPC servers (net.createServer()) and clients (net.createConnection()).
And from the HTTP documentation. HTTP is the common way to transmit large sets of data as requested by the client and then a response is generated. It's the standard way of communicating over the internet and introduces the concept of handshakes and is done through REST protocol, you know the usual request and response way of communicating.
The HTTP interfaces in Node.js are designed to support many features of the protocol which have been traditionally difficult to use. In particular, large, possibly chunk-encoded, messages. The interface is careful to never buffer entire requests or responses — the user is able to stream data.
Websockets are an upgrade over the HTTP headers and offer low latency and less server load and are a much more minimal conversation. If you're talking peer to peer communication, that's the way you'll want to go.
We are working on a game with millions of clients communicating with our servers. These games are for the most part turn-based. I am aware that UDP offers some performance advantages over TCP, but I'm wondering if one protocol enjoys a security advantage over the other? I've read some sites indicating that TCP will generally be safer, but I've seen a significant number of attacks that exploit weaknesses in TCP.
Our code is pretty tolerant of unreliable connections and lost/out-of-order data, which is why I thought of UDP. Thank you!
The big security problem with UDP is that you are susceptible to spoofing and DOS attacks. It's not possible to spoof an address across the internet using TCP since the handshake will never complete. OTOH with UDP there is no implicit handshake - any session maintenance must be done by your code (processing overhead).
I am aware that UDP offers some performance advantages over TCP
Only across a LAN - part of the reason is the decreased latency of not having to carry out a handshake - but the big difference is that it bypasses congestion control mechanisms. That's not an issue for data across a LAN where the packet loss will be very low - but if you want to send data across the internet you're going to have to implement bandwidth throttling, error recovery and congestion control in your application (more processing overhead). While you can handle some types of packet loss via forward error control, this won't help with an overloaded router. All that stuff which slows down UDP is there for a reason.
If your dataflows are not more than, say 2 MSS in any direction followed by an acknowledgement from the remote end, then go for it - but if you want to move a lot of data quickly use TCP (or a station wagon).
This is a good resource to compare UDP and TCP : http://www.skullbox.net/tcpudp.php.
Traditionally,most real-time applications use UDP eg:VOIP.I am not an expert on Security,
but I guess both of them are equally secure/unsecure.It depends on usage of Security protocols like TLS etc.
TCP just has mechanisms to guarantee delivery of packets.
I know p2p software like Skype is using UDP hole punching for that. But what if one of the clients is a web browser which needs to download a file from another client (TCP connection instead of UDP)? Is there any technique for such case?
I can have an intermediate public server which can marry the clients but I can't afford all the traffic between these clients go through this server. The public server can only establish the connection between the clients, like Skype does, and that's all. And this must work via TCP (more exactly, HTTP) to let the downloading client be a web browser.
Both clients must not be required to setup anything in their routers or anything like that.
I'll plan to code this in C/C++ but at the point I'm wondering if this idea is possible at all.
I previously wrote up a very consolidated rough answer on how P2P roughly works with some discussion on various protocols and corresponding open-source libraries. You can read it here.
The reliability of P2P is ultimately a result of how much you invest in it from both a client coding perspective and a service configuration (i.e. signaling servers and relays). You can settle for easy NAT traversal of UDP with no firewall support. Maybe a little more effort and you get TCP connectivity. And you can go "all the way" and have relays that have HTTPS listeners for clients behind the hardest of firewalls to traverse.
As to the answer of your question about firewalls. Depends on how the Firewall is configured. Many firewalls are just glorified NATs with security to restrict traffic to certain ports and block unsolicited incoming connections. Others are extremely restrictive and just allow HTTP/HTTPS traffic over a proxy.
The video conference apps will ultimately fallback to emulating an HTTPS connection over the PC's configured proxy server to port 443 (or 80) of a remote relay server if it can't get directly connected. (And in some cases, the remote client will try to listen on port 80 or port 443 so it can connect direct).
You are absolutely right to assume that having all the clients going through a relay will be expensive to maintain. If your goal is 100% connectivity no matter what type of firewall the clients is behind, some relay solution will have to exist. If you don't support a relay solution, you can invest heavily in getting the direct connectivity to work reliably and only have a small percentage of clients blocked.
Hope this helps.
PeerConnection, part of WebRTC solves this in modern browsers.
Under the hood it uses ICE which is an RFC for NAT hole-punching.
For older browsers, it is possible to use the P2P support in Flash.
I need an EXPERT opinion please, and sorry if my question itself is a confused question.
I was reading around about structure of VOIP applications (Client/Server). And mostly UDP is recommended for voice streams. I also checked some voicechat applications like paltalk and inspeak and their sites mention they use udp voice stream which dont seem correct for below reasons.
I examined the traffic/ports used by paltalk and inspeak. They have UDP and TCP ports open and using a packet sniffer i can see there is not much UDP communication but mostly it is the TCP communication going on.
Also as far as i know, In UDP Protocol server can not send data to a client behind NAT (DSL Router). And "UDP Braodcast" is not an option for "internet" based voice chat applications. THATS WHY YAHOO HAVE MENTIONED in their documentation that yahoo messenger switch to tcp if udp communication is not possible.
So my question is ....
Am i understanding something wrong in my above statements ?
If UDP is not possible then those chat applications use TCP Stream for voice ?
Since i have experienced that TCP voice streams create delay, No voice breaking but Delay in voice, so what should be the best structure for a voice chat server/client communication ?
So far i think that , if Client send data as udp packets to server and server distribute the packets to clients over TCP streams, is this a proper solution ? I mean is this what commercial voicechat applications do ?
Thanks your answer will help me and a lot of other programmers .
JF
UDP has less overhead (in terms of total packet size), so you can squeeze more audio into the channel's bandwidth.
UDP is also unreliable - packets sent may never be received or could be received out of order - which is actually OK for voice applications, since you can tolerate some loss of signal quality and keep going. a small amount of lost packets can be tolerated (as opposed to downloading a file, where every byte counts).
can you use TCP? sure, why not... it's slightly more overhead, but that may not matter.
SIP is a voice/media standard that supports UDP and TCP. most deployments use UDP because of the lower overhead.
The Skype protocol prefers UDP where possible, and falls back to TCP.
in SIP situations, the NAT problem is solved by using a nat keep-alive packet (any request/response data) to keep the channel up and open, and by exploiting the fact that most NATs will accept replies on the same source port the connection was opened from... this isn't foolproof, and often requires a proxy server mediating the connection between 2 nat'd peers, but it's used in many deployments.
STUN, TURN, and ICE are additional methods that help with NAT scenarios, and especially in p2p (serverless) situations.
info regarding NAT issues and media:
http://www.voip-info.org/wiki/view/NAT+and+VOIP
http://en.wikipedia.org/wiki/UDP_hole_punching
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html
if you're implementing a voice service of some kind, a system like FreeSwitch provides most of the tools you need to deliver media to distributed clients:
http://www.freeswitch.org/
I see the question is 3 years overdue, but I see no answer accepted, so I'll take a shot at it
1- your statements are correct
2- correct, TCP or UDP can be used for audio stream.
3- Combining tcp and udp for the audio stream is not useful. If UDP is working for transmission to the server, it will work for reception, that's how all NAT firewalls work, i.e they send datagram received from internal host to remote host after they change the ip header to make the packet seem coming from them, and when they receive response, they forward it back to internal host. The difference between NAT firewalls is for how long the NAT tunnel will remain alive, but this does not matter for the audio part of the call, as there is constant flow of audio in both way during a call. This would matter more for the signalling part of the call, which uses the SIP protocol. So I would recommend using TCP for SIP as the TCP session has a default timeout of 900s, making the keep alive messages less frequently needed.
Now some applications you mentioned do not use SIP for session initiation, and hence have proprietary ways of signalling.
Other applications take advantage of something called 'hole punching' to allow client-to-client direct communication (or peer-to-peer) such as Skype. The advantage of these is that the server does not stay in the middle of the voice stream, and this can effectively reduce latency, making TCP a potential choice for the audio stream.
The guys behind development of Asterisk, the famous opensource PBX, have realized the problems in SIP which require having lots of ports open, and they have developed their own protocol, called IAX, to transmit signalling and media over one port. I would encourage you to consider implementing IAX for your client/server, because it ensures that if a client is able to connect (through signalling), then it's able to make calls.