[
https://issues.apache.org/jira/browse/TS-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831863#comment-13831863
]
James Peach commented on TS-2365:
---------------------------------
I don't think that you can use {{REC_EstablishStaticConfigInt32}} here, because
that assumes you can always write to the given memory location. This in not
true in this case, because SSLConfigParams instances can come and go. I think
this should just use {{REC_ReadConfigInteger}}.
{{SSLConfig::acquire}} needs to be matched with {{SSLConfig::release}}. The
simplest way to do this is to always use the {{SSLConfig::scoped_config}}
helper.
After thinking some more about this, I realize that it would be OK to just set
a global variable in SSLConfig to specify the TLS record size. This would work
correctly with {{REC_EstablishStaticConfigInt32}} and remove the need to
acquire the {{SSLConfig}} in the IO path.
> Configure max TLS record size
> -----------------------------
>
> Key: TS-2365
> URL: https://issues.apache.org/jira/browse/TS-2365
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, SSL
> Reporter: Wei Sun
> Assignee: James Peach
> Labels: A
> Fix For: 4.2.0
>
> Attachments: ssl_maxrecordsize.diff, ssl_maxrecordsize2.diff
>
>
> The client can decipher the data only once it has received a full record over
> SSL. The record size can have significant impact on the page load time
> performance of the application. No limitation on record size means that
> clients might have to download up to 16KB of data before starting to process
> them, whereas very small records incur a larger overhead due to record
> framing. The suggestion is to configure the TLS record size to fit into a
> single TCP segment, this can improve page load times on browsers located over
> high latency or low bandwidth networks.
> ref:
> http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/
--
This message was sent by Atlassian JIRA
(v6.1#6144)
