2010-12-15 16:49:55 +00:00
|
|
|
// Copyright 2010 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
package tls
|
|
|
|
|
|
|
|
import (
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
"bytes"
|
|
|
|
"io"
|
|
|
|
"net"
|
2010-12-15 16:49:55 +00:00
|
|
|
"testing"
|
|
|
|
)
|
|
|
|
|
|
|
|
func TestRoundUp(t *testing.T) {
|
|
|
|
if roundUp(0, 16) != 0 ||
|
|
|
|
roundUp(1, 16) != 16 ||
|
|
|
|
roundUp(15, 16) != 16 ||
|
|
|
|
roundUp(16, 16) != 16 ||
|
|
|
|
roundUp(17, 16) != 32 {
|
|
|
|
t.Error("roundUp broken")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var paddingTests = []struct {
|
|
|
|
in []byte
|
|
|
|
good bool
|
|
|
|
expectedLen int
|
|
|
|
}{
|
|
|
|
{[]byte{1, 2, 3, 4, 0}, true, 4},
|
|
|
|
{[]byte{1, 2, 3, 4, 0, 1}, false, 0},
|
|
|
|
{[]byte{1, 2, 3, 4, 99, 99}, false, 0},
|
|
|
|
{[]byte{1, 2, 3, 4, 1, 1}, true, 4},
|
|
|
|
{[]byte{1, 2, 3, 2, 2, 2}, true, 3},
|
|
|
|
{[]byte{1, 2, 3, 3, 3, 3}, true, 2},
|
|
|
|
{[]byte{1, 2, 3, 4, 3, 3}, false, 0},
|
|
|
|
{[]byte{1, 4, 4, 4, 4, 4}, true, 1},
|
|
|
|
{[]byte{5, 5, 5, 5, 5, 5}, true, 0},
|
|
|
|
{[]byte{6, 6, 6, 6, 6, 6}, false, 0},
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestRemovePadding(t *testing.T) {
|
|
|
|
for i, test := range paddingTests {
|
|
|
|
payload, good := removePadding(test.in)
|
|
|
|
expectedGood := byte(255)
|
|
|
|
if !test.good {
|
|
|
|
expectedGood = 0
|
|
|
|
}
|
|
|
|
if good != expectedGood {
|
2010-12-17 21:47:52 +00:00
|
|
|
t.Errorf("#%d: wrong validity, want:%d got:%d", i, expectedGood, good)
|
2010-12-15 16:49:55 +00:00
|
|
|
}
|
|
|
|
if good == 255 && len(payload) != test.expectedLen {
|
|
|
|
t.Errorf("#%d: got %d, want %d", i, len(payload), test.expectedLen)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-10-08 15:06:53 +01:00
|
|
|
|
|
|
|
var certExampleCom = `308201403081eda003020102020101300b06092a864886f70d010105301e311c301a060355040a131354657374696e67204365727469666963617465301e170d3131313030313138353835325a170d3132303933303138353835325a301e311c301a060355040a131354657374696e67204365727469666963617465305a300b06092a864886f70d010101034b003048024100bced6e32368599eeddf18796bfd03958a154f87e5b084f96e85136a56b886733592f493f0fc68b0d6b3551781cb95e13c5de458b28d6fb60d20a9129313261410203010001a31a301830160603551d11040f300d820b6578616d706c652e636f6d300b06092a864886f70d0101050341001a0b419d2c74474c6450654e5f10b32bf426ffdf55cad1c52602e7a9151513a3424c70f5960dcd682db0c33769cc1daa3fcdd3db10809d2392ed4a1bf50ced18`
|
|
|
|
|
|
|
|
var certWildcardExampleCom = `308201423081efa003020102020101300b06092a864886f70d010105301e311c301a060355040a131354657374696e67204365727469666963617465301e170d3131313030313139303034365a170d3132303933303139303034365a301e311c301a060355040a131354657374696e67204365727469666963617465305a300b06092a864886f70d010101034b003048024100bced6e32368599eeddf18796bfd03958a154f87e5b084f96e85136a56b886733592f493f0fc68b0d6b3551781cb95e13c5de458b28d6fb60d20a9129313261410203010001a31c301a30180603551d110411300f820d2a2e6578616d706c652e636f6d300b06092a864886f70d0101050341001676f0c9e7c33c1b656ed5a6476c4e2ee9ec8e62df7407accb1875272b2edd0a22096cb2c22598d11604104d604f810eb4b5987ca6bb319c7e6ce48725c54059`
|
|
|
|
|
|
|
|
var certFooExampleCom = `308201443081f1a003020102020101300b06092a864886f70d010105301e311c301a060355040a131354657374696e67204365727469666963617465301e170d3131313030313139303131345a170d3132303933303139303131345a301e311c301a060355040a131354657374696e67204365727469666963617465305a300b06092a864886f70d010101034b003048024100bced6e32368599eeddf18796bfd03958a154f87e5b084f96e85136a56b886733592f493f0fc68b0d6b3551781cb95e13c5de458b28d6fb60d20a9129313261410203010001a31e301c301a0603551d1104133011820f666f6f2e6578616d706c652e636f6d300b06092a864886f70d010105034100646a2a51f2aa2477add854b462cf5207ba16d3213ffb5d3d0eed473fbf09935019192d1d5b8ca6a2407b424cf04d97c4cd9197c83ecf81f0eab9464a1109d09f`
|
|
|
|
|
|
|
|
var certDoubleWildcardExampleCom = `308201443081f1a003020102020101300b06092a864886f70d010105301e311c301a060355040a131354657374696e67204365727469666963617465301e170d3131313030313139303134315a170d3132303933303139303134315a301e311c301a060355040a131354657374696e67204365727469666963617465305a300b06092a864886f70d010101034b003048024100bced6e32368599eeddf18796bfd03958a154f87e5b084f96e85136a56b886733592f493f0fc68b0d6b3551781cb95e13c5de458b28d6fb60d20a9129313261410203010001a31e301c301a0603551d1104133011820f2a2e2a2e6578616d706c652e636f6d300b06092a864886f70d0101050341001c3de267975f56ef57771c6218ef95ecc65102e57bd1defe6f7efea90d9b26cf40de5bd7ad75e46201c7f2a92aaa3e907451e9409f65e28ddb6db80d726290f6`
|
|
|
|
|
|
|
|
func TestCertificateSelection(t *testing.T) {
|
|
|
|
config := Config{
|
|
|
|
Certificates: []Certificate{
|
|
|
|
{
|
|
|
|
Certificate: [][]byte{fromHex(certExampleCom)},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Certificate: [][]byte{fromHex(certWildcardExampleCom)},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Certificate: [][]byte{fromHex(certFooExampleCom)},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Certificate: [][]byte{fromHex(certDoubleWildcardExampleCom)},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
config.BuildNameToCertificate()
|
|
|
|
|
|
|
|
pointerToIndex := func(c *Certificate) int {
|
|
|
|
for i := range config.Certificates {
|
|
|
|
if c == &config.Certificates[i] {
|
|
|
|
return i
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
2014-08-06 19:22:00 +01:00
|
|
|
certificateForName := func(name string) *Certificate {
|
|
|
|
clientHello := &ClientHelloInfo{
|
|
|
|
ServerName: name,
|
|
|
|
}
|
|
|
|
if cert, err := config.getCertificate(clientHello); err != nil {
|
|
|
|
t.Errorf("unable to get certificate for name '%s': %s", name, err)
|
|
|
|
return nil
|
|
|
|
} else {
|
|
|
|
return cert
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if n := pointerToIndex(certificateForName("example.com")); n != 0 {
|
2011-10-08 15:06:53 +01:00
|
|
|
t.Errorf("example.com returned certificate %d, not 0", n)
|
|
|
|
}
|
2014-08-06 19:22:00 +01:00
|
|
|
if n := pointerToIndex(certificateForName("bar.example.com")); n != 1 {
|
2011-10-08 15:06:53 +01:00
|
|
|
t.Errorf("bar.example.com returned certificate %d, not 1", n)
|
|
|
|
}
|
2014-08-06 19:22:00 +01:00
|
|
|
if n := pointerToIndex(certificateForName("foo.example.com")); n != 2 {
|
2011-10-08 15:06:53 +01:00
|
|
|
t.Errorf("foo.example.com returned certificate %d, not 2", n)
|
|
|
|
}
|
2014-08-06 19:22:00 +01:00
|
|
|
if n := pointerToIndex(certificateForName("foo.bar.example.com")); n != 3 {
|
2011-10-08 15:06:53 +01:00
|
|
|
t.Errorf("foo.bar.example.com returned certificate %d, not 3", n)
|
|
|
|
}
|
2014-08-06 19:22:00 +01:00
|
|
|
if n := pointerToIndex(certificateForName("foo.bar.baz.example.com")); n != 0 {
|
2011-10-08 15:06:53 +01:00
|
|
|
t.Errorf("foo.bar.baz.example.com returned certificate %d, not 0", n)
|
|
|
|
}
|
|
|
|
}
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
|
|
|
|
// Run with multiple crypto configs to test the logic for computing TLS record overheads.
|
|
|
|
func runDynamicRecordSizingTest(t *testing.T, config *Config) {
|
|
|
|
clientConn, serverConn := net.Pipe()
|
|
|
|
|
2016-06-21 15:00:41 +01:00
|
|
|
serverConfig := config.clone()
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
serverConfig.DynamicRecordSizingDisabled = false
|
2016-06-21 15:00:41 +01:00
|
|
|
tlsConn := Server(serverConn, serverConfig)
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
|
|
|
|
recordSizesChan := make(chan []int, 1)
|
|
|
|
go func() {
|
|
|
|
// This goroutine performs a TLS handshake over clientConn and
|
|
|
|
// then reads TLS records until EOF. It writes a slice that
|
|
|
|
// contains all the record sizes to recordSizesChan.
|
|
|
|
defer close(recordSizesChan)
|
|
|
|
defer clientConn.Close()
|
|
|
|
|
|
|
|
tlsConn := Client(clientConn, config)
|
|
|
|
if err := tlsConn.Handshake(); err != nil {
|
|
|
|
t.Errorf("Error from client handshake: %s", err)
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
var recordHeader [recordHeaderLen]byte
|
|
|
|
var record []byte
|
|
|
|
var recordSizes []int
|
|
|
|
|
|
|
|
for {
|
|
|
|
n, err := clientConn.Read(recordHeader[:])
|
|
|
|
if err == io.EOF {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
if err != nil || n != len(recordHeader) {
|
|
|
|
t.Errorf("Error from client read: %s", err)
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
length := int(recordHeader[3])<<8 | int(recordHeader[4])
|
|
|
|
if len(record) < length {
|
|
|
|
record = make([]byte, length)
|
|
|
|
}
|
|
|
|
|
|
|
|
n, err = clientConn.Read(record[:length])
|
|
|
|
if err != nil || n != length {
|
|
|
|
t.Errorf("Error from client read: %s", err)
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// The last record will be a close_notify alert, which
|
|
|
|
// we don't wish to record.
|
|
|
|
if recordType(recordHeader[0]) == recordTypeApplicationData {
|
|
|
|
recordSizes = append(recordSizes, recordHeaderLen+length)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
recordSizesChan <- recordSizes
|
|
|
|
}()
|
|
|
|
|
|
|
|
if err := tlsConn.Handshake(); err != nil {
|
|
|
|
t.Fatalf("Error from server handshake: %s", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// The server writes these plaintexts in order.
|
|
|
|
plaintext := bytes.Join([][]byte{
|
|
|
|
bytes.Repeat([]byte("x"), recordSizeBoostThreshold),
|
|
|
|
bytes.Repeat([]byte("y"), maxPlaintext*2),
|
|
|
|
bytes.Repeat([]byte("z"), maxPlaintext),
|
|
|
|
}, nil)
|
|
|
|
|
|
|
|
if _, err := tlsConn.Write(plaintext); err != nil {
|
|
|
|
t.Fatalf("Error from server write: %s", err)
|
|
|
|
}
|
|
|
|
if err := tlsConn.Close(); err != nil {
|
|
|
|
t.Fatalf("Error from server close: %s", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
recordSizes := <-recordSizesChan
|
|
|
|
if recordSizes == nil {
|
|
|
|
t.Fatalf("Client encountered an error")
|
|
|
|
}
|
|
|
|
|
|
|
|
// Drop the size of last record, which is likely to be truncated.
|
|
|
|
recordSizes = recordSizes[:len(recordSizes)-1]
|
|
|
|
|
|
|
|
// recordSizes should contain a series of records smaller than
|
|
|
|
// tcpMSSEstimate followed by some larger than maxPlaintext.
|
|
|
|
seenLargeRecord := false
|
|
|
|
for i, size := range recordSizes {
|
|
|
|
if !seenLargeRecord {
|
crypto/tls: adjust dynamic record sizes to grow arithmetically
The current code, introduced after Go 1.6 to improve latency on
low-bandwidth connections, sends 1 kB packets until 1 MB has been sent,
and then sends 16 kB packets (the maximum record size).
Unfortunately this decreases throughput for 1-16 MB responses by 20% or so.
Following discussion on #15713, change cutoff to 128 kB sent
and also grow the size allowed for successive packets:
1 kB, 2 kB, 3 kB, ..., 15 kB, 16 kB.
This fixes the throughput problems: the overhead is now closer to 2%.
I hope this still helps with latency but I don't have a great way to test it.
At the least, it's not worse than Go 1.6.
Comparing MaxPacket vs DynamicPacket benchmarks:
name maxpkt time/op dyn. time/op delta
Throughput/1MB-8 5.07ms ± 7% 5.21ms ± 7% +2.73% (p=0.023 n=16+16)
Throughput/2MB-8 15.7ms ±201% 8.4ms ± 5% ~ (p=0.604 n=20+16)
Throughput/4MB-8 14.3ms ± 1% 14.5ms ± 1% +1.53% (p=0.000 n=16+16)
Throughput/8MB-8 26.6ms ± 1% 26.8ms ± 1% +0.47% (p=0.003 n=19+18)
Throughput/16MB-8 51.0ms ± 1% 51.3ms ± 1% +0.47% (p=0.000 n=20+20)
Throughput/32MB-8 100ms ± 1% 100ms ± 1% +0.24% (p=0.033 n=20+20)
Throughput/64MB-8 197ms ± 0% 198ms ± 0% +0.56% (p=0.000 n=18+7)
The small MB runs are bimodal in both cases, probably GC pauses.
But there's clearly no general slowdown anymore.
Fixes #15713.
Change-Id: I5fc44680ba71812d24baac142bceee0e23f2e382
Reviewed-on: https://go-review.googlesource.com/23487
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-05-27 14:50:06 +01:00
|
|
|
if size > (i+1)*tcpMSSEstimate {
|
|
|
|
t.Fatalf("Record #%d has size %d, which is too large too soon", i, size)
|
|
|
|
}
|
|
|
|
if size >= maxPlaintext {
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
seenLargeRecord = true
|
|
|
|
}
|
|
|
|
} else if size <= maxPlaintext {
|
|
|
|
t.Fatalf("Record #%d has size %d but should be full sized", i, size)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !seenLargeRecord {
|
|
|
|
t.Fatalf("No large records observed")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestDynamicRecordSizingWithStreamCipher(t *testing.T) {
|
2016-06-21 15:00:41 +01:00
|
|
|
config := testConfig.clone()
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
config.CipherSuites = []uint16{TLS_RSA_WITH_RC4_128_SHA}
|
2016-06-21 15:00:41 +01:00
|
|
|
runDynamicRecordSizingTest(t, config)
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestDynamicRecordSizingWithCBC(t *testing.T) {
|
2016-06-21 15:00:41 +01:00
|
|
|
config := testConfig.clone()
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
config.CipherSuites = []uint16{TLS_RSA_WITH_AES_256_CBC_SHA}
|
2016-06-21 15:00:41 +01:00
|
|
|
runDynamicRecordSizingTest(t, config)
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestDynamicRecordSizingWithAEAD(t *testing.T) {
|
2016-06-21 15:00:41 +01:00
|
|
|
config := testConfig.clone()
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
config.CipherSuites = []uint16{TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256}
|
2016-06-21 15:00:41 +01:00
|
|
|
runDynamicRecordSizingTest(t, config)
|
crypto/tls: implement dynamic record sizing
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes #14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
2016-02-18 02:20:24 +00:00
|
|
|
}
|