[CS/ Network] 컴퓨터 네트워킹 하향식 접근 8판 2장 애플리케이션 계층 / 2.2 웹과 HTTP

yujeongkwon·2023년 7월 18일

CS network

CS / Network

목록 보기

5/27

🕸 2.2 웹과 HTTP

📑 2.2.1 HTTP 개요

HTTP(HyperText Transfer Protocol)

웹의 애플리케이션 계층 프로토콜
메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의
클라이언트 프로그램과 서버 프로그램으로 구현됨.
클라이언트/서버 프로그램(서로다른 종단시스템)은 HTTP 메시지를 교환하여 통신

용어 정리

온디맨드 방식 : 사용자는 원할 때 원하는 정보를 수신할 수 있음.
웹 페이지(문서): 객체들로 구성
객체(object) : 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML 파일，JPEG 이미지，자바스크립트，CCS 스타일 시트 파일，비디오 클립 등)
- 보통 기본 HTML 파일과 여러 참조 객체로 구성
  - 기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조한다.
  - 각 URL은 2개의 요소，즉 객체를 갖고 있는 서버의 호스트 이름과 객체의 경로 이름을 가짐
    ex) http://www.someSchool.edu/someDepartment/picture.gi
    - 호스트 이름: www.someSchool.edu
    - 객체 경로 이름 :/someDepartment/picture.gif
웹 브라우저 : HTTP의 클라이언트 측 구현 ~= 클라이언트
- 요구한 웹 페이지를 보여주고 여러 가지 인터넷 항해와 구성 특성을 제공
웹 서버(Webserver) : HTTP의 서버 측을 구현
- URL로 각각을 지정할 수 있는 웹 객체를 가짐.
- ex) 아파치, 마이크로소프트 인터넷 인포메이션 서버 등
HTTP: 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언로 어떻게 웹 페이지를 전송하는지를 정의
HTTP, TCP 사용에 있어서 통신 과정
1. 사용자가 웹 페이지를 요청
2. 브라우저는 페이지 내부의 객체에 대한 HTTP요청 메시지를 서버에 전송
3. HTTP는 TCP를 전송 프로토콜 사용 - HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작
4. 브라우저(클라이언크)와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속
5. 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 전송
  - 클라이언트 측의 소켓 인터페이스는 클라이언트 프로세스와 TCP 연결 사이에서의 출입구
6. HTTP 서버는 요청 메시지를 받고 소켓 인터페이스를 통해 객체를 포함하는 HTTP 응답 메시지 전송
  - 서버 측의 소켓 인터페이스는 서버 프로세스와 TCP 연결 사이에서의 출입구
7. 클라이언트는 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
계층구조의 장점 : 위 과정에서 HTTP는 데이터의 손실, TCP 서비스를 생각할 필요X
비상태 프로토콜(stateless protocol) : HTTP의 가장 큰 특성중 하나로, 서버는 클라이언트에 관한 어떠한 상태정보도 저장X

🤝🏻2.2.2 비지속 연결과 지속 연결

비지속 연결 : 요구/응답 쌍이 분리된 TCP 연결을 통해 전송
지속 연결 : 모든 요구와 해당하는 응답들이 같은 TCP 연결을 통해 전송
둘 다 되는 HTTP로 알아보쟈~

비지속연결 HTTP(HyperText Transfer Protocol)
ex) 웹 페이지를 서버에서 클라이언트로 전송하는 단계에서
페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고, 이 객체들은 같은 서버에 존재
기본 HTML 파일의 URL : http://www.someSchool.edu/someDepartment/home.index
연결 수행 과정
1. HTTP 클라이언트는 HTTP의 기본 포트 번호 80을 통해 www. someSchool.edu 서버로 TCP 연결 시도
  TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 됨.
2. HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지 전송
  이 요청 메시지는 /someDepartment/home.index 경로 이름을 포함
