Welcome back to this series about the new HTTP/3 protocol.
새로운 HTTP/3 프로토콜에 대한 이 시리즈로 돌아온 것을 환영합니다.
In part 1, we looked at why exactly we need HTTP/3 and the underlying QUIC protocol, and what their main new features are.
1부에서는 HTTP/3와 기본 QIC 프로토콜이 정확히 필요한 이유와 그 주요 새로운 기능이 무엇인지 살펴봤습니다.
In this second part, we/ will zoom in on the performance improvements (that QUIC and HTTP/3 bring to the table) (for web-page loading).
두 번째 부분에서는 QUIC과 HTTP/3이 웹 페이지 로딩에 가져오는 성능 개선을 자세히 살펴볼 것입니다
We will, however, also be somewhat skeptical of the impact we can expect from these new features in practice.
그러나 실제로 이러한 새로운 기능으로 인해 예상할 수 있는 영향에 대해서도 다소 회의적입니다.
As we will see, QUIC and HTTP/3 indeed have great web performance potential, but mainly for users on slow networks.
앞으로 보게 되겠지만, QUIC와 HTTP/3는 웹 성능 잠재력이 매우 높지만, 주로 느린 네트워크의 사용자들에게 적합합니다.
If your average visitor is on a fast cabled or cellular network, they probably won’t benefit from the new protocols all that much.
평균 방문자가 빠른 케이블 또는 셀룰러 네트워크에 있는 경우 새 프로토콜의 이점을 크게 누리지 못할 것입니다
However, note that even in countries and regions with typically fast uplinks, the slowest 1% to even 10% of your audience/ (the so-called 99th or 90th percentiles) still stand/ to potentially gain a lot.
그러나 일반적으로 업링크 속도가 빠른 국가 및 지역에서도 가장 느린 1%에서 10%(이른바 99번째 또는 90번째 백분위수)의 오디언스가 여전히 많은 것을 얻을 수 있습니다.
This is because HTTP/3 and QUIC mainly help deal with the somewhat uncommon yet potentially high-impact problems that can arise on today’s Internet.
HTTP/3와 QUIC는 오늘날 인터넷에서 발생할 수 있는 다소 드물지만 잠재적으로 영향력이 큰 문제를 처리하는 데 주로 도움이 되기 때문입니다.
This part is a bit more technical than the first, though it offloads most of the really deep stuff to outside sources, focusing on explaining why these things matter to the average web developer.
이 부분은 첫 번째 부분보다 약간 더 기술적이지만, 대부분의 정말 깊은 내용을 외부 소스로 오프로딩하여 일반 웹 개발자에게 중요한 이유를 설명하는 데 중점을 둡니다.
A Primer On Speed
Discussing performance and “speed” can quickly get complex, because many underlying aspects contribute to a web-page loading “slowly”.
성능과 "속도"에 대한 논의는 많은 기본적인 측면이 "느리게" 웹 페이지 로딩에 기여하기 때문에 빠르게 복잡해질 수 있습니다.
Because we are dealing with network protocols here, we will mainly look at network aspects, of which two are most important: latency and bandwidth.
여기서는 네트워크 프로토콜을 다루고 있기 때문에 네트워크 측면을 주로 살펴보며, 그 중 가장 중요한 것은 지연 시간과 대역폭입니다.
Latency can be roughly defined as the time it takes to send a packet from point A (say, the client) to point B (the server).
지연 시간은 대략 A 지점(예: 클라이언트)에서 B 지점(서버)으로 패킷을 보내는 데 걸리는 시간으로 정의할 수 있습니다.
It/ is (physically) limited by the speed of light or, practically, how fast signals can travel in wires or in the open air.
빛의 속도 또는 실질적으로 신호가 전선이나 야외에서 얼마나 빨리 이동할 수 있는지에 의해 물리적으로 제한됩니다.
This means that latency often depends on the physical, real-world distance between A and B.
이는 지연 시간이 종종 A와 B 사이의 물리적, 실제 거리에 따라 달라진다는 것을 의미합니다.
(On earth), this/ means/ that typical latencies are (conceptually small), (between roughly 10 and 200 milliseconds).
지구상에서는 일반적인 지연 시간이 약 10밀리초에서 200밀리초 사이로 개념적으로 작다는 것을 의미합니다.
However, this is only one way: Responses to the packets also need to come back.
그러나 이것은 한 가지 방법일 뿐입니다: 패킷에 대한 응답도 다시 돌아와야 합니다.
Two-way latency is often called round-trip time (RTT).
양방향 지연 시간은 종종 왕복 시간(RTT)이라고 불립니다.
Due to features such as congestion control (see below), we will often need quite a few round trips to load even a single file.
혼잡 제어(아래 참조)와 같은 기능으로 인해 단일 파일이라도 로드하려면 종종 꽤 많은 왕복이 필요합니다.
As such, even low latencies of less than 50 milliseconds can add up to considerable delays.
따라서 50밀리초 미만의 낮은 지연 시간에도 상당한 지연이 발생할 수 있습니다.
This is one of the main reasons why content delivery networks (CDNs) exist:
이것이 콘텐츠 전달 네트워크(CDN)가 존재하는 주요 이유 중 하나입니다.
They place servers physically closer to the end user in order to reduce latency, and thus delay, as much as possible.
지연 시간을 줄이고 지연 시간을 최대한 줄이기 위해 서버를 최종 사용자에게 물리적으로 더 가깝게 배치합니다.
Bandwidth, then, can roughly be said to be the number of packets that can be sent at the same time.
그렇다면 대역폭은 대략 동시에 전송할 수 있는 패킷 수라고 할 수 있습니다.
This is (a bit more difficult to explain), (because it depends on the physical properties of the medium) (for example, the used frequency of radio waves), the number of users on the network, and also the devices that interconnect different subnetworks (because they typically can only process a certain number of packets per second).
이는 매체의 물리적 특성(예: 전파의 사용 주파수), 네트워크 상의 사용자 수 및 서로 다른 하위 네트워크를 상호 연결하는 장치(일반적으로 초당 특정 수의 패킷만 처리할 수 있기 때문)에 따라 달라지기 때문에 설명하기가 조금 더 어렵습니다.
An often used metaphor is that of a pipe used to transport water.
자주 사용되는 비유는 물을 운반하는 데 사용되는 파이프의 비유입니다.
The length of the pipe is the latency, while the width of the pipe is the bandwidth.
파이프의 길이는 지연 시간이고 파이프의 폭은 대역폭입니다.
On the Internet, however, we typically have a long series of connected pipes, some of which can be wider than others (leading to so-called bottlenecks at the narrowest links).
그러나 인터넷에서는 일반적으로 긴 일련의 연결된 파이프가 있으며, 그 중 일부는 다른 파이프보다 더 넓을 수 있습니다(가장 좁은 링크에서 소위 병목 현상으로 이어짐).
As such, the end-to-end bandwidth between points A and B is often limited by the slowest subsections.
따라서 지점 A와 B 사이의 종단 간 대역폭은 종종 가장 느린 하위 섹션에 의해 제한됩니다.
While a perfect understanding of these concepts is not needed for the rest of this post, having a common high-level definition would be good.
이 게시물의 나머지 부분에는 이러한 개념에 대한 완벽한 이해가 필요하지 않지만 공통적인 높은 수준의 정의가 있으면 좋을 것입니다.
For more info, I recommend checking out Ilya Grigorik’s excellent chapter on latency and bandwidth in his book High Performance Browser Networking.
자세한 내용은 Ilya Grigorik의 저서 High Performance Browser Networking에서 대기 시간과 대역폭에 대한 훌륭한 장을 확인해 보시기 바랍니다.
모르는 단어
somewhat: 어느 정도
skeptical: 회의적인
underlying: 근본적인
latency: 지연시간, 대기시간
원글: https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/
