기능을 외워서 나열하는지, HTTP/1.1의 어떤 제약을 어떻게 풀었고 어디까지가 여전히 실무 기본인지 구조로 설명하는지를 가르는 질문이다.
HTTP/2는 텍스트 기반 HTTP/1.1을 바이너리 프레임/스트림 구조로 바꿔 한 연결 위에서 여러 요청·응답을 멀티플렉싱한다. HPACK으로 반복되는 헤더 필드를 정적/동적 테이블로 압축해 헤더 오버헤드를 끊는다. 이로써 HTTP/1.1의 직렬 처리와 도메인 샤딩·여러 연결로 우회하던 부담이 사라진다. 단 서버 푸시는 스펙엔 있지만 캐시 중복과 우선순위 제어 문제로 크롬이 2022년 기본 비활성화했고, 실무에서는 죽은 기능으로 본다.
도메인 샤딩이나 스프라이트 같은 1.1 우회 기법을 HTTP/2 전환 후 걷어낸 경험이 있다면, 멀티플렉싱의 실효를 그 변화 폭으로 설명할 수 있다
번들/청크 분할 기준을 잡으며 멀티플렉싱을 전제로 작은 청크를 늘릴지 큰 청크로 묶을지 고민했다면, HTTP/2의 연결 구조와 묶어 풀어낼 수 있다
preload/prefetch로 자산 우선순위를 잡아본 적이 있다면, 왜 서버 푸시 대신 그 길을 택했는지로 답변을 시작할 수 있다
Chrome DevTools 워터폴에서 TCP HOL을 체감했다면, HTTP/2의 한계와 HTTP/3 동기를 자기 사례로 이을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.