Skip to content

N
net
Switch branch/tag
  1. 25 Feb, 2019 1 commit
  3. 13 Feb, 2019 1 commit
  5. 06 Feb, 2019 1 commit
    • Brad Fitzpatrick's avatar
      http2/h2demo: fix the HTTP/1-vs-HTTP/2 demo after HSTS breakage · 65e2d4e1
      Brad Fitzpatrick authored 
      We were previously demoing HTTP/1 vs HTTP/2 loading performance using
http:// scheme (which uses HTTP/1 implicitly) on the http2.golang.org
domain for HTTP/1, and https://http2.golang.org for HTTP/2.

But then golang.org got into the HSTS preload list, forcing all
*.golang.org to only be HTTPS.

So now, rather than find a new base domain name, to compare against
HTTP/1 we instead use https://http1.golang.org/ and then use the SNI
name to determine whether we advertise "h2".

Also, some cleanup:

* remove launch.go; it's no longer used since we moved to kubernetes
* use a multi-stage Dockerfile rather than the hacky workarounds
  that used to be necessary to simulate multiple stages
* modernize the kubernetes deployment stuff to match how we do
  it elsewhere ("gcloud docker" is long deprecated too)
* update from Go 1.9 to Go 1.11 for the prod base

Fixes golang/go#30033

Change-Id: I9f6b1f496d4005e5a08bf990843d440005a5b3e8
Reviewed-on: https://go-review.googlesource.com/c/160857Reviewed-by: 's avatarAndrew Bonventre <andybons@golang.org>
      65e2d4e1
  7. 25 Jan, 2019 2 commits
  9. 19 Jan, 2019 1 commit
  11. 10 Jan, 2019 2 commits
  13. 08 Jan, 2019 3 commits
  15. 07 Jan, 2019 3 commits
  17. 20 Dec, 2018 2 commits
    • Nigel Tao's avatar
      publicsuffix: hold icann-ness until wildcards fully match · 927f9776
      Nigel Tao authored 
      Consider the "uberspace.de" domain. The relevant rules in the Public
Suffix List are "*.uberspace.de" (in the PRVIATE DOMAIN section) and
"de" (in the ICANN DOMAIN section).

The PublicSuffix function returns a string and a bool. Both before and
after this commit, the string returned is "de", which is correct
according to a literal interpretation of the formal algorithm. But the
bool returned, icann-ness, is false before and true after. The correct
answer is true, since the matching rule, "de", is in the ICANN DOMAIN
section of the PSL.

Before this commit, the two-stage match for "*.uberspace" set the icann
bit when matching the back part, "uberspace", before checking that the
front part, the "*" wildcard, also matched.

A couple more examples, for the "bd" and "ck" domains. The relevant
rules are "*.bd" and "*.ck", with no non-wildcard "bd" or "ck" rule.
Before this commit, the PublicSuffix function would return (icann ==
true), when the correct result is (icann == false), the same as for
"nosuchtld".

Benchmarks get worse, but correctness trumps performance. Future commits
may be able to recover some of the loss. In any case, in absolute terms,
15µs is still pretty fast.

name             old time/op  new time/op  delta
PublicSuffix-56  11.0µs ± 0%  14.8µs ± 2%  +34.57%  (p=0.000 n=9+10)

Change-Id: I85ca6ab57a31308af5a29c46313197897eab5ab6
Reviewed-on: https://go-review.googlesource.com/c/154977Reviewed-by: 's avatarNigel Tao <nigeltao@golang.org>
      927f9776
    • Nigel Tao's avatar
      publicsuffix: add comments on the icann return value · 45fec1d2
      Nigel Tao authored 
      Change-Id: I51d236b07f187a6cbf4f6b8167f445e3280bbdf6
Reviewed-on: https://go-review.googlesource.com/c/155199Reviewed-by: 's avatarNigel Tao <nigeltao@golang.org>
      45fec1d2
  19. 17 Dec, 2018 1 commit
  21. 13 Dec, 2018 1 commit
    • Michael Fraenkel's avatar
      http2/hpack: track the beginning of a header block · 891ebc4b
      Michael Fraenkel authored 
      dynamic table size updates must occur at the beginning of the first
header block. The original fix, golang/go#25023, guaranteed it was at
the beginning of the very first block. The Close method implicitly
marked the end of the current header. We now document the Close behavior
and can track when we are at the beginning of the first block.

Updates golang/go#29187

Change-Id: I83ec39546527cb17d7de8a88ec417a46443d2baa
Reviewed-on: https://go-review.googlesource.com/c/153978Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      891ebc4b
  23. 07 Dec, 2018 1 commit
  25. 01 Dec, 2018 1 commit
    • Brad Fitzpatrick's avatar
      http2: revert Transport's strict interpretation of MAX_CONCURRENT_STREAMS · 351d144f
      Brad Fitzpatrick authored 
      And add the http2.Transport.StrictMaxConcurrentStreams bool knob to
