Champ

This one is floating round at work, and I can't find a definitive
answer.

I was told some time ago that HTTPS traffic was up to four times
larger than ordinary HTTP i.e. an encrypted web page is larger than
unencrypted.

Yesterday, I was told this is an urban myth.

Can anyone confirm or deny this?

--
Champ : Old enough to know better
GSX-R 1000, GPz 750 turbo, ZX-7RR Endurance Racer x 2
GYASB#0;BotToS#2;BOTAFO(T|F)#35;UKRMFBC#2;IHABWTMM J#3;MCT#5;WG*#1;BONY#40;DFV#8;IbW#17;SBS#34;BHaLC# 1
Racing : www.team-ukrm.co.uk. Vanity Publishing : www.champ.org.uk

Slider

Champ wrote:
> This one is floating round at work, and I can't find a definitive
> answer.
>
> I was told some time ago that HTTPS traffic was up to four times
> larger than ordinary HTTP i.e. an encrypted web page is larger than
> unencrypted.
>
> Yesterday, I was told this is an urban myth.
>
> Can anyone confirm or deny this?

There is a bandwidth overhead with https because more information has to
pass in either direction before you even start serving the files. However,
I think the four times argument is an urban myth. If it was that
inefficient people wouldn't use it.

--
Steve "Slider"
'02 YZF-R6

dwb

"Champ" <news@champ.org.uk> wrote in message
news:j2he40d0o7obkeuo48fq8qqp3815b0ia1j@4ax.com...
> This one is floating round at work, and I can't find a definitive
> answer.

It will be higher, but not 4 times.

Just done some very unscientific monitoring with network monitor and it
looks like HTTPS pages generate approximately 25% more network traffic then
HTTP ones.

So maybe a quarter, but certainly not 4 times.

antonye

Champ wrote:
>
> This one is floating round at work, and I can't find a definitive
> answer.
>
> I was told some time ago that HTTPS traffic was up to four times
> larger than ordinary HTTP i.e. an encrypted web page is larger than
> unencrypted.
>
> Yesterday, I was told this is an urban myth.
>
> Can anyone confirm or deny this?

It will take an initially longer period for the key to
be negotiated (remember there are actually two types of
encryption happening here - one slow but secure to pass
the key then the other uses that insecure (to transfer)
but quick to encrypt key) but once that has been done
the only overhead is the extra processing required to
encrypt and decrypt.

So yes, it will increase bandwidth but only for a short
blast at the beginning as a key is negotiated. The rest
is the same.

--
Antony. Far Up! Far Out! Far More!
Ducati 748S / 318iSE E46 Nobody Does it Better
----------------------------------------------------------
I'd rather die peacefully in my sleep like my Grandfather,
than screaming in terror like his passengers.- Jim Harkins

ozmick

Champ wrote:

>This one is floating round at work, and I can't find a definitive
>answer.
>
>I was told some time ago that HTTPS traffic was up to four times
>larger than ordinary HTTP i.e. an encrypted web page is larger than
>unencrypted.
>
>Yesterday, I was told this is an urban myth.
>
>Can anyone confirm or deny this?

As a few folks have said htpps generates a little more traffic. It
does for the first page certainly.

Where the myth comes from is typically in how https affects the
compression performance of circuits.

Typically this means modems and PPP, although VPNs now can include
compression algorithms, which is handy for some traffic.

Basically an encrypted stream will not compress very much, whereas
plain text will easily compress by 400%. In the old days when web
servers dished out a lot of text, browsers were not smart, and modems
were really slow, this was important.

These days most web stuff is images and providing the images are using
some compressed format like jpegs, compression performance really
doesn't have much effect.

If the performance is an issue, and it is if you have a dialup
community, a good web server will identify if the browser itself
supports compression on the fly - IE 5 and above i think does with
some caveats.

I can dig up some more info if you need it.

HTH.
--
Mick cbr6, mille, fof37, fot150(approx)

Simian

Champ wrote:
> This one is floating round at work, and I can't find a definitive
> answer.
> I was told some time ago that HTTPS traffic was up to four times
> larger than ordinary HTTP i.e. an encrypted web page is larger than
> unencrypted.
> Yesterday, I was told this is an urban myth.
> Can anyone confirm or deny this?

HTTPS is just HTTP over SSL or TLS, often with a couple of extra header
lines.

You'll get an x509 certificate exchange for the SSL, which will be 250-3000
bytes per certificate, depending on how much junk in in them, and there'll
probably be between 1 & 16 certificates - the usual case will 1 - 3 from
the server, and none going up stream.

There's a few hundred bytes of security version / level negotiation as well,
now I think about it.

Most http exchanges are over keep-alive connections, so the certificate
exchange will only happen once, but then many browsers open multiple
connections for each page.

So, if you're downloading a small text only page, and the server has
a long certificate chain, then it could easily be 4 times overhead, but
if you are doing normal pages from top end servery people (able to afford
close to root certificates), it'll be maybe 5%.

