quic-go / quic-go Goto Github PK

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

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

This is what Chrome does.

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.

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)

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

Right now, only Stream-level flow control works.

Might be multiple bugs here.

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.

This is needed for caddy integration.

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.

Probably the batch mode should also be removed.

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

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

Sample output:

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

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.

We should also send intermediates properly.

We could check this using SetFinalizer.

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.

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.