- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Testing with FreeRTOS+LwIP build on 43438.
Compare to TLS-v1.1, the TLS-v1.2 https request throughput is very bad.
The number of https request sent per minute with TLSv1.1 is 14 times of TLSv1.2.
In additional, when ble scan and sending https request at the same time,
the device will hang if using TLS-v1.2.
- Labels:
-
Wifi+Bluetooth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
axel.lin_1746341 wrote:
In additional, when ble scan and sending https request at the same time,
the device will hang if using TLS-v1.2.
After doing more testing, I believe TLS-v1.2 can block BT thread when connecting to http server.
This is a problem because if BT thread is blocked for some reason it run into GKI_exception.
I check it by checking the BLE scan result.
While TLS-v1.1 looks fine with the same test.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which HTTP library did you use for testing? Do you have a sample application code to share? It will be easier for us to reproduce.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
Which HTTP library did you use for testing? Do you have a sample application code to share? It will be easier for us to reproduce.
I'm not able to share my code, sorry.
I don't think it's related to the http library but related to BESL library because TLS1.1 looks fine.
I believe you can modify snip.httbin_org to send request endless and create another thread for receiving BLE data.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi grsr
I think you should fist check my statement about "TLS1.2 is extremely slow".
e.g.
you can use loop to send https request for 100 times.
Then compare the difference timing between TLS1.1 v.s. TLS1.2.
Simply modify include/wiced_defaults.h
WICED_TLS_MINOR_VERSION_MIN and WICED_TLS_MINOR_VERSION_MAX for this test.
I tested with FreeRTOS build.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr
I found the problem happens when MBEDTLS_TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is used. (which is only used by TLS-1.2)
I'm not able to test all supported ciphersuits, but I think you should check all supported ciphersuits by your SDK.
Also note, the older sdk before sdk-5.2 do not have such problem.
This looks like a regression after switching to mbedTLS.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am not able to reproduce this issue. The total time taken for 100 request-responses is similar for both TLS 1.2 and TLS 1.1. I had used FreeRTOS for testing and modified httpbin snip. Here is the code used for testing:
elapsed_time1=host_rtos_get_time();
for(i=0;i<100;i++)
{
http_request_init( &requests[0], &client, HTTP_GET, request_uris[0], HTTP_1_1 );
http_request_write_header( &requests[0], &header[0], 1 );
http_request_write_end_header( &requests[0] );
http_request_flush( &requests[0] );
wiced_rtos_get_semaphore(&sem,WICED_WAIT_FOREVER);
}
elapsed_time2=host_rtos_get_time();
The semaphore would be set when the HTTP_DATA_RECEIVED event was received. Timestamps were recorded before and after the loop to determine the total time taken to send and receive 100 requests-responses.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not sure if wiced BESL library has hardware dependent code.
Here is my test on CYW43438 platform: (Maybe you should try on CYW43438)
I only measure the time spent by http_client_connect() call as below:
elapsed_time1=host_rtos_get_time();
if ( ( result = http_client_connect( &client, (const wiced_ip_address_t*)&ip_address, SERVER_PORT, HTTP_USE_TLS, CONNECT_TIMEOUT_MS ) ) != WICED_SUCCESS )
{
WPRINT_APP_INFO( ( "Error: failed to connect to server: %u\n", result) );
return;
}
elapsed_time2=host_rtos_get_time();
printf("DIFF= %u\r\n", (unsigned) (elapsed_time2 - elapsed_time1));
I test twice for TLS-v1.1 and TLS-v1.2:
TLS v1.2:
www.httpbin.org is at 23.23.171.5
Connecting to www.httpbin.org
DIFF= 2375
www.httpbin.org is at 50.17.225.199
Connecting to www.httpbin.org
DIFF= 2480
TLS v1.1:
www.httpbin.org is at 54.225.64.197
Connecting to www.httpbin.org
DIFF= 953
www.httpbin.org is at 54.243.65.67
Connecting to www.httpbin.org
DIFF= 1018
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I test the http_client_connect() call 5 times on CYW43438 with FreeRTOS and here is the numbers in ms:
TLSv1.2
2061,3652,2173,2396,2434
TLSv1.1
930,800,993,813,1227
So it took longer time to connect with TLSv1.2. I will check with the engineers on this.
Regarding my previous post, I test the 100 request-response on CYW43438 with FreeRTOS 5 times and here is the numbers in ms:
TLSv1.2
6149,5835,5881,6858,5836
TLSv1.1
6159,6153,5829,7129,6158
The numbers looked similar.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the connecting time, TLSv1.2 takes double~triple time with TLSv1.1.
Then it seems strange the end result becomes almost the same for TLS1.1. and TLS 1.2 in your test.
BTW, I'm still trying to figure out why I can get 10 times difference in some environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We believe the higher connection time is due to ECC which consumes more CPU cycles irrespective of TLS 1.1 or 1.2. Can you confirm the cipher suite used in SDK before 5.2 for httpbin connection?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
On the same device, it looks fine if using old BESL (sdk5.1).
But has long delay after switch to mbedTLS since sdk-5.2+.