好的，为了测试我的理论在生产环境中，我编写了一个自定义的TLS拨号器，它执行了一些非常不安全的操作：

func (d *deadlineDialer) DialTLSContext(ctx context.Context, network, addr string) (c net.Conn, err error) {
	defer func() {
		if err != nil {
			err = maybeWrapErr(err)
		}
	}()

	var firstTLSHost string
	if firstTLSHost, _, err = net.SplitHostPort(addr); err != nil {
		return nil, err
	}

	cfg := &tls.Config{}
	cfg.ServerName = firstTLSHost

	trace := httptrace.ContextClientTrace(ctx)

	plainConn, err := d.dialer.DialContext(ctx, network, addr)
	if err != nil {
		return nil, err
	}

	tlsConn := tls.Client(plainConn, cfg)
	increaseTLSBufferSizeUnsafely(tlsConn)

	errc := make(chan error, 2)
	var timer *time.Timer // for canceling TLS handshake
	if d := transport.TLSHandshakeTimeout; d != 0 {
		timer = time.AfterFunc(d, func() {
			errc <- errs.NewRetryableError(errors.New("TLS handshake timeout"))
		})
	}
	go func() {
		if trace != nil && trace.TLSHandshakeStart != nil {
			trace.TLSHandshakeStart()
		}
		err := tlsConn.Handshake()
		if timer != nil {
			timer.Stop()
		}
		errc <- err
	}()
	if err := <-errc; err != nil {
		plainConn.Close()
		if trace != nil && trace.TLSHandshakeDone != nil {
			trace.TLSHandshakeDone(tls.ConnectionState{}, err)
		}
		return nil, err
	}
	cs := tlsConn.ConnectionState()
	if trace != nil && trace.TLSHandshakeDone != nil {
		trace.TLSHandshakeDone(cs, nil)
	}

        return tlsConn, nil
}

func increaseTLSBufferSizeUnsafely(tlsConn *tls.Conn) {
	var (
		pointerVal = reflect.ValueOf(tlsConn)
		val        = reflect.Indirect(pointerVal)
		member     = val.FieldByName("rawInput")
		ptrToY     = unsafe.Pointer(member.UnsafeAddr())
		realPtrToY = (*bytes.Buffer)(ptrToY)
	)
	*realPtrToY = *bytes.NewBuffer(make([]byte, 0, 1<<18))
}

在我使用新的拨号器和256kib缓冲区大小部署了服务之后，我在系统调用中花费的所有时间几乎完全从我的配置文件中消失了。性能差异最终比我预期的要大得多，使用旧实现的配置文件有23.36秒的CPU时间，而新版本在同一工作负载下为19.98秒。
我会分享CPU配置文件的比较，但这有点困难，因为我的应用程序不是开源的，我不想通过方法名称潜在地泄露任何敏感信息。

CC @FiloSottile, @katiehockman, @rolandshoemaker, @kevinburke via owners。

+1 赞同这个观点！我们的数据库在提供读取服务的同时，从S3下载新的分区。我们正在考虑用不同的语言重写下载器组件，因为这4GB的下载必须通过最多64KB宽的系统调用管道进行，这是Conn.rawInput工作方式导致的。
读取系统调用返回值：

@bytes:
(..., 0)           87559 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[0]                 1629 |                                                    |
[1]                 1287 |                                                    |
[2, 4)               103 |                                                    |
[4, 8)                54 |                                                    |
[8, 16)              464 |                                                    |
[16, 32)             121 |                                                    |
[32, 64)             134 |                                                    |
[64, 128)            213 |                                                    |
[128, 256)           666 |                                                    |
[256, 512)           608 |                                                    |
[512, 1K)            948 |                                                    |
[1K, 2K)            4310 |@@                                                  |
[2K, 4K)            6920 |@@@@                                                |
[4K, 8K)           25991 |@@@@@@@@@@@@@@@                                     |
[8K, 16K)          46532 |@@@@@@@@@@@@@@@@@@@@@@@@@@@                         |
[16K, 32K)         42064 |@@@@@@@@@@@@@@@@@@@@@@@@                            |
[32K, 64K)         16326 |@@@@@@@@@                                           |
[64K, 128K)          160 |                                                    |
[128K, 256K)           3 |                                                    |
[256K, 512K)           1 |                                                    |
[512K, 1M)             2 |                                                    |

Dupe of #20420 .

#20420 的副本。我认为它相关但不是副本。#20420 是关于协商协议中较小的单个记录以减少(对等方)内存需求的。这是关于一次从线路读取多个记录以减少系统调用开销的。

@FiloSottile ,为了解决这个问题，需要采取什么措施？提案是否可接受，如果沿着这些方向进行PR,是否会被接受？

正在重构一些代码，发现上面有一个链接指向这个问题，我引入了一个非常丑陋的hack来解决它：P如果能看到这个建议被接受或者有替代方案提出就太棒了！

我们显然没有在1.20(抱歉)达到这个目标，但这将是我在1.21关注的事情。

感谢@richardartoul提供的解决方法，我也使用了这个方法。
对于Go维护者——我们是否有机会在下一个Go版本中对此进行调查？