In this article we will go through all the Networking requirements Modern Web Browsers and applications can have and what possible issues might come up with each one of them.
Introduction on how the Internet Works
Let’s start from the basics, machines and applications on the Internet communicate through a set of protocols, the most common of which is TCP. TCP is a transactional protocol that ensures that one packet of information sent from one machine to another will get there or the sender will receive an error. The second most common protocol is called UDP, UDP is not transactional, meaning the client will never know if the packet of information that it has sent will ever reach the other party or not.
Both TCP and UDP use what are named as “ports”, ports are numbered from 1 up to 65,535 and they exist so a single machine can accommodate multiple simultaneous connections by selecting a different port each time. Typically a server listens to a port and a client makes a request to that port. If you want to read more about TCP and UDP you can dive into this very insightful article.
Understanding Firewalls and QoS
A firewall is a machine (it can also be a software) whose job is to apply the security policy of the organization it belongs to. Firewalls typically exist in business, enterprise and large organization environments and what they essentially do is block certain Internet connectivity due to security or other concerns.
QoS stands for Quality of Service and is a more delicate operation where the organization (or Internet Service Provider) prioritizes certain services over others or traffic shapes parts or the whole of your connection. Prioritizing can be good in a limited network by giving priority to video / audio streaming services and lowering the priority on less real-time services like email. Traffic shaping is the act of forcefully lowering the available connection bandwidth a client has, compared to the total capacity of the network, this can be useful in cases where many clients have to share a low bandwidth Internet line.
Network Resources a Browser Uses
World Wide Web Protocol
The World Wide Web (otherwise known as Web) uses TCP port 80 for non-encrypted
http itself is a protocol on top of TCP and implements what we today know as the web. For secure, encrypted communications (
https) the TCP port 443 is used. These two ports, 80 and 443 have been established since the very first time the first web server was implemented.
It is often the case in large organizations to block all Internet connectivity except the specific few services an organization needs to have to operate, which in most cases is the Web and the 80 and 443 ports. In some extreme cases we have observed organizations closing port 80 all-together for security concerns as communications through
http are not encrypted and thus can easily be intercepted by a third party who can eavesdrop on our communications.
Connectivity for the web can be very easily assessed as the client will either be able to load our website or not.
The Websocket Protocol was introduced in 2011 and it was the first protocol to be standardized by the IETF organization which makes it an Open Standard. It too uses the same ports as the Web, TCP port 80 and 443 but it uses a different protocol of communication and the only relation with HTTP is the request a Websocket client makes to the webserver to Upgrade the connection to the “Websocket Protocol”.
A Websocket is an always-on, full-duplex communication between the client (browser) and the server. So each time a Websocket connection is established the client has a direct communication to the server without the connection overhead and vice versa. The connection overhead that I mentioned refers to the way both TCP and HTTP protocols work, they both have lengthy handshake processes in order for a connection to be established, a resource requested and served.
Websockets slash through all that overhead by retaining the connection open throughout the whole duration of a client’s session. As a result of this it is a much faster way to communicate between the client and the server and it has the additional benefit of allowing the server to push (send) events to the client and notify them of new messages they have or any other type of action performed on the server by another user.
Websockets generally work, except when they don’t. Because of their persistent nature Websockets have been observed to not work on many cellular networks, it is simply not possible to establish a websocket connection when you are on specific cellular networks. This happens regardless of the client, it can be a mobile device or any type of PC or laptop, the problem is down at the network level.
Websockets also do not survive through strict firewall setups, they behave strangely by either not being able to establish a connection at all or having the connection drop after a while.
All in all, websockets are good as long as they work but a business should not use them for mission critical operations unless it’s prepared to loose a small percentage of its connections with whatever consequences that might have. In cases where this is not acceptable web service should implement fallback solutions like XHR Long Polling which is a technique where the browser performs a background HTTP request to the server but will leave the connection open until it timeouts, when timeout occurs the client reconnects and waits again, in effect having a constant connection to the server.
WebRTC is a rather new protocol which allows Video and Audio Real Time Communications between two or multiple clients of the web using only their browsers. It has been pioneered by Google and Mozilla and has been implemented experimentally on their respective browsers (Chrome and Firefox). It is expected to become an open standard in 2016 by IETF and W3C.
The WebRTC protocol is the most demanding one yet. For a WebRTC call to be performed a very complex handshaking operation is required. The two or more clients that need to perform a call need to go through multiple tests between them and the Webserver so as to determine which connectivity protocol and port should be used.
WebRTC can use both TCP and UDP (UDP is preferred in this case) and will attempt to connect and accept connections from the other clients in non-privileged ports which are from 1,025 up to 65,535. As you can safely assume by now, WebRTC will most likely not work behind big organization’s firewalls as they actively block anything that is not web (ports 80 and 443).
In a previous article of ours we go through how WebRTC works and understanding WebRTC’s connectivity, it’s definetely worth your time if you are using this technology.
Third-Party plugins and extensions
A user might select to install certain plugins or extensions to their browser. These plugins can have different networking requirements to work, like the Flash plugin from Adobe which has a proprietary protocol named Datagram Socket and uses UDP and a special server for communicating. As these plugins and technologies are not of the standard Web and they no longer have any significant install base or use on today’s Internet we will not dive into them.