http
"Hypertext Transfer Protocol"의 약자로서, 웹(web)을 이용하여 HTML로 작성된 하이퍼텍스트(hypertext) 문서를 주고받을 수 있는 프로토콜
HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송한다. HTTP의 확장성 덕분에 오늘날 하이퍼 텍스트 문서뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트하기 위해 사용된다.
특성
-
비연결성 : HTTP는 먼저 클라이언트가 요청을 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 응답을 보내고 접속을 끊는 특성이 있다.
-
무상태성 : 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다. 두 가지 특징이자 약점을 보완하기 위해서
쿠키(cookie)와세션(session)을 사용한다. 예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도, 페이지를 이동할 때마다 계속 로그인을 해야 한다.
http messages
HTTP는 요청과 응답으로 구성되어 있고, 클라이언트가 요청을 하면 서버가 응답을 하는 구조로 되어 있다. HTTP 메세지는 구성 파일, API, 기타 인터페이스에 의해 자동으로 구성된다.
구조
1. start line(request)/ status line(response) : 요청이나 응답의 상태를 나타내면 http message에 항상 첫번째 줄에 위치한다.
2. HTTP headers : 요청을 지정하거나, 메세지에 포함된 본문을 설명하는 헤더의 집합
3. empty line : 헤더와 본문을 구분하는 빈 줄
4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서
start line 과 HTTP headers 를 묶어 head 라고 하고 body는 payload라고도 한다.
요청(request)
-
start line
- HTTP method : 수행할 작업이나 방식을 나타냄 (ex. GET,PUT, Post 등)
- URL or URI : 요청 대상 또는 프로토콜, 포트, 도메인의 절대 경로
- HTTP 버전
-
headers
- Request headers : User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화한다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.
- General headers : 메시지 전체에 적용되는 요구사항을 담고있다.
- Entity headers : Content-Length와 같은 헤더는 body에 적용된다. body가 비어있는 경우, entity headers는 전송되지 않는다.
-
body : http messages 에 마지막에 위치하며 모든 요청에 필요한 요소는 아니다. POST나 PUT 처럼 데이터 업데이트가 필요할 때 사용
응답(response)
-
start line
- HTTP 버전
- 상태 코드 : 요청의 결과를 숫자로 나타낸다.(200, 302, 404 등)
- 상태 텍스트 : 상태 코드에 대한 설명
-
headers : request의 헤더와 유사하다.
-
body : http messages 에 마지막에 위치하며 모든 요청에 필요한 요소는 아니다.
https
HTTPS는 기존 HTTP에 비해 보안성을 강화한 프로토콜이다. 암호화 프로토콜인 SSL 이나 TLS 프로토콜을 사용하여 통신을 주고받는다. HTTPS는 HTTP 헤더와 요청·응답 데이터를 비롯한 모든 메시지 내용을 암호화한다.
HTTP 프로토콜의 문제점은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않고 전송이 된다는 것이었다. 즉, 데이터가 쉽게 도난당할 수 있다는 것이었는데, 이를 극복하기 위해 HTTPS 프로토콜에 SSL을 사용함으로써 등장하게 되었다.
동작 원리
HTTPS는 대칭키와 비대칭키 방식을 혼합하여 사용한다.
대칭키 : 클라이언트와 서버는 암호화, 복호화를 할 수 있는 동일한 키를 공유한다.
대칭기의 한계는 이 동일한 키를 양쪽이 어떻게 공유하느냐에 있다. 대칭키를 서로가 공유하기 위해선 반드시 한쪽에서 다른 한쪽으로 이 키를 전달해주어야 하는데 이 과정에서 키 값이 유출되면 문제가 원점으로 돌아온다.
비대칭키 : 대칭키의 한계를 보완하기 위해 등장한 시스템으로 암호화, 복호하에 각각 다른 키를 사용하여 비대칭키라고 한다.
대칭 키 방식에서는 암호화, 복호화를 모두 같은 키로 할 수 있었지만 비대칭키 방식에서는 A키로 암호화한 데이터는 B키로만 복호화할 수 있다. 반대로 B키로 암호화한 데이터는 A키로만 복호화 가능하다. 서버는 개인키를 가지고 이에 대응하는 공개키를 외부에 공개한다. 클라이언트가 공개키로 암호화한 데이터는 서버가 가지고 있는 개인키가 있어야만 복호화가 가능하고 같은 공개키로는 복호화할 수 없기 때문에 이 데이터는 이제 해당 서버만 읽을 수 있다. 외부에 공개된 공개키는 CA에 의해 인증된다. 우리가 사용하는 웹 브라우저에는 이 CA의 목록들이 내장되어 있다.
클라이언트는 서버와 데이터를 교환하기 전 일련의 탐색 과정을 거치는데 이를 handshake라고 한다. 클라이언트는 랜덤한 데이터를 서버에 보내고 이를 받은 서버 또한 랜덤한 데이터에 해당 서버 인증서를 함께 보낸다. 클라이언트는 이 인증서의 진위 여부를 CA를 통해 확인한다. 여기서 비대칭키가 사용된다. CA의 인증을 받은 인증서들은 CA의 개인키를 통해 암호화되어있다. 해당 인증서가 진짜라면 브라우저에 내장되어있는 CA의 공개키를 통해 복호화할 수 있다. 이 과정을 통해 인증서가 성공적으로 복호화되면 이 인증서에는 서버의 공개키가 포함되어있다.
이 때부터 비대칭키와 대칭키 방식이 함께 사용된다. 이 둘을 함께 쓰는 이유는 비대칭키로 모든 메세지를 암호화 복호화하는 것은 컴퓨터에게 상당한 부담을 주기 때문이다. 클라이언트는 handshake 과정에서 주고받은 랜덤 데이터를 혼합하여 임시키를 생성한 뒤 인증서를 통해 얻은 서버의 공개키로 암호화하여 서버에 전송한다. 이 임시키는 일련의 과정을 거쳐 서버와 클라이언트 모두가 공유하고 있는 대칭키가 된다.
https의 한계
-
HTTPS의 문제점은 사용 시 반드시 증명서를 구입해야 한다는 것이다. 증명서의 구입 비용이 부담되는 서비스나 개인 웹사이트의 경우 HTTP만 선택하기도 한다.
-
HTTPS를 사용할 경우 처리가 늦어지게 되는 단점이 있다. 그 이유는 클라이언트 요청 시, SSL에 필요한 통신이 추가되고, 암호화 복호화 계산을 하므로 서버나 클라이언트의 리소스를 추가적으로 소비하기 때문이다.