You'd need to do some statistical testing to really find out.

Pip Luscher

On Thu, 04 Mar 2004 19:02:17 GMT, "Slider"
<steve@somewhere.invalid.com> wrote:

>There is a bandwidth overhead with https because more information has to
>pass in either direction before you even start serving the files. However,
>I think the four times argument is an urban myth. If it was that
>inefficient people wouldn't use it.

Surely that depends on how much the security is valued over bandwidth?

--
-Pip

Champ

On Thu, 04 Mar 2004 18:25:49 +0000, Champ <news@champ.org.uk> wrote:

>This one is floating round at work, and I can't find a definitive
>answer.

Thanks for the responses.

We're thinking of making our entire site HTTPS cos the offloaded SSL
solution (Alteon) offered by a certain multinational computer
corporation (looks at Ginge) only really supports an all or nothing
mechanism.

Course, our webservers will be happy as larry, cos the encrypt/decrypt
overhead will be on separate dedicated hardware. I'm just trying to
size the impact on dialup users bandwidth, and of course the CPU hit
on their client machines.

Tests have been commissioned.
--
Champ
GSX-R 1000, GPz 750 turbo, ZX7RR Endurance Racer x 2
GYASB#0 BotToS#2 BOTAFO(T|F)#35 WG*#1 DFV#8
Team UKRM Racing : www.team-ukrm.com

Slider

Pip Luscher wrote:
> On Thu, 04 Mar 2004 19:02:17 GMT, "Slider"
> <steve@somewhere.invalid.com> wrote:
>
>> There is a bandwidth overhead with https because more information
>> has to pass in either direction before you even start serving the
>> files. However, I think the four times argument is an urban myth.
>> If it was that inefficient people wouldn't use it.
>
> Surely that depends on how much the security is valued over bandwidth?

What I mean is that if it was 4x the size of an uncompressed file, a better
algorithm would be used - not that people just wouldn't encrypt stuff.

--
Steve "Slider"
# You're in it now, I hope they throw away the key.
'02 YZF-R6

darsy

"dwb" <parc_erom@crossdata.co.uk> wrote:

>If they're sub <133 then they will probably have issues running a
>Windows-type OS [1] , let alone your web page.

what rot. I ran Windows 95 on a P75 /32Mb Ram for a couple of years -
no bother.

--
d.

'Hog

dwb wrote:
> "Champ" <news@champ.org.uk> wrote in message
> news:j2he40d0o7obkeuo48fq8qqp3815b0ia1j@4ax.com...
>> This one is floating round at work, and I can't find a definitive
>> answer.
>
> It will be higher, but not 4 times.
>
> Just done some very unscientific monitoring with network monitor and
> it looks like HTTPS pages generate approximately 25% more network
> traffic then HTTP ones.
>
> So maybe a quarter, but certainly not 4 times.

Yup, ~25% overhead gets the vote here too.

--
'Hog

darsy

"CT" <ukrm@siteline.freeserve.co.uk> wrote:

>"darsy" <darsy@sticky.co.uk> wrote in message
>news:jjqg40da9p3hnr2ghufpau5vk0gehic59o@4ax.com.. .
>> I've got a PII-266 with 256mb of RAM, and it's completely usable for
>> pretty much any "normal home use" i.e. web browsing, word processing
>> etc. It does balk at the idea of doing anything else at the same time
>> as burning a CD, though...
>>
>In which case blame the CD-burning software.

It's Nero - I've no complaints with it otherwise.

--
d.

CT

"darsy" <darsy@sticky.co.uk> wrote in message
news:jkrg40d4boo69d6mrralm8h6g760ujio9d@4ax.com...
> "CT" <ukrm@siteline.freeserve.co.uk> wrote:
>
> >"darsy" <darsy@sticky.co.uk> wrote in message
> >news:jjqg40da9p3hnr2ghufpau5vk0gehic59o@4ax.com.. .
> >> I've got a PII-266 with 256mb of RAM, and it's completely usable
for
> >> pretty much any "normal home use" i.e. web browsing, word
processing
> >> etc. It does balk at the idea of doing anything else at the same
time
> >> as burning a CD, though...
> >>
> >In which case blame the CD-burning software.
>
> It's Nero - I've no complaints with it otherwise.


I'm sure it's good as CD-burning software goes, but
I suspect it was written recently enough that the
developers assumed a pre-emptive, multi-tasking
OS with no allowance built in to it to allow other
applications any processor time.

I'm not saying that that is particularly bad these
days, mind, as most I suspect most people would be
running it on NT/W2K/XP anyway.
--
Chris

ZX-9R (in green, obviously) BOTAFOT#51

Jeremy

