HTTP 개념 정리

Minsang Yu·2023년 4월 3일

HTTP2.0 SSL/TLS TCP/IP http https

HTTP (HyperText Transfert Protocol)

텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜.
모든 프로그램들이 이 규약에 맞춰서 정보를 교환 할 수 있게되었다.

HTTP 동작 원리

클라이언트는 브라우저를 통해 어떠한 서비스를 url이나 다른것을 통해서 request 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 response 한다.
요청 : Client -> server
응답 : server -> client
Html 뿐 아니라 plainText, Json, XML과 같은 형태의 정보도 주고 받을수 있으며 client가 어떤 정보를 HTML이나 JSON형태로 받고싶은지 명시해주는 경우가 많다.

HTTP 특징

TCP/IP를 이용하는 응용 프로토콜이다.
연결 상태를 유지하지않는 비연결성 프로토콜이다. (이러한 단점 떄문에 Cookie와 Session 이 등장)
연결 상태를 유지하지 않기 떄문에 요청/응답방 방식으로만 작동한다.

HTTP 1.0

HTTP 1.0 은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계됨
non-persistent HTTP
이는 RTT(패킷이 목적지에 도달ㅇ하고 나서 다시 출발지로 돌아오는데 걸리는시간) 증가를 불러움

RTT의 증가를 해결하기 위한 방법
1. 이미지 스플리팅

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

  // css에서 의 표기법
  #icons>li:nthh-child(2)>a{
  	background-position : -29px, -8px;
  }

코드 압축

코드를 압축해 개행문자, 빈칸을 없애서 코드의 크기를 최소화 한다.

이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩 하는 방법
이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP요청을 할 필요가 없는 장점이있다.
단 37%정도 파일의 크기가 커진다.

HTTP 1.1

HTTP1.0처럼 매번 TCP 연결을 하는것이 아니라 한 번 TCP 초기화 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신 할 수 있다.
Persistent HTTP
TCP 세션 부하를 줄이고 응답속도를 개선할 수 있다.
HTTP1.1은 파이프라이닝 기능을 제공해 여러개의 요청을 동시에 보낼 수 있다.
해더에 쿠키등 많은 메타데이터가 들어 있고 압축이 되지 않아 매우 무거운 구조

HOL Blocking

네트워크에서 같은 큐에 있는 패킷이 그 첫번쨰 패킷에 의해 지연될떄 발생하는 성능 저하 현상
예를들어 그림처럼 image.jpg와 style.css, data.xml을 다운로드받을 떄 보통은 순차적으로 잘 받아지지만 image.jpg가 느리게 받아진다면 뒤에있는것은 대기상태가 되어 다운로드가 지연되는것

HTTP 2.0

구글의 SPDY라는 구글의 비표준 개방형 네트워크 프로토콜에 기반한다.
HTTP1.X보다 지연시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며 멀티플렉싱,헤더 압축, 서버 푸쉬, 요청의 우선순위 처리를 지원하는 프로토콜
기본의 plain text(평문)를 사용하고, 개행으로 구별되는 HTTP/1.x 아 달리 2.0 에서는 바이너리 포멧으로 인코딩 된 Message, Frame으로 구성된다.
헤더 데이터 압축
- 허프만 코딩 알고리즘을 사용해서 HPACK이라는 header압축방식을 이용하여 데이터 전송 효율을 높였다.
  
  Huffman Coding 방식: 데이터 문자의 빈도에 따라서 다른 길이의 부호를 사용하는 알고리즘

서버 푸쉬
- 클라이언트가 요청하지 않은 JavaScript, CSS, Font 이미지 파일등과 같이 필요하게 될 특정 파일들을 서버에서 단일 HTTP요청 응답시 함꼐 사용할 수 있다.
멀티플렉스
- HOL Blocking 해결
- 여러개의 스트림을 사용하여 병렬적으로 패킷을 송수신한다.
- 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작한다.
- 단일 연결을 사용하여 병렬로 여러 요청을 받을수있고 응답을 줄 수 있다.

HTTPS

기본골격이나 사용 목적등은 HTTP와 동일하지만 보안 요소가 추가되었다.
서버와 클라이언트 사이의 모든 통신 내용이 암호화된다.
애플리케이션과 전송계층 사이에 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청을 말한다.

SSL/TLS