3. HTTP 서버는 1단계에서 설정된 연결 소켓을 통해 요청 메시지 수신 저장장치로부터 /someDepartment/home.index 객체를 추출
  ,HTTP메시지에 그 객체를 캡슐화
  ,그리고 응답 메시지를 소켓을 통해 클라이언트에 전송
4. HTTP 서버는 TCP에게 TCP 연결을 끊는것 요청
5. HTTP 클라이언트가 응답 메시지를 받으면，TCP 연결이 중단된다.
  ,메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다.
  ,클라이언트는 응답 메시지로부터 파일 추출
  ,HTML 파일을 조사하고 10개의 JPEG 객체에 대한 참조를 찾는다
6. 그 이후에 참조되는 각 JPEG 객체에 대해 처음 네 단계(클라이언트 전송과같음)를 반복
위는 서버가 객체를 보낸 후에 각 TCP 연결이 끊어지므로 비지속 연결
HTTP/1.0 : 비지속 연결, 각 TCP 연결은 하나의 요청 메시지와 하나의 응답 메시지만 전송
위에서는 사용자가 웹 페이지를 요청할 때 11개의 TCP 연결이 만들어짐.
- 동시 연결을 사용하여 응답 시간을 줄일 수 있음.
RTT : 작은 패킷이 클라이언트->서버->클라이언트 과정까지의(전송/수신) 걸리는 시간
- 패킷 전파 지연，중간 라우터와 스위치에서의 패킷 큐잉 지연，패킷 처리 지연 등을 포함
세 방향 핸드셰이크
1. 클라이언트가 작은 TCP 메시지를 서버로 전송
2. 서버는 작은 메시지로 응답
이때 1 RTT가 계산됨.
3. 클라이언트가 다시 서버에게 응답
일단 요청 메시지가 서버에 도착하면 서버는 HTML 파일을 TCP 연결로 보낸다.
이 HTTP 요청/응답은 1 RTT를 필요로 한다.
총 응답 시간 = 2 RTT + HTML 파일을 서버가 전송하는 데 걸리는 시간
단점
- 각 요청 객체에 대한 새로운 연결이 설정, 유지
TCP 버퍼가 할당, TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다.
이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담
- 둘째，앞서 언급한 대로 각 객체는 2 RTT를 필요로 함
(TCP 연결 설정에 1 RTT, 객체를 요청하고 받는 데 1 RTT）.

지속연결 HTTP(HyperText Transfer Protocol)
H1TP/1.1 : 지속 연결
- 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지
- 같은 서버의 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 전송 가능
- 파이프라이닝 : 진행 중인 요청에 대한 응답을 기다리지 않고 연속해서 응답 가능
HTTP 서버는 타임아웃 기간 동안 사용되지 않으면 연결을 닫음
HTTP 디폴트 모드 : 파이프라이닝을 이용한 지속 연결

📧 2.2.3 HTTP 메시지 포맷

HTTP 요청 메시지, HTTP 응답 메시지 이 2개의 포맷을 보쟈~

HTTP 요청 메시지
예시 함 보고시작하자~

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

요청 라인 : HTTP 요청 메시지의 첫 줄
- 3개의 필드를 가짐 - method 필드，URL 필드，HTTP 버전 필드
  - method 필드 : GET, POST, HEAD, PUT, DELETE 등
헤더 라인 : 이후의 줄들
- host : 객체가 존재하는 호스트를 명시
  - 이는 웹 프록시 캐시에서 필요로 함.
- Connection: 브라우저는 서버에게 지속 연결 사용 여부
- User-agent: 사용자 에이전트=서버에게 요청을 하는 브라우저 타입을 명시
  - 서버가 같은 객체의 다른 버전을 다른 브라우저에 보낼 수 있으므로 유용
- Accept-language : 사용자가 원하는 객체의 언어（서버에 존재한다면)
  - 없으면 기본 버전을 전송함
  - HTTP에서 사용 가능한 많은 콘텐츠 협상 헤더 중 하나

HTTP 요청 메시지의 일반 포맷