In article <c29r8q$1qi27c$1@ID-155023.news.uni-berlin.de>, CT says...
> "darsy" <darsy@sticky.co.uk> wrote in message
> news:jkrg40d4boo69d6mrralm8h6g760ujio9d@4ax.com...
> > "CT" <ukrm@siteline.freeserve.co.uk> wrote:
> >
> > >"darsy" <darsy@sticky.co.uk> wrote in message
> > >news:jjqg40da9p3hnr2ghufpau5vk0gehic59o@4ax.com.. .
> > >> I've got a PII-266 with 256mb of RAM, and it's completely usable
> for
> > >> pretty much any "normal home use" i.e. web browsing, word
> processing
> > >> etc. It does balk at the idea of doing anything else at the same
> time
> > >> as burning a CD, though...
> > >>
> > >In which case blame the CD-burning software.
> >
> > It's Nero - I've no complaints with it otherwise.
>
>
> I'm sure it's good as CD-burning software goes, but
> I suspect it was written recently enough that the
> developers assumed a pre-emptive, multi-tasking
> OS with no allowance built in to it to allow other
> applications any processor time.
>
I have Roxio Easy CD Creator 5 (bundled on the PC when I bought it) -
burning CDs is about the only task I have performed on the PC that
prevents anything else from running at all with brief reprieves in
between each track IIRC.

This is on a 2ghz 512mb RAM XP pro box.

--

jeremy
['75 RD250A] | ['02 Fazer 600 in blue]

darsy

"CT" <ukrm@siteline.freeserve.co.uk> wrote:

>I'm not saying that that is particularly bad these
>days, mind, as most I suspect most people would be
>running it on NT/W2K/XP anyway.

sure. I'm very reluctant to upgrade the OS on this particular machine,
because it's very very stable - I've had it for years, and - when it
was my main machine - spent a lot of time tuning the Windows
installation - tweaking the registry, removing unwanted stuff etc.
I've got it to the stage where it boots in about 40 seconds, which
isn't bad for a 266, but I'm particularly please with the 3 second
shutdown.

Also, I don't have any spare Windows XP or 2000 licences at the
moment.
--
d.

CT

"Jeremy" <newspostings@hazelweb.co.uk> wrote in message
news:MPG.1ab281c5b44c7e6d989af4@news.individual.ne t...
> I have Roxio Easy CD Creator 5 (bundled on the PC when I bought it) -
> burning CDs is about the only task I have performed on the PC that
> prevents anything else from running at all with brief reprieves in
> between each track IIRC.
>
> This is on a 2ghz 512mb RAM XP pro box.
>


I have the same[1] on a similar spec. machine. I just don't
like apps that take up all processing power without occasionally
yielding to allow other apps a look in now and then.

The 'multi-tasking' built into the OS itself isn't enough.

[1] Actually it's Easy CD/DVD Creater Ver 6. but 'hey'.
--
Chris

ZX-9R (in green, obviously) BOTAFOT#51

darsy

"CT" <ukrm@siteline.freeserve.co.uk> wrote:

>[1] Actually it's Easy CD/DVD Creater Ver 6. but 'hey'.

so we've found that 3 of the leading CD burning software packages all
lock up the machine despite reasonably high hardware specs. Maybe the
process of CD burning needs to be near "real time" in order to ensure
a proper burn?
--
d.

'Hog

darsy wrote:
> "CT" <ukrm@siteline.freeserve.co.uk> wrote:
>
>> [1] Actually it's Easy CD/DVD Creater Ver 6. but 'hey'.
>
> so we've found that 3 of the leading CD burning software packages all
> lock up the machine despite reasonably high hardware specs. Maybe the
> process of CD burning needs to be near "real time" in order to ensure
> a proper burn?

Surprise? Not!

--
'Hog

mups

darsy <darsy@sticky.co.uk> wrote:
> "CT" <ukrm@siteline.freeserve.co.uk> wrote:
>
> >[1] Actually it's Easy CD/DVD Creater Ver 6. but 'hey'.
>
> so we've found that 3 of the leading CD burning software packages all
> lock up the machine despite reasonably high hardware specs. Maybe the
> process of CD burning needs to be near "real time" in order to ensure
> a proper burn?

Yep, data needs to be streamed to a CDR or you get a bad burn. CD burning
software use lots of buffers to ensure that there is always data avalable
and they run constantly unlike most other stuff which runs, stops to wait
for some IO runs etc...

--
Chris (XChrislX@Xchurchstone.comX) Remove X's for address
CBR1000FL The Honda Fatblade
Yam RS200 Ring-a-Ding

Les Goodwin

On Fri, 05 Mar 2004 12:36:26 +0000, darsy <darsy@sticky.co.uk> wrote:

>"CT" <ukrm@siteline.freeserve.co.uk> wrote:
>
>>[1] Actually it's Easy CD/DVD Creater Ver 6. but 'hey'.

I got Nero 5

>so we've found that 3 of the leading CD burning software packages all
>lock up the machine despite reasonably high hardware specs.
2.4 g with 760 meg ram, does the same thing so I reckon that's 4.
> Maybe the process of CD burning needs to be near "real time" in order to ensure
>a proper burn?
thought it had summat to do with the buffer but then again
wibble flip etc. etc.


--

regards
Les