QUIC FAQ

이 문서는 https://www.chromium.org/quic/quic-faq 를 번역한 문서입니다. 오역 및 의역이 매우 많을 가능성이 있습니다. :)

QUIC 작동 방법에 관한 문서가 있습니까?

2015 년 4 월, 우리는 QUIC에서 보았던 성능상의 이점에 대한 블로그 게시물을 썼습니다.
게시물: https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html

Chrome을 빌드하지 않고 간이 클라이언트, 서버를 구축 할 수 있습니까?

넵. quic_server 타겟은 Chrome전체를 빌드하지 않고 만들 수 있습니다. playing-with-quic 문서에 따라 독립 실행 형 QUIC 클라이언트 및 서버를 빌드하고 실행할 수 있습니다.

테스트 서버에서 어떻게 Chrome을 목표로 지정합니까?

HTTP 서버가 있다면 다음과 같은 응답 헤더를 보내야합니다.

Alternate-Protocol: quic:<QUIC server port>

그런 다음 평상시처럼 크롬을 실행할 수 있으며, 자동으로 QUIC를 사용하게 됩니다.

간이 QUIC 서버로만 테스트하는 경우 다음과 같이 할 수 있습니다.

% chrome --disable-setuid-sandbox --enable-quic --origin-to-force-quic-on=localhost:6121 http://localhost:6121/

문제 해결에 도움이 필요하면 –v = 1을 사용하여 QUIC 서버를 실행하거나 playing-with-quic 문서를 확인하십시오.

전송 계층이 암호화되는 이유는 무엇입니까?

QUIC(혼잡 관련 정보)에 대한 전송 정보는 전송이 항상 발전할 수 있다는 것을 보장하기 위해 주로 암호화 됩니다. 만약 ACK또는 checksum이 올바른 경우, 우려되는 것은 결국 미들박스는 혼잡정보를 분석하기 시작할 것이고 어떠한 전향적인 변화와도 단절될 것입니다. 이것이 현재 TCP의 문제입니다. 유선 형식은 인터넷 상의 현재 하드웨어의 기대 때문에 협상 옵션들과 실제적으로 사용 불가능한 유연한 기능을 허용합니다.

물론 아랫쪽인 미들 박스에서 세부 정보를 숨기는 것은 엔드 포인트를 제어 할 수 없다면 QUIC를 분석하기 어렵다는 것을 의미합니다. tcpdump 툴은 패킷의 비율과, 패킷의 틈을 시각화 할 수 있지만, 어떤 패킷이 페이로드, 혼잡 정보, 재전송 등을 포함하고 있는지 판단하기 어렵습니다. 클라이언트와 서버측 코드는 사용자 공간 처리 중에 이러한 정보를 쉽게 덤프할 수 있도록 설계되어 있습니다. 이러한 로그는 tcpdumps보다 더 많은 데이터를 포함할 수 있으며 커널 수준의 패킷 추적과 함께 묶어 전체 시스템에서 대기 시간을 더 잘 파악할 수 있습니다.