HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML, 서버 간에 데이터 주고 받기 등등
HTTP의 역사
(1991) HTTP/0.9
(1997) HTTP/1.1 : 가장 많이 사용, 대부분의 기능이 여기 들어 있음. TCP.
(2015) HTTP/2 : 성능 개선. TCP.
(현재진행형) HTTP/3 : 성능 개선. UDP.
개발자 도구의 네트워크 탭에서 protocol 컬럼을 활성화 하면 어느 네트워크 프로토콜을 사용하는지 알 수 있다. 예를 들어, h2는 HTTP/2, h3은 HTTP/3이다.
HTTP 특징
클라이언트-서버 구조
클라이언트는 서버에 요청을 보내고 대기. 서버는 요청 결과를 만들어서 응답을 준다.
구조를 분리한 것에 대한 이점이 존재. 클라이언트는 UI를 그리는 것에 집중하고, 서버는 복잡한 비즈니스 로직을 담당. 각자 구조를 발전시키는 데에도 용이.
무상태(stateless), 비연결성(connectionless)
stateless : 서버가 클라이언트의 이전 상태를 보존하지 않음.
connectionless : 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어 연결을 유지 하지 않는 것.
현재는 HTTP 지속연결(Persistent Connections)로 문제 해결
(처음 연결 이후 일정 시간 연결을 유지하거나, 여러 개의 요청(HTML, 자바스크립트, 이미지 등등)에 대한 응답이 다 올 때까지 기다린 후 연결을 종료)
HTTP 메시지
요청메세지와 응답메세지로 구분
HTTP 헤더 : HTTP 전송에 필요한 모든 부가 정보가 들어 있다.
단순함, 확장 가능
❗️ 문제점
서버에서부터 브라우저로 전송되는 정보가 암호화되지 않기에 데이터가 쉽게 도난당할 수 있다.
2-1. HTTPS
HTTPS란?
HTTPS
에서 마지막의 S는 Over Secure Socket Layer의 약자로 Secure라는 말을 통해서 알 수 있듯이 보안이 강화된 HTTP를 말한다.
SSL/TLS 인증서로 통신 내용(데이터)을 암호화시킨다.
HTTPS와 SSL
HTTPS와 SSL을 같은 의미로 이해하는 경우가 많은데,
결론적으로 말하면 웹이 인터넷 위에서 돌아가는 서비스 중의 하나인 것처럼 HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜이다.
SSL과 SSL 디지털 인증서를 이용했을 때의 이점
브라우저에 녹색 주소 표시줄이 표시된 EV 인증서를 받으면 방문자에게 신뢰감을 줄 수 있다.
(그렇지만 올바르게 사용되지 않는다면 사용자들에게 보안에 대한 잘못된 안심을 줄 수 있으므로 주의해야 한다.)
방문자에게 서버의 사용자가 실제 사용자임을 보장하기 때문에, 접속하려는 서버가 신뢰할 수 있는 서버인지를 판단할 수 있다.
통신 내용의 악의적인 변경을 방지할 수 있다.
HTTPS의 보안 외 장점
검색엔진 최적화
구글에서 가산점을 주기도 하고, 더 쉽게 노출되어 사람들이 더 많이 방문할 수 있다.
보다 빠른 브라우징 경험 제공
암호화가 서버 자원 및 페이지 로드 시간에 부정적인 영향을 미칠 것이라는 우려가 있었지만, 그 동안 서버와 클라이언트 소프트웨어 양 측에서 이뤄져 온 개선점들로 인해 TLS 암호화가 속도에 미치는 부정적 영향은 무시할 수 있는 수준으로 감소했다고 한다.
HTTP/2의 최적화로 인한 다수의 속도 개선 사항들이 배경으로 작용했다.
공식적으로 HTTP/2 스펙에는 암호화가 요구사항으로 포함되어 있지 않지만, 브라우저 제작사들이 이를 의무화하고 있었고, 웹사이트 개발자들은 자사 사용자들이 HTTP/2의 주요 속도 개선 기능들을 온전히 이용할 수 있도록 하려면 HTTPS를 배치해야 했던 것.
공개키는 이상적인 통신 방법이지만, 대칭키 방식보다 암호화 연산 시간이 더 소요되어 비용이 크다.
SSL 통신
암호화된 데이터를 전송하기 위해 공개키와 대칭키를 혼합해서 사용
클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화
대칭키 방식으로 암호화된 실제 정보를 복호화할 때 사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는다.
실제 데이터 : 대칭키
대칭키의 키 : 공개키
공개키-개인키 교환 과정 (TLS/SSL handshake)
1) 프로토콜과 사용할 암호화 알고리즘에 대한 동의가 이뤄진다.
2) 클라이언트는 임시 생성값을 서버에 보내 접속을 시도한다.
3) 서버 또한 이에 대응하는 임시 생성값을 만들어 인증서(내부에 서버의 공개키)와 함께 보낸다.
4) 클라이언트는 클라이언트에 내장된 CA의 공개키를 이용해 인증서를 복호화한다.
5) 검증 후, 클라이언트는 pre master secret key(위의 과정에서 생성된 임시 생성값을 조합해 만든 key) 를 서버가 준 공개키로 암호화해서 서버에 보낸다.
6) 서버는 자신의 개인키로 이를 복호화한다.
7) 이렇게 클라이언트와 서버는 모두 pre master secret key를 공유하게 된다. (대칭키 완성)
8) 클라이언트와 서버는 pre master secret key를 master secret key로 바꾸고, 이는 다시 session key를 생성한다.
9) 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받는다.
10) 데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이 때 통신에서 사용한 대칭키인 session key를 폐기한다.
HTTPS 배포를 선택한 이유
1. webRTC 라이브러리에서 HTTP를 지원하지 않음.
프로젝트의 핵심기능인 화상 채팅을 구현하기 위해 webRTC를 사용하기로 결정.
webRTC의 내부 메소드 중 필수로 사용해야 하는 getUserMedia 메소드가 HTTP를 지원하지 않음.
2. 보안 과 속도, 그리고 검색엔진최적화 의 관점에서 모두 HTTP보다 HTTPS가 우수
HTTP vs HTTPS
1. HTTP
HTTP란?
HTTP의 역사
HTTP 특징
❗️ 문제점
2-1. HTTPS
HTTPS란?
HTTPS와 SSL
HTTPS와 SSL을 같은 의미로 이해하는 경우가 많은데, 결론적으로 말하면 웹이 인터넷 위에서 돌아가는 서비스 중의 하나인 것처럼 HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜이다.
SSL과 SSL 디지털 인증서를 이용했을 때의 이점
HTTPS의 보안 외 장점
2-2. SSL 에서 사용하는 암호화의 종류
대칭키
공개키/비밀키
SSL 통신
HTTPS 배포를 선택한 이유
1. webRTC 라이브러리에서 HTTP를 지원하지 않음.
2. 보안 과 속도, 그리고 검색엔진최적화 의 관점에서 모두 HTTP보다 HTTPS가 우수
Reference
https://www.ssl.com/article/pros-and-cons-of-ssl-https-tls/ https://opentutorials.org/course/228/4894 https://www.itworld.co.kr/print/103924