google / quiche

QUICHE

QUICHE stands for QUIC, Http, Etc. It is Google's production-ready implementation of QUIC, HTTP/2, HTTP/3, and related protocols and tools. It powers Google's servers, Chromium, Envoy, and other projects. It is actively developed and maintained.

There are two public QUICHE repositories. Either one may be used by embedders, as they are automatically kept in sync:

• https://quiche.googlesource.com/quiche
• https://github.com/google/quiche

To embed QUICHE in your project, platform APIs need to be implemented and build files need to be created. Note that it is on the QUICHE team's roadmap to include default implementation for all platform APIs and to open-source build files. In the meanwhile, take a look at open source embedders like Chromium and Envoy to get started:

• Platform implementations in Chromium
• Build file in Chromium
• Platform implementations in Envoy
• Build file in Envoy

To contribute to QUICHE, follow instructions at CONTRIBUTING.md.

QUICHE is only supported on little-endian platforms.

quiche's Issues

Quiche stalls occasionally because of the stack traces

I had the following problem, my clients stalled the event loop when closing their session for more than 10 seconds.

One or two clients (do not really know, should be one thread) for webtransport (but it does not matter), called my equivalent of:

quiche/quiche/quic/tools/quic_client_base.h

Line 353 in 30eeff5

void ResetSession() { session_.reset(); }

in their destructor.

This ended up in:

quiche/quiche/quic/core/http/quic_spdy_session.cc

Line 479 in 30eeff5

QUIC_BUG_IF(quic_bug_12477_2, destruction_indicator_ != 123456789)

,
where
QuicStackTrace() caused the 10-second stall, I used the supplied default implementation.
Putting debug code into the stack trace showed, that

quiche/quiche/common/platform/default/quiche_platform_impl/quiche_stack_trace_impl.cc

Line 35 in 30eeff5

bool success = absl::Symbolize(function, symbol_name, sizeof(symbol_name));

took a very long time to progress.
Maybe a second per stack frame. It can be a locking issue since it has some synchronization built in. ( I am not sure=)
(Only on mac and linux, windows is probably fine)

Anyway, I use now a dummy stack trace on my platform.
But I think, this issue should be addressed, since it can hit hard the performance of an application, that uses it (and can take a day or more to find).
Either
QuicStackTrace should only be called, if an error occurs, so put an if around:

quiche/quiche/quic/core/http/quic_spdy_session.cc

Line 479 in 30eeff5

QUIC_BUG_IF(quic_bug_12477_2, destruction_indicator_ != 123456789)

and probably similar places.
Or something needs to be done to prevent the slow performance of the current stack trace. I can not rule out, that this is a problem of absl, I am using lts_2022_06_23 .

Got ASSERT_OK error while using bazel build

