[FoRK] spdy

Lucas Gonze lucas.gonze at gmail.com
Thu Nov 12 16:23:09 PST 2009


Yup, I was thinking of caching proxies.  But now that you point out
that SSL != HTTPS, I realize that that's a non-problem.  Awesome.

What do you think? Is it time for basically all connections to be encrypted?

There's a CPU price, but my guess is that Moore's law has made it moot.

How about a bandwidth price?  There must be a bandwidth increase or
there wouldn't be any chaff in the stream.

On Thu, Nov 12, 2009 at 3:47 PM, Stephen D. Williams <sdw at lig.net> wrote:
> Lucas Gonze wrote:
>>
>> I think that the value is in taking a conservative and responsible
>> approach to the radical task of making improvements to HTTP.
>>
>> Within my limited understanding of their ideas, I believe they leave
>> the object model alone and keep their work within a safe zone.  The
>> one thing they are proposing that doesn't make sense at first look is
>> using SSL more extensively, since it breaks caching.
>>
>
> Does SSL necessarily break caching in the browser?  In their method, just
> because the transport is SSL/TLS doesn't mean that requests over it are
> logically HTTPS.  Or do you mean that it is an issue with caching proxies,
> transparent or not?  In the latter case, you Could (but shouldn't) use the
> fake CA certificate trick to get a (safe?) transparent man-in-the-middle.
>  This is how corporate environments that absolutely insist on seeing all
> traffic deal with HTTPS.
>
> I think that the browser should be integrated into solving this problem,
> however another solution would be to have a local proxy that does a lot of
> this and presents a standard interface locally to the web browser.  The
> other thing that they should benchmark against is using a web proxy or even
> SOX or an SSL VPN.  Those all use a single TCP connection over what could be
> a slow link.  The methods other than a true VPN should cut down on TCP slow
> start based waits.
>
> Back to their methods, on the server side, the server could learn based on
> client patterns what other requests tend to go together, for images, CSS,
> etc. and preemptively provide that data at just the right point.
>
> sdw
>>
>> On Thu, Nov 12, 2009 at 1:55 PM, Stephen D. Williams <sdw at lig.net> wrote:
>>
>>>
>>> Benjamin Black wrote:
>>>
>>>>
>>>> Lucas Gonze wrote:
>>>>
>>>>
>>>>>
>>>>> http://dev.chromium.org/spdy/spdy-whitepaper
>>>>>
>>>>> This kind of proposal is usually wildly offbase, but this looks well
>>>>> conceived.
>>>>> It reminds me of first encountering HTTP-NG.
>>>>>
>>>>>
>>>>>
>>>>
>>>> In what has become Google SOP, they have neglected some obvious prior
>>>> art, intentionally or out of ignorance.  BEEP covered a lot of this
>>>> ground, whether it came to the right answers or not.
>>>>
>>>> http://beepcore.org/
>>>>
>>>>
>>>
>>> I was thinking the same thing.  I always liked BEEP (originally BXXP),
>>> and
>>> have used it in projects.
>>> The other reinvention of the wheel is the AMQP work.
>>>
>>> Still, each new attempt pushes things forward.  I'm glad someone finally
>>> put
>>> the work into creating a working browser / web server combination.  I've
>>> been wanting this for a while.  Perhaps their code will be a convenient
>>> test
>>> bed.  In addition to the many-item-download problem, it would be great to
>>> have an automatic peer-to-peer download mechanism to make all web sites
>>> scalable.  It could be protected via Merkle trees and use bittorrent or
>>> better methods.
>>>
>>> Related concepts include W3C EXI "Efficient XML Interchange" (i.e.
>>> binary),
>>> Google Protocol Buffers, and GDATA.
>>>
>>> I agree with what is in EXI, however I have some additional ideas to
>>> avoid
>>> parsing, support deltas, and have sharable schema representations.
>>>  Additionally, I've specified the design of a binary superset of RDF for
>>> processing and size efficiency.  Back to that soon, as I'll need it
>>> shortly.
>>>
>>> Stephen
>>>
>>>>
>>>> b
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> FoRK mailing list
>>> http://xent.com/mailman/listinfo/fork
>>>
>>>
>>
>> _______________________________________________
>> FoRK mailing list
>> http://xent.com/mailman/listinfo/fork
>>
>
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork
>



More information about the FoRK mailing list