QUIC - 版本历史

Riguz：/* Fast handshakes */

2024-01-31T09:58:13Z

Fast handshakes

←上一版本		2024年1月31日 (三) 09:58的版本
第38行：		第38行：

	QUIC allows a client to include data already in the 0-RTT handshake. This feature allows a client to deliver data to the peer as fast as it possibly can, and that then of course allows the server to respond and send data back even sooner.		QUIC allows a client to include data already in the 0-RTT handshake. This feature allows a client to deliver data to the peer as fast as it possibly can, and that then of course allows the server to respond and send data back even sooner.

			== Encryption ==
			The transport security used in QUIC is using TLS 1.3 (RFC 8446) and there are never any unencrypted QUIC connections.

	=Algorithm=		=Algorithm=

Riguz：/* Fast handshakes */

2024-01-31T09:56:54Z

Fast handshakes

←上一版本		2024年1月31日 (三) 09:56的版本
第36行：		第36行：

	QUIC offers both 0-RTT and 1-RTT connection setups, meaning that at best QUIC needs no extra round-trips at all when setting up a new connection. The faster of those two, the 0-RTT handshake, only works if there has been a previous connection established to a host and a secret from that connection has been cached.		QUIC offers both 0-RTT and 1-RTT connection setups, meaning that at best QUIC needs no extra round-trips at all when setting up a new connection. The faster of those two, the 0-RTT handshake, only works if there has been a previous connection established to a host and a secret from that connection has been cached.

			QUIC allows a client to include data already in the 0-RTT handshake. This feature allows a client to deliver data to the peer as fast as it possibly can, and that then of course allows the server to respond and send data back even sooner.

	=Algorithm=		=Algorithm=

Riguz：/* Overview */

2024-01-31T09:56:15Z

Overview

←上一版本		2024年1月31日 (三) 09:56的版本
第32行：		第32行：

	QUIC offers flow control on both connection and streams.		QUIC offers flow control on both connection and streams.

			==Fast handshakes ==

			QUIC offers both 0-RTT and 1-RTT connection setups, meaning that at best QUIC needs no extra round-trips at all when setting up a new connection. The faster of those two, the 0-RTT handshake, only works if there has been a previous connection established to a host and a secret from that connection has been cached.

	=Algorithm=		=Algorithm=
	== UDP Datagram 1 - Client hello ==		== UDP Datagram 1 - Client hello ==

2024年1月31日 (三) 09:55 Riguz

2024-01-31T09:55:07Z

@@ 第14行： / 第14行： @@
 * Transport extensibility
 * Optional unreliable delivery
 =Algorithm=
 == UDP Datagram 1 - Client hello ==

Riguz：/* FAQ */

2024-01-31T09:54:50Z

FAQ

←上一版本		2024年1月31日 (三) 09:54的版本
第189行：		第189行：

	== UDP Datagram 8 - Close connection ==		== UDP Datagram 8 - Close connection ==

	~~= FAQ =~~
	~~== How does QUIC ensure reliability if it uses UDP? ==~~
	While UDP is not a reliable transport, QUIC adds a layer on top of UDP that introduces reliability. It offers re-transmissions of packets, congestion control, pacing and the other features otherwise present in TCP.
	~~Data sent over QUIC from one end-point will appear in the other end sooner or later, as long as the connection is maintained.~~

	~~By doing the fragmentation, retransmission and acknowledgements in QUIC.<ref>https://www.quora.com/How-does-QUIC-ensure-reliability-if-it-uses-UDP</ref>~~

	~~=== Streams ===~~
	Similar to SCTP, SSH and HTTP/2, QUIC features separate logical streams within the physical connections. A number of parallel streams that can transfer data simultaneously over a single connection without affecting the other streams.

	A connection is a negotiated setup between two end-points similar to how a TCP connection works. A QUIC connection is made to a UDP port and IP address, but once established the connection is associated by its "connection ID".

	Over an established connection, either side can create streams and send data to the other end. '''Streams are delivered in-order and they are reliable, but different streams may be delivered out-of-order.'''


	~~[[Image:Quic-stream-order.webp\|600px]]~~

	~~QUIC offers flow control on both connection and streams.~~

Riguz：/* Streams */

2024-01-31T09:45:28Z

Streams

←上一版本		2024年1月31日 (三) 09:45的版本
第205行：		第205行：


	[[Image:Quic-stream-order.~~png~~\|600px]]		[[Image:Quic-stream-order.webp\|600px]]

	QUIC offers flow control on both connection and streams.		QUIC offers flow control on both connection and streams.

Riguz：/* Streams */

2024-01-31T09:44:57Z

Streams

←上一版本		2024年1月31日 (三) 09:44的版本
第203行：		第203行：

	Over an established connection, either side can create streams and send data to the other end. '''Streams are delivered in-order and they are reliable, but different streams may be delivered out-of-order.'''		Over an established connection, either side can create streams and send data to the other end. '''Streams are delivered in-order and they are reliable, but different streams may be delivered out-of-order.'''


			[[Image:Quic-stream-order.png\|600px]]

	QUIC offers flow control on both connection and streams.		QUIC offers flow control on both connection and streams.



	Ref:		Ref:

Riguz：/* How does QUIC ensure reliability if it uses UDP? */

2024-01-31T09:43:14Z

How does QUIC ensure reliability if it uses UDP?

@@ 第192行： / 第192行： @@
 = FAQ =
 == How does QUIC ensure reliability if it uses UDP? ==
 Ref:

Riguz：/* UDP Datagram 8 - Close connection */

2024-01-31T09:38:34Z

UDP Datagram 8 - Close connection

←上一版本		2024年1月31日 (三) 09:38的版本
第189行：		第189行：

	== UDP Datagram 8 - Close connection ==		== UDP Datagram 8 - Close connection ==

			= FAQ =
			== How does QUIC ensure reliability if it uses UDP? ==


	Ref:		Ref:

Riguz：/* Server initial keys cacl */

2024-01-31T08:00:14Z

Server initial keys cacl

←上一版本		2024年1月31日 (三) 08:00的版本
第171行：		第171行：
	server initial header protection key: 440b2725e91dc79b370711ef792faa3d		server initial header protection key: 440b2725e91dc79b370711ef792faa3d
	</syntaxhighlight>		</syntaxhighlight>

			=== Server Hello ===

			The server responds with an "Initial" packet in return. This packet contains the "ServerHello" TLS record, used to continue the TLS 1.3 encrypted session negotiation.

			[[Image: server hello packet.png\|600px]]

	== UDP Datagram 3 - Server handshake finished ==		== UDP Datagram 3 - Server handshake finished ==

QUIC - 版本历史

Riguz：​/* Fast handshakes */

Riguz：​/* Fast handshakes */

Riguz：​/* Overview */

2024年1月31日 (三) 09:55 Riguz

Riguz：​/* FAQ */

Riguz：​/* Streams */

Riguz：​/* Streams */

Riguz：​/* How does QUIC ensure reliability if it uses UDP? */

Riguz：​/* UDP Datagram 8 - Close connection */

Riguz：​/* Server initial keys cacl */

Riguz：/* Fast handshakes */

Riguz：/* Fast handshakes */

Riguz：/* Overview */

Riguz：/* FAQ */

Riguz：/* Streams */

Riguz：/* Streams */

Riguz：/* How does QUIC ensure reliability if it uses UDP? */

Riguz：/* UDP Datagram 8 - Close connection */

Riguz：/* Server initial keys cacl */