Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Trying to learn something but not sure what to Google...



Dan Ritter wrote:
> Now you need a decision-maker based on L4 or higher protocols, such as
> HTTP1.1. (Note that if you are receiving an HTTP1.0 packet, you are out of
> luck because that protocol doesn't include the FQDN in the request.) This

I think most of us can live with not supporting browsers that are a
decade+ old, though a limitation worth noting, as that may be relevant
in some cases.


> If you have a TCP packet coming in, and you do all your forwarding based
> on the TCP and IP headers, you cannot solve the problem of "where should
> this packet go" in this scenario. So you give up on *routing* (L3), and
> kick it up a level.
> 
> [This] is called a *proxy*...

And Ben Eisenbraun wrote:
> ...technology has blurred quite a bit these days.  Layer 3 switches are
> old-hat now, and routers that do deep packet inspection (i.e. look at
> the header fields of encapsulated protocols to determine how to route
> the packet at layer 3) are in use more and more.
> 
> Boundary violators, all of 'em!

Boundary violation indeed, but I think deep packet inspection used to
control layer 3 routing is a practical and efficient solution that would
probably work quite nicely for a scenario where you are doing server
selection on a consumer-grade router.

The failure scenario that comes to mind is a case where the first packet
fails to contain the Host: header. Per the RFCs, the HTTP header can
have any number of header lines, and be in any order, so you aren't
guaranteed to see that header in the first packet. (This is why an HTTP
protocol aware layer 7 solution is the strictly correct approach.)
Practically speaking, you'd probably never have this problem.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org