학습목표
- Web 서비스 및 네트워크에서 성능 하락의 가장 큰 요인은?
- HTTP/0.9부터 HTTP/2의 특징을 이해하고 적용해보자.
HTTP를 배우기 전에 Web 서비스 및 네트워크에서 성능 하락의 가장 큰 요인은?
- Bandwith(대역폭), Latency(지연시간)이라고 판단된다.
- Bandwith: 단위 시간 동안 한 지점에서 다른 지점으로 전달될 수 있는 최대 데이터양을 의미(단위: bps)
- Latency: 네트워크에서 하나의 데이터 패킷이 한 지점(출발 지점)에서 다른 지점(도착 지점)으로 전송될 때 소요되는 시간.
ex) 웹사이트 메인화면에 이미지가 표출(렌더링) 되는 시간 = 지연시간(latency)
- 2010 Mike Belshe, google Report
- Bandwith보다는 Latency를 줄이는 방향이 성능 향상에 더 중요하다 라는 사실을 입증하게 됨.
HTTP/0.9
- HTTP의 초기 버전이며, GET Method만 통신이 가능했고 HTTP 헤더가 없기 때문에 전송은 HTML 문서만 가능
HTTP/1
- 헤더가 추가되었으며, Content-Type이 추가되어 HTML이외의 타입도 전송 가능
- 1 Request & 1 Response per connection 이므로 (모든 Connection마다 3-way Handshake를 수행)
서버 부하가 증가되며 매번 새로운 연결로 성능이 저하된다.
HTTP/1.1
- HTTP/1의 1 Request & 1 Response per connection을 보안하고자 Persistnet Connection이 도입됨
(Persistent Connection: 지정한 timeout동안 Connection을 닫지 않는 방식)
- Pipelining을 도입하여 응답 대기 시간을 축소(= HTTP 요청은 순차적으로 응답을 받아 대기 시간이 길게 됨)
(Pipelining: 하나의 Connection에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식)
- Pipelining 기법으로 대기 시간을 줄이는 것은 좋았지만, 아래와 같은 문제가 발생
- Head of Line Blocking : Clinet의 첫번 째 Request가 Server에서 처리하는 시간이 길어진다면 2번째, 3번째.. 요청도 대기해야하는 문제 발생
- Header 구조의 중복 : method(GET) host(000.com) 등 Request 마다 header 구조가 중복 될 가능성이 높음
HTTP/2
- 기존 HTTP/1.X 버전의 성능 향상에 초점을 맞춘 프로토콜
- HTTP 메시지 전송 방식의 변화
- Binary Frameing 계층 사용(Text보다 Binary로 보내기 때문에 파싱, 전송 속도가 빨라지며, 오류 가능성이 낮아진다)
- Fram을 사용하기 때문에, 메시지 간의 순서가 사라짐(Head of Line Blocking 문제 해결)
- Stream Prioritiztion: 리소스간 우선순위 설정이 가능
- Server Push: Client에서 요청하지 않았는데도, Server에서 데이터를 전송시켜준다.
예를 들어, HTML 소스를 요청한다면, js와 css파일이 필요할 것으로 간주하여 Server에서 Push
- Header Compression: 헤더를 압축하여 헤더의 크기를 줄여 페이지 로드 시간 감소
HTTP/1.1과 HTTP/2의 속도차이
HTTP/2의 한계
HTTP/2는 TLS 기반이기 때문에 TCP의 3-way Handshake와 TLS의 Handshake가 동시에 이루어지기 때문에 성능 이슈가 있음
이를 해결하기 위해 HTTP/3은 UDP를 사용하여 문제를 해결 함.
Reference