GET 방식 : 자원을 요청할 때 사용
- body 비워둠 -> body 넣으면 POST ^^
- 보통 GET 방식을 사용하고 요청된 URL의 입력 데이터（폼필드들）를 전송함
- ex) GET 방식에서 두 필드의 입력값이 monkeys와 bananas라면
  확장된 URL : www.somesite.com/animalsearch?monkeys&bananas
POST 방식 : 데이터 생성이나 업데이트와 같은 데이터 처리를 요청
- HTTP 클라이언트는 사용자가 폼을 채워 넣을 때 body에 입력하는 해당 방식 사용
HEAD 방식 : 보통 디버깅을 위해 사용(애플리케이션 개발자)
- GET 방식과 유사
- 서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답하는데，요청 객체는 보내지X
PUT 방식 : 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용
- 리소스 대체, 없으면 생성
DELETE 방식 : 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허용

HEAD 방식은 처음봤는데 저 뒤쪽에 웹캐싱 부분에서 웹 캐싱에 있는 내용이면 웹서버에서는 요청 객체없이 응답만 하자나. 그때 쓰지 않을까라고 생각을 쪼끔 해봤슴둥. (디버깅떄 쓴다했지만,,)

HTTP 응답 메시지
예시 함 보고시작하자~

HTTP/1.1 200 OK
Connection: close
Date: Tuez 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 （CentOS）
L크st-Mod丄fied: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
（데이터 데이터 데이터 데이터 데이터 ...）

3개의 섹션 : 초기 상태 라인(status line), 6개의 헤더 라인，개체 몸체로 이루어짐.
- 상태 라인 - 3개의 필드 : 프로토콜 ‘버전 필드’，'상태 코드’，‘해당 상태 메시지’를 가짐.
- 헤더라인
  1. Connection: close： 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫는데 사용
  2. Date： HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간
  - ~~객체의 생성, 수정된 시간~~
  3. Server： 메시지가 만들어진 웹 서버(여기서는 아파치)
  - HTTP 요청 메시지의 User-agent: 헤더 라인과 비슷하다.
  4. Last-Modified: 객체가 생성되거나 마지막으로 수정된 시간과 날짜
  - 객체를 로컬 클라이언트와 네트워크 캐시 서버(프록시 서버) 캐싱에 매우 중요하다.
  5. Content-Length： 송신되는 객체의 바이트 수
  6. Content-Type： 개체 몸체 내부의 객체 타입(여기서는 HTML 텍스트)
  - 객체 타입은 파일 확장자로 나타내는 것이 아니라 공식적으로 Content-type: 헤더로 나타낸다.
- body는 요청 객체（데이터 데이터 데이터 데이터 데이터 . . .로 표현된 부분）를 포함

HTTP 응답 메시지의 일반 포맷

상태코드
- 200 OK：요청이 성공했고，정상적으로 정보가 응답 전송 완료
- 301 Moved Permanently：요청 객체가 이동
  - 새로운 URL은 응답 메시지의 Location: 헤더에 나와 있다.
  - 클라이언트 소프트웨어는 자동으로 이 새로운 URL을 추출한다.
- 400 Bad Request: 클라이언트의 잘못된 요청(서버가 요청을 이해X 일반 오류 코드)
- 404 Not Found：요청 문서가 서버에 존재하지 않는다.
- 505 HTTP Version Not Supported: 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.
  
  200 번째 성공!
  300 리다이렉트!
  400 클라이언트 실수
  500 서버 실수

🍪 2.2.4 사용자와 서버 간의 상호작용: 쿠키

HTTP 서버는 상태 유지X = 사용자 접속 제한, 사용자 따라 콘텐츠 제공 못함.
-> 이에 대한 해결안 = 쿠키
쿠키 : 쿠키는 사이트가 사용자를 추적 가능하도록 함.
- 비상태 HTTP 위에서 사용자 세션 계층을 생성하는 데 이용 가능
- 사용자 사생활 침해로 논쟁 됨
  요소
  1. HTTP 응답 메시지 쿠키 헤더 라인
  2. HTTP 요청 메시지 쿠키 헤더 라인
  3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
  4. 웹사이트의 백엔드(back-end) 데이터베이스
