Monty Linden posted an update in the Technology forum. See it here: Second Life Network Architecture.

Second Life Network Architecture – 2015

Quoting:

To the left (in red) are pieces of the viewer.  To the right (in blue) are simhost/simulators and other backend services.  And at bottom (in green) are new CDN services.

Solid lines with arrowheads are communication paths, either UDP or TCP/HTTP.  Dashed lines indicate legacy communication paths that are now or soon will be deprecated, obsoleted and/or deleted.

Ball-and-stick objects between a communication path and a text label indicate a viewer debug setting and the communication path or paths that setting influences.  These, too, are in solid and dashed flavors.  The latter indicating obsolescence.  And as always, at least one error crept into my diagram.  In this case, the ‘HttpPipelining’ setting only influences mesh and texture communications.  Inventory is currently unaffected by this setting.  [Image has been corrected – ed]

Generally, things are moving in the direction of simplification and less resource conflict.  The mesh and texture HTTP traffic, which is usually the greatest load, tends to part ways with the UDP traffic a few network hops after a user’s router or modem.  Lacking TCP’s throttling mechanism, UDP often wins in a fight (give-or-take the efforts of fairness algorithms along the path).  Allowing UDP to overrun the path between viewer and simulator does still degrade the experience and the bandwidth setting remains an effective tool for avoiding this problem.

Other settings should generally be left alone.  A lot of bad advice was spread around in the community in an effort to work around throughput problems.  We’re trying to undo that history and get back on track with more typical (albeit aggressive) HTTP patterns.