This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
The article starts by stating that QUIC is a "transport layer network protocol". However that statement is wrong. QUIC is not listed on IANA Assigned Internet Protocol Numbers list. See: [1]. Actually QUIC works on top of UDP which is a transport layer network protocol. I believe the sentence should be fixed. - Silverbach ( talk) 18:14, 21 March 2021 (UTC)
This sentence: "it does this by establishing a number of multiplexed connections between two endpoints over User Datagram Protocol (UDP)." is wrong. UDP is connectionless and it doesn't make sense to have multiplexed connections. I believe it means that it uses multiple UDP data streams in parallel. — Preceding unsigned comment added by Ingframin ( talk • contribs) 22:27, 2019 January 24 (UTC)
This reads like a marketing page for Google; "As improving TCP is a long-term goal for Google, QUIC aims to be ..." — Preceding unsigned comment added by 2.29.7.103 ( talk) 14:21, 11 April 2016 (UTC)
Reading through forward error correction and what Google describes of what they did, there is no error correction right now. All they have is forward error detection. — Preceding unsigned comment added by Dschonbe ( talk • contribs) 22:04, 30 June 2016 (UTC)
This text is, it seems, very inaccurate.
It does not "aim to update UDP", saying it focuses on "data streams" is pretty nonsensical when talking about protocols, and its main use is not "to run a TCP like flow and congestion control mechanism over UDP" (which would not be useful in itself). — Preceding unsigned comment added by 130.231.12.75 ( talk) 11:44, 2013 February 28 (UTC)
"data streams" are not "nonsensical", is common nomenclature for continuous sensor data and control signal streams that are typically fixed bandwidth continuous streams. Like RTP or other things used in Live Streaming video where delay is unacceptable. Or in the case of robotic control systems where again, it's about pushing the most current information for control systems to operate. - John Sokol — Preceding unsigned comment added by John.sokol ( talk • contribs) 02:38, 2013 June 4 (UTC)
How can I add a disambiguation from QUIC the scientific software: http://www.cs.utexas.edu/~sustik/QUIC/ ? Sustik ( talk) —Preceding undated comment added 05:36, 9 November 2013 (UTC)
The Source Code section does not give any URL's to QUIC-specific source code. Instead it tells what license the code was released under, links to the generic BSD license, and what source code control systems (SCCS) were used to store the source code with URL's pointing to the wikipedia descriptions of the SCCS's. It tells you nothing specific about the QUIC source code, which is what someone would expect to find in a "Soure Code" section for the QUIC protocol, with special interest in a link to the latest source code for a reference or sample implementation (assuming one exists). If it doesn't exist, the section should be removed, as it provides nothing one would expect to find in a 'Source Code' section for a software project. - Astara Athenea ( talk) 19:15, 25 October 2017 (UTC)
The article says that QUIC is not have an acronym. Doesn't QUIC stand for Quick UDP Internet Connections? [1] in vivo veritas 00:36, 19 March 2019 (UTC)
References
"The protocol that was created by Google and taken to the IETF under the name QUIC ... is quite different from the QUIC that has continued to evolve ..."
Mary deusdedith
Use
Mary deus (
talk) 20:19, 12 July 2019 (UTC)
One of the sentences reads "The original Google QUIC was designed to be a general purpose protocol, though it was initially deployed as a protocol to support HTTP(S) in Chromium, while the current evolution of the IETF protocol QUIC is the general purpose transport protocol." (bold emphasis mine).
It basically says both the original Google QUIC and the current IETF QUIC are "general purpose". This is confusing to me.
In fact the entire "Google QUIC (gQUIC)" section of this article seems unnecessary. It doesn't say much besides that Google created QUIC then submitted it to the IETF, which is already in the lead section. It doesn't even mention the acronym gQUIC from the title once.
I think the section should just be deleted. Nog642 ( talk) 11:14, 23 November 2020 (UTC)
I've seen a good edit adding criticism (with proper citations) to the protocol getting reverted. Why? For as much as Google wants to describe QUIC as a silver bullet, most of the problems that arise from using UDP where TCP should be used are unresolved, and the article should reflect this, especially if there are other protocols based on TCP that are aimed specifically at doing what QUIC should do, but more securely. Amideee ( talk) 10:48, 29 October 2021 (UTC)
I restructured and lengthened the lede for balance.
With the complete lack of any adverse consideration in the lede, the protocol should probably have been named BLIS instead.
My framing of small gripes at the bottom is second rate, but at least the possibility of less-than-universal fawning is actually mentioned now.
I'm a one-and-done kind of guy. Revise or revert at will. — MaxEnt 02:24, 13 December 2021 (UTC)
It has clearly lacked it for years, though it's not as bad as it once was (I shall not link the relevant WP:MOS topics, as people are perfectly capable of perusing the MOS themselves and I find that behavior asinine).
It still has a blatantly editorial and unencyclopaedic tone. One only need read for seconds to realize that criticism has no fighting chance in this framework. A significant redesign of the article (requiring the efforts of several people) is necessary. I will try to contribute when I have time.
Sources discussing QUIC's very common use cases for ads, tracking, fingerprinting, data–wasting background connections in the case of mobile, et cetera can likely be found on EFF or similar privacy-focused outlets to achieve better balance.
QUIC connections are often totally optional, so the idea or insinuation that it is some sort of next-generation drop-in replacement for TCP or other established HTTP protocols is pretty silly.
The privacy and security implications of this protocol, owing much to the manner in which companies like Meta are choosing to use it, are disconcerting to say the least. A reader would not glean a single iota of these concerns from this article. Pariah24 ( talk) 13:12, 15 June 2022 (UTC)
I'm not well versed in editing Wikipedia so I wasn't sure if this was a worthwhile edit or not, but Apple's iCloud Private Relay service now uses QUIC. I felt that since it's a widespread service that Apple is rolling out, mentioning it in the "Adoption" topic might be worthwhile.
Sources: https://support.apple.com/en-us/102602, https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay 128.252.89.29 ( talk) 19:39, 8 January 2024 (UTC)
QUIC (Quick UDP Internet Connections) and why it is considered an improvement over traditional TCP-based protocols. QUIC is a modern transport protocol developed by Google that aims to enhance web performance and security. Here are some key points that could be included:
QUIC Overview:
QUIC is designed to address the limitations and performance bottlenecks of TCP (Transmission Control Protocol) by combining features of both transport and security layers into a single protocol. It operates over UDP (User Datagram Protocol) to provide a more efficient and secure way of transmitting data over the internet.
Advantages of QUIC:
QUIC reduces latency and connection establishment times compared to TCP. It achieves this by combining multiple functions, such as encryption and error correction, into a single round trip, reducing the number of handshakes required to establish a connection. (Source: [https://cloud.google.com/blog/products/networking/new-tcp-bbr-comes-to-gcp-your-internet-just-got-faster Google Cloud Blog])
* Multiplexing:
QUIC supports multiplexing multiple streams of data over a single connection, allowing for more efficient use of network resources and faster loading of web pages. (Source: [ https://www.chromium.org/quic+Chromium+Project])
* Connection Migration: QUIC allows connections to seamlessly switch between IP addresses or networks (e.g., from Wi-Fi to mobile data) without interrupting the user experience, improving connection reliability. (Source: [ https://datatracker.ietf.org/doc/html/rfc9000+IETF+RFC+9000])
* Improved Security:
QUIC encrypts data by default, providing confidentiality and integrity of transmitted data. It also incorporates mechanisms to mitigate common network attacks, such as connection amplification attacks. (Source: [ https://tools.ietf.org/html/rfc9000 IETF RFC 9000])
* Adaptive Congestion Control: QUIC includes built-in mechanisms for congestion control, adapting to network conditions more efficiently than TCP, resulting in better performance over lossy or congested networks. (Source: [
https://cloud.google.com/blog/products/gcp/new-quic-protocol-google-cloud-beyond-tcp Google Cloud Blog])
I believe adding a section on QUIC would enhance the article's coverage of modern internet protocols and provide readers with valuable information on emerging technologies. Please feel free to incorporate this feedback into the article for the benefit of Wikipedia users.
Thank you!
Fraaz Alee Fraaz Alee ( talk) 10:45, 2 May 2024 (UTC)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
The article starts by stating that QUIC is a "transport layer network protocol". However that statement is wrong. QUIC is not listed on IANA Assigned Internet Protocol Numbers list. See: [1]. Actually QUIC works on top of UDP which is a transport layer network protocol. I believe the sentence should be fixed. - Silverbach ( talk) 18:14, 21 March 2021 (UTC)
This sentence: "it does this by establishing a number of multiplexed connections between two endpoints over User Datagram Protocol (UDP)." is wrong. UDP is connectionless and it doesn't make sense to have multiplexed connections. I believe it means that it uses multiple UDP data streams in parallel. — Preceding unsigned comment added by Ingframin ( talk • contribs) 22:27, 2019 January 24 (UTC)
This reads like a marketing page for Google; "As improving TCP is a long-term goal for Google, QUIC aims to be ..." — Preceding unsigned comment added by 2.29.7.103 ( talk) 14:21, 11 April 2016 (UTC)
Reading through forward error correction and what Google describes of what they did, there is no error correction right now. All they have is forward error detection. — Preceding unsigned comment added by Dschonbe ( talk • contribs) 22:04, 30 June 2016 (UTC)
This text is, it seems, very inaccurate.
It does not "aim to update UDP", saying it focuses on "data streams" is pretty nonsensical when talking about protocols, and its main use is not "to run a TCP like flow and congestion control mechanism over UDP" (which would not be useful in itself). — Preceding unsigned comment added by 130.231.12.75 ( talk) 11:44, 2013 February 28 (UTC)
"data streams" are not "nonsensical", is common nomenclature for continuous sensor data and control signal streams that are typically fixed bandwidth continuous streams. Like RTP or other things used in Live Streaming video where delay is unacceptable. Or in the case of robotic control systems where again, it's about pushing the most current information for control systems to operate. - John Sokol — Preceding unsigned comment added by John.sokol ( talk • contribs) 02:38, 2013 June 4 (UTC)
How can I add a disambiguation from QUIC the scientific software: http://www.cs.utexas.edu/~sustik/QUIC/ ? Sustik ( talk) —Preceding undated comment added 05:36, 9 November 2013 (UTC)
The Source Code section does not give any URL's to QUIC-specific source code. Instead it tells what license the code was released under, links to the generic BSD license, and what source code control systems (SCCS) were used to store the source code with URL's pointing to the wikipedia descriptions of the SCCS's. It tells you nothing specific about the QUIC source code, which is what someone would expect to find in a "Soure Code" section for the QUIC protocol, with special interest in a link to the latest source code for a reference or sample implementation (assuming one exists). If it doesn't exist, the section should be removed, as it provides nothing one would expect to find in a 'Source Code' section for a software project. - Astara Athenea ( talk) 19:15, 25 October 2017 (UTC)
The article says that QUIC is not have an acronym. Doesn't QUIC stand for Quick UDP Internet Connections? [1] in vivo veritas 00:36, 19 March 2019 (UTC)
References
"The protocol that was created by Google and taken to the IETF under the name QUIC ... is quite different from the QUIC that has continued to evolve ..."
Mary deusdedith
Use
Mary deus (
talk) 20:19, 12 July 2019 (UTC)
One of the sentences reads "The original Google QUIC was designed to be a general purpose protocol, though it was initially deployed as a protocol to support HTTP(S) in Chromium, while the current evolution of the IETF protocol QUIC is the general purpose transport protocol." (bold emphasis mine).
It basically says both the original Google QUIC and the current IETF QUIC are "general purpose". This is confusing to me.
In fact the entire "Google QUIC (gQUIC)" section of this article seems unnecessary. It doesn't say much besides that Google created QUIC then submitted it to the IETF, which is already in the lead section. It doesn't even mention the acronym gQUIC from the title once.
I think the section should just be deleted. Nog642 ( talk) 11:14, 23 November 2020 (UTC)
I've seen a good edit adding criticism (with proper citations) to the protocol getting reverted. Why? For as much as Google wants to describe QUIC as a silver bullet, most of the problems that arise from using UDP where TCP should be used are unresolved, and the article should reflect this, especially if there are other protocols based on TCP that are aimed specifically at doing what QUIC should do, but more securely. Amideee ( talk) 10:48, 29 October 2021 (UTC)
I restructured and lengthened the lede for balance.
With the complete lack of any adverse consideration in the lede, the protocol should probably have been named BLIS instead.
My framing of small gripes at the bottom is second rate, but at least the possibility of less-than-universal fawning is actually mentioned now.
I'm a one-and-done kind of guy. Revise or revert at will. — MaxEnt 02:24, 13 December 2021 (UTC)
It has clearly lacked it for years, though it's not as bad as it once was (I shall not link the relevant WP:MOS topics, as people are perfectly capable of perusing the MOS themselves and I find that behavior asinine).
It still has a blatantly editorial and unencyclopaedic tone. One only need read for seconds to realize that criticism has no fighting chance in this framework. A significant redesign of the article (requiring the efforts of several people) is necessary. I will try to contribute when I have time.
Sources discussing QUIC's very common use cases for ads, tracking, fingerprinting, data–wasting background connections in the case of mobile, et cetera can likely be found on EFF or similar privacy-focused outlets to achieve better balance.
QUIC connections are often totally optional, so the idea or insinuation that it is some sort of next-generation drop-in replacement for TCP or other established HTTP protocols is pretty silly.
The privacy and security implications of this protocol, owing much to the manner in which companies like Meta are choosing to use it, are disconcerting to say the least. A reader would not glean a single iota of these concerns from this article. Pariah24 ( talk) 13:12, 15 June 2022 (UTC)
I'm not well versed in editing Wikipedia so I wasn't sure if this was a worthwhile edit or not, but Apple's iCloud Private Relay service now uses QUIC. I felt that since it's a widespread service that Apple is rolling out, mentioning it in the "Adoption" topic might be worthwhile.
Sources: https://support.apple.com/en-us/102602, https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay 128.252.89.29 ( talk) 19:39, 8 January 2024 (UTC)
QUIC (Quick UDP Internet Connections) and why it is considered an improvement over traditional TCP-based protocols. QUIC is a modern transport protocol developed by Google that aims to enhance web performance and security. Here are some key points that could be included:
QUIC Overview:
QUIC is designed to address the limitations and performance bottlenecks of TCP (Transmission Control Protocol) by combining features of both transport and security layers into a single protocol. It operates over UDP (User Datagram Protocol) to provide a more efficient and secure way of transmitting data over the internet.
Advantages of QUIC:
QUIC reduces latency and connection establishment times compared to TCP. It achieves this by combining multiple functions, such as encryption and error correction, into a single round trip, reducing the number of handshakes required to establish a connection. (Source: [https://cloud.google.com/blog/products/networking/new-tcp-bbr-comes-to-gcp-your-internet-just-got-faster Google Cloud Blog])
* Multiplexing:
QUIC supports multiplexing multiple streams of data over a single connection, allowing for more efficient use of network resources and faster loading of web pages. (Source: [ https://www.chromium.org/quic+Chromium+Project])
* Connection Migration: QUIC allows connections to seamlessly switch between IP addresses or networks (e.g., from Wi-Fi to mobile data) without interrupting the user experience, improving connection reliability. (Source: [ https://datatracker.ietf.org/doc/html/rfc9000+IETF+RFC+9000])
* Improved Security:
QUIC encrypts data by default, providing confidentiality and integrity of transmitted data. It also incorporates mechanisms to mitigate common network attacks, such as connection amplification attacks. (Source: [ https://tools.ietf.org/html/rfc9000 IETF RFC 9000])
* Adaptive Congestion Control: QUIC includes built-in mechanisms for congestion control, adapting to network conditions more efficiently than TCP, resulting in better performance over lossy or congested networks. (Source: [
https://cloud.google.com/blog/products/gcp/new-quic-protocol-google-cloud-beyond-tcp Google Cloud Blog])
I believe adding a section on QUIC would enhance the article's coverage of modern internet protocols and provide readers with valuable information on emerging technologies. Please feel free to incorporate this feedback into the article for the benefit of Wikipedia users.
Thank you!
Fraaz Alee Fraaz Alee ( talk) 10:45, 2 May 2024 (UTC)