[네트워크] HTTP

기본적으로 HTTP는 전송 계층 위에 있는 애플리케이션 계층으로서 웹 서비스 통신에 사용

HTTP/1.0

HTTP/ 1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어 있다. 이는 RTT 증가를 불러오게 되었다.

서버로부터 파일을 가져올 때마다 TCP의 3-웨이 핸드셰이크를 열어야 하기 때문에 RTT가 증가하는 단점이 있음.

* RTT : 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간(패킷 왕복시간)

 

> RTT 증가를 해결하기 위한 방법?

이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용

 

이미지 스플리팅

- 많은 이미지를 다운로드 받게 되면 과부하가 걸리기 때문에 많은 이미지가 합쳐 있는 하나의 이미지를 다운받고, 이를 기반으로 backgroud-image의  position을 이용하여 이미지를 표기하는 방법

 

코드 압축

- 코드압축은 코드를 압축해서 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법

 

이미지 Base64 인코딩

- 이미지 파일을 64 진법으로 이루어진 문자열로 인코딩하는 방법.

- 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있음.

- 하지만 Base64 문자열로 변환할 경우 37% 정도 크기가 커지는 단점

 

* 인코딩 : 정보의 형태나 형식을 표준화, 보안 처리 속도 향상, 저장 공간 절약 등을 위해 다른 형태나 형식으로 변환 처리

 

HTTP/1.1

매번 TCP 연결을 하는 것이 아니라 한번 TCP 초기화를 한 이후에 keep-alive 라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다. 참고로 HTTP/1.0에서 keep-alive가 있었지만 표준화가 되어있지 않았고 HTTP/1.1 부터 표준화가 되어 기본 옵션으로 설정

 

한번 TCP 3-웨이 핸드셰이크가 발생하면 그 다음부터 발생하지 않는 것을 볼수 있다. 하지만 문서 안에 포함된 다수의 리소스를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어진다.

 

HOL Blocking

네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 떄 발생하는 성능 저하 현상

예륻 들어 image.jpg와 style.css, data.xml을 다운받을 떄 보통은 순차적으로 잘 받아지지만 image.jpg가 느리게 받아진다면 그 뒤에 있는것들이 대기하게 되며 다운로드가 지연되는 현상

 

무거운 헤더 구조

HTTP/1.1헤더에는 쿠키 등 많은 메타데이터가 들어있고 압축이 되지않아 무거움

 

 

HTTP/2

SPDY 프로토콜에서 파생된 HTTP/1.x보타 지연시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며 멀티플렉싱, 헤더압축, 서버푸시, 요청의 우선순위 처리를 지원하는 프로토콜

 

 

멀티플렉싱

- 여러개의 스트림을 사용하여 송수신하는 것

- 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작

- HTTP/1.x에서 발생하는 문제인 HOL Blocking를 해결할 수 있음

 

*스트림 : 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

 

헤더압축

- HTTP/1.x에는 크기가 큰 헤더라는 문제를 해결하기 위함

- 하프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형실을 가짐

 

* 하프만 코딩 : 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 방법

 

서버푸시

- HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있었다면 HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.

 

html에는 css나 js 파일이 포함되기 마련인데 html을 읽으면서 그 안에 들어 있는 css 파일을 서버에서 푸시하여 클라이언트에 먼저 줄 수 있다.

 

 

HTPPS

HTTP/2는 HTTPS위에서 동작한다. HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP요청을 말한다. 이를 통해 '통신을 암호화' 한다.

 

SSL/TLS

- SSL은 SSL 1.0부터 시작해서 SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.3까지 버전이 올라가며 마지막으로 TLS로 명칭이 변경되었으나, 보통 이를 합쳐 SSL/TLS 라고 부른다.

- SSL/TLS은 전송 계층에서 보안을 제공하는 프로토콜이다.

- 클라이언트와 서버가 통신 할 떄 SSL/TLS를 통해 제3자가 메시지를 도청하거나 변조하지 못하도록 한다.

- 그림처럼 SSL/TLS를 통해 공격자가 서버인 척하며 사용자 정보를 가로채는 네트워크상의 '인터셉터' 방지

- 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어 질때 인증 메커니즘, 키교환 알고리즘, 해싱 알고리즘 사용

 

보안세션

- 보안이 시작되고 끝나는 동안 유지되는 세션

- SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 공유

 

* 세션

운영체제가 어떠한 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간, 사용자는 일정시간 동안 응용프로그램, 자원 사용가능

 

HTTP/3

HTTP/1.1 및 HTTP/2와 함꼐 World Wide Web에서 정보를 교환하는데 사용되는 HTTP의 세 번째 버전. TCP위에서 돌아가는 HTTP/2와 달리 HTTP/3은 QUC이라는 계층 위에서 돌아가며 TCP기반이 아닌 UDP 기반으로 돌아감. 또한 HTTP/2에서 장점이었던 멀티플렉싱을 가지고 있으며 초기 연결 설정 시 지연 시간을 감소

 

초기연결 설정시 지연 시간 감소

QUIC는 TCP를 사용하지 않기 떄문에 통신을 시작할 때 3-웨이 핸드셰이크 과정을 거치치 않아도됨

QUIC은 첫 연결 설정에 1-RTT만 소요된다. 클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있다는 것. 참고로 QUIC은 순방향 오류 수정 메커니즘(FEC)이 적용되었다. 이는 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.