HTTP, HTTPS

HTTP란?

Hyper Text Transfer Protocol

HTTP는 www상에서 하이퍼텍스트를 교환하기 위한 프로토콜입니다.

HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 동작합니다.

WWW
World Wide Web의 약자로 인터넷에 연결된 컴퓨터를 이용해 사람들과 정보를 공유할 수 있는 공간을 이야기합니다.
HTTP를 기반으로 HTML로 작성된 하이퍼 텍스트를 웹 브라우저를 통해 읽을 수 있습니다.
보통 인터넷과 동일하게 보는 경우가 있지만 엄밀히 말하면 인터넷보다 작은 개념입니다.

Stateless

HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜으로 요청 / 응답 방식으로 동작합니다.

각각의 HTTP 통신은 독립적이며, 그전에 처리된 HTTP 통신에 대해서는 전혀 알지 못합니다.

서버는 클라이언트의 세션 관리를 하지 않아 Scaling이 자유롭다는 장점도 존재합니다.

Stateful
서버와 클라이언트간에 상태를 서버에 저장하고 상태에 기반해 응답을 하는 형태입니다.
이는 서버에서 상태를 가지고 있기 때문에 자원 낭비로 이어질 수 있습니다.
그리고 Stateful은 다수의 서버를 운영하는 경우 문제가 발생할 수 있습니다.
1번 서버에 클라이언트에 정보가 저장이 되어있다고 하더라도 2번 서버에는 클라이언트에 대한 정보가 없기 때문에 세션 인증을 처음부터 다시 해야하는 상황이 발생할 수 있습니다. 

Stateless의 단점 또한 존재합니다.

HTTP 요청을 보낼 때는 해당 요청을 처리하기 위해 필요한 모든 데이터를 매번 포함시켜 요청해야 합니다.

이러한 단점을 보완하기 위해 Server가 Client를 식별할 수 있는 방법으로 쿠키와 세션을 사용할 수 있습니다.

이전에는 연결을 유지하지 않기 때문에 매번 TCP/IP 연결을 시도 (3 way handshake) 하는 단점도 존재했습니다. (비지속 연결)

현재는 HTTP 지속 연결로인해 문제를 해결했습니다.

지속 연결은 서버가 클라이언트의 요청에 대해 응답한 후 TCP 연결을 유지하는 방식으로 같은 클라이언트-서버간의 요청-응답이 동일한 TCP연결을 통해 이루어지는 연결 방식입니다.

HTTP가 TCP위에서 구현되었기 때문에 연결지향적이라고 할 수 있다는 이야기아 있지만, 아직까지는 네트워크 관점에서 keep-alive는 옵션으로 두고, 서버측에서 비연결지향적인 특성으로 커넥션 관리에 대한 비용을 줄이는 것이 명확한 장점으로 보기 때문에 비연결지향으로 보고있습니다.

HTTP 메시지 구조

HTTP는 클라이언트와 서버 사이에 이뤄지는 요청(Request), 응답(Response)을 통해 메시지를 주고받습니다.

메시지 구조

메시지는 세 부분(공백 제외)으로 구성되어 있습니다.

Request 메시지 구조

• Start Line

GET /login HTTP/1.1

해당 Request가 무엇을 요구하는 요청인지를 정의합니다.

HTTP 메서드, Request target(전송되는 url), HTTP version이 있습니다.

• Header

Headers: {
	Host: 요청을 보내는 타겟의 주소. 즉, 요청을 보내는 웹사이트의 기본 주소가 된다 (ex. www.apple.co.kr)
	User-Agent: 요청을 보내는 클라이언트의 대한 정보 (ex. chrome, firefox, safari, explorer)
	Content-Type: 해당 요청이 보내는 메세지 body의 타입 (ex. application/json)
	Content-Length: body 내용의 길이
	Authorization: 회원의 인증/인가를 처리하기 위해 로그인 토큰을 Authroization 에 담는다
}

