TLS-V1.2 HTTPS请求吞吐量非常差

Axel.LIN 174631写道：
另外，当BLE扫描同时发送HTTPS请求时，
如果使用TLS-V1.2，设备将挂起。
在做了更多的测试之后，我相信TLS-V1.2可以在连接到HTTP服务器时阻止BT线程。
这是一个问题，因为如果BT线程由于某种原因被阻塞，那么它会进入GKIYExpRebug。
我通过检查BLE扫描结果来检查它。
而TLS-V1.1在同一测试中看起来很好。
马迪格尔



     以下为原文
  

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.
 
mady grsr

您使用哪一个HTTP库进行测试？是否有共享应用程序的示例代码？我们会更容易繁殖。



     以下为原文
  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.

GRSR写道：
您使用哪一个HTTP库进行测试？是否有共享应用程序的示例代码？我们会更容易繁殖。
对不起，我不能分享我的密码。
我不认为它与HTTP库有关，但与BESL库相关，因为TLS1.1看起来很好。
我相信您可以修改SNIP.HTTBIN ORG来发送请求，并且创建另一个线程来接收BLE数据。



     以下为原文
  

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.

H-GRSR
我想你应该先检查一下我关于“TLS1.2非常慢”的说法。
例如
可以使用循环100次发送HTTPS请求。
然后比较TLS1.1 V.S.TLS1.2之间的差分定时。
简单地修改包含/WICDEDY默认值。
这个测试的WieDeTl SmithTyrSuxRuxOrnOrnon Min和WieDig-TLSsMi-MurrOrthValon最大。
我用FrRetos构建测试。



     以下为原文
  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.

GRSR
我发现这个问题发生在Mebttsl Telsx EcdHexRSAIa使用AES12128GCMYSHA256。（仅由TLS-1.2使用）
我无法测试所有支持的密封剂，但我认为你应该检查所有支持的密封剂SDK。
还要注意的是，SDK-5.2之前的旧SDK没有这样的问题。
这看起来像是在切换到MbEdTLS之后的回归。



     以下为原文
  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.

我无法重现这个问题。对于100个请求响应所花费的总时间对于TLS 1.2和TLS 1.1都是相似的。我曾使用FreeRTOS来测试和修改HTTPSBN SNIP。这里是用于测试的代码：
EasPosithItime1= HoothRotoSigGETTimeTIME（）；
（i＝0；i，lt；100；i++）
{
HtpIQuestestyIIT（和；请求（0），和客户端，HtpPyGET，RealestyURI（0），HTTPY1Y1）；
HtpPiRestRestRead Enter标题（＆；请求〔0〕，＆标题〔0〕，1〕；
HTTPIQuestStReWrdEnEnthHead报头（＆；请求〔0〕）；
HTTPIQuestESTFLUH（和请求（0））；
WICDED RotoSigGETSM语言（＆SEM，WICDEDWAITITYON）；
}
EasPosithTime2= HoothRoStGETGETTIME（）；
当接收到HTTPYDATAGEL接收事件时，将设置信号量。在循环之前和之后记录时间戳，以确定发送和接收100个请求响应所花费的总时间。



     以下为原文
  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.

我不确定West-BESL库是否有硬件相关的代码。
这是我在CYW4338平台上的测试：（也许你应该试试CYW4338）
我只测量由HtpPixCyclinCuffelType（）调用的时间，如下所示：
EasPosithItime1= HoothRotoSigGETTimeTIME（）；
如果（结果= HTTPYclient连接（和；客户端，（const WieDeIpIpAddisSt**）和；= WICEDDY成功
{
WPRNTHYAPAPIOFIN（（错误：连接到服务器失败：%UN），结果）；
返回；
}
EasPosithTime2= HoothRoStGETGETTIME（）；
PrimTf（“DIFF＝%rn”），（未签名）（EAPSESEDY TIME2-ELAPSSEDY TIME1）；
对TLS-V1.1和TLS-V1.2进行两次测试：
V1.1.2：
www. HutpBi.Org为23.23.171.5
连接到www. HutpBi.Org
差异＝2375
www. HutpBi.Org为50.17225.199
连接到www. HutpBi.Org
差异＝2480
TLV1.1：
www. HutpBi.Org为54.225.64.197
连接到www. HutpBi.Org
差异＝953
www. HutpBi.Org为54.243.65.67
连接到www. HutpBi.Org
差异＝1018



     以下为原文
  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: %un", result) );
        return;
    }
    elapsed_time2=host_rtos_get_time();
    printf("DIFF= %urn", (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

我用FreeRTOS在CYW4338上测试了5次HtpPyclitIn连接（）调用，这里是MS中的数字：
TLSV1.2
2061365 2217324962434
TLV1.1
九千三百零八兆零九十九亿三千八百一十三万一千二百二十七
因此，与TLV1.2连接需要更长的时间。我要和工程师们商量一下。
关于我以前的帖子，我用Fieltos测试了CYW4338上的100个请求响应5次，这里是MS中的数字：
TLSV1.2
61495835588 1685 85 836
TLV1.1
615961535829 71296158
数字看起来很相似。



     以下为原文
  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.

对于连接时间，TLV1.2采用TLV1.1双三次。
那么奇怪的是TLS1.1的最终结果几乎是一样的。测试中的TLS 1.2。
顺便说一下，我仍然在想为什么我能在某些环境中获得10倍的差异。



     以下为原文
  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.

我们相信较高的连接时间是由于ECC消耗更多的CPU周期而不考虑TLS 1.1或1.2。您能在5.2之前确认SDK中使用的密码套件用于HTTPBN连接吗？



     以下为原文
  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?

它使用Telsx EdHeHyRSA和AES12128GCMSHA256。
在同一设备上，如果使用旧的BESL（SDK5.1），看起来很好。
但自从SDK-5.2+切换到MbEdTLS后，它有很长的延迟。



     以下为原文
  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+.