HTTP 완벽 가이드 - 10장 : HTTP/2.0

10장. HTTP/2.0

등장 배경

HTTP/1.1은 심각한 회전 지연이 발생하기 때문에 성능 문제가 존재한다.

이를 해결하기위해 구글에서 SPDY를 개발하였고 이것이 바로 HTTP/2.0의 기반이 되었다.

HTTP/2.0

HTTP/2.0 또한 TCP Connection 위에서 동작한다.(초기화는 클라이언트)

요청과 응답을 길이가 정의된 한 개 이상의 Frame에 담는다.(HTTP Header는 압축되어 담김)

이 Frame들은 하나의 스트림을 통해 보내진다.

한 개의 TCP Connection은 여러 Frame을 만들 수 있기 때문에 HTTP Transaction을 동시에 처리하는 것이 가능해진다.

또한 스트림에 대한 흐름 제어와 우선 순위를 부여할 수 있다.(중요한 리소스가 담겨있는 스트림에 우선 순위를 부여)

문법만 변경하였을 뿐 header의 의미들은 이전과 동일하다.

---

프레임

HTTP/2.0에서는 모든 메시지가 프레임에 담겨서 전송된다.

---

스트림

클라이언트와 서버 사이에서 교환되는 프레임들의 독립된 양방향 시퀀스이다.

• HTTP Transaction(요청 + 응답)은 하나의 스트림을 통해 이뤄짐

여러 개의 스트림을 통해 동시에 요청이 전송될 수 있다.

중요도에 따라 우선순위를 부여할 수도 있다.(하지만 무조건 우선순위대로 처리된다는 보장은 없음)

• OS에서 프로세스의 우선 순위를 부여할 수 있지만 반드시 그대로 처리된다는 보장은 없는 것과 동일하네?

스트림은 상대방과 협상 없이 일방적으로 만들기 때문에 TCP 패킷을 주고받는 시간 낭비가 없어진다.

한번 사용한 스트림 식별자는 다시 사용할 수 없기 떄문에 식별자가 고갈되는 현상이 일어날 수 있다.

이 때는, 커넥션을 다시 맺자!

---

헤더 압축

헤더를 압축하고 조각으로 쪼개어 전송한다. 수신측에서는 쪼개어진 조각을 재조립하고 헤더의 압축을 해제한다.

---

Push

HTTP/2.0의 새로운 기능인 푸시는 서바가 클라이언트에게 필요하다고 생각하는 리소스라면 명시적인 요청이 없어도 능동적으로 클라이언트에게 보내준다.

이는 서버 입장에서 클라이언트가 어떤 리소스를 요구할 것인지를 미리 알 수 있는 상황에서 유용하게 사용할 수 있다.

• HTML 요청시 CSS 푸시

이는 추후에 발생할 요청을 미리 능동적으로 보내는 것이기 때문에 트래픽, 회전 지연을 줄일 수 있다.

푸시를 할 때 서버는 PUSH_PROMISE라는 프레임을 보내 푸시할 것임을 클라이언트에게 알려주어야한다.

• 동일한 리소스를 요청하는 상황을 막기위해

클라이언트가 PUSH_PROMISE를 전달받게되면 해당 스트림은 예약상태가 된다.

클라이언트가 푸시를 원치않는다면 RST_STREAM을 보내면된다. 이 프레임을 보내면 해당 스트림이 즉시 종료된다.

푸시 주의 사항

• 프록시가 중간에서 서버가 푸시하는 리소스를 재대로 전달하지 않을 수도 있다.(받지 않았음에도 클라이언트에게 전달할 수도)
• 안전, 캐시 가능, 본문을 포함하지 않은 요청에 대해서만 푸시
• 명시적으로 보낸 요청과 연관된 리소스여야함
• 동일 출처 정책에 따라 검사를 해야함
• SETTINGS_ENABLE_PUSH를 0으로 설정하면 푸시를 끌 수 있음

---

보안 이슈

중개자 캡슐화 공격

긴 커넥션 유지로 인한 개인정보 누출 우려

---

HTTP/1.1 vs HTTP/2.0

HTTP/1.1을 사용하는 큐넷과 HTTP/2.0을 사용하는 네이버에 캐시를 비운 후 개발자 도구를 키고 접속해봤습니다.

네이버

큐넷

더 많은 요청이 수행되고 더 많은 데이터를 불러오는 네이버가 더 빠르게 로드되는 것을 확인할 수 있습니다.