HTTP

HTTP(HyperText Transfer Protocol) 란?

- 인터넷에서 데이터를 주고 받을 수 있는 프로토콜

 

프로토콜(Protocol) 이란?

- 개발에서 정보를 교환하기 위해 필요한 규칙

 

 

HTTP 의 기본적인 개념 및 구조 정리 링크: https://gyurim.tistory.com/category/HTTP%20%EC%9B%B9%20%EA%B8%B0%EB%B3%B8%20%EC%A7%80%EC%8B%9D

 

HTTP/1.0

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

- 서버로부터 파일을 가져올 때마다 TCP의 3-way-handshake를 계속 열어야 함

-> RTT 증가 -> 서버 부담 증가 -> 사용자 응답 시간 증가

 

RTT(Round Trip Time)

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

ex)

클라이언트 -> 서버 (요청)

+

서버 -> 클라이언트 (응답)

=

총 소요 시간



RTT 증가 문제 해결 방안

1. 이미지 스플리팅

- 많은 이미지를 다운받으면 과부하가 걸림

-> 많은 이미지가 합쳐진 하나의 이미지 다운

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

 

2. 코드 압축

- 개행 문자, 빈칸을 없애서 코드의 크기 최소화

-> 코드 용량 감소

 

3. 이미지 Base64 인코딩

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

- Base64 인코딩 방식은 이메일 SMTP에서 많이 사용

- 인코딩된 문자열을 <img> element 혹은 CSS 백그라운드로 사용

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

- 단점: Base64 문자열로 변환할 경우 37% 정도의 크기가 커짐

 

- 하지만 요즘 자주 사용되지 않음

1) http 버전이 높아짐

2) 이미지 호스팅 서비스 사용 ex)amazon s3

 

HTTP/1.1

- 매번 TCP 연결을 하는 HTTP/1.0의 단점을 개선

- 한번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있음

- HTTP/1.0에서도 keep-alive 옵션이 있었지만 표준화 되어 있지 않았음, HTTP/1.1부터 표준화되어 기본 옵션으로 설정

- TCP의 3-way-handshake가 한 번 발생하면, 그 다음부터 발생하지 않음

- 하지만 문서 안에 포함된 다수의 resource(image, css 파일, script 파일)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어질 수 있음(단점)

 

HTTP/1.1 문제점

1. HOL Blocking (Head Of Line Blocking)

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

1) image.jpg 2) styles.css 3) data.xml 

- 위 3파일을 다운로드 받을 때, 순차적으로 잘 다운로드 받지만, image.jpg파일이 비교적 크기 때문에 다운로드 속도 느림

-> 그 뒤의 파일들은 대기 상태

-> 다운로드 지연 상태 발생

-> HTTP/2.0에서 해결

 

2. 무거운 헤더 구조

- 쿠키 등 많은 메타 데이터가 헤더에 들어 있고 압축되지 않아 무거운 상태

 

HTTP/2

- SPDY 프로토콜에서 파생된 프로토콜

 

SPDY(speedy)

: 웹 콘텐츠를 전송할 목적으로 구글이 개발한 비표준 개방형 네트워크 프로토콜

: HTTP 헤더를 해석하고 단순화하여 압축 전송함

: 기존에 보냈던 HTTP 헤더와 같은 내용의 헤더가 재전송될 경우 다시 보내지 않고, 다른 내용의 헤더는 압축 전송함으로써 전송 시간을 절약한다.

 

- HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 함

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

 

1. 멀티플렉싱

- 여러 개의 스트림(stream)을 사용하여 송수신

 

스트림(stream)

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

 

- 특정 스트림의 패킷이 손실되어도, 해당 스트림에만 영향을 미치고 나머지 스트림은 정상 동작

- 애플리케이션에서 받아온 메시지를 독립된 프레임으로 조각내어 서로 송수신 및 조립하며 데이터 주고 받음

- 단일 연결을 사용하여 병렬로 여러 요청 받고 응답할 수 있음

-> HOL Blocking 문제 해결

 

2. 헤더 압축

- 기존 HTTP/1.x에는 헤더가 큰 문제 존재

- 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식으로 헤더를 압축

 

허프만 코딩(huffman coding)

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

- 전체 데이터의 표현에 필요한 비트양을 줄이는 원리

- 무거운 헤더 구조 문제 해결

 

3. 서버 푸시

- 기존 HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운 받을 수 있었음

- HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스 푸시 가능

- 서버 푸시를 하지 않은 경우에는 html, css 파일들을 개별적으로 각각 요청 후 응답 받아야 함

- 서버 푸시를 하는 경우에는 html 파일 요청 시, 그 안에 들어 있던 css파일을 서버에서 푸시하여 클라이언트에게 먼저 제공, 개별 요청할 필요 X

 

HTTPS(Secure)

- 애플리케이션 계층과 전송 계충 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청, "통신을 암호화"

- HTTP/2는 HTTPS 위에서 동작

 

출처: http://iloveulhj.github.io/posts/http/https-basic.html

 

SSL/TLS

- SSL(Secure Socket Layer), TLS(Transport Layer Security Protocol)

- 전송 계층에서 보안을 제공하는 프로토콜

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

- 인터셉터 방지

• 인터셉터
  • 공격자가 서버인 척하며 사용자 정보를 가로챔

- 보안 세션을 기반으로 데이터를 암호화

• 보안 세션
  • 보안이 시작되고 끝나는 동안 유지되는 세션
