HTTP
웹에서 데이터를 주고받는데 사용되는 프로토콜
HTTP/1.0
HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었다.
-> RTT를 증가시킴
RTT증가
RTT란?
패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는시간
= 패킷 왕복 시간
서버로부터 파일을 가져올 때마다 TCP의 3-way handshake를 계속해서 열어야 하기 때문에 RTT가 증가하는 단점이 있다.
RTT의 증가를 해결하기 위한 방법
매번 연결할 때마다 RTT가 증가하니 서버에 부담이 많이 가고 사용자 응답시간이 길어진다.
-> 해결법 : 이미지 스플리팅, 코드압축, 이미지 Base64인코딩 등
이미지 스플리팅
많은 이미지를 다운로드 받게되면 과부하가 걸리기 때문에, 많은 이미지가 합쳐 있는 하나의 이미지를 다운로드받고, 이를 기반으로 background-image의 position을 이용하여 이미지를 표기하는 방법.
쉬운 표현으로 이해-> 큰 이미지를 여러 개의 작은 조각으로 나누는 과정을 말하는데, 이렇게 나눈 작은 이미지 조각들은 병렬적으로 전송된다. 그 후에, 이 조각들은 클라이언트에서 다시 조합되어 원본 이미지를 복원한다.
코드 압축
코드를 압축해서 개행문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법
-> 개행문자, 띄어쓰기 등이 사라져서 용량이 줄어든다. 네트워크 대역폭을 절약하고 성능을 향상 시킬 수 있음.
이미지 Base64 인코딩
이미지파일 -> 64진법의 문자열로 인코딩하는 방법.
이 방법을 쓰면 서버랑 연결하고 HTTP요청을 할 필요가 없다.
그만큼 웹 페이지의 로딩시간이 단축된다. 하지만 용량이 커져서 HTML문서 파일 크기 자체가 커지고, 인코딩된 이미지는 캐싱이 불가능하다.
디코딩 오버헤드.
HTTP/1.1
HTTP/1.0에서 발전된 형태.
매번 TCP 연결을 하는게 아니라 한 번 TCP 초기화 한 이후에 keep-alive 옵션으로 여러개의 파일을 송수신할 수 있다.
HTTP/1.0에도 keep-alive 있었지만 표준화가 안되어있었고, HTTP/1.1부터 표준화 되어서 기본옵션으로 바뀜.
- keep-alive ?
저번에 작성 했던 글 링크 참고 https://velog.io/@p65454/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-3
핵심은 keep-alive 를 통해서 TCP 3-way handwhake가 1번만 발생하게 하는 것.
-
장점
기존 대비 한 번의 연결에서 다 처리가 되기때문에 오버헤드 감소, 로딩시간 단축 등의 사용자 경험을 향상시킬 수 있다. 요청이 또 들어와도 기존 연결을 재사용하니까 서버의 부하가 감소된다. -
단점
TCP연결을 유지하는데 자원을 더 쓰게된다. TCP 연결을 유지하면서 일부 리소스가 유휴 상태로 대기하게 되므로, 일부 리소스가 블록되는 상황이 발생할 수 있다. 이는 네트워크 자원(네트워크 포트에 할당된 메모리)의 효율성을 저하시킨다. 보안에 취약하다
HOL Blocking
Head Of Line Blocking.
네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능저하현상
그림처럼 image.jpg 와 stles.css, data.xml을 다운받을 때 보통은 순차적으로 잘 받아지지만 image.jpg가 느리게 받아진다면 그 뒤에 있는 것들이 대기하게 되며 다운로드가 지연되는 상태가 된다.
무거운 헤더 구조
HTTP/1.1 의 헤더에는 쿠키 등 많은 메타데이터가 들어 있고 압축이 되지 않아 무겁다.
메타데이터 : 다른 데이터에 대한 설명이나 정보를 제공하는 데이터
리소스 vs 트래픽
리소스 는 서버에 있는 정보의 단위. 사용자가 요청할 수 있는 모든 정보
트래픽 은 이러한 리소스가 네트워크를 통해 전송되는 데이터 양.
즉, 서버는 리소스를 제공하고, 클라이언트가 이를 요청하고 전송하는 과정에서 트래픽이 발생한다.
HTTP/2
HTTP/1.x 보다 지연시간을 줄이고 응답시간을 빠르게 할 수 있으며 펄티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜
멀티플렉싱
여러 개의 스트림을 사용하여 송수신 하는 것
이를 통해 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작 가능
- 스트림
시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름
-> 단일 연결로 병렬로 요청을 주고 받을 수가 있다. HTTP/1.x 에서 발생하는 문제인 HOL Blocking 을 해결 할 수 있음
헤더 압축
HTTP/1.x 에서는 크기카 큰 헤더라는 문제가 있다.
이것을 HTTP/2 에서는 헤더 압축을 써서 해결하는데 , 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가진다.
허프만 코딩
문자열을 문자 단위로 쪼개 빈도수를 세서 빈도가 높은 정보는 적은 비트로 표현하고, 빈도가 낮은 정보는 비트수를 많이 써서 표현해서 전테 데이터의 표현에 필요한 비트양을 줄이는 원리
서버 푸시
HTTP/1.1 에서는 클라이언트가 서버에 요청을 해야 파일을 다운받을 수 있다.
HTTP/2 는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.
서버푸시 O 쪽을 보면 css파일 요청을 안해도 바로 css파일을 푸시해준다.
-
장점
로딩시간 단축, 라운드트립 감소, 서버가 클라이언트의 요청에 대한 응답으로 필요한 리소스를 미리 전송 가능. 이는 데이터 전송을 최적화하고 대역폭을 효율적으로 사용할 수 있도록 해준다.리소스 병렬 다운로드 -> 서버가 여러 리소스를 동시에 전송가능해서 웹페이지 로딩 시간 단축
리소스를 캐시로 활용 -> 재접속 했을 때 더 빠른 로딩시간
-
라운드 트립
클라이언트 <-> 서버 간의 왕복시간
클라이언트가 요청을 보내고 다시 서버에서 요청을 보내서 클라이언트가 받는데 까지 걸린 시간을 의미.