Request의 추가 정보를 담고 있습니다. Key : Value의 구조로 구성되어 있습니다.

• Body

Body: {
	"user_email": "jun.choi@gmail.com"
	"user_password": "wecode"
}

Request가 전송하는 데이터를 담고 있는 부분입니다. 생략할 수 있습니다.

Response 메시지 구조

• Start Line

Response의 상태를 보여줍니다 이 또한 3 부분으로 구성되어 있습니다.

HTTP version, Status code, Status Text이 있습니다.

• Header: Response의 추가 정보를 담고 있습니다

• Body: Response의 실제 내용입니다.

Response Status Codes
1xx - 정보 (요청을 받았으며 프로세스를 계속 진행하라는 의미)
2xx - 성공 
3xx - 리다이렉션 (요청 완료를 위해 추가 작업 조치가 필요함)
4xx - 클라이언트 오류
5xx - 서버 오류

그 외 Status Codes
https://developer.mozilla.org/ko/docs/Web/HTTP/Status

HTTPS란?

HTTP Secure, HTTP over SSL

HTTP에 데이터 암호화가 추가된 프로토콜입니다. HTTPS는 HTTP(80)와 다르게 443 포트를 사용합니다.

네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있습니다.

SSL

Secure Socket Layer

웹 표준 암호화 통신으로서 웹 브라우저와 서버 사이에 정보를 암호화해주는 프로토콜입니다.

TLS(Trans Layer Security)는 과거 SSL에서 이름이 변경된 것으로 사실상 SSL과 같은 의미입니다.

SSL은 대칭키와 비대칭키(공개키) 방식을 함께 사용하고 있습니다.

handshake 과정에 비대칭키를 써서 인증서(대칭키)를 보내고 이 인증서에 대칭키를 안전하게 받았다면 연결 이후에는 대칭키를 사용해서 전달하게 됩니다.

• 대칭키

클라이언트, 서버 모두 동일한 키를 가지고 데이터를 암/복호화 하는 방식을 말합니다.

대칭키는 비대칭키보다 빠릅니다. 단점은 키가 노출이 됐을 시 위험합니다.

• 비대칭키 (공개키)

클라이언트 서버 모두 다른 키를 가지고 데이터를 암/복호화 하는 방식을 말합니다.

하나의 키로 암호화 하면 또 다른 키로 복호화할 수 있는 것을 말합니다. 

대칭키 알고리즘에 비하여 속도가 느립니다. (약 1000배)

Public Key가 노출이 되더라도 Private Key로만 복호화할 수 있어 안전합니다.

인증서 발급

SSL방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 합니다.
인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 합니다.
이러한 인증서를 발급하는 기관을 CA(Certificate authority)라고 부릅니다.
공인인증기관의 경우 브라우저는 미리 CA 리스트와 함께 각 CA 공개키를 알고 있습니다.

인증서가 발급되는 과정.

1. 인터넷 사이트는 사이트의 정보와 공개키를 인증기관에 제출합니다.

2. 인증기관은 제출된 정보의 검증절차를 거쳐 개인키로 사이트에서 제출한 정보를 암호화합니다. (인증서 발급)

3. 인증기관은 웹 브라우저에서 자신의 공개키를 제공합니다.

사용자가 사이트에 접속하는 과정.

1. 사용자가 사이트에 접속하면 사이트의 인증서(공개키 포함)를 웹 브라우저에게 보냅니다.

2. 웹 브라우저는 미리 받았던 인증기관의 공개키로 인증서를 해독하여 검증합니다. 그러면 사이트의 정보와 사이트의 공개키를 알 수 있습니다.

3. 세션 키(대칭키)를 랜덤으로 생성해 공개키로 암호화해서 사이트로 보냅니다.

4. 사이트는 개인키로 암호문을 해동해 대칭키를 얻게 되고, 이제 대칭키로 데이터를 주고받을 수 있게 됩니다.