0-RTT Connection Set-Up
A second performance aspect is about how many round trips it takes before you can send useful HTTP data (say, page resources) on a new connection.
두번째 성능 측면은 새로운 연결에서 유용한 HTTP 데이터(예: 페이지 자원)를 보내기 전까지 몇 번의 왕복 여행이 필요한지에 대한 것입니다.
Some claim that QUIC is two to even three round trips faster than TCP + TLS, but we’ll see that it’s really only one.
일부는 QUIC이 TCP + TLS보다 두 번에서 세 번 정도 왕복 여행이 빠르다고 주장하지만, 실제로는 한 번 만큼 빠른 것을 알게 될 것입니다.
Did You Know?
As we’ve said in part 1, a connection/ typically performs one (TCP) or two (TCP + TLS) handshakes before HTTP requests and responses can be exchanged.
우리가 part 1에서 언급했듯이 연결은 HTTP 요청과 응답이 교환되기 전에 일반적으로 한 번(TCP) 또는 두 번(TCP + TLS)의 핸드셰이크를 수행합니다.
These handshakes exchange initial parameters that both client and server need to know in order to, for example, encrypt the data.
이러한 핸드셰이크는 예를 들어 데이터를 암호화하기 위해 클라이언트와 서버가 모두 알아야 하는 초기 매개 변수를 교환합니다.
As you can see in figure 2 below, each individual handshake takes at least one round trip to complete (TCP + TLS 1.3, (b)) and sometimes two (TLS 1.2 and prior (a)).
아래의 도표 2에서 볼 수 있듯이, 각 개별 핸드셰이크는 적어도 한 번의 왕복이 소요되어 완료됩니다 (TCP + TLS 1.3, (b)) 그리고 때로는 두 번(TLS 1.2 이전(a)) 소요됩니다.
This is inefficient, because we need at least two round trips of handshake waiting time (overhead) before we can send our first HTTP request, which means waiting at least three round trips for the first HTTP response data (the returning red arrow) to come in.
이것은 비효율적입니다, 왜냐하면 우리는 최소한 두 번의 왕복 핸드셰이크 대기 시간이 필요하기 때문에 첫 번째 HTTP 요청을 보낼 수 있기 전에, 이는 첫 번째 HTTP 응답 데이터가 들어오기까지 최소한 세 번의 왕복 대기를 의미합니다(되돌아오는 빨간 화살표)
On slow networks, this can mean an overhead of 100 to 200 milliseconds.
느린 네트워크에서는 100~200밀리초의 오버헤드를 의미할 수 있습니다.
Figure 2: TCP + TLS versus QUIC connection set-up. (Large preview)
You might be wondering why the TCP + TLS handshake cannot simply be combined, done in the same round trip.
너는 TCP + TLS 핸드셰이크를 간단히 결합할 수 없는 이유를 궁금해할 것입니다.
While this is conceptually possible (QUIC does exactly that), things were initially not designed like this, because we need to be able to use TCP with and without TLS on top.
이것은 개념적으로 가능하지만(QUIC이 정확히 그렇게 합니다), 초반에는 이렇게 설계되지 않았습니다. 왜냐하면 우리는 위에 TLS가 있는 TCP와 TLS 없이 사용할 수 있어야 하기 때문입니다.
Put differently, TCP simply does not support sending non-TCP stuff during the handshake.
다르게 말하면, TCP는 단순히 핸드쉐이크 동안 TCP가 아닌 것을 보내는 것을 지원하지 않습니다.
There have been efforts to add this with the TCP Fast Open extension; however, as discussed in part 1, this has turned out to be difficult to deploy at scale.
TCP Fast Open 확장 기능과 함께 이를 추가하려는 노력이 있었지만, 파트 1에서 설명한 바와 같이, 이는 대규모 구축이 어려운 것으로 밝혀졌습니다.
Luckily, QUIC was designed with TLS in mind from the start, and as such does combine both the transport and cryptographic handshakes in a single mechanism.
다행히도 QUIC는 처음부터 TLS를 고려하여 설계되었으며, 따라서 전송 및 암호화 핸드셰이크를 하나의 메커니즘으로 결합합니다
This means that the QUIC handshake will take only one round trip in total to complete, which is one round trip less than TCP + TLS 1.3 (see figure 2c above).
이것은 QUIC 핸드셰이크가 총 한 번의 왕복 여행만으로 완료될 것이라는 것을 의미하며, 이는 TCP + TLS 1.3보다 왕복 여행이 하나 적습니다 (위의 그림 2c 참조).
You might be confused, because you’ve probably read that QUIC is two or even three round trips faster than TCP, not just one.
너는 혼란스러울 수 있습니다. 왜냐하면 QUIC가 TCP보다 두 번이나 세 번이나 라운드트립이 빠르다고 읽은 적이 있기 때문입니다.
This is because most articles only consider the worst case (TCP + TLS 1.2, (a)), not mentioning that the modern TCP + TLS 1.3 also “only” take two round trips ((b) is rarely shown).
대부분의 기사들은 최악의 경우만을 고려합니다. (TCP + TLS 1.2, (a)를) 최신 TCP + TLS 1.3도 두 번의 라운드 트립을 하는 것을 언급하지 않습니다. (b는 거의 표시되지 않습니다.)
While a speed boost of one round trip is nice, it’s hardly amazing.
왕복 한 번의 속도 향상은 좋지만, 그것은 거의 놀랍지 않습니다.
Especially on fast networks (say, less than a 50-millisecond RTT), this will be barely noticeable, although slow networks and connections to distant servers would profit a bit more.
특히 빠른 네트워크에서 (예를 들어, 50밀리초 미만의 RTT), 이것은 거의 눈에 띄지 않을 것입니다. 하지만 느린 네트워크와 먼 서버에 대한 연결은 조금 더 이득을 볼 것입니다.
모르는 단어
inefficient: 비효율적인
원글: https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/
