Hacker Newsnew | comments | show | ask | jobs | submit login

I'm sure I'm missing something, because Zed is smarter than me. Why is this much better than just running each of those services on different ports? How does having everything behind a single port increase flexibility? It seems like he's serving multiple services over a single port, but I thought the point of ports as a software construct were to advertise different services?



Helps with firewalls. Helps with poorly-documented services. Helps when you don't know what you're going to be running (i.e. your language/platform supports multiple sorts with a config file, and you don't want your web server to have to read that config file).

Also helps when you may be changing what you're doing. You know all that annoyance you currently do with NGinX and Apache and whatever else where you write a very cryptic config file telling it what runs on what ports and in what directories and how to serve it? I would love to do less of that. I would love to not have to change it every time I put up a new little Ruby-on-Rails toy web-app. I would love to be able to just shove a new Rails or PHP or Sinatra or Node.js project into my github repository, have a simple cron job on my server check it out into my "checkouts" directory, and then not have to configure the web server for it.

These things are doable with current servers, of course. They're just a pain and involve writing a fair bit of code to make it happen. If you could subtract the "update your NGinX/Apache/whatever config" step, you'd eliminate a fair bit of the current friction.

This is more important for hobbyists than big sites. A really flexible server will never be quite as fast as a fully dedicated server (cf Mongrel_cluster versus, say, Passenger). But for hobbyists, it could be a godsend.

Newer hobbyists won't even have to learn how to deploy a Comet/FlashSocket/Websocket server from behind a reverse-proxy. I envy that.

-----


In general yes, but as more and more technology gets added to the stack, it becomes increasingly difficult to keep everything running on port 80, which is the only port your users should have to hit on a web request. Take web sockets for instance, I have to run that on an off port because I can't run it through nginx yet.

-----


I've dealt with this by getting another IP and pointing a subdomain at it, then I can start all over again with port 80. Your point still stands for this discussion, though.

-----


That's very true. There's only so far a parser can go at keeping the protocols straight. Thankfully most protocols are designed to be really different so it's easy to do this right now. If I ran into a protocol that didn't work in this way then I'd have that on a separate port.

-----


> How does having everything behind a single port increase flexibility?

It increases reach. Millions of people are behind firewalls that only allow HTTP traffic.

-----


Port 80. This means you can make web apps that use all available protocols but only need to know about port 80. Gets through firewalls, cuts down on configuration, and it's not too hard to do in the server.

-----


Honest question: I'm not too familiar with firewalls, but do they not check for the validity of the traffic on port 80 to make sure it's actually HTTP?

-----


no, they just pass it along to the service listening on that port. How would you verify HTTPS without decrypting it?

-----


Let’s be careful here.

Yes there are firewalls/proxies which check for validity of HTTP over port 80, though others don’t bother, or just look at the first bit of traffic for each connection.

HTTPS goes over port 443, and I imagine there are some firewalls somewhere or another which block it altogether. Probably not enough of them to worry too much about though.

Some firewalls at least make sure that traffic over port 443 does a proper SSL handshake.... after that the data is encrypted, so they have no way to tell just what’s going through.

-----


So would FlashSocket traffic get blocked by these firewalls if it was trying to sneak in through port 80, then? That would kinda beat the purpose of this effort.

-----


Even if your firewall doesn't track it, you could set up an IDS system to detect and alert on it, if you were into that sort of thing.

-----


You don't need to be able to decrypt anything to identify an HTTPS flow. An unencrypted SSL/TLS handshake takes place first, before any encrypted data is sent across the wire.

Some firewalls can track this.

-----


Right. But you can still run whatever protocol you like -on top- of SSL.

-----


Hah. Good point. Thanks.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: