lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] HTTPS support in lwip


From: Jan Menzel
Subject: Re: [lwip-users] HTTPS support in lwip
Date: Thu, 18 May 2017 16:31:18 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

Hi Sandeep!
        I've an application where about 500kb of JS-Code, webpages and other
stuff is loaded by the browser initially. This does not require more
then 2..3 connections in parallel (a pool of 4 clients was always enough).
        At the end, the buffer size required for encrypting/decrypting
transmitted/received data is something, that depends on your setup and
on configuration options commonly available. So, if you carefully
control and debug your setup you probably can run with less memory.
        Also, memory (and other resources) heavenly depends on the certificate
validation and chain length which is something you might be also able to
control.
        I agree with Simon, generic HTTPS is something that requires lots of
RAM. But if you can control your setup, you might get a way with much less.
        You may wont to check the mbedTLS webpage to get numbers depending on
the configuration you select. You might then need to multiply this
numbers by 4..6 parallel connections...

        Jan

On 18.05.2017 14:06, Simon Goldschmidt wrote:
> Sandeep wrote:
>> Could you please give me a rough figure of how much RAM it may
>> use, just to know whether it is viable in the above said system?
> 
> The most consuming part is that TLS requires 16 kByte per direction and 
> connection as encrypt/decrypt buffer.
> As modern web browsers open multiple connections (~6?), that means you need 
> >= 192 Byte only for TLS.
> 
> Of course that can be stripped down, but that's additional work to do.
> 
> Simon
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]