As a second example, TCP / sees all of the data it transports (as a single “file” or byte stream), (even if we’re actually using it to transfer several files at the same time) (for example, when downloading a web page consisting of many resources).
두번째 예로 TCP는 실제로 여러 파일을 동시에 전송하는데 사용되더라도 모든 전송 데이터를 하나의 파일 또는 바이트 스트림으로 보여줍니다.(예를 들어 많은 리소스로 구성된 웹 페이지를 다운로드 할 때입니다.)
In practice, this / means (that if TCP packets containing data of a single file are lost), (then all other files) / will also get delayed until those packets are recovered.
실제로, 이것은 TCP 패킷이 단일 파일의 데이터를 포함하고 있는 경우 잃어버리면 모든 다른 파일들도 그 패킷이 복구될 때까지 지연될 것이라는 것을 의미합니다.
This is called head-of-line (HoL) blocking.
이것은 head-of-line(HoL)이라고 불리웁니다.
While these inefficiencies are quite manageable in practice (otherwise, we wouldn’t have been using TCP for over 30 years), they do affect higher-level protocols such as HTTP (in a noticeable way).
이런 비효율성들은 실제로는 꽤 관리가능하다, 그렇지 않으면 우리는 30년 넘게 TCP를 사용하지 않았을 것이다. 그것들은 HTTP와 같은 상위 수준 프로토콜에 알아차릴 정도로 영향을 미칩니다.
Over time, we’ve tried (to evolve and upgrade) TCP (to improve some of these issues) and even (introduce new performance features).
시간이 흐름에 따라, 우리는 TCP를 발전시키고 업그레이드하여 이 문제들 중 일부를 개선하기 위해 노력해왔고, 심지어는 새로운 성능 기능을 도입하기도 했습니다.
For example, TCP Fast Open / gets rid of the handshake overhead by allowing higher-layer protocols to send data along from the start.
예를 들어, TCP Fast Open은 상위 계층 프로토콜이 시작부터 데이터를 전송할 수 있도록 함으로써 handshake overhead를 제거합니다.
Another effort is called MultiPath TCP.
또 다른 노력은 다중 경로 TCP라고 불립니다.
Here, the idea is that your mobile phone typically has both Wi-Fi and a (4G) cellular connection, so why not use them both at the same time for extra throughput and robustness?
여기서 아이디어는 일반적으로 핸드폰은 와이파이와 (4G) 셀룰러 연결이 모두 있으므로, 왜 이 둘을 추가 처리량과 견고성을을 위해 동시에 두개를 사용하지 않는 것일까요?
It’s not terribly difficult to implement these TCP extensions.
이것은 이러한 TCP 확장을 구현하는 것이 크게 어렵지 않습니다.
However, it is extremely challenging to actually deploy them at Internet scale.
그러나, 그것을 실제로 인터넷 규모로 배포하는 것은 극도로 어렵습니다.
Because TCP is so popular, almost every connected device / has its own implementation of the protocol on board.
왜내하면 TCP는 매우 인기있습니다, 거의 모든 연결된 장치는 자체 프로토콜의 구현을 가지고 있습니다
If these implementations / are too old, lack updates, or are buggy, / then the extensions won’t be practically usable.
이러한 구현이 너무 오래되었거나, 업데이트가 없거나, 버그가 있다면, 이러한 확장은 실질적으로 사용할 수 없습니다.
(Put differently), all implementations / need to know about the extension in order for it to be useful.
모든 구현은 이 확장 기능을 알아야만 유용할 수 있습니다
This / wouldn’t be (much of a problem) if we were only talking about end-user devices (such as your computer or web server), because those can relatively easily be updated manually.
만약 우리가 오직 end-user 장치(컴퓨터 또는 웹 서버와 같은)에 관하여만 이야기 한다면 문제가 아주 많지 않을겁니다, 왜냐하면 상대적으로 쉽게 수동 업데이트 할 수 있습니다.
However, many other devices / are sitting between the client and the server that also have their own TCP code on board (examples include firewalls, load balancers, routers, caching servers, proxies, etc.).
하지만 클라이언트와 서버 사이에 있는 다른 많은 장치들도 또한 그들 자신의 TCP 코드를 갖고 있는데, (예를 들어 방화벽, 로드 밸런서, 라우터, 캐싱 서버, 프록시 등이 있습니다.)
These middleboxes / are often (more difficult to update) and (sometimes more strict in what they accept).
이 middleboxes들은 자주 업데이트하기 더 어렵고 때로는 받아들이는 것에 대해 더 엄격합니다.
For example, if the device is a firewall, / it might be configured (to block all traffic containing (unknown) extensions).
예를 들어 만약 그 장치가 방화벽이라면, 알려지지 않은 확장을 포함하는 모든 트래픽을 차단하도록 구성될 수 있습니다.
In practice, it turns out that (an enormous number of active) middleboxes make (certain assumptions about TCP) that no longer hold for the new extensions.
실젤로는 수많은 활성 중간 상자들은 TCP에 대해 더 이상 새로운 확장을 허용하지 않는 특정한 가정을 하고 있는 것으로 나타났습니다.
Consequently, it / can take (years to even over a decade) before enough (middlebox) TCP implementations / become updated to (actually) use the extensions on a large scale.
결과적으로, (중간상자) TCP 구현이 충분히 업데이트되어 실제로 대규모로 확장을 사용하기까지 몇 년 이상 걸릴 수 있습니다.
You could say that it has become practically impossible to evolve TCP.
TCP를 진화시키는 것은 사실상 불가능해졌다고 말할 수 있습니다.
As a result, it was clear that we would need a replacement protocol for TCP, rather than a direct upgrade, to resolve these issues.
그 결과, 이 문제들을 해결하기 위해 TCP의 직접적인 업그레이드 대신 대체 프로토콜이 필요하다는 것이 명확해졌습니다
However, (due to the sheer complexity of TCP’s features and their various implementations), creating something new but better from scratch / would be (a monumental undertaking).
그러나 TCP의 기능의 막대한 복잡성과 그들의 다양한 구현 때문에, 제로 베이스에서 새롭고 더 나은 것을 만드는 것은 거대한 작업이 될 것입니다.
As such, in the early 2010s it was decided to postpone this work.
이처럼 2010년대 초반에 이 작업을 연기하기로 결정했습니다.
After all, there were issues not only with TCP, but also with HTTP/1.1.
결국, TCP 뿐만 아니라 HTTP/1.1에서도 문제가 있었기 때문에
We / chose to split up the work / and first “fix” HTTP/1.1, leading to what is now HTTP/2.
우리는 작업을 나누고 먼저 HTTP/1.1을 수정하는 일을 선택했습니다.
그 결과로 현재의 HTTP/2가 나오게 되었습니다.
(When that was done), the work / could start on the replacement for TCP, which is now QUIC.
그 일이 끝난 후에는 TCP의 대체물인 QUIC을 시작할 수 있었습니다.
Originally, we / had hoped to be able to run HTTP/2 on top of QUIC directly, but in practice this would make implementations too inefficient (mainly due to feature duplication).
원래, 우리는 QUIC 위에 직접 HTTP/2를 실행할 수 있을 것을 희망했지만, 실제로 이것은 주로 기능 중복 때문에 구현이 매우 비효율적으로 만들어 질 것입니다.
Instead, HTTP/2 was adjusted (in a few key areas) to make it compatible with QUIC.
대신, 몇 가지 주요 영역에서 HTTP/2가 QUIC과 호환되도록 조정되었습니다.
This tweaked version / was (eventually) named HTTP/3 (instead of HTTP/2-over-QUIC), mainly for marketing reasons and clarity.
이 꼬인 버전은 HTTP/2-over-QUIC 대신에 HTTP/3로 결국 불리어집니다.
이는 주로 마케팅적인 이유와 명확성 때문입니다.
As such, the differences between HTTP/1.1 and HTTP/2 are much more substantial than those between HTTP/2 and HTTP/3.
그러므로, HTTP/1.1과 HTTP/2 사이의 차이점은 HTTP/2와 HTTP/3 사이의 것보다 훨씬 중요합니다.
TAKEAWAY
The key takeaway here is that what we needed was not really HTTP/3, but rather “TCP/2”,/ and we got HTTP/3 “for free” in the process.
여기서 주요 결론은 우리가 실제로 필요한 것은 HTTP/3이 아니라 'TCP/2'였고, 우리는 이 과정에서 HTTP/3를 '무료로' 얻었다는 것입니다.
The main features (we’re excited about) for HTTP/3 (faster connection set-up, less HoL blocking, connection migration, and so on) are really all coming from QUIC.
우리가 기대하는 주요 특징인 HTTP/3 (연결 설정 속도 향상, HoL 차단 감소, 연결 이전 등)은 실제로 모두 QUIC에서 온 것입니다.
모르는 단어
transports: 수송(운송)하다, 수송, 운송
transfer: 옮기다, 갈아타다, 이동하다, 전달하다
inefficiencies: 비효율성
affect: 영향을 미치다, 작용하다, 악영향을 끼치다
evolve: 발전시키다, 진화하다
throughput: 작업처리량
robustness: 견고성
in order for: ~하기 위하여
manually: 수동으로
assumptions: 가정, 억측, 사실이라고 생각함
adjusted: 조정되다.
tweaked: 꼬인
takeaway: 결론
원글: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
0개의 댓글