• 세션 
  • 운영체제가 어떠한 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간
  • 사용자는 일정 시간 동안 응용 프로그램, 자원 등 사용 가능

 

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

- 클라이언트와 서버가 키를 공유 -> 인증, 인증 확인 등의 작업

- 위 과정이 단 한번의 1-RTT가 생긴 후 데이터를 송수신

-> 클라이언트에서 사이퍼 슈트(cypher suites)를 서버에 전달

-> 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인

-> 제공 가능하면 서버에서 클라이언트로 인증서를 보내는 인증 매커니즘 시작

-> 해싱 알고리즘 등으로 암호화된 데이터의 송수신 시작

 

사이퍼 슈트(Cypher suites)

- 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약, 5가지 존재

ex) TLS_AES_128_GCM_SHA256

1) TLS(Transport Layer Security): 인터넷 커뮤니케이션을 위한 개인 정보와 데이터의 무결성을 제공하는 보안 프로토콜

2) AES_128_GCM: AEAD 사이퍼 모드

3) SHA256: 해싱 알고리즘

 

인증 매커니즘

- CA(Certificated Authorities)에서 발급한 인증서를 기반으로 이뤄짐

- 안전한 연결을 시작하는데 있어 필요한 "공개키"를 클라이언트에 제공하고 사용자가 접속한 "서버"가 "신뢰"할 수 있는 서버임을 보장

- 인증서 구성 ex) 서비스 정보, 공개키, 지문, 디지털 서명

 

CA 발급 과정

- 자신의 사이트 정보와 공개키를 CA에 지출

- CA는 공개키를 해시한 값인 지문(finger print)을 사용하는 CA의 비밀키 등을 기반으로 CA 인증서 발급

 

개인키(비밀키)

-  개인이 소유하고 있는 키이자 반드시 자신만이 소유해야 하는 키

 

공개키

- 공개되어 있는 키

 

 

2) AEAD(Authenticated Encryption with Associated Data) 사이퍼 모드

- 데이터 암호화 알고리즘

- AES_128_GCM: 128비트의 키를 사용하는 표준 블록 암호화 기술 + 병렬 계산에 용이한 암호화 알고리즘 GCM

암호화 알고리즘

- 대수곡선 기반의 ECDHE

- 모듈식 기반의 DHE

-> 둘다 디피-헬만(Diffie-Hellman)방식을 근간으로 만들어짐

 

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

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

- 공개 값을 공유하고, 각자의 비밀 값과 혼합한 후 혼합 값을 공유

- 이후, 공통의 암호키 생성

- 클라이언트, 서버 모두 개인키와 공개키를 생성하고 서로에게 공개키를 보내고 공개키와 개인키를 결합하여 PSK(사전 합의된 비밀키) 생성

- 악의적인 공격자가 개인키 또는 공개키를 가지고 있더라도 PSK가 없기 때문에 공격 불가 -> 암호화 성공

 

3) 해싱 알고리즘

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

- SSL/TLS는 해싱 알고리즘으로 SHA-256, SHA-384 사용

 

SHA-256

- 해시 함수의 결괏값이 256비트인 알고리즘

- 비트 코인을 비롯한 많은 블록체인 시스템에서 사용됨

- 해싱해야할 메시지에 1을 추가하는 등 전처리를 하고, 전처리된 메시지를 기반으로 해시 반환

 

해시

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

해싱

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

해시 함수

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

 

HTTPS는 SEO에 도움이 됨

- 구글에서 SSL 인증서를 강조해옴

- 사이트 내 모든 요소가 동일하다면 HTTPS 서비스하는 사이트가 그렇지 않은 사이트보다 SEO 높을 것임을 공식적으로 밝힘

 

SEO(Search Engine Optimization)

- 검색 엔진 최적화

- 구글과 같은 검색엔진으로 웹 사이트 검색 시, 결과를 페이지 상단에 노출시켜 많은 사람들이 볼 수 있도록 최적화하는 방법

1) 캐노니컬 설정

2) 메타 설정

3) 페이지 속도 개선

4) 사이트맵 관리

 

HTTPS 구축 방법 3가지

1) 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스 구축

2) 서버 앞단에 HTTPS를 제공하는 로드밸런서 배치

3) 서버 앞단에 HTTPS를 제공하는 CDN 배치

 

 

HTTP/3

- HTTP/2는 TCP위에서 돌아감

- HTTP/3는 QUIC이라는 계층 위에서 돌아감, TCP기반이 아닌 UDP기반

- QUIC(Quick UDP Internet Connection)

 

HTTP/3 장점

- HTTP/2의 장점인 멀티플렉싱 존재

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

-> QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way-handshake 과정 필요 X

-> 첫 연결 과정에서 1-RTT만 소요, 클라이언트가 서버에 어떤 신호를 한 번 요청, 서버는 거기에 응답만하면 바로 통신 가능

 

- QUIC는 순방향 오류 수정 매커니즘 적용

-> 전송 패킷이 손실되더라도, 수신 측에서 에러를 검출하고 수정하는 방식

-> 열악한 네트워크 환경에서도 낮은 패킷 손실률

 

QUIC 계층 추가로 인하여 기존의 UDP와 다르게

- TCP와 같은 데이터 신뢰성 보장

- 순서에 맞는 전송 처리

- 스트림이 전송 중에 잃은 스트림의 패킷을 재전송

 

 

요약

출처: http://blog.skby.net/quic-quick-udp-internet-connection/