산업계는 경량 웹사이트를 만드는 것 외에는 모든 것을 시도하고 있음. 90년대 후반에는 빠른 인터넷 연결이 있다면 페이지가 작고 자바스크립트가 거의 없었음. 오늘날에도 이러한 빠르게 로딩되는 경량 페이지를 찾을 수 있으며, 경험은 거의 초현실적임. 사용자 경험이 더 좋았다면 더 견딜 수 있었을 것임.
Google에서 순수 JS Speedtest를 작업했음. 당시 Ookla는 Flash 기반이어서 Chromebooks에서 작동하지 않았음. TCP가 다양한 요소에 어떻게 반응하는지 많이 배웠음. 이 기사를 보고 결과가 예상대로라고 생각함. 왜냐하면 흐름 제어를 커널에서 사용자 공간으로 밀어내기 때문임. TCP는 흐름 제어와 시퀀싱을 가지고 있음. QUIC은 이를 스스로 관리하게 함. TCP 혼잡 제어는 현대 연결 속도와 맞지 않아 BRR과 같은 새로운 알고리즘이 필요하지만 비용이 듦. 가장 큰 교훈은 네트워크 테스트에서 지연 시간의 중요성을 간과하지 말아야 한다는 것임. 아시아나 호주에 사는 사람들은 100ms RTT 지연 시간이 얼마나 치명적인지 알 것임. QUIC의 오버헤드가 실질적으로 중요하지 않을 수 있음. 왜냐하면 단일 TCP 연결이나 QUIC 스트림을 통한 실제 대역폭이 원시 대역폭보다 훨씬 낮을 수 있기 때문임.
Curl의 창시자이자 유지보수자인 Daniel Stenberg가 HTTP/3에 대해 블로그에 글을 올렸음. HTTP/3의 높은 CPU 사용률을 강조했으며, CPU가 처리량을 제한할 수 있다고 언급함. 이는 구현의 미성숙함 때문인지, QUIC의 설계 방식 때문인지 궁금함.
빠른 인터넷에서 UDP+QUIC+HTTP/3 스택이 TCP+TLS+HTTP/2에 비해 데이터 전송 속도가 최대 45.2% 감소한다고 함. 아직 논문을 다 읽지는 않았지만, 600 Mbit/s 이하가 "느린 인터넷"으로 간주됨.
QUIC은 빠른 인터넷에서 충분히 빠르지 않다고 함. 900mbps 속도를 quic+http3에서 달성했으며, TLS 구현이 나쁜 것인지, 초기 구현이 비효율적인 것인지 의문임. CPU 사용률은 gen 2 epyc 코어에서 평균 5% 정도였음.
여기서 "빠른 인터넷"은 500Mbps이며, quic이 CPU에 의존적이기 때문이라고 함. 테스트 시스템이 기본 소비자 시스템인지 고성능 데스크탑에서도 문제인지 확인하지 않았음.
QUIC은 지연 시간에 최적화되어 있다고 생각했음. 웹페이지와 비디오 게임에서 작은 패킷을 많이 로드하는 데 최적화되어 있음. 전체 처리량만 측정할 때는 부족할 수 있음. 프로토콜 수준에서 대용량 파일 전송이나 고대역폭 비디오 스트리밍을 감지하여 덜 CPU 집약적인 것으로 전환할 수 있는지 궁금함. QUIC이 TCP보다 하드웨어/OS 수준에서 최적화가 덜 된 것인지 궁금함.
QUIC이 TLS 모드가 없는 것을 바람. 로컬에서 개발할 때 가끔은 전송되는 것을 보고 싶고, 이는 불필요한 마찰을 추가함.
Hacker News 의견
산업계는 경량 웹사이트를 만드는 것 외에는 모든 것을 시도하고 있음. 90년대 후반에는 빠른 인터넷 연결이 있다면 페이지가 작고 자바스크립트가 거의 없었음. 오늘날에도 이러한 빠르게 로딩되는 경량 페이지를 찾을 수 있으며, 경험은 거의 초현실적임. 사용자 경험이 더 좋았다면 더 견딜 수 있었을 것임.
Google에서 순수 JS Speedtest를 작업했음. 당시 Ookla는 Flash 기반이어서 Chromebooks에서 작동하지 않았음. TCP가 다양한 요소에 어떻게 반응하는지 많이 배웠음. 이 기사를 보고 결과가 예상대로라고 생각함. 왜냐하면 흐름 제어를 커널에서 사용자 공간으로 밀어내기 때문임. TCP는 흐름 제어와 시퀀싱을 가지고 있음. QUIC은 이를 스스로 관리하게 함. TCP 혼잡 제어는 현대 연결 속도와 맞지 않아 BRR과 같은 새로운 알고리즘이 필요하지만 비용이 듦. 가장 큰 교훈은 네트워크 테스트에서 지연 시간의 중요성을 간과하지 말아야 한다는 것임. 아시아나 호주에 사는 사람들은 100ms RTT 지연 시간이 얼마나 치명적인지 알 것임. QUIC의 오버헤드가 실질적으로 중요하지 않을 수 있음. 왜냐하면 단일 TCP 연결이나 QUIC 스트림을 통한 실제 대역폭이 원시 대역폭보다 훨씬 낮을 수 있기 때문임.
Curl의 창시자이자 유지보수자인 Daniel Stenberg가 HTTP/3에 대해 블로그에 글을 올렸음. HTTP/3의 높은 CPU 사용률을 강조했으며, CPU가 처리량을 제한할 수 있다고 언급함. 이는 구현의 미성숙함 때문인지, QUIC의 설계 방식 때문인지 궁금함.
빠른 인터넷에서 UDP+QUIC+HTTP/3 스택이 TCP+TLS+HTTP/2에 비해 데이터 전송 속도가 최대 45.2% 감소한다고 함. 아직 논문을 다 읽지는 않았지만, 600 Mbit/s 이하가 "느린 인터넷"으로 간주됨.
QUIC은 빠른 인터넷에서 충분히 빠르지 않다고 함. 900mbps 속도를 quic+http3에서 달성했으며, TLS 구현이 나쁜 것인지, 초기 구현이 비효율적인 것인지 의문임. CPU 사용률은 gen 2 epyc 코어에서 평균 5% 정도였음.
여기서 "빠른 인터넷"은 500Mbps이며, quic이 CPU에 의존적이기 때문이라고 함. 테스트 시스템이 기본 소비자 시스템인지 고성능 데스크탑에서도 문제인지 확인하지 않았음.
QUIC은 지연 시간에 최적화되어 있다고 생각했음. 웹페이지와 비디오 게임에서 작은 패킷을 많이 로드하는 데 최적화되어 있음. 전체 처리량만 측정할 때는 부족할 수 있음. 프로토콜 수준에서 대용량 파일 전송이나 고대역폭 비디오 스트리밍을 감지하여 덜 CPU 집약적인 것으로 전환할 수 있는지 궁금함. QUIC이 TCP보다 하드웨어/OS 수준에서 최적화가 덜 된 것인지 궁금함.
QUIC이 TLS 모드가 없는 것을 바람. 로컬에서 개발할 때 가끔은 전송되는 것을 보고 싶고, 이는 불필요한 마찰을 추가함.