4 ms·

This seems like X Windows protocol over HTTPS with JSON as the wire encoding. It's sad to think how much effort is spent reimplementing technologies because th

This seems like X Windows protocol over HTTPS with JSON as the wire encoding. It's sad to think how much effort is spent reimplementing technologies because the IPv4 address space wasn't large enough. If IP address space were larger, we wouldn't have needed to rely on Network Address Translation (NAT). NAT became a poor-man's firewall and effectively blocked peer-to-peer connections making it difficult to host a server at home. This incentivized early ISPs to offer only asymmetric connections that pushed users towards a consumer-only service that crippled early Internet protocols. With the World Wide Web being "the" reason people got on to the Internet in the first place, early NAT-enabled routers focused only on HTTP tunneling, so completed protocols that required inbound connections were finally killed off. Who would have thought that a small IP address space could result in a mass protocol extinction event from which only HTTP and HTML would survive....

schpaencoder 6y ago
Couldn’t agree more
zajio1am 6y ago
> NAT became a poor-man's firewall and effectively blocked peer-to-peer connections making it difficult to host a server at home. Most ISPs (with the exception of very small ones) until recently assign one public IP address per customer and NAT is done on home router. With this setup it is not hard to host a server at home - it is just one rule on router to NAT all incoming connections to that server. Many SOHO routers support such setup. Alternatively, the server can just work as a router. > This incentivized early ISPs to offer only asymmetric connections that pushed users towards a consumer-only service that crippled early Internet protocols. Asymmetric connections are offered because many last-mile technologies (like ADSL and cable modem) are asymmetric on link-level - they use different bandwidth allocations for upstream and downstream.
- Skunkleton 6y ago
  They are asymmetric because the are provisioned that way. IE it was done intentionally.
  - dilyevsky 6y ago
    This. But also majority of people are (or were, before covid and the whole wfh thing) consumers of content not producers so that uplink would have terrible utilization anyway
- akshaybhalotia 6y ago
  Not necessarily true for all countries and ISPs. Eg in India, you have to specifically request for and pay approx $55/mo for a connection with static IP whereas regular broadband connections (150 Mbps, 500 GB data, FTTH) start as low as $12/mo.
thu2111 6y ago
HTTP isn't only about NAT. Lots of protocols have a clear notion of client and server, and don't require dialback. HTTP is successful partly because it's simple and "stateless", in the sense that all protocol state is held by the client in cookies. Keeping all state in cookies+database provides some useful properties, in particular around scaling, being unfazed by IP address changes (e.g. wifi to wired), reboots of both clients and servers, version changes, hibernation/wake-from-sleep, and a variety of other things that otherwise break connection oriented protocols. Of course sometimes people screw that up in other ways, hence the popularity of "clear your cookies" as a troubleshooting tip. But overall it works pretty well. Look at the prevalence of hacks on top of SSH to create persistent sessions, to see what has to be done when you don't have that model. SSH only survives as a protocol because remote administration doesn't need to be a particularly great user experience and it doesn't need to scale, so legacy and inertia wins out. Otherwise we'd probably see a request/response protocol take over there too. X11 was always a PITA not only due to NAT but also due to institutional firewalls, e.g. universities often have enough IPs to give everyone a public IP but firewall traffic anyway to stop exploitation of vulnerable devices. So the whole "remote client connects to local server" model was not only confusing but also a poor fit for the real world internet in which centralised, professionally run servers are invariably more secure than scattered non-professionally run edge devices.

schpaencoder 6y ago

Couldn’t agree more

zajio1am 6y ago

> NAT became a poor-man's firewall and effectively blocked peer-to-peer connections making it difficult to host a server at home. Most ISPs (with the exception of very small ones) until recently assign one public IP address per customer and NAT is done on home router. With this setup it is not hard to host a server at home - it is just one rule on router to NAT all incoming connections to that server. Many SOHO routers support such setup. Alternatively, the server can just work as a router. > This incentivized early ISPs to offer only asymmetric connections that pushed users towards a consumer-only service that crippled early Internet protocols. Asymmetric connections are offered because many last-mile technologies (like ADSL and cable modem) are asymmetric on link-level - they use different bandwidth allocations for upstream and downstream.

Skunkleton 6y ago
They are asymmetric because the are provisioned that way. IE it was done intentionally.
- dilyevsky 6y ago
  This. But also majority of people are (or were, before covid and the whole wfh thing) consumers of content not producers so that uplink would have terrible utilization anyway
akshaybhalotia 6y ago
Not necessarily true for all countries and ISPs. Eg in India, you have to specifically request for and pay approx $55/mo for a connection with static IP whereas regular broadband connections (150 Mbps, 500 GB data, FTTH) start as low as $12/mo.

thu2111 6y ago

HTTP isn't only about NAT. Lots of protocols have a clear notion of client and server, and don't require dialback. HTTP is successful partly because it's simple and "stateless", in the sense that all protocol state is held by the client in cookies. Keeping all state in cookies+database provides some useful properties, in particular around scaling, being unfazed by IP address changes (e.g. wifi to wired), reboots of both clients and servers, version changes, hibernation/wake-from-sleep, and a variety of other things that otherwise break connection oriented protocols. Of course sometimes people screw that up in other ways, hence the popularity of "clear your cookies" as a troubleshooting tip. But overall it works pretty well. Look at the prevalence of hacks on top of SSH to create persistent sessions, to see what has to be done when you don't have that model. SSH only survives as a protocol because remote administration doesn't need to be a particularly great user experience and it doesn't need to scale, so legacy and inertia wins out. Otherwise we'd probably see a request/response protocol take over there too. X11 was always a PITA not only due to NAT but also due to institutional firewalls, e.g. universities often have enough IPs to give everyone a public IP but firewall traffic anyway to stop exploitation of vulnerable devices. So the whole "remote client connects to local server" model was not only confusing but also a poor fit for the real world internet in which centralised, professionally run servers are invariably more secure than scattered non-professionally run edge devices.