Connectivity
Construct 2's multiplayer engine is based on WebRTC DataChannels. This is a peer-to-peer browser networking technology. Players connect directly to each other, rather than going through a central server.
Despite the fact players can connect directly to each other, the games themselves are still based on a server with clients. The first peer to join a game becomes the host. All the subsequently joining players then connect to the host only. The non-host players are called peers. The host acts as the server for the game. The key difference with central servers is that the host can be anyone joining the game, rather than an always-on server run by the game developer. Also, the host can be an active participant in the game, whereas central servers often just blindly run the game for other players.
It's still possible to use central servers though: you can design your game so the host is not a participant, and leave it running on a dedicated server. However this requires paying for the server hosting, so the peer-to-peer approach is likely to be cheaper.
For a joining peer to be able to connect to the host, it needs to know where they are and how to connect to them. This involves finding out their IP address, finding out if they have a router that restricts connections, and working around those restrictions if possible.
Restricted routers are very common. The Internet ran out of IPv4 addresses several years ago. The workaround is to hide multiple users behind one IP address. This is done by Network Address Translation (NAT). For example in your own home or office, there may be a router that everyone on the internal network connects to the Internet through. In this case, one variant of NAT would make everyone appear to come from the same IP address, but over different ports. There are several other variants of NAT, including large scale NAT applied to entire regions, ISPs, or mobile networks, and some are more restrictive than others. Unfortunately this means in some cases connections are not possible, particularly if both the host and the joining peer are behind highly restrictive NAT. However with common setups players can usually connect to each other, and generally the closer they are geographically the more likely the connection is to work and provide good quality service. This is one reason it's good to encourage players join other players from at least the same continent.
Connectivity is handled automatically by WebRTC. It will try to determine how to connect to the host working through NAT restrictions. This also means there is no specific port that the games run over; it runs over whichever ports WebRTC finds are working. For example in the above diagram, three clients share one IP address, so a peer on the other side must connect to that IP address over port A to reach the first client, or port B to reach the second client, and so on. However bear in mind that in some cases two users will not be able to connect to each other, and it may be necessary to find another player to act as the host.
IPv6 is gradually gaining adoption over the Internet with a vastly bigger address space. This will enable every device connected to the Internet to have a unique IP address again, making NAT unnecessary and allowing connections between anyone regardless of their networking setup. Until that happens, connectivity problems are an unfortunate consequence. Google also publish statistics on the adoption of IPv6.