비록 서버는 클라이언트의 이름을 알 수는 없지만, 1678 사용자가 어느 페이지를，어떤 순서로，몇 시에 방문했는지 정확히 알 수 있다.
- 쇼핑몰에서 클라이언트는 구매 목록을 유지할 수 있고, 세션이 끝날 때 총괄하여 지불 가능
클라이언트가 일주일 후에 재 접속하면, 브라우저는 Cookie: 1678을 헤더 라인에 넣어 요청 메시지를 보내고, 이전에 정보를 기반으로 제품 추천이 가능하다.
클라이언트가 회원가입을 한다면 쇼핑몰은 DB에 추가하고, 쿠키의 식별번호를 클라이언트와 연관 O

클라이언트의 브라우저에 key-value쌍으로 저장되는 작은 데이터입니다. 이는 로그인 상태를 유지하고 식별할 수 있습니다.
1. 서버가 클라이언트로 부터 요청을 받았을 떄, 클라이언트에 관한 정보를 토대로 쿠키를 구성
2. 서버는 클라이언트에게 보내는 응답의 헤더에 쿠키를 담아 전송
3. 클라이언트가 응답을 받으면, 브라우저는 쿠키를 쿠키 디렉터리에 저장

👛 2.2.5 웹 캐싱

웹 캐시(프록시 서버) : 기점 웹 서버(origin Webserver)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체
- 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존
- 아래처럼 브라우저는 사용자의 모든 HTTP 요구가 웹 캐시에 가장 먼저 보내지도록 구성 가능
- 브라우저가 설정되면 객체에 대한 각각의 브라우저 요청은 웹 캐시에 가장 먼저 보내진다.
- ex)콘텐츠 전송 네트워크(Content Distribution Network, CDN=넷플릭스)의 사용
  - CDN 회사는 인터넷 전역을 통해 지역적으로 분산된 캐시를 설치 -> 많은 트래픽을 지역화
- ex) http: //www. someschool. edu/campus. gift 라는 객체를 요청할 때 발생 과정
  1. 브라우저 -> 웹 캐시로 TCP 연결 설정, 웹 캐시에 있는 객체에 대한 HTTP으로 요청
  2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인
    if 저장되어있다면 웹 캐시-> 클라이언트 브라우저로 HTTP 응답 메시지와 객체를 전송
    else 웹 캐시가 객체를 갖고 있지 않다면, 아래 수행
  3. 웹 캐시 -> 기점 서버인 www.someschool.edu로 TCP 연결을 설정 +
    , 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청 +
    , 기점 서버 -> 웹 캐시로 HTTP 응답 메시지와 함께 객체 전송
  4. 웹 캐시가 객체를 수신할 때，객체를 지역 저장장치에 복사 +
    , 웹 캐시 -> 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본 전송
    （클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP 연결을 통해)
- 일반적으로 웹 캐시는 isp가 구입하고 설치
  ex) 대학교 - 캠퍼스 네트워크에 웹 캐시를 설치, 모든 캠퍼스의 브라우저가 이 캐시로 요청
- 장점
  - 클라이언트의 요청에 대한 응답 시간↘
    - 클라이언트-기점 서버 병목 대역폭 << 클라이언트-캐시 병목 대역폭(속도) -> 더욱 효과적
  - 한 기관에서 인터넷으로의 접속하는 링크상의 웹 트래픽을 대폭↘
    - 트래픽↘ = 기관（회사나 대학）은 자주 대역폭을 개선할 필요X 비용↘
    - 인터넷 전체의 웹 트래픽↘ = 모든 애플리케이션을 위한 성능↗

