하루에 한 문제
HTTP, HTTPS 본문
HTTP
- 웹 서버와 클라이언트 간의 문서를 교환하기 위한 통신 규약으로 80번 포트를 사용하고 있다.
- 웹에서만 사용하는 프로토콜로 TCP/IP기반으로 서버와 클라이언트 간의 요청과 응답을 전송한다.
- 현재 HTTP/2까지 버전이 등장한 상태이다.
HTTP구조
- HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.
HTTP 요청
시작 줄
HTTP 요청은 서버가 특정 동작을 취하게끔 만들기 위해 클라이언트에서 전송하는 메세지이다.
시작 줄은 다음과 같은 세 가지 요소로 이루어져 있다.
1. 첫번째는 HTTP메서드로 (GET, POST, PUT, DELETE)를 사용해 서버가 수행해야 할 동작을 나타낸다.
2. 두번쨰로 오는 요청 타겟은 주로 URL, 또는 프로토콜, 포트, 도메인의 절대 경로를 나타낸다.
3. 마지막으로 HTTP버전이 들어간다.
헤더
요청에 들어가는 HTTP 헤더는 HTTP헤더의 기본구조를 따른다. 대소문자 구분없는 문자열 다음에 콜론(:)이 붙으며, 그 뒤에 오는 값은 헤더에 따라 달라진다. 헤더는 값까지 포함해 한 줄로 구성되지만 꽤 길어질 수 있다.
Content-Type, Content-Length, Host, User-Agent 등의 정보가 담겨져 있다.
본문
GET, DELETE에도 본문을 넣어 보내는 것이 가능은 하지만 GET과 DELETE의 본문은 어떻게 처리해야한다는 정의가 없기 때문에 POST, PUT, PATCH시에 사용을 한다.
Request Payload 부분이 본문 부분인데 위 사진은 크롬이 보기 좋게 표시한 것이고 실제로는 다음과 같이 요청이 전달이 될 것이다.
POST myfit.xyz/male/upper HTTP/1.1
Accept-encoding: gzip
Accept-language: ko-KR
...
{data:{type: "UPPER_ANALYZE_REQUEST", brand: "MYFIT" ... } -> 본문
서버는 저 본문을 받아 파싱(해석)한 후 사용하게 되는 형식이다.
만약 GET에 데이터를 담아 보내고 싶다면 어떻게 할까?
위 이미지에서 Query String Parameters 을 이용한다.
저 부분은 myfit.xyz/male/upper?test=false에서 ? 뒷 부분(test=false)이다.
이렇게 주소 뒤에 ?를 붙인 후 키=값&키=값 식으로 데이터를 보낼 수 있다.
GET 요청은 본문 대신 주소에 쿼리스트링으로 데이터를 동봉하겠다는 뜻이다.
예를 들어 사용자를 이름순으로 가져오고 싶다면 GET /users?sort=name HTTP/1.1요청을 보내면 된다.
GET /users?sort=name&filter=developer&limit=100 HTTP/1.1처럼 쿼리스트링 간에 &로 구별도 가능하다!
HTTP특징
- TCP 기반의 통신 방식
- 비연결(Stateless) 지향
- 브라우저를 통해 사용자의 요청으로 서버와 접속하여 요청에 대한 응답의 데이터를 전송 후, 연결 종료
- 간단하기 때문에 자원이 적게드는 장점이 있다.
- 클라이언트와 서버가 계속 연결된 상태가 아니기 떄문에 클라이언트와 서버 간의 최대 연결 수 보다 훨씬 많은 요청과 응답을 처리할 수 있다.
- 연결 종료 후 추가적인 요청 시 어떤 사용자의 요청인지 알 수 없다는 단점 존재 -> 쿠키사용
- 단방향성
- 사용자의 요청 한개에 대해 한개의 응답을 하는 방식
HTTP의 문제점
- HTTP는 평문 통신이기 때문에 도청이 가능
- 통신 상대를 확인하지 않기 대문에 위장이 가능
- 완전성을 증명할 수 없기 대문에 변조가 가능
HTTPS
- Hyper Text Transfer Protocol Secure
- HTTP에 데이터 암호화가 추가된 프로토콜이다.
- HTTP 통신하는 소켓 부분을 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer)라는 프로토콜로 대체한 것이다.
- TTP는 TCP와 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
- 즉, 하나의 레이어를 더 둔 것이다.
- HTTPS의 SSL에서는 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용한다.
대칭키 / 공개키
HTTPS는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화하고 있다.
공개키와 개인키는 서로를 위한 1쌍의 키이다.
- 공개키: 모두에게 공개가능한 키
- 개인키: 나만 가지고 알고 있어야 하는 키
공개키와 개인키로 암호화하면 다음과 같은 효과를 얻을 수 있다.
- 공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. -> 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
- 개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다. -> 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.
SSL
- SSL 프로토콜은 Netscape 사에서 웹 서버와 브라우저 사이의 보안을 위해 만들어졌다. CA(Certificate Authority)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다.
애플리케이션 서버를 운영하는 기업은 CA를 통해 인증서를 만든다.
- 애플리케이션 서버를 운영하는 기업은 HTTPS 적용을 위해 공개키와 개인키를 만든다.
- 신뢰할 수 있는 CA 기업을 선택하고 인증서 생성을 요청한다.
- CA는 서버의 공개키, 암호화 방법 등의 정보를 담은 인증서를 만들고 해당 CA의 개인키로 암호화하여 서버에 제공한다.
- 클라이언트가 SSL로 암호화된 페이지(https://)를 요청시 서버는 인증서를 전송한다.
클라이언트와 서버의 통신 흐름 과정
- 클라이언트가 SSL로 암호화된 페이지를 요청한다.
- 서버는 클라이언트에게 인증서를 전송한다.
- 클라이언트는 인증서가 신용이 있는 CA로부터 서명된 것인지 판단한다. 브라우저는 CA 리스트와 해당 CA의 공개키를 가지고 있다. 공개키를 활용하여 인증서가 복호화가 가능하다면 접속한 사이트가 CA에 의해 검토되었다는 것을 의미한다. 따라서 서버가 신용이 있다고 판단한다. 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것으로 이러한 것을 전자 서명 이라고 한다.
- 클라이언트는 CA의 공개키를 이용해 인증서를 복호화하고 서버의 공개키를 획득한다.
- 클라이언트는 서버의 공개키를 사용해 랜덤 대칭 암호화키, 데이터 등을 암호화하여 서버로 전송한다.
- 서버는 자신의 개인키를 이용해 복호화하고 랜덤 대칭 암호화키, 데이터 등을 획득한다.
- 서버는 랜덤 대칭 암호화키로 클라이언트 요청에 대한 응답을 암호화하여 전송한다.
- 클라이언트는 랜덤 대칭 암호화키를 이용해 복호화하고 데이터를 이용한다.
인증서에 포함된 내용
- 서버측 공개키(public key)
- 공개키 암호화 방법
- 인증서를 사용한 웹서버의 URL
- 인증서를 발행한 기관 이름
모든 웹페이지에서 HTTPS를 사용하지 않는다. 이유는 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 많이 필요로 하기 때문이다. 통신할 때마다 암호화를 하면 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 Request 수가 줄어들게 된다.
따라서 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용해야 한다.
참고
https://developer.mozilla.org/ko/docs/Web/HTTP/Messages
https://www.boostcourse.org/web316/lecture/16661?isDesc=false
github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/HTTP%2C%20HTTPS.md
developer.mozilla.org/ko/docs/Web/HTTP/Overviewblog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/