behavior being reverted.

In CL 53250 for golang/go#13774 (for Go 1.10) we changed the HTTP/2
Transport's policy such that a server's advertisement of a
MAX_CONCURRENT_STREAMS value meant that it was a maximum for the
entire process, instead of just a single connection.

We thought that was a reasonable interpretation of the spec and
provided nice safety against slamming a server from a bunch of
goroutines doing concurrent requests, but it's been largely
unpopular (see golang/go#27044). It's also different behavior from
HTTP/1 and because you're usually not sure which protocol version
you're going to get, you need to limit your outbound HTTP requests
anyway in case you're hitting an HTTP/1 server.

And nowadays we have the Go 1.11 Transport.MaxConnsPerHost knob too
(CL 71272 for golang/go#13957). It doesn't yet work for HTTP/2, but it
will in either Go 1.12 or Go 1.13 (golang/go#27753)

After this is bundled into net/http's, the default HTTP client will
have this knob set false, restoring the old Go 1.9 behavior where new
TCP connections are created as necessary. Users wanting the strict
behavior and import golang.org/x/net/http2 themselves and make a
Transport with StrictMaxConcurrentStreams set to true. Or they can set
Transport.MaxConnsPerHost, once that works for HTTP/2.

Updates golang/go#27044 (fixes after bundle into std)

Change-Id: I4efdad7698feaf674ee8e01032d2dfa5c2f8a3a8
Reviewed-on: https://go-review.googlesource.com/c/151857Reviewed-by: 's avatarAndrew Bonventre <andybons@golang.org>
      351d144f
  27. 29 Nov, 2018 1 commit
  29. 14 Nov, 2018 2 commits
  31. 13 Nov, 2018 2 commits
  33. 08 Nov, 2018 3 commits
  35. 07 Nov, 2018 2 commits
  37. 06 Nov, 2018 2 commits
  39. 02 Nov, 2018 2 commits
    • uhei's avatar
      icmp: fix InterfaceIdent.Index handling · c10e9556
      uhei authored 
      RFC 7223, Section 3 defines 32 bits for if-index.
RFC 8335, Section 2.1 defines
"If the Interface Identification Object identifies the probed
interface by index, the length is equal to 8 and the payload contains
the if-index [RFC7223]."
The object should be comprised of a 4-byte object header and a 4-byte interface index.

Fixes golang/go#28530

Change-Id: Ib3ac729b7ec738a90a8c76ef984da0d5b28fa9c9
GitHub-Last-Rev: eba6714ed4c7af61e89f6e54d6a7544c570acebb
GitHub-Pull-Request: golang/net#23
Reviewed-on: https://go-review.googlesource.com/c/146637
Run-TryBot: Mikio Hara <mikioh.public.networking@gmail.com>
Reviewed-by: 's avatarMikio Hara <mikioh.public.networking@gmail.com>
      c10e9556
    • Mikio Hara's avatar
      Revert "icmp: fix ExtendedEchoRequest extension object" · b7e29687
      Mikio Hara authored 
      This reverts commit e1173011.

Reason for revert: The reverted test case is one of typical wrong wire
format test cases. The exposed API intentionally doesn't provide any
extenion object validation because the API is also used to construct
wire format compliance test tools. The API is extesion object-agnostic
and should be able to transmit and receive payload containing extension
objects in wrong wire format. Please preserve such test cases for now.

If you want to drop such test case, please add 1) extension object
validation, 2) a control knob for skipping validation, then drop all of
them.

Change-Id: I5c488c95523488e511e7a91e29a2f24f08448415
Reviewed-on: https://go-review.googlesource.com/c/146877Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      b7e29687
  41. 01 Nov, 2018 2 commits
  43. 29 Oct, 2018 1 commit
  45. 23 Oct, 2018 1 commit
  47. 17 Oct, 2018 1 commit
  49. 11 Oct, 2018 1 commit
    • Arthur Fabre's avatar
      bpf: support JumpIf on RegX instead of K · 49bb7cea
      Arthur Fabre authored 
      Add a JumpIfX instruction which implements conditional jumps using
RegA and RegX. This is in addition to the pre-existing JumpIf
instruction which uses RegA and K.

This instruction / addressing mode is not mentionned in the original BPF
paper, but is supported by tools like bpf_asm, and has recently been
added to the kernel's filter.txt.

Simplify some of the parsing logic, and add a separate helper for
checking for "fake" JumpIfs.

Add JumpIfX support to the BPF vm.

Update testdata with JumpIfX instructions, and add tests
for both the assembler/disassembler and vm.

Fixes golang/go#27814

Change-Id: I0c3f6ac7eb5b4cd4d9c5af8784ee2e8d25195a0a
GitHub-Last-Rev: 39a88165b2d3253c37db4b0e303d862b60dc37c9
GitHub-Pull-Request: golang/net#20
Reviewed-on: https://go-review.googlesource.com/c/136895Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      49bb7cea