The Big Changes
So, how exactly does QUIC improve upon TCP, then?
그렇다면 TCP에서 QUIC는 정확히 어떻게 개선됩니까?
What is so different?
무엇이 다르니?
There / are / several new concrete features and opportunities in QUIC /(0-RTT data, connection migration, more resilience to packet loss and slow networks) /that/ we will discuss in detail in the next part of the series.
QUIC에는 여러 가지 새로운 구체적인 기능과 기회가 있습니다 (0-RTT 데이터, 연결 이전, 패킷 손실 및 느린 네트워크에 대한 더 많은 탄력성), 이를 다음 시리즈의 다음 부분에서 자세히 논의할 것입니다.
However, all of these new things basically boil down to four main changes:
그러나 이 모든 새로운 것들은 기본적으로 4가지 변화로 요약됩니다.
QUIC deeply integrates with TLS.
QUIC supports multiple independent byte streams.
QUIC uses connection IDs.
QUIC uses frames.
QUIC는 TLS와 깊이 통합합니다.
QUIC는 여러 개의 독립적인 바이트 스트림을 지원합니다.
QUIC는 연결 ID를 사용합니다.
QUIC는 프레임을 사용합니다.
Let’s take a closer look at each of these points.
각각의 포인트를 더 자세하게 살펴봅시다.
THERE IS NO QUIC WITHOUT TLS
As mentioned, TLS (the Transport Layer Security protocol) /is/ in charge of securing and encrypting data sent over the Internet.
TLS (전송 계층 보안 프로토콜)은 인터넷을 통해 전송되는 데이터를 안전하게 암호화하는 역할을 담당합니다."
When you use HTTPS, your plaintext HTTP data / is / first encrypted by TLS, before being transported by TCP.
HTTPS를 사용할 때, 당신의 평문 HTTP 데이터는 TCP에 의해 전송되기 전에 먼저 TLS에 의해 암호화됩니다.
Did You Know?
TLS’s technical details, luckily, aren’t really necessary here;
다행스럽게도 TLS의 기술적 세부사항은 여기서 꼭 필요한 것은 아닙니다;
you just need to know that encryption is done using some pretty advanced math and very large (prime) numbers.
당신은 단지 (암호화가 상당히 고급 수학 매우 큰 (소수)숫자를 사용하여 수행된다는 것을) 알아야 합니다.
These mathematical parameters / are negotiated between the client and the server (during a separate TLS-specific cryptographic handshake).
이러한 수학적 매개변수는 client와 서버 간의 별도의 TLS 특정 암호화 handshake 중에 협상됩니다.
(Just like the TCP handshake), this negotiation / can take some time.
이 협상은 어느 정도의 시간이 걸릴 수 있습니다.
In older versions of TLS (say, version 1.2 and lower), this typically takes two network round trips.
TLS의 (1.2버전보다 낮은) 오래된 버전은 일반적으로 두번의 네트워크 왕복이 소요됩니다
Luckily, newer versions of TLS (1.3 is the latest) reduce this to just one round trip.
다행스럽게도, TLS의 (1.3보다 최신)새로운 버전은 딱 한번의 왕복으로 줄었습니다.
This / is mainly because TLS 1.3 / (severely) / limits the different mathematical algorithms / (that can be negotiated to just a handful (the most secure ones)).
이것은 주로 TLS 1.3이 협상할 수 있는 다양한 수학적 알고리즘을 가장 안전한 소수의 것들로 엄격하게 제한하기 때문입니다.
This / means (that the client can just immediately guess which ones the server will support), instead of having to wait for an explicit list, saving a round trip.
이것은 클라이언트가 서버가 지원할 알고리즘을 즉시 추측할 수 있게 됨을 의미합니다. 대신에 명시적 목록을 기다리지 않아도 되므로, 라운드 트립을 절약할 수 있습니다.
In the early days of the Internet, encrypting traffic was quite costly in terms of processing.
인터넷 초기에는 트래픽을 암호화하는 데 처리 비용이 상당히 많이 들었습니다. 또한 모든 사용 사례에 필요한 것은 아닙니다.
Additionally, it was also not deemed necessary for all use cases.
추가적으로 또한 모든 사용 사례에 필요한 것으로 간주되지도 않았습니다.
Historically, TLS / has (thus) been (a fully) separate protocol (that can optionally be used on top of TCP).
따라서 역사적으로 TLS는 TCP 위에서 선택적으로 사용할 수 있는 완전히 별개의 프로토콜이었습니다.
This is why we have a distinction between HTTP (without TLS) and HTTPS (with TLS).
이것이 우리가 HTTP(TLS 없음)와 HTTPS(TLS 있음)를 구별하는 이유입니다.
Over time, our attitude (towards security on the Internet) / has, of course, changed to “secure by default”.
시간이 지나면서 인터넷 상에서 보안에 대한 우리의 태도는 당연히 "기본 보안"으로 바뀌었습니다.
(As such, while) HTTP/2 / can, (in theory, run directly over TCP without TLS (and this is even defined in the RFC specification as cleartext HTTP/2), no (popular)) web browser actually supports this mode.
따라서 HTTP/2는 이론적으로 TLS 없이 TCP를 통해 직접 실행할 수 있지만(이것은 심지어 RFC 사양에서 cleartext HTTP/2로 정의되어 있음), 어떤 (인기 있는) 웹 브라우저도 실제로 이 모드를 지원하지 않습니다.
In a way, the browser vendors made a conscious trade-off for more security at the cost of performance.
어떤 면에서 브라우저 공급업체는 성능 비용으로 더 많은 보안을 위해 의식적으로 절충했습니다.
Given this clear evolution towards always-on TLS (especially for web traffic), it / is no surprise (that the designers of QUIC decided to take this trend to the next level).
(특히 웹 트래픽의 경우) 상시 TLS를 향한 이러한 명확한 발전을 고려할 때, QUIC의 설계자들이 이러한 추세를 다음 단계로 끌어올리기로 결정한 것은 놀라운 일이 아닙니다.
Instead of simply not defining a cleartext mode for HTTP/3, they elected to ingrain encryption deeply into QUIC itself.
HTTP/3에 대한 명확한 텍스트 모드를 정의하지 않는 대신 암호화를 QUIC 자체에 깊이 포함시키기로 결정했습니다.
While the first (Google-specific versions of QUIC) used a custom set-up for this, standardized QUIC / uses the existing TLS 1.3 itself directly.
최초의 구글 고유 버전의 QUIC가 이를 위해 사용자 정의 설정을 사용했다면, 표준화된 QUIC는 기존 TLS 1.3 자체를 직접 사용합니다.
(For this), it/ (sort of) breaks/ the typical clean separation /between protocols / (in the protocol stack), (as we can see in the previous image).
이 경우 이전 이미지에서 볼 수 있듯이 프로토콜 스택에서 프로토콜 간의 일반적인 깨끗한 분리를 깨뜨립니다.
(While) TLS 1.3 / can (still) run independently (on top of TCP), (QUIC instead) (sort of) encapsulates / TLS 1.3.
TLS 1.3은 여전히 TCP 위에서 독립적으로 실행될 수 있지만, QUIC는 TLS 1.3을 캡슐화합니다.
(Put differently), there / is/ no way to use QUIC without TLS; QUIC (and, by extension, HTTP/3)/ is /always fully encrypted.
즉, TLS 없이는 QUIC를 사용할 방법이 없습니다. QUIC(그리고, 확장으로, HTTP/3)는 항상 완전히 암호화됩니다.
Furthermore, QUIC encrypts almost all of its packet header fields as well;
또한 QUIC는 거의 모든 패킷 헤더 필드를 암호화합니다.
transport-layer information/ (such as packet numbers, which are never encrypted for TCP) is/ no longer readable by intermediaries in QUIC (even some of the packet header flags are encrypted).
전송 계층 정보(예: TCP용으로 암호화되지 않은 패킷 번호)는 QUIC의 중개자에 의해 더 이상 읽을 수 없습니다(패킷 헤더 플래그 중 일부도 암호화됨).
For all this, QUIC / first uses /the TLS 1.3 handshake more or less as you would with TCP to establish the mathematical encryption parameters.
이 모든 것에 대해 QUIC는 먼저 TCP와 마찬가지로 TLS 1.3 핸드셰이크를 사용하여 수학적 암호화 파라미터를 설정합니다.
After this, however, QUIC /takes/ (over and encrypts the packets itself)/, whereas with TLS-over-TCP, TLS does its own encryption.
그러나 이 후 QUIC는 패킷 자체를 인수하여 암호화하는 반면 TLS-over-TCP에서는 TLS가 자체 암호화를 수행합니다.
(This seemingly small) difference / represents/ a fundamental conceptual change / towards always-on encryption (that is enforced at ever lower protocol layers).
(이처럼 작은) 차이는 점점 더 낮은 프로토콜 계층에서 시행되는 상시(Always-on) 암호화에 대한 근본적인 개념 변화를 나타냅니다.
This approach/ provides /QUIC with several benefits:
이 접근 방식은 QUIC에게 다음과 같은 몇 가지 이점을 제공합니다.
01. QUIC is more secure for its users.
01. QUIC는 사용자에게 더 안전합니다.
There / is / no way to run cleartext QUIC, so there are also fewer options for attackers and eavesdroppers to listen in on.
Cleartext QUIC을 실행할 방법이 없으므로 공격자와 도청자가 들을 수 있는 옵션도 줄어듭니다.
(Recent research has shown how dangerous HTTP/2’s cleartext option can be.)
(최근 연구에 따르면 HTTP/2의 Cleartext 옵션이 얼마나 위험할 수 있는지 알 수 있습니다.)
02. QUIC’s connection set-up is faster.
02. QUIC의 연결 설정이 더 빠릅니다.
While for (TLS-over-TCP), both protocols / need their own separate handshakes,
TLS-over-TCP의 경우, 두 프로토콜 모두 각각의 개별 핸드셰이크가 필요하지만,
QUIC/ instead combines/ (the transport and cryptographic handshake) into one, saving a round trip (see image above).
QUIC는 전송 핸드셰이크와 암호화 핸드셰이크를 하나로 결합하여 왕복을 절약합니다(위 이미지 참조).
We’ll discuss this in more detail in part 2.
이에 대해서는 2부에서 좀 더 자세히 다루도록 하겠습니다.
03. QUIC can evolve more easily.
03. QUIC는 더 쉽게 진화할 수 있습니다.
(Because it is fully encrypted), middleboxes/ (in the network) can/ no longer observe and interpret its inner workings like they can with TCP.
완전히 암호화되어 있기 때문에 네트워크의 중간 상자는 TCP에서 할 수 있는 것처럼 내부 작동을 더 이상 관찰하고 해석할 수 없습니다.
Consequently, they /also can /no longer break (accidentally) (in newer versions of QUIC) (because they failed to update).
따라서 업데이트에 실패했기 때문에 새로운 버전의 QUIC에서 (우발적으로) 더 이상 깨질 수 없습니다.
If we want to add new features to QUIC in the future,/ we/ “only” have/ (to update the end devices), (instead of all of the middleboxes as well).
향후 QUIC에 새로운 기능을 추가하려면 모든 중간 상자가 아닌 최종 장치를 "오직" 업데이트해야 합니다.
Next to these benefits, however, there are also some potential downsides to extensive encryption:
그러나 이러한 이점 외에도 광범위한 암호화에는 몇 가지 잠재적인 단점이 있습니다.
01. Many networks will hesitate to allow QUIC.
01. 많은 네트워크가 QUIC를 허용하는 것을 주저할 것입니다.
Companies/ might want/ to block it on their firewalls, because (detecting unwanted traffic becomes more difficult).
원치 않는 트래픽을 탐지하는 것이 더 어려워지기 때문에 기업은 방화벽에서 이를 차단하기를 원할 수 있습니다.
ISPs and intermediate networks / might block it because (metrics (such as) average delays / and packet loss percentages/ are (no longer) (easily) available), (making it more difficult to detect and diagnose problems).
평균 지연 및 패킷 손실 비율과 같은 메트릭을 더 이상 쉽게 사용할 수 없어 문제를 감지하고 진단하기가 더 어려워지기 때문에 ISP와 중간 네트워크가 이를 차단할 수 있습니다.
This all/ means /that QUIC (will probably never be universally available), (which we’ll discuss more in part 3).
이 모든 것은 QUIC가 결코 보편적으로 사용할 수 없다는 것을 의미하며, 이에 대해서는 3부에서 더 자세히 설명하겠습니다.
02. QUIC has a higher encryption overhead.
QUIC는 암호화 오버헤드가 더 높습니다.
QUIC /encrypts/ each individual packet/ (with TLS), /(whereas TLS-over-TCP) can encrypt several packets at the same time.
QUIC는 각 개별 패킷을 TLS로 암호화하는 반면, TLS-over-TCP는 여러 패킷을 동시에 암호화할 수 있습니다.
This /potentially makes/ QUIC slower (for high-throughput scenarios) (as we’ll see in part 2).
이로 인해 처리량이 많은 시나리오의 경우 QUIC 속도가 느려질 수 있습니다(파트 2에서 살펴보겠지만).
03. QUIC makes the web more centralized.
QUIC은 웹을 보다 중앙 집중화합니다.
A complaint/ (I’ve encountered often) is/ (something like), “QUIC/ is being/ pushed (by Google) because it gives them full access to the data while sharing none of it with others”.
제가 자주 접하는 불만 사항은 "QuIC는 다른 사람들과 공유하지 않으면서 데이터에 대한 완전한 액세스를 제공하기 때문에 Google에 의해 밀려나고 있습니다."와 같습니다.
I mostly disagree with this.
저는 대부분 이것에 동의하지 않습니다.
First, QUIC/ doesn’t hide/ more (or less!) user-level information/ (for example, which URLs you are visiting) /from outside observers than TLS-over-TCP does (QUIC keeps the status quo).
첫째, QUIC는 TLS-over-TCP보다 외부 관찰자의 사용자 수준 정보(예: 방문 중인 URL)를 더 많이 숨기지 않습니다(QUIC는 현상 유지).
Secondly, while Google initiated the QUIC project,/ the final protocols/ we’re talking about today were designed/ by a much wider team / (in the Internet) Engineering Task Force (IETF).
둘째, 구글이 QUIC 프로젝트를 시작하는 동안, 오늘 우리가 이야기할 마지막 프로토콜은 인터넷 엔지니어링 태스크 포스(IETF)의 훨씬 더 광범위한 팀에 의해 설계되었습니다.
IETF’s QUIC/ is/ (technically) very different from Google’s QUIC.
IETF의 QUIC은 구글의 QUIC과 기술적으로 매우 다릅니다.
Still, (it is true that) the people/ (in the IETF) are/ mostly from larger companies (like Google and Facebook) and CDNs (like Cloudflare and Fastly).
그럼에도 불구하고, IETF에 있는 사람들은 대부분 구글, 페이스북과 같은 대기업과 클라우드플레어, 패스트리와 같은 CDN 출신인 것은 사실입니다.
Due to QUIC’s complexity,/ it/ will be mainly those companies/ (that have the necessary know-how/ to correctly and performantly deploy), for example, HTTP/3 in practice.
QUIC의 복잡성으로 인해 실제 HTTP/3와 같이 정확하고 효과적으로 구현할 수 있는 필요한 노하우를 보유하고 있는 기업들이 주를 이을 것입니다.
This will probably lead to more centralization in those companies, which is a real concern.
이는 아마도 해당 기업에서 더 많은 중앙 집중화로 이어질 것이며, 이는 진정한 우려입니다.
Takeaway
The key takeaway here is that QUIC is deeply encrypted by default.
여기서 중요한 점은 QUIC가 기본적으로 심층 암호화되어 있다는 것입니다.
This/ not only improves/ its security and privacy characteristics, /but also helps /its deployability and evolvability.
이는 보안 및 개인 정보 보호 특성을 개선할 뿐만 아니라 배포 가능성과 진화 가능성에도 도움이 됩니다.
It makes the protocol a bit heavier to run but, in return, allows other optimizations, (such as faster connection establishment).
프로토콜을 실행하기에 조금 더 무겁게 만들지만 그 대신 더 빠른 연결 설정과 같은 다른 최적화를 허용합니다.
모르는단어
concrete: 구체적인
integrates: 통합하다
negotiated: 협상하다
cryptographic: 암호의
explicit: 명시적, 명백한, 뚜렷한
distinction: 구별
vendors: 공급업체
conscious: 의식적으로
ingrain: 포함시키다, 뿌리 내리다
encapsulates: 캡슐화
eavesdroppers: 도청자
potential: 잠재적인
downsides: 단점
hesitate: 망설이다.
diagnose: 진단하다
원글: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