I am using 'bazel build ...' and got this error
ERROR: /home/ubuntu/quiche/quiche/BUILD.bazel:242:28: Compiling quiche/binary_http/binary_http_message_test.cc failed: (Exit 1): gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 84 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
quiche/binary_http/binary_http_message_test.cc: In member function 'virtual void quiche::BinaryHttpResponse_Equality_Test::TestBody()':
quiche/binary_http/binary_http_message_test.cc:622:3: error: 'ASSERT_OK' was not declared in this scope
ASSERT_OK(
^~~~~~~~~
quiche/binary_http/binary_http_message_test.cc:622:3: note: suggested alternative: 'ASSERT_GT'
ASSERT_OK(
^~~~~~~~~
ASSERT_GT
quiche/binary_http/binary_http_message_test.cc: In member function 'virtual void quiche::BinaryHttpResponse_Inequality_Test::TestBody()':
quiche/binary_http/binary_http_message_test.cc:634:3: error: 'ASSERT_OK' was not declared in this scope
ASSERT_OK(
^~~~~~~~~
quiche/binary_http/binary_http_message_test.cc:634:3: note: suggested alternative: 'ASSERT_GT'
ASSERT_OK(
^~~~~~~~~
ASSERT_GT
quiche/binary_http/binary_http_message_test.cc:640:3: error: 'EXPECT_OK' was not declared in this scope
EXPECT_OK(different_status.AddInformationalResponse(
^~~~~~~~~
quiche/binary_http/binary_http_message_test.cc:640:3: note: suggested alternative: 'EXPECT_EQ'
EXPECT_OK(different_status.AddInformationalResponse(
^~~~~~~~~
EXPECT_EQ

and I didn't found the definition of "ASSERT_OK" or "EXPECT_OK" in gtest.h, how can i solve it ?

using gcc 7.5 on ubuntu 18.04

sendfile support?

Hi,
Do you plan to support linux sendfile?
Otherwise, where is the best place to put it? Don't want to break anything.

Thanks

Prioritization support

Does quiche have any prioritization support? Either the three-based ones or the recent Extensible Prioritization Scheme?

OnCanCreateNewOutgoingStream in SpdySession

Hi,
I am trying to make unit test for the MAX_STREAM property in my WebTransport lib.
I ran into an issue, if the number of bidirectional streams is increased the visitor was not informed.
I tracked it down to

quiche/quiche/quic/core/http/quic_spdy_session.cc

Line 1619 in 87cb8c8

void QuicSpdySession::OnCanCreateNewOutgoingStream(bool unidirectional) {

which does not inform in case of bidrectional streams.
The new generic session does it:

quiche/quiche/quic/core/quic_generic_session.cc

Line 170 in 87cb8c8

void QuicGenericSessionBase::OnCanCreateNewOutgoingStream(bool unidirectional) {

It is not a big deal, since I can overload the method, but I am wondering, if it is intentional and if I am missing something.

Use of QUIC_LOG and getting a log file

Not an issue but a question about how to use the logging functionality
Would like to get all levels/granular level of logs.

The current quic_client or quic_server doesn't have the option to
supply the log file name into which the logs will be written.

Was curious as to how get logs. Is it platform dependent (chromium/envoy) configuration/option?

Can chrome send NEW_CONNECTION_ID frame to server after h3 handshake ?

hello everyone，when I test http3 with chrome and my server, I find a question. between the handshake, the server send the param quic_active_connection_id_limit to client is 5, but the chrome doesn't send NEW_CONNECTION_ID frame to server after the handshake.
I don't know why, or chrome not implement the protocol ?
when the client address changes, without new unused client id, the server cann't response to connection migration.

Allow sending NEW_TOKEN frames before TLS NewSessionTickets

This issue was originally opened in the quic-go repository.

Currently, it is not possible to make use of QUIC's address validation tokens if the server sends the NEW_TOKEN frame before sending the crypto frame containing the TLS NewSessionTicket. The address validation token gets stored, then thrown away.

It currently works as follows:

• Upon arrival of a NEW_TOKEN frame, the token gets stored alongside its associated server ID (i.e. a combination of host and port) inside a cache that holds TLS sessions.
• When a new session ticket arrives, the session gets added to the cache entry for the associated server
• This new session does not specify the same QUIC transport parameters and is therefore assumed to be related to another, more recent session. The old cache entry (containing the token) gets removed and a new entry without the token is inserted.

Is the described behavior on purpose or is it a bug?
AFAIK, a client should be able to use tokens independent of the TLS session ticket.

If this is a bug, maybe it would make sense to copy an existing address validation token from the existing cache entry into the new cache entry for the same server ID before deleting the existing cache entry. Let me know if I should contribute this solution to the QUICHE project if the solution is fine.

Streams with the same priority use round robin to write data

It seems to me that when there is multiple streams with the same priority, then the implemented algorithm still uses round-robin to choose the one that will actually write. However, this is not what RFC 9218 suggests, unless "incremental" parameter is provided (which is not supported at the moment). I am not sure if this behaviour is actually a bug, or if it is intended deviation from the RFC.

There is a soft limit (16k) implemented:
https://quiche.googlesource.com/quiche/+/refs/heads/main/quiche/quic/core/quic_write_blocked_list.cc#56

Then, when a stream is being added to the list of write blocked stream, it is added to the front or to the back of the list,
see QuicWriteBlockedList::AddStream().

If the stream is pushed to the end, then the other streams with the same priority will write at the next writing opportunity, instead of the stream that is being added.

QuicBatchWriterBuffer with custom allocated buffer

I am currently reworking my web transport node.js plugin to not use its own eventloop, but custom quicwriters (actually you do not need a reader at all) to use node.js internal udpsockets. (Victor suggested this a year ago).
So at least all tests are passing on the development branch.
I assume for better performance batch processing of writing on quic and node.js side will be beneficial.
As not all napi-supported platforms, support memory allocated outside of v8 for array buffers, it would be nice, if I could use a node-allocated array buffer for QuicBatchWriterBuffer, so either passing my own buffer to the object or an abstract base class for QuicBatchWriterBuffer can help.

Is this a possible change in quiche? (Of course I can also make a PR if necessary).
Thanks!

QuicIdleNetworkDetector::StopDetection error or duplicated?

void QuicIdleNetworkDetector::StopDetection() {
  alarm_->PermanentCancel();
  handshake_timeout_ = QuicTime::Delta::Infinite();
  idle_network_timeout_ = QuicTime::Delta::Infinite();
  handshake_timeout_ = QuicTime::Delta::Infinite(); //bandwidth_update_timeout_ ?
  stopped_ = true;
}

Masque Server segmentation fault

Hi,
the compiled masque-server throws an "Segmentation fault (core dumped)" upon execution.
Steps to reproduce:

1. Compile the masque-server: bazel build //quiche:masque_server
2. Execute the built executable: ./masque_server

I debugged the executable with GDB:

Core was generated by ./masque_server.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005605207d5b36 in quic::TlsServerConnection::CreateSslCtx(quic::ProofSource*) ()

Greetings,
Heiko

reuse memory in stream_sequencer_buffer

in quic_stream_sequencer_buffer.cc

I make some change in my person project, during test most time only one memory block is used.(reduce new/free)

  void QuicStreamSequencerBuffer::Clear() {
  if (blocks_ != nullptr) {
    for (size_t i = 0; i < current_blocks_count_; ++i) {
      if (blocks_[i] != nullptr) {
        //RetireBlock(i);
        delete blocks_[index];
        blocks_[index] = nullptr;
      }
    }
  }
  num_bytes_buffered_ = 0;
  bytes_received_.Clear();
  bytes_received_.Add(0, total_bytes_read_);
}

//  DCHECK(max_buffer_capacity_bytes_ % kBlockSizeBytes  == 0);
bool QuicStreamSequencerBuffer::RetireBlock(size_t index) {
  if (blocks_[index] == nullptr) {
    QUIC_BUG(quic_bug_10610_1) << "Try to retire block twice";
    return false;
  }
  
  //keeping current block to use
  const auto block_finished = total_bytes_read_ % kBlockSizeBytes == 0;
  if (!block_finished)
   return true;

  //move current block to next
  const auto maybe_read_block = GetBlockIndex(total_bytes_read_ + num_bytes_buffered_ + kBlockSizeBytes);
  if (blocks_[maybe_read_block] == nullptr) {
    blocks_[maybe_read_block] = blocks_[index];
    blocks_[index] = nullptr;
  } else {  
    delete blocks_[index];
    blocks_[index] = nullptr;
  }
  QUIC_DVLOG(1) << "Retired block with index: " << index;
  return true;
}

Undefined behavior sanitizer (ubsan) => Load of value <value>, which is not a valid value for type 'QuicErrorCode'.

Many tests from quic_framer_test.cc fail for build with enabled ubsan because "load of value , which is not a valid value for type 'QuicErrorCode'". Enum QuicErrorCode is supposed to carry different than defined values which leads to this problem. Ubsan is correct according to C++ standard:

8) A value of integer or enumeration type can be converted to any complete enumeration type.
If the underlying type is not fixed, the behavior is undefined if the value of expression is out of range (the range is all values possible for the smallest bit-field large enough to hold all enumerators of the target enumeration).

The problematic code is in quic_framer.cc:

void MaybeExtractQuicErrorCode(QuicConnectionCloseFrame* frame) {

  ...
  ...

  frame->quic_error_code = static_cast<QuicErrorCode>(extracted_error_code);

  ...
  ...

}

Unable to use SSLKEYLOGFILE option

As i wanted to look at the decrypted packets using wireshark, i tried using the below:

export SSLKEYLOGFILE=<quic_keylog_file>, which should work for boring ssl
https://github.com/google/boringssl/search?q=SSLKEYLOGFILE&type=code

But it didn't work and i didn't get the keylog file.

Should we change the cmake file to include boringssl tool/client.cc to make it work and obtain SSLKEYLOGFILE?

How to access the spdsession object from a WebTransportSession

I would like to support getStats and sending goaway stuff in the node webtransport addon.
However, I am hitting the following problem.
GetStats and as well as sendGoawayHttps3 (needed at least from the server side) are available through the underlying QuicSpdySession.
However, it is a private member of WebTransportHttp3, so I have no way to access it from a visitor.
(My plan is to do a dynamic cast on the WebTransport object....).

Are there any plans to make these features available through the WebTransport base class, or at least to get access to the SpdySession?
(I think deriving a class from WebTransportHttp3 is not an option, since it is created deep within quiche objects?)
Or any hints, on how to do it in another way?
Thanks?

IETF Connection Close Frame - Possible narrowing of error code coming from reason phrase

Looks like error code coming from reason phrase of CLOSE_FRAME can be very big number (64 bits) but the target enum QuicErrorCode can be of non-fixed underlying type unsigned int (32 bits). This can lead to narrowing. I have checked this behavior by updating the QuicFramerTest.ConnectionCloseFrameWithUnknownErrorCode so it sends following reason phrase "4294967296:bla" which leads to quic_error_code with value 0 (QUIC_NO_ERROR) because of narrowing.

The problematic code:

void MaybeExtractQuicErrorCode(QuicConnectionCloseFrame* frame) {
  std::vector<absl::string_view> ed = absl::StrSplit(frame->error_details, ':');
  uint64_t extracted_error_code;

...
...
...

  frame->quic_error_code = static_cast<QuicErrorCode>(extracted_error_code);
}

how to build on window?

ERROR: C:/users/user/_bazel_user/rwpuuipt/external/zlib/BUILD.bazel:7:11: Compiling uncompr.c failed: (Exit 2): cl.exe failed: error executing command (from target @zlib//:zlib) D:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\bin\HostX64\x64\cl.exe /nologo /DCOMPILER_MSVC /DNOMINMAX /D_WIN32_WINNT=0x0601 /D_CRT_SECURE_NO_DEPRECATE ... (remaining 26 arguments skipped)
cl: 命令行 error D8021 :无效的数值参数“/Wno-narrowing”
Target //quiche:quiche_core failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 231.785s, Critical Path: 13.94s
INFO: 202 processes: 37 internal, 165 local.

Commit about ECN break UDP socket platform impl

I during my weekly tracking of the quiche library, I ran into an issue with the commit:
Alter IP_TOS socket call for ECN based on platform.

It misses an implementation of GetEcnCmsgArgsPreserveDscpImpl in https://github.com/google/quiche/blob/main/quiche/common/platform/default/quiche_platform_impl/quiche_udp_socket_platform_impl.h
Also in envoy, I think it is missing.
It would be nice if a default implementation would be added, or a pointer to what it does so that I can implement it if a default implementation is not provided.
Thanks!
Marten

Build error on mac

I get the following error when running bazel build //quiche:quiche_core:

ERROR: /private/var/tmp/_bazel_nathanmittler/1814428b3f255bb79b4de47698a8348b/external/com_google_googleurl/url/BUILD:12:11: Compiling url/url_idna_icu.cc failed: (Exit 1): wrapped_clang_pp failed: error executing command (from target @com_google_googleurl//url:url) external/local_config_cc/wrapped_clang_pp '-D_FORTIFY_SOURCE=1' -fstack-protector -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -fno-omit-frame-pointer -O0 -DDEBUG '-std=c++11' ... (remaining 36 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
external/com_google_googleurl/url/url_idna_icu.cc:83:25: error: no matching function for call to 'uidna_nameToASCII'
    int output_length = uidna_nameToASCII(uidna, src, src_len, output->data(),
                        ^~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/unicode/uidna.h:294:1: note: candidate function not viable: no known conversion from 'const char16_t *' to 'const UChar *' (aka 'const unsigned short *') for 2nd argument
uidna_nameToASCII(const UIDNA *idna,
^

I'm building on an m1 macbookpro with OSX Ventura (13.1) and the latest Xcode SDK (13.1).

Anyone seen this before or have a workaround?

[masque_client] Failed to enable receiving of self v4 ip on macOS

Environment: macOS 14.0 Beta (23A5337a), Xcode 15 beta 8, bazel 6.3.2

I received the following error when executing the following command:

$ ./bazel-bin/quiche/masque_client <$PROXY_HOST:$PROXY_PORT> https://quic.rocks:4433 \
> --disable_certificate_verification=true
E0911 11:22:48.963996       1 quic_udp_socket_posix.inc:219] Failed to enable receiving of self v4 ip
E0911 11:22:48.964022       1 masque_client_tools.cc:91] Failed to initialize MasqueEncapsulatedClient for https://quic.rocks:4433

However, adding --dns_on_client=true --address_family=4 at the end makes this problem free:

$ ./bazel-bin/quiche/masque_client <$PROXY_HOST:$PROXY_PORT> https://quic.rocks:4433 \
> --disable_certificate_verification=true \
> --dns_on_client=true \
> --address_family=4
$ echo "there is no error"

Toy Client not validating path or using Server Preferred Address

I am trying out the Sever Preferred Address feature and have updated the simple_server_bin to send a preferred server address using SetIPv4AlternateServerAddressToSend(). The preferred server address gets sent to the client in the transport parameters but the client doesn’t validate/query the path to the preferred address or starts sending packets to the preferred address.

I am running the two using the following commands with the SPA2 option on the client:

Server:
~/chromium/src# ./out/Debug/quic_server --quic_response_cache_dir=/tmp/quic-data/www.example.org --certificate_file=net/tools/quic/certs/out/leaf_cert.pem --key_file=net/tools/quic/certs/out/leaf_cert.pkcs8 --v=1

Client:
~/chromium/src# ./out/Debug/quic_client --host=HOST --port=6121 https://www.example.org/ --disable_certificate_verification --connection_options=SPA2,SPAD --client_connection_options=SPA2,SPAD --v=1

Can someone please guide me how I edit the toy client so it validates and sends packets on the received server preferred address?

Quic Session Datagram Queue is ignored when considering whether App limited

Doing some prototyping using Quiche with WebTransport+BBR2, I found the datagram queue appeared to be ignored when assessing whether the app is limiting the bitrate:

1. QuicSession::datagram_queue_:

   quiche/quiche/quic/core/quic_session.h

   Line 979 in 9b45510

   QuicDatagramQueue datagram_queue_;

2. QuicSession::WillingAndAbleToWrite() does not consider the datagram queue, and therefore returns false when data is being paced by congestion control:

   quiche/quiche/quic/core/quic_session.cc

   Line 711 in 9b45510

   bool QuicSession::WillingAndAbleToWrite() const {

3. WillingAndAbleToWrite() is used by QuicConnection to determine whether congestion control is app limited:

   quiche/quiche/quic/core/quic_connection.cc

   Line 5277 in 9b45510

   void QuicConnection::CheckIfApplicationLimited() {

In my test, where the pipe is filled with datagrams, BBR constantly marks datapoints as app limited and never gets out of STARTUP phase.

Simply considering a non-empty datagram queue as willingness to write allows BBR to get into PROBE_BW, although I'm sill seeing poor behavior, where the RTT increases quite dramatically from ~40ms (min RTT) to sustained ~200ms when we hit a bitrate close to congestion, but I haven't looked into what's causing it (no draining on latency increase?)

BBR2 logs an ERROR, when there is "bytes in flight" mismatch between QuicUnackedPacketMap and Bbr2NetworkModel

We observed that BBR2 logs the following ERROR:

quiche/quiche/quic/core/congestion_control/bbr2_misc.cc

Line 155 in 4069625

QUIC_LOG_FIRST_N(ERROR, 1)

One scenario that leads to this error:

This can happen during processing of ACKs, when sent packet is at first marked as LOST, but later an ACK for this packet is received. There are two entities that estimate "bytes in flight" and process the ACKs:

1. QuicUnackedPacketMap, see QuicUnackedPacketMap:bytes_in_flight()
   2.Bbr2NetworkModel/BandwidthSampler, see Bbr2NetworkModel::OnCongestionEventStart

When a packet is marked as LOST, QuicUnackedPacketMap is updated and the packet is removed from "bytes in flight".
Later, when a ACK for this packet is received, QuicUnackedPacketMap does NOT modify "bytes in flight" again, as the packet is not in flight anymore. There is the following check:

void QuicUnackedPacketMap::RemoveFromInFlight(QuicTransmissionInfo* info) { if (info->in_flight) { ...

However, such a check is not applied when processing ACKs in Bbr2NetworkModel/BandwidthSampler, and the counter that computes the number of acked bytes is increased despite the fact that the packet is not "in flight" anymore.

This leads to a mismatch between "bytes in flight" from QuicUnackedPacketMap and "bytes in flight" from Bbr2NetworkModel/BandwidthSampler. In that case the ERROR message can be logged.

Undefined behavior sanitizer (ubsan) => Null pointer passed as argument 2, which is declared to never be null.

It is about calling memcpy(...) with null for src argument from WriteBytes(...) which is called from AppendStreamFrame(...) - In Process of packet serialization. It seems this is completely valid for stream frame - To have zero data. It is not good to call memcpy where this causes undefined behavior according to C++ standard:

The behavior is undefined if either dest or src is an invalid or null pointer.

In my memcpy implementation see __nonnull attribute:

extern void *memcpy (void *_restrict __dest, const void *_restrict __src, size_t __n) __THROW __nonnull ((1, 2));

The problematic code is here calling WriteBytes(...) which leads to calling memcpy(...) with nullptr for src argument:

bool QuicFramer::AppendStreamFrame(const QuicStreamFrame& frame,
                                   bool no_stream_frame_length,
                                   QuicDataWriter* writer) {

...
...

  if (!writer->WriteBytes(frame.data_buffer, frame.data_length)) {
    QUIC_BUG(quic_bug_10850_84) << "Writing frame data failed.";
    return false;
  }
  return true;

...
...

}

Any version release?

Hi all,
I find this project has been some years, but has no releases or tags. Can this project release a version? Thanks a lot!

Example Implementations?

Is there a example server and client available for testing purposes?

time-wait handler should take precedence over `OnFailedToDispatchPacket`

I think the order in quic_dispatcher could be improved, here

This block allows an overridden dispatcher to catch a packet that doesn't match a connection ID and perform an alternative action; I'm thinking about using this in Envoy to facilitate hot restart, wherein we would want to pass new connections to the new instance, but continue to pass packets for existing connections to their respective sessions.

With the code as it is now, this would mostly work, but in the case of a connection being in time-wait state, we would incorrectly pass the packet to the new instance.

If I'm understanding things correctly, it seems to me that a packet which can be associated with a time-wait connection is correctly dispatched by doing what time_wait_list_manager_ does with it, so any packet which could take that branch should not fall into the OnFailedToDispatchPacket handler.

Switching the order of the two blocks would achieve this.

XDP Support

Hi - I grepped the source code, but could not find support for XDP underlying quiche. I know Microsoft has added XDP support to their msquic implementation - but they don't seem to support MASQUE. Is there a plan for quiche to support XDP?

Testing masque server proxy and client

Hi @DavidSchinazi

Do you have instructions to test the masque server proxy and client?

I tried the below:

Before i did tested the masque client/server, i tested the simple_client(toy) and simple_server(toy)
and was able to connect and transfer data file.

Then i tested with masque

1. started the server (proxy)

./build/masque_quic_server --cache_dir=/data/quic-root/  --certificate_file=/data/quic-cert/leaf_cert.pem   --key_file=/data/quic-cert/leaf_cert.pkcs8  --cache_dir=/data/quic-root/ --port=9661

Started Open MASQUE server

started the client

./build/masque_quic_client   --disable_certificate_verification=true   127.0.0.1:9661   "https://www.example.org/index.html"

MASQUE is connected 5e56f37d2d6ce2e7 in Open mode

but the data file wasn't sent over from the masque server to the client and i saw dns requests to try to resolve the url.

Failed to connect with client f7f7d2ac0ceccd3d server bebdd806c8411e8f to www.example.org. Error: QUIC_NETWORK_IDLE_TIMEOUT

Do i have to configure the masque server proxy to a quic server? How do i do that (don't see options/examples)?

Should the topology look like below? And how do i configure the proxy?

masque_client<->masque_server_proxy<->quic_server

Thanks,
Raj

Wireshark parser?

Is there a wireshark parser available anywhere? I want to explore this protocol more.
https://gitlab.com/wireshark/wireshark/-/issues/17502

how to enable QUIC_LOG

SyscallWrapper no matching problem when compile quiche on android

Hi,
I try to compile quiche on android(ndk r25c), and I get an error.

/root/quic-client/third_party/quiche/quiche/quic/core/io/socket_posix.inc:81:10: error: no matching function for call to 'SyscallWrapper'
  return SyscallWrapper(&::send, sockfd, buf, len, flags);
         ^~~~~~~~~~~~~~
/root/quic-client/third_party/quiche/quiche/quic/core/io/socket_posix.inc:39:8: note: candidate template ignored: couldn't infer template argument 'Result'
Result SyscallWrapper(Result (*syscall)(Args...), Args... args) {
       ^
1 error generated.

It seems we should specify the template arguments.

ssize_t SyscallSend(int sockfd, const void* buf, size_t len, int flags) {
  return SyscallWrapper<ssize_t, int,const void*, size_t, int>(&::send, sockfd, buf, len, flags);
}

@platforms//os:linux is not a valid configuration key

bazel version: bazel 3.5.1- (@non-git)
commit: 6e7791f
uname -a: Linux cf8c6ca46f1e 4.18.0-348.20.1.el7.aarch64 #1 SMP Wed Apr 13 20:57:50 UTC 2022 aarch64 GNU/Linux

I don't know why it is failed. @platforms//os:linux should match //conditions:default and using -lpthread.

# bazel --output_base=./bazel/output build //quiche:quiche_core --jobs $(nproc)
Starting local Bazel server and connecting to it...
ERROR: /go/quiche/bazel/output/external/boringssl/BUILD:152:11: @platforms//os:linux is not a valid configuration key for @boringssl//:crypto
ERROR: Analysis of target '//quiche:quiche_core' failed; build aborted: Analysis failed
INFO: Elapsed time: 3.050s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (33 packages loaded, 88 targets configured)
    currently loading: @com_google_protobuf//
    Fetching @rules_pkg; fetching

cc_library(
    name = "crypto",
    srcs = crypto_sources + crypto_internal_headers + crypto_sources_asm,
    hdrs = crypto_headers + fips_fragments,
    copts = boringssl_copts_c11,
    includes = ["src/include"],
    linkopts = select({
        # Android supports pthreads, but does not provide a libpthread
        # to link against.
        "@platforms//os:android": [],
        "@platforms//os:macos": [],
        "@platforms//os:windows": ["-defaultlib:advapi32.lib"],
        "//conditions:default": ["-lpthread"],
    }),
    visibility = ["//visibility:public"],
)

a small bug when use quic_client test connection migration with fixed client_connection_id_length

@bnc-google @wu-bin @vasilvv hi，when I use quic_client test connection migration with fixed client_connection_id_length=16，I find a smalle bug：

In the quic_client, when you specify a fixed client_connection_id_length, will call the function QuicConnection::set_client_connection_id。then the client_connection_id_length will be used to call SetExpectedClientConnectionIdLength to set expected_client_connection_id_length_, which is used to decide dst id length when a packet comes in.

On the other hand, the client issued client id with a default fixed length is 8，when connection migration happens, the server will choose an unused client id with length is 8 to send packet to client。 so when then expected_client_connection_id_length_ is not 8, the client will get a wrong length dst id.

optimize SerializedPacket copy/move

in file quic_packet_creator.h
change
virtual void OnSerializedPacket(SerializedPacket serialized_packet) = 0 to
virtual void OnSerializedPacket(SerializedPacket& serialized_packet) = 0
can reduce twice copy/move SerializedPacket.

in file quic_packet_creator.cc

  SerializedPacket packet(std::move(packet_));
  ClearPacket();
  RemoveSoftMaxPacketLength();
  delegate_->OnSerializedPacket(packet); //no need more/copy now,

some other interface also need changed (use reference to replace move )

Does it support the Windows platform

Why don't you use absl::Hash by default here?

quiche/common/quiche_linked_hash_map.h

Line 39 in 5b786df

class Hash = std::hash<Key>,

Hi there, recently I was reading the source code of quiche, and this line confused me a bit. I wonder why you don't use absl::Hash by default instead of std::hash, since std::hash may not have the high entropy in most significant bits that absl::node_hash_map needs? Thank you!

I have a question about compute min_rtt in bbrV2

BandwidthSampler::OnCongestionEvent(QuicTime ack_time,
const AckedPacketVector& acked_packets,
const LostPacketVector& lost_packets,
QuicBandwidth max_bandwidth,
QuicBandwidth est_bandwidth_upper_bound,
QuicRoundTripCount round_trip_count) {
CongestionEventSample event_sample;
.
.
.
for (const auto& packet : acked_packets) {
BandwidthSample sample =
OnPacketAcknowledged(ack_time, packet.packet_number);
if (!sample.rtt.IsZero()) {
event_sample.sample_rtt = std::min(event_sample.sample_rtt, sample.rtt);
}

I think the bbrv2 get the min_rtt in this code,and it's triggered by one ack frame.And one ack frame may include some packet number to be acked.For example,if one ack frame has three acked packet number : 1,2,3; the 3 is largest ack packet number。And the “acked_packets” contain packet 1，2，3. So when compute min_rtt， the code will loop "acked_packets",for packet 1,2,3, it will get min value. But obviously，the packet 1will get min value becaues the packet 1's send time is smallest ,and ack time is same.

So my question is does it will cause the rtt will be smaller than real rtt.I think may be only use packet 3 to compute rtt is more correct？
And the ack frame may contain packet‘s receive timestamp,why it doesn't used in compute rtt? because ietf quic may not contain receive timestamp?

IETF RFC #9000

Hi,
congratulations for the excellent work all of you are doing.

• Is the QUIC implementation provided in this project compliant with the IETF RFC9000?

Thanks,
MQ

Update Platform Implementations Links in README

When I click on the link about platform implementations in README, it shows that "The file does not exist at this commit". Does it mean that those links in the README are outdated? It is welcome to submit a PR to fix this? Thank you.