This is what Chrome does.

Error message:

[0503/232045:VERBOSE1:quic_connection.cc(1913)] Client: Closing connection: 16302095663918797941, with error: QUIC_INVALID_STOP_WAITING_DATA (60), and details:  Least unacked too small.

Probably the batch mode should also be removed.

The cert and key should be passed to the server in memory.

The docs says:

Any message may contain a padding (PAD) tag. These can be used to to defeat traffic analysis. Additionally, we may define a global minimum size for client hellos to limit amplification attacks. Client hellos that are smaller than the minimum would need a PAD tag to make up the difference.

Downloads with Chrome not working at the moment, since Chrome sets an initial flow control window of 0x600000 = 6 MB, whereas the default flow control window is only 0x4000 = 16 KB.

Issue #33 is a race condition where the client may send encrypted data, but the server has not processed the handshake yet. In these cases, we should queue the undecryptable packets for later decryption (i.e. at latest once we have forward secure encryption set up), instead of simply discarding them.

There should be an error if:

• Too many undecryptable packets arrive
• Queued packets are still undecryptable after FS encryption is set up

Might be multiple bugs here.

The test case has increasing cwnd stats during convex region in cubic_test.go currently has no assertions. Copy the ones from chromium once https://bugs.chromium.org/p/chromium/issues/detail?id=606768 gets fixed.

This is needed for caddy integration.

Sure, we can just disable the fmt.Printf, but there might be a deeper problem here.

When a packet is lost and needs to be retransmitted, we immediately send the StopWaitingFrame with the next packet. The StreamFrames contained in the lost packet however are queued and might get transmitted much later if the StreamFrame queue in the PacketPacker is long.

The map packetHistory should be cleaned when old entries are not needed any more.

The client always crashes for downloads of non-trivial amounts of data because we are sending too fast.

Error message:

[0501/115530:VERBOSE1:quic_flow_controller.cc(62)] Client: Stream 5 highest byte offset increased from: 15137 to 16538
[0501/115530:VERBOSE1:quic_flow_controller.cc(62)] Client: Stream 0 highest byte offset increased from: 15137 to 16538
[0501/115530:ERROR:quic_flow_controller.cc(94)] Client: Flow control violation on stream 5, receive window offset: 16384, highest received byte offset: 16538
[0501/115530:VERBOSE1:quic_connection.cc(1913)] Client: Closing connection: 14740099974783558584, with error: QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA (59), and details:  Flow control violation after increasing offset
[0501/115530:VERBOSE1:quic_connection.cc(1928)] Client: Sending connection close packet.

Panic message:

[0501/115530:FATAL:quic_flow_controller.cc(174)] Check failed: bytes_consumed_ <= receive_window_offset_ (16538 vs. 16384)

Right now, packet payloads are stored as byte-slices. If we store them as Frame-Slices, we can remove old ACKs before retransmitting a packet.

Client sends ConnectionCloseFrame because of Invalid entropy after a couple of hundert packets on network connections (not on loopback).

We should also send intermediates properly.

Right now, only Stream-level flow control works.

We could check this using SetFinalizer.

Sample output:

<- Reading packet 6 for connection 3793658948447668933
Closing session with error: authentication failed
invalid http2 frame: authentication failed