[
https://issues.apache.org/jira/browse/TS-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177827#comment-14177827
]
Wei Sun edited comment on TS-3138 at 10/21/14 2:00 AM:
-------------------------------------------------------
[~briang], fyi, I verified tls false start in the past for full handshake with
ats-4.x + Firefox 29.0.1, seems ats is able to handle that. Please see tcpdump
screenshots in the attachment.
{{enabled_tls_falsestart_ats.png}}: #479 shows that client sends out
application data immediately after its “Change Cipher Spec”.
was (Author: sunwei):
[~briang], fyi, I verified tls false start in the past for full handshake with
ats-4.x + Firefox 29.0.1, seems ats works fine. Please see tcpdump screenshots
in the attachment.
{{enabled_tls_falsestart_ats.png}}: #479 shows that client sends out
application data immediately after its “Change Cipher Spec”.
> Implement TLS False Start
> -------------------------
>
> Key: TS-3138
> URL: https://issues.apache.org/jira/browse/TS-3138
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core, SSL
> Reporter: Brian Geffon
> Assignee: Brian Geffon
> Fix For: 5.2.0
>
>
> TLS false start can really reduce latency by allowing data to be transmitted
> before the CipherChange has been completed. For more information see:
> http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_FALSE_START
> and http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
> We need to 1) verify that Traffic Server correctly reads data that was
> transmitted as false start before the hand shake is "officially complete."
> and 2) if it's not then determine why the read is not happening earlier.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
