[CS] HTTP

     

목차

 

 

 

HTTP/1.0

기본적으로 한 연결당 하나의 요청을 처리하도록 설계

-> RTT의 증가

 

 

RTT증가를 위한 해결 방법

이미지 스플리팅

많은 이미지를 다운로드받게 되면 과부하가 걸리기 때문에 합쳐 있는 하나의 이미지를 다운로드 받고

이를 기반으로 background-image의 position을 이용하여 이미지 표기

 

 

코드 압축

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

 

 

이미지 Base64 인코딩

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

이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없다는 장점이 있다.

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

 

 

HTTP/1.1

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

문서 안에 포함된 다수의 리소스를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다.

 

Hol Blocking

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

 

무거운 헤더 구조

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

 

HTTP/2

SPDY 프로토콜에서 파생된 HTTP/1.1보다 지연 시간을 줄이고 응답 시간을 더 빠르게할 수 있으며

멀티 플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜이다.

 

멀티 플렉싱

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

이를 통해 특정 스트림의 패킷이 손실되었다고 해도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작한다.

 

 

++추가 정보

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

 

애플리케이션에서 받아온 메세지를 독립된 프레임으로 조각내어 송수신한 이후 다시 조립

 

-> Hol blocking 문제를 해결 가능

 

HTTP2 헤더 압축

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

 

허프만 코딩 

문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고

빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해 전체 데이터의 필요한 비트양을 줄이는 원리

 

서버 푸시

HTTP 1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드받을 수 있었다면

HTTP2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.

 

 

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

 

HTTPS

HTTP2는 HTTPS 위에서 동작한다.

 HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP요청을 말한다.

이를 통해 통신을 암호화 한다.

 

 

SSL/TLS

SSL은 1.0부터 시작해서 2.0, 3.0 TLS 1.0 ~1.3까지 버전이 올라가 이를 합쳐서 SSL/TLS라고 많이 부른다.

전송 계층에서 보안을 제공하는 프로토콜로 클라이언트와 서버가 통신 할 때 제 3자가 메시지를 도청하거나 변조하지 못하도록 한다.

 

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

 

보안 세션

보안 세션이란 보안이 시작되고 끝나는 동안 유지되는 세션을 말한다.

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

 

 

1. 클라이언트 Hello

클라이언트에서 랜덤 난수를 생성하여 서버에 보냅니다.

암호화 연결이 수립되지 않았기 때문에 평문으로 전달됩니다.

 

2. 서버 Hello

서버에서 서버 인증서와 함께 랜덤 난수를 생성하여 클라이언트에 보냅니다.

마찬가지로 암호화 연결이 수립되지 않았습니다.

 

3. 인증서 검증

클라이언트에서 서버로부터 수신한 서버 인증서를 인증 기관 (CA)에 유효한지 검증 요청을 합니다.

 

4. 프리 마스터 키 전송

클라이언트에서 프리 마스터 키 (랜덤 난수)를 생성하고 서버의 공개키로 암호화하여 보냅니다.

이전 단계에서 수신한 인증서에는 공개키가 담겨있습니다. 공개키에 대한 개인 키는 서버만 알고 있습니다.

 

5. 세션 키 생성

서버: 암호화된 프리 마스터 키를 복호화하고 프리 마스터 키, 클라이언트 랜덤 난수, 서버 랜덤 난수를 이용하여 세션 키를 생성합니다.

 

클라이언트: 프리 마스터 키, 클라이언트 랜덤 난수, 서버 랜덤 난수를 이용하여 세션 키를 생성합니다.

 

⇒ 서버와 클라이언트는 같은 데이터로 세션 키를 생성하기에, 서로 동일한 값을 가지고 있습니다.

 

클라이언트 OK: 클라이언트에서 서버로 ‘완료’ 응답을 세션 키로 암호화하여 전송합니다.

서버 OK: 서버에서 클라이언트로 ‘완료’ 응답을 세션 키로 암호화하여 전송합니다.

 

6. 안전한 양방향 암호화

Handshake가 완료되었습니다. 이후 서버와 클라이언트가 주고 받는 데이터는 모두 세션 키를 통해 암호화된 상태로 처리됩니다.

 

이때 위의 case는 tls1.3이전의 버전 과정입니다.

 

tls1.3이 되고 ClientHello 단계에서 이미 “암호화 알고리즘”과 “키 교환 값(KeyShare)”을 함께 보내어 1RTT 감소가 되었습니다.

 

사이퍼 슈트

프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약

ex) TLS_128_GCM_SHA256

 

인증 메커니즘

인증 메커니즘은 CA에서 발급한 이증서를 기반으로 이루어짐

안전한 연결을 시작하는데 있어 필요한 공개키를 클라이언트에게 제공하고

사용자가 접속한 서버가 신뢰할 수 있는 서버임을 보장

인증서는 서비스 정보, 공개키, 지문, 디지털 서명 등으로 이루어짐

 

-> 이때 CA는 공인된 기업들만 가능한데 Comodo, GoDddy, GlobalSign 아마존 등이 있다.

 

암호화 알고리즘

대수곡선 기반의 ECDHE 또는 모듈식 기반의 DHE를 사용한다.

 

디피-헬만 키 교환 암호화 알고리즘

암호키를 교환하는 하나의 방법

y=g^xmodp

g와 p를 안다면 y는 구하기 쉽지만 g와 y와 p만 안다면 x를 구하기는 어렵다는 원리에 기반한 알고리즘

 