SSL은 1.0부터 시작해 SSL 2.0, SSL 3.0, TLS(Transport Layer Security Protocol)1.0, TLS 1.3 버전이 올라가며 마지막으로 TLS로 명칭이 변경되었으면 보통 SSL/TLS라고 부른디/
SSL/TLS는 전송계층에서 보안을 제공하는 프로토콜이다.
클라이언트와 서버가 통신할 떄 SSL/TLS를 통해 제3자가 메시지를 도청하거나 변조하지 못하도록 한다.

보안 세션

보안이 시작되고 끝나는 동안 유지되는 세션
SSL/TLS는 핸드쉐이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보등을 공유한다.
클라이언트와 서버가 키를 공유하고 이를 기반으로 인증, 인증확인 작업이 일어나는 단 한번의 1-RTT가 생긴후 데이터를 송수신한다.
클라이언트에서 사이퍼 슈트(cyper suites)를 서버에 전달하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할수 있는지 확인한구 제공할 수 있다면 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작되고 이후 해싱 알고리즘 등으로 암호화된 데이터 송수신이 시작된다.

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

HTTPS 인증 메커니즘

HTTPS인증 메커니즘은 CA(Certificate Authorites)에서 발급한 인증서를 기반으로 이루어진다.
CA에서 발급한 인증서는 안전한 연결을 시작하는 데 있어 필요한 공개키를 클라이언트에 제공하고 사용자가 접속한 서버가 신뢰 할 수 있는 서버임을 보장한다.

암호화 방식

공개키 암호화 방식과 공개키가 느리다는 단저을 보안환 대칭키 암호화 방식을 함께 사용한다. 공개키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신하게 된다.

공개키 암호화 방식

암호화와 복호화에 사용하는 키가 서로 다른 암호화 방식
본인만 가지고 있는 키는 개인키(private key)
상대방에게 공개하는 키는 공개키(public key)
공개키로 암호화 하면 데이터 보안에 중점을 두고, 개인키로 암호화 하면 인증과정에 초점을 둔다.
암호화 과정
1. 송신자는 수신자의 공개키를 구한다.
2. 송신자는 공개키로 평문을 암호화하여 수신자에게 전달한다.
3. 메시지는 암호화 되어있고 누군가 메시지를 도청하고, 공개키를 가지고 있다고 해도 비밀키 없이는 복호화 할 수 없다. 비밀키는 수신자만이 가지고 있다.
4. 수신자는 메시지를 받아 비밀키로 복호화 하여 평문을 얻는다.

대칭키 암호화 방식

동일한 키로 암호화, 복호화가 가능하다.
대칭키는 매번 랜덤으로 생성되어 누출되어도 다음에 사용할 떄는 다른 키가 사용되기 떄문에 안전하다.
공개키보다 빠르게 통신할 수 있다.

이러한 SSL/TLS 방식을 적용하려면 CA에서 인증서를 발급 받아야한다.

동작과정

CA에서 인증서 발급

1. 서버는 공개키와 개인키를 만들고 CA에 자신의 정보와 공개키를 관리해 달라고 계약한다.
2. 인증기관은 사이트가 제출된 데이터를 검증하고 인증 기관의 개인키로 사이트에서 제출한 정보를 암호화해서 인증서를 만든다.
3. 인증 기관은 웹 브라우저에게 자신의 공개키를 제공한다.

사용자의 인증과정

사용자가 사이트에 접속하면 서버는 자신의 인증서를 웹 브라우저(클라이언트)에게 보낸다.
예를들어 클라이언트가 index.html을 요청하면 서버의 정보를 인증 기관의 개인키로 암호화한 인증서를 받게된다.
클라이언트는 CA의 공개키로 인증서를 해독하여 검증한다. 그러면 사이트의 정보와 서버의 공개키를 알 수있게된다.
이렇게 얻은 서버의 공개키로 대칭키를 암호화해서 다시 사이트에 보낸다.
사이트는 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 이제 대칭키로 데이터를 주고받을수 있다.

HTTPS는 SEO에 도움이 된다.

구글은 SSL인증서를 강조해왔고 사이트 내 모든 요소가 동일하다면 HTTPS 서비스를 하는 사이트가 그렇지 않은 사이트보다 SEO 순위가 그렇지 않은 사이트보다 높을것이라고 공식적으로 밝혔다.

HTTPS 구축 방법

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

HTTP 3.0

HTTP3.0은 QUIC라는 계층 위에서 돌아가며 TCP기반이 아닌 UDP기반의 QUIC로 돌아간다.

