웹 통신 성능과 효율성을 개선하기 위해 설계된 프로토콜

UDP 를 기반으로 만들어진 QUIC 프로토콜을 사용. 본래 이름은 HTTP-over-QUIC 프로토콜

QUIC
(Quick UDP Internet Connection)

UDP 상에 구현된 다중 전송 프로토콜

HTTP 의 시맨틱스는 동일. (요청 메소드, 상태 코드, 메시지 필드)

차이점은 기반이 되는 트랜스포트(Transport) 가 다르다.

TCP 가 아닌 QUIC 으로의 전환의 이유는 Head of Line Blocking 문제를 해결하기 위함이다.

주요 기능

• 연결 설정 시간 단축
  핸드쉐이크가 아닌 라운드 트립(Round-Trip) 으로 연결 설정과 해제를 수행
• 혼잡 제어 개선
  TCP 와 달리 독자적인 혼잡 제어 알고리즘을 사용
  네트워크 상태를 모니터링 하고 혼잡한 네트워크 에서도 대역폭을 효율적으로 사용하여 패킷 손실을 최소화
• Head of Line Blocking 없는 멀티 플렉싱
  여러 개의 데이터 스트림을 동시에 전송 가능
  하나의 데이터 스트림이 지연되더라도 다른 스트림의 데이터 전송은 계속된다
• 전달 오류 수정
  패킷 손실이나 손상이 감지되면 해당 패킷을 재전송하여 오류를 수정하고 완전하고 정확한 데이터를 수신 가능
• 연결 마이그레이션
  네트워크 환경이 변경되거나 사용자가 이동하는 경우에도 연결을 유지하면서 다른 네트워크로의 이동이 가능하다. 네트워크 전환이나 이동 시에도 연결 손실 없이 서비스를 계속 이용할 수 있다 (ex: WiFi -> 셀룰러)

1 사용자의 입력 처리

주소창에 google.com 이 입력되면 접두사로 https:// 접두사를 추가한다.

2 DNS 조회

입력된 도메인을 ip 로 변환하는 과정을 아래의 순서로 수행한다

2.1 브라우저 DNS 캐시 확인

2.2 로컬 시스템 DNS 캐시 확인

2.3 DNS 서버 조회

2.3.1 재귀적 DNS 조회
DNS 서버에 데이터가 존재하는지 확인. DNS 캐시에도 해당 정보가 없다면 다른 DNS 서버들에게 정보를 요청. 이 과정은 재귀적으로 수행된다

2.3.2 루트 DNS 서버 조회
DNS 서버가 루트 DNS 서버에게 어느 TLD(Top-Level Domain) 서버가 ".com" 도메인을 관리하는지 정보 요청

2.3.3 TLD DNS 서버 조회
TLD DNS 서버의 정보를 받은 후 해당 정보를 바탕으로 ".com" TLD 서버에게 "google.com" 도메인을 관리하는 Authoritative DNS 서버가 무엇인지 정보 요청

2.3.4 Authoritative DNS 서버 조회
Authoritative DNS 서버에게 "google.com" 의 IP 주소 요청

2.4 IP 주소 수신

3 초기 연결 설정

3.1 TCP 연결 설정: DNS 서버를 통해 알아낸 IP 주소로 TCP 연결 수립

3.2 TLS/SSL handshake 수행 (HTTPS 인 경우)

4 HTTP 요청 송신

4.1 요청 준비: HTTP 요청 생성

4.2 패킷 분할

4.3 패킷 전송

4.4 전송 제어: TCP 프로토콜 사용하여 패킷 손실이나 오류 발생 시 재전송

5 네트워크를 통한 패킷 전송

5.1 라우터

5.2 스위치

5.3 백본 네트워크

6 패킷 도착 및 서버 처리: 서버의 네트워크 스택 에서 패킷 재결합

6.1 Servlet container 가 요청 수신

6.2 Front controller 가 uri 매핑에 따른 handler 수행

6.3 응답 HTML 화면 생성

6.4 응답 객체 생성

7 패킷 분할

TCP 계층 -> IP 계층 패킷화 -> 패킷 전송 -> 전송제어

8 응답 수신 및 연결 종료

서버로 부터 응답 수신 -> 4 way handshake 로 연결 종료, 페이지 렌더링