클라이언트와 서버 모두가 개인키와 공개키를 생성하고, 서로에게 공개키를 보내고 공개키와 개인키를 결합하여 PSK가

생성된다면 악의적인 공격자가 개인키 또는 공개키를 가지고도 PSK(Pre Shared Key)가 없기 때문에 아무것도 할 수 없다.

 

해싱 알고리즘

데이터를 추적하기 힘든 더 작고, 섞여 있는 조각으로 만드는 알고리즘

대표적으로 많이 쓰는 알고리즘은 SHA-256 알고리즘이다.

 

SHA-256 알고리즘은 해시 함수의 결과값이 256 비트인 알고리즘이며 비트 코인을 비롯한 많은 블록체인 시스템에서도 사용한다.

 

++추가 정보

해시 - 다양한 길이를 가진 데이터를 고정된 길이 데이터로 매핑한 값

해싱 - 임의의 데이터를 해시로 바꿔주는 일이며 해시 함수가 이를 담당

해시 함수 - 임의의 데이터를 입력으로 받아 일정한 길이의 데이터로 바꿔주는 함수

 

참고로 TLS 1.3은 사용자가 이전에 방문한 사이트로 다시 방문하면 SSL/TLS에서 보안 세션을 만들 때 걸리는 통신을 하지 않아도 됨 -> 0-RTT

 

 

SEO에 도움이 되는 HTTPS

 

사이트맵

사이트맵이란 웹사이트에서 구글이나 네이버와 같은 검색 엔진에 색인할 모든 페이지를 나열한 XML 파일로, 웹사이트에 방문하는 검색엔진 크롤러에게 지도와 같은 역할을 한다.

다시 말해 사이트맵은 색인이 되어야 할 모든 페이지의 목록을 제공함으로써 검색엔진 크롤러가 발견하는 데 어려움을 겪는 페이지도 문제없이 크롤링 되고 색인될 수 있게 해주는 파일이다.

 

캐노니컬 설정

다음과 같은 다양한 이유로 사이트에 중복 콘텐츠가 있을 수 있다.

• 지역별 변형: 예를 들어 미국과 영국을 대상으로 제공되는 콘텐츠이며 여러 URL을 통해 액세스할 수 있지만, 본질적으로는 동일한 언어로 작성된 동일한 콘텐츠인 경우
• 기기 변형: 예를 들어 페이지에 모바일 버전과 데스크톱 버전이 둘 다 있는 경우
• 프로토콜 변형: 예를 들어 사이트에 HTTP 버전과 HTTPS 버전이 있는 경우
• 사이트 기능: 예를 들어 카테고리 페이지에 정렬 및 필터링 기능을 사용한 결과
• 실수로 인한 변형: 예를 들어 사이트의 데모 버전이 실수로 크롤러가 액세스할 수 있는 상태로 남아 있다.

Google 검색에서 중복되거나 매우 비슷한 페이지의 표준 URL을 지정할 때, 여러 가지 방법을 사용해 자신이 선호하는 표준 URL이 무엇인지 나타낼 수 있다

 

 

HTTPS 구축 방법 

CA에서 구매한 인증키를 기반으로 HTTPS 서비스를 구축하거나 서버 앞단의 HTTPS를 제공하는 로드밸런서를 두거나, 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축한다.

 

-> nginx를 통한 https 구축은 ca에서 구매한 인증키를 기반으로 한 https 서비스 구축에 속한다.

 

HTTP/3

TCP위에서 돌아가는 HTTP2와 달리 HTTP3는 QUIC라는 계층 위에서 돌아간다.

TCP기반이 아닌 UDP 기반으로 돌아간다. 또한 멀티플렉싱을 가지고 있으며 초기 연결 설정 시 지연 시간 감소라는 장점이 있다.

 

초기 연결 시 지연 시간 감소

TCP를 사용하지 않기 때문에 통신을 할 때 번거로운 3-웨이 핸드셰이크 과정을 거치지 않아도 됨

QUIC는 순방향 오류 수정 메커니즘이 적용되었다.

 

 

• TLS 1.3 암호화 계층을 내장하고 있어서
  “연결”과 “보안 설정”을 동시에 처리한다.
• 즉, 기존처럼 “TCP → TLS” 두 단계를 따로 안 하게된다.

따라서 최소 2RTT를 소모했던 것이 1RTT로 통신이 가능하게 되었다.

 

클라이언트의 IP가 바뀌어도 연결이 유지됨

 

TCP의 경우 소스의 IP 주소와 포트, 연결 대상의 IP 주소와 포트로 연결을 식별하기 때문에 클라이언트의 IP가 바뀌는 상황이 발생하면 연결이 끊어져 버린다. 연결이 끊어졌으니 다시 연결을 생성하기 위해 결국 눈물나는 3 Way Handshake 과정을 다시 거쳐야한다는 것이고, 이 과정에서 다시 레이턴시가 발생한다.

 

게다가 요즘에는 모바일로 인터넷을 사용하는 경우가 많기 때문에 Wi-fi에서 셀룰러로 전환되거나 그 반대의 경우, 혹은 다른 Wi-fi로 연결되는 경우와 같이 클라이언트의 IP가 변경되는 일이 굉장히 잦아서 이 문제가 더 눈에 띈다.

 

반면 QUIC은 Connection ID를 사용하여 서버와 연결을 생성한다. Connection ID는 랜덤한 값일 뿐, 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다. 이는 새로 연결을 생성할 때 거쳐야하는 핸드쉐이크 과정을 생략할 수 있다는 의미이다.