QUIC
QUIC는 구글에서 2013년에 발표한 프로토콜이다. 기존의 TCP기반 연결의 성능을 개선하고자 하는 프로젝트였고 UDP를 채택하였다.

기본적 보안 기능 내장
- 기존 TLS의 핸드 쉐이크와 3-way핸드쉐이크를 합쳐서 인증과 암호화 파라미터 조절 기능 제공
- 기존의 TCP,TLS에서는 2번의 왕복 통신이 필요한 반면 1번의 왕복만으로 처리된다.
메타데이터 암호화
- HOL Blocking 해결
  - QUIC는 HTTP2.0과 다르게 QUIC전송 스트림을 각각의 HTTP스트림과 매핑하고 동시에 QUIC연결은 하나만 유지한다.
  - 연결이 하나이므로 추가전인 핸드쉐이크 불필요, 혼잡 상황이 전파되지않는다.

Request Method 종류

GET : 자료를 요청할떄 사용
POST : 자료의 생성을 요청할 떄 사용
PUT : 자료의 수정을 요청할 떄 사용
DELETE : 자료의 삭제를 요청할 떄 사용

Status Code (상태코드)

1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으면 성공적으로 처리함
3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.
5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

HTTP 구조

1. REQUEST Message(요청)

HTTP Request Message는 공백을 제외하고 3가지 부분으로 되어있다.

Start Line

GET /test.html HTTP/1.1
[HTTP Method] [Request target] [HTTP version]

HTTP request Message의 시작 라인
3가지 부분으로 구성됨
- HTTP method
  - 요청의 의도를 담고 있는 GET,POST,PUT,DELETE등이 있다.
- Reqeust target
  - HTTP Request가 전송되는 목표 주소
- HTTP version
  - version에 따라 Request메시지 구조나 데이터가 다를 수 있어서 version을 명시한다.

Header

Host: google.com
Accept: text/html
Accept-Encoding: gzip, deflate
Connection: keep-alive
...

해당 request에 대한 추가정보를 담고 있는 부분
header도 3가지 부분으로 나뉜다.(general headers, request headers, entity headers)
Host 요청하려는 서버 호스트 이름과 포트번호
User-agent 클라이언트 프로그램 정보. 이 정보를 통해 서버는 클라이언트 프로그램(브라우저)에 맞는 최적의 데이터를 보내줄 수 있다.
Referer 바로 직전에 머물렀던 웹 링크 주소
Accept 클라이언트가 처리 가능한 미디어 타입 종류 나열
If-Modified-Since 여기에 쓰여진 시간 이후로 변경된 리소스 취득. 페이지가 수정되었으면 최신 페이지로 교체한다.
Authorization 인증 토큰을 서버로 보낼 때 쓰이는 Header
Origin 서버로 Post 요청을 보낼 때 요청이 어느 주소에 시작되었는지 나타내는 값. 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS(Cross-Origin Resource Sharing) 에러가 발생한다.
Cookie 쿠키 값이 key-value로 표현된다.

Body

POST /test HTTP/1.1

Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 83
Content-Type: application/json
Host: google.com
User-Agent: HTTPie/0.9.3

{
    "test_id": "tmp_1234567",
    "order_id": "8237352"
}

Http Request가 전송하는 데이터를 담고 있다.
전송하는 데이터가 없으면 body는 비어있다.
보통 HTML, FormData, Json, XML등이 있다.

Response Message

HTTP Response Message는 동일하게 공백을 제외하고 3가지 부분으로 나뉘어졌다.

Status Line

HTTP/1.1 200 OK
[HTTP version] [Status Code] [Status Text]

HTTP Response의 상태를 간략하게 나타내주는 부분
HTTP Response의 status line또한 3가지 부분으로 구성

HTTP version
Status Code
Status Text

Headers

Response의 headers와 동일하다.

다만 response에서만 사용되는 header 값들이 있다.

예를 들어, User-Agent 대신에 Server 헤더가 사용된다.

Body

Response의 body와 일반적으로 동일하다.

Request와 마찬가지로 모든 response가 body가 있지는 않다.

데이터를 전송할 필요가 없을경우 body가 비어있게 된다.

Minsang Yu

Jr. DataEngineer

이전 포스트

AWS EC2 프리티어사용시 메모리 부족을 해결해보자

다음 포스트