조건부 GET
- 웹 캐싱의 문제 : 캐시 내부에 있는 객체의 복사본 != 새것 (데이터 업데이트 버전:캐싱<서버)
- 해결=조건부 GET
  - HTTP가 가지는 방식
  - 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱하도록
  - HTTP 요청 메시지가 아래 2조건을 갖춘다면 조건부 GET 메시지
  (1) GET 방식을 사용
  (2) If-Modified-Since: 헤더 라인 포함
  
  A(클라이언트), B(클라이언트) , 유정(웹 캐싱), 짱구(서버)라 가정하자
  0 단계
  9월 09일 수요일날 유정인 지금 아무 것도 모르는데, A가 유정이한테 와서
  A : 너 짱구랑 친하지? 너 이번달에 짱구 봤어? 철수랑 유리랑 뭔사이야?
  유정 : 읭? 나 모르는데 ㄱㄷㄱㄷ 짱구한테 물어봄
- 동작 과정
1. 브라우저의 요청을 대신해 프록시 캐시는 -> 웹 서버로 요청메시지 전송
```
  ```
    GET /fruit/kiwi.qif HTTP/1.1
    Host: www.exotiquecu丄sine.com
  ```
```
  1단계
  유정: 얌마 짱구야 유리랑 철수랑 사귐??
2. 웹 서버 -> 캐시에게 객체를 가진 응답 메시지를 보낸다.
```
HTTP/1.1 200 0K
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(데이터 데이터 데이터 데이터 데이터 ...》 
```
  2단계
  짱구 : ㅇㅇ 철수랑 유리랑 사귀던데 오늘(09.09) 가져온 따근한 정보임
  Last-Modified: Wed, 9 Sep 2015 09:23:24
3. 캐시 -> 요청 브라우저에게 객체 전달 + 자신에 객체를 저장
  * 중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장.
  
  3단계
  유정 : 오쒸 철수랑 유리랑 그러코 그런사이였써? 09.09 일기써야지
  Last-Modified: Wed, 9 Sep 2015 09:23:24
  ..
  유정 : ㅇㅇ 사귄대
  A : ㅇ0ㅇ!!
4. 일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어있음.
  - 이 객체는 지난주에 웹서버에서 수정됐으므로 브라우저는 조건부 GET으로 갱신조사를 수행
  - 특히，브라우저는 다음과 같은 내용을 보낸다.
  - If-modified-since: = Last-Modified:
  - 아래 조건부 GET은 서버에게 그 객체가 명시된 날짜 이후 수정된 경우만 그 객체를 보내라함.
```
   ```
      GET /fruit/kiwi.gif HTTP/1.1
      Host: www.exotiquecuisine.com
      If-modified-since: Wed, 9 Sep 2015 09:23:24	
   ```
```
  4단계 일주일 후 09.09 -> 09.16
  B : 유정아 니 철수랑 유리랑 뭔 사인지 앎?
  유정 : ㅇㅇ 나근데 저번주 09.09날 들었는데 오늘(09.16)은 모름 헤어졌을 수 도?
  B: ㅇ-ㅇ?
  따릉따룽 B가 짱구한테 저나함
  B : 얌마! 쨩구 09.09 이후에 철수 유리 사이에 대한 수정된 최신 정보 있음?(If-modified-since: Wed, 9 Sep 2015 09:23:24) 철수랑 유리랑 뭔 사이임?
5. 변경되지 않았다면 웹 서버 -> 클라이언트에게 다음과 같은 응답 메시지를 보낸다.
```
   ```
      HTTP/1.1 304 Not Modified
      Date: Sat, 10 Oct 2015 15:39:29
      Server: Apache/1.3.0 (Unix)
      《빈개체 몸체》
   ```
```
  5단계
  짱구 : 그거 유정이한테 말했을 때랑 달라진거 없음 -0- (If-modified-since: = Last-Modified:)
  금마 알고있음(Not Modified) 또 말하기 귀찮으니까 니 옆에 있는 유정이한테 물어보셈;;(304) 폰빠떄리 아까움 ㅡㅡ
