it is https, I am not sure if ocsp stapling is enabled, how can I know ?

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi 30 juin 2020 17:26, Илья Шипицин <chipits...@gmail.com> a écrit :

> is it https ? is ocsp stapling enabled ?
>
> вт, 30 июн. 2020 г. в 20:24, Paul Belloc <paul.bel...@protonmail.com>:
>
>> Hello, I have been struggling on this issue for some time.
>>
>> I am trying to monitor the total request time in haproxy 1.7.5 HTTP logs.
>> My usecase is customers want to know the exact overhead of calling our 
>> service. Sometime we have complaints that we are adding overhead, and we 
>> know that our backend is fast, but we don't have the data to show the total 
>> overhead from the last end user point of view.
>>
>> So I started saving all haproxy HTTP logs in an ELK cluster.
>>
>> At this point I must say: we use http-server-close and option httplog.
>>
>> What I see is the Tr and Tt seem to depend on the TCP opening timer. The 
>> consequence is the logged time is good only for the first http request of a 
>> tcp connection, i.e the request that has a NI cookie-status.
>>
>> To show that, I can show the difference between querying the backend through 
>> haproxy using
>>
>> 1) CURL (no keep alive)
>>
>> Jun 30 17:18:23 19/0/0/3/22 200 1993 - - --NI 567/567/0/1/0 0/0 "GET 
>> /website/5be174f9a9403/tag.js HTTP/1.1"
>> Jun 30 17:18:25 18/0/0/2/20 200 1993 - - --NI 449/449/0/1/0 0/0 "GET 
>> /website/5be174f9a9403/tag.js HTTP/1.1"
>> Jun 30 17:18:28 19/0/0/2/21 200 1993 - - --NI 605/605/0/1/0 0/0 "GET 
>> /website/5be174f9a9403/tag.js HTTP/1.1"
>>
>> We see that there is 1 seconds between my two first curls, and that the Tr 
>> and Tt are similar. We see both are NI. Then there is 3 seconds between the 
>> 2 last curls, but the Tr and Tt is still similar.
>>
>> 2) Web browser (keep-alive)
>>
>> Jun 30 17:14:49 190305/0/0/4/190309 304 205 - - --VN 963/963/0/0/0 0/0 "GET 
>> /website/5be174f9a9403/tag.js HTTP/1.1"
>> Jun 30 17:14:51 1940/0/0/1/1941 304 205 - - --VN 966/966/0/1/0 0/0 "GET 
>> /website/5be174f9a9403/tag.js HTTP/1.1"
>>
>> We see the first request has crazy Tt and Tr even if it was really fast on 
>> the client side. This is, I guess because of the idle time on the TCP 
>> connection.
>> We see the second request has 2000 ms Tt / Tr, this is the time elapsed 
>> since the first request, plus the 'real' http response time.
>>
>> Now I wonder if this is normal behaviour and what are my options.
>>
>> I see:
>>
>> - Disable all form of keepalive, with a big performance cost
>> - Monitor only the NI requests, with a risk of inconsistencies
>>
>> Is there another way ? Do I understand correctly what is going on ?
>>
>> Thank you

Reply via email to