Skip to content

N
net
Switch branch/tag
  1. 01 Aug, 2018 2 commits
    • Brad Fitzpatrick's avatar
      http2/hpack: lazily build huffman table on first use · 22bb95c5
      Brad Fitzpatrick authored 
      This generated 120 kB on the heap before at init, regardless of
whether somebody used http2. Worse, because we vendored it into std,
users would have two copies, for about 256 kB of memory. After CL
127235 that went down to 60 kB per copy, so 120 kB for a binary using
golang.org/x/net/http2 explicitly.

With this, it goes to 0 until one of the two copies in the binary
actually uses one of the http2 packages.

I wasn't able to measure any difference with the Once.Do in the decode
path:

name             old time/op    new time/op    delta
HuffmanDecode-4     732ns ± 8%     707ns ± 3%   ~            (p=0.268 n=10+9)

(admittedly noisy)

Change-Id: I6c1065abc0c3458f3cb69e0f678978267ff35ea2
Reviewed-on: https://go-review.googlesource.com/127275
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      22bb95c5
    • Brad Fitzpatrick's avatar
      http2/hpack: reduce memory for huffman decoding table · 32f9bdbd
      Brad Fitzpatrick authored 
      Reduces process-wide heap (inuse_space) by 60kB by using a pointer to
a fixed-sized array instead of a slice of a fixed size.

Before:
119.44kB 23.43% 23.43%   147.88kB 29.01%  golang.org/x/net/http2/hpack.addDecoderNode

After:
 59.72kB 13.28% 39.85%    87.94kB 19.56%  golang.org/x/net/http2/hpack.addDecoderNode

(This is all work from an init func in http2/hpack)

Doesn't seem to affect runtime performance.

Measured with:

$ cat huffman_test.go
package main

import (
        "testing"

        _ "golang.org/x/net/http2"
        )

func TestMem(t *testing.T) {}

$ GODEBUG=memprofilerate=1 go test -memprofilerate=1 -memprofile=mem.prof -v .
=== RUN   TestMem
--- PASS: TestMem (0.00s)
PASS
ok      huffmem 0.052s

$ go tool pprof --inuse_space mem.prof

Change-Id: I5e56a5a2682f1063c955b342b37e97ca4c303dab
Reviewed-on: https://go-review.googlesource.com/127235Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      32f9bdbd
  3. 31 Jul, 2018 1 commit
  5. 30 Jul, 2018 4 commits
  7. 29 Jul, 2018 1 commit
    • William Chang's avatar
      http2/h2c: add h2c implementation (unencrypted HTTP/2) · c4299a1a
      William Chang authored 
      Implements h2c by leveraging the existing http2.Server by implementing the 2
ways to start an h2c connection as described in RFC 7540, which are: (1)
create a connection starting with HTTP/1 and then upgrading to h2c [Section 3.2]
and (2) starting a connection directly speaking h2c (aka starting with prior
knowledge) [Section 3.4].

For both of the above connection methods the implementation strategy is to
hijack a HTTP/1 connection, perform the h2c connection on the hijacked
net.Conn, and create a suitably configured net.Conn to pass into
http2.Server.ServeConn.

For h2c with prior knowledge this is relatively simple. For that we just have
to verify the HTTP/2 client preface has been written to the net.Conn, and
then reforward the client preface to the hijacked connection.

For h2c upgraded from HTTP/1, this is a bit more involved. First we validate
the HTTP/1 Upgrade request, and respond to the client with 101 Switching
Protocols. Then we write a HTTP/2 client preface on behalf of the client,
and a settings frame and a headers frame which correspond to what was in
the upgrade request. Then since http2.Server is going respond with a
settings ACK, we swallow it so that it is not forwarded to the client since
for h2c upgrade from HTTP/1 the 101 Switching Protocols response replaces
the settins ACK.

Fixes golang/go#14141

Change-Id: I435f40216c883809c0dcb75426c9c59e2ea31182
Reviewed-on: https://go-review.googlesource.com/112999Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      c4299a1a
  9. 24 Jul, 2018 1 commit
  11. 19 Jul, 2018 3 commits
  13. 18 Jul, 2018 1 commit
    • Ian Gudger's avatar
      dns/dnsmessage: fix bug in length fixup · 8887df42
      Ian Gudger authored 
      If during packing, the byte slice gets re-allocated between packing the
ResourceHeader and ResourceBody, the length will get updated in the old
byte slice before re-allocation resulting in a zero length in the final
packed message.

This change fixes the bug by passing the offset at which the length
should be written instead of a slice of the output byte slice from
ResourceHeader encoding step.

Updates golang/go#16218

Change-Id: Ifd7e2f549b7087ed5b52eaa6ae78970fec4ad988
Reviewed-on: https://go-review.googlesource.com/123835
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      8887df42
  15. 12 Jul, 2018 4 commits
  17. 10 Jul, 2018 3 commits
  19. 09 Jul, 2018 6 commits
  21. 06 Jul, 2018 3 commits
  23. 02 Jul, 2018 4 commits
  25. 29 Jun, 2018 3 commits
  27. 28 Jun, 2018 2 commits
    • Brad Fitzpatrick's avatar
      http2: make Server send GOAWAY if Handler sets "Connection: close" header · 97aa3a53
      Brad Fitzpatrick authored 
      In Go's HTTP/1.x Server, a "Connection: close" response from a handler results
in the TCP connection being closed.

In HTTP/2, a "Connection" header is illegal and we weren't previously
handling it, generating malformed responses to clients. (This is one
of our violations listed in golang/go#25023)

There was also a feature request in golang/go#20977 for a way for
HTTP/2 handlers to close the connection after the response. Since we
already close the connection for "Connection: close" for HTTP/1.x, do
the same for HTTP/2 and map it to a graceful GOAWAY errcode=NO
response.

Updates golang/go#25023 (improves 8.1.2.2. Connection-Specific Header Fields)
Updates golang/go#20977 (fixes after vendor into std)

Change-Id: Iefb33ea73be616052533080c63b54ae679b1d154
Reviewed-on: https://go-review.googlesource.com/121415
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      97aa3a53
    • Michael Fraenkel's avatar
      http2: correct overflow protection · d1d521f6
      Michael Fraenkel authored 
      Correct overflow detection when going negative.

Updates golang/go#25023

Change-Id: Ic2ddb7ee757f081d1826bfbbfd884e2b7e819335
Reviewed-on: https://go-review.googlesource.com/111675Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      d1d521f6
  29. 27 Jun, 2018 1 commit
  31. 21 Jun, 2018 1 commit