- 조건부 GET에 대해 웹 서버 응답 메시지 보냄 but 요청된 객체를 포함X -> 대역폭 절약
- 404 Not Modified : 클라이언트에게 요청 객체의 캐싱된 복사본을 사용하라는 것을 의미

📄 2.2.6 HTTP/2

HTTP/2의 주요 목표
- 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간↘
- 요청 우선순위화
- 서버 푸시
- HTTP 헤더 필드의 효율적인 압축 기능 등
- HOL(Head of Line) 블로킹 문제를 해결하기 위해 하나의 웹 페이지를 전송하기 위한 병렬 TCP의 수를 줄이거나 제거
  - ㄴ 아래 HTTP/1.1 과 달리 소켓↘ + TCP 혼잡제어 가능
클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경한 것
<-> HTTP/1.1
- 지속적인 TCP 연결을 이용, 웹 페이지당 오직 하나의 TCP 연결
  ㄴ-> 서버에서의 소켓 수↘, 전송되는 각 웹 페이지는 공정한 네트워크 대역폭을 가짐
- but! 하나의 TCP상에서 웹 페이지의 모든 객체를 보내면 HOL(Head of Line) 블로킹 문제 발생
- HOL(Head of Line) 블로킹 문제 : 큰놈 먼저 보내면 뒤에 작은애들 졸라 기다려야 함.
- HTTP/1.1 는 여러개(6개까지) TCP 연결해서 이를 해결함. + 더 많은 대역폭

HTTP/2 프레이밍

각 메시지를 작은 프레임으로 자르고，같은 TCP 연결에서의 요청과 응답 메시지를 끼워 넣기 = 인터리빙
이후 반대편에서 재조립
1. 서버가 HTTP 응답을 보낼 때, 응답은 프레이밍 서브 계층에 의해 처리되며 프레임들로 나눠짐.
2. 응답의 헤더 필드는 하나의 프레임이 되며 메시지 본문은 하나의 프레임으로 쪼개진다
3. 서버의 프레이밍 서브 계층에서 응답 프레임들이 끼워진 후 하나의 지속적인 TCP 연결에서 전송
4. 클라이언트에 도착하면 프레이밍 서브 계층에서 모두 재조립되며 브라우저에 의해 처리됨.
1. 마찬가지로，클라이언트의 HTTP 요청은 프레임으로 쪼개지고 끼워짐.
+) 프레이밍 서브 계층은 프레임을 비이너리 인코딩도 함.
- 바이너리 프로토콜은 파싱하기에 더 효율적,더 작은 프레임 크기，에러에 더 강건

메시지 우선순위화 및 서버푸싱

메시지 우선순위화(message prioritization) : 개발자이 요청들의 상대적 우선
순위를 조정 -> 애플리케이션의 성능을 최적화
클라이언트가 여러개 동시요청，각 메시지에 1~256 사이의 가중치를 부여 -> 요청에 우선순위를 매김
높은 수치일수록 높은 우선순위 -> 가장 높은 우선순위의 요청을 위한 프레임 먼저
특정 클라이언트 요청에 대해 여러 개의 응답을 전송 가능
- 원래 응답 외에도 서버는 추가적인 객체를 클라이언트에게 푸시
- 한 객체에 대한 HTTP 요청을 기다리는 대신 서버는 HTML 페이지를 분석 + 필요 객체들 식별
- 해당 객체들에 대한 요청이 도착하기도 전에 해당 객체들을 클라이언트로 전송 -> 추가지연 없앰

HTTP/3

QUIC
- 트랜스포트 프로토콜
- UDP 프로토콜 위에 위치하는 애플리케이션 계층에 구현
- 메시지 멀티플렉싱(인터리빙)，스트림별 흐름 제어，저지연 연결 확립 등 여러 특징 가짐
HTTP/3
- QUIC 위에서 작동하도록 설계된 새로운 HTTP 프로토콜
- 표준화된 상태는 아님
- HTTP/2 특징들은 QUIC에 의해 포함 -> HTTP/3은 훨씬 더 간단한 설계