HTTP
HTTP(Hyper Text Transfer Protocol) 데이터를 주고 받기 위한 프로토콜 서버/클라이언트 모델을 따른다.
- 상태를 저장하지 않는 Stateless 특성
- 요청을 보내고 연결을 끊는 Connectionless 특징을 가진다.
HTTP/1.0의 특징
- 한 연결당 하나의 요청을 처리하도록 설계됨
- 서버에 요청을 할때마다 TCP 3 -way-handshake과정을 거치기 때문에 패킷왕복시간이 증가하는 단점이 있다.
BASE64 인코딩
- 패킷왕복시간이 길어지기 때문에 해결방법으로 이미지를 64진법으로 이루어진 문자열로 인코딩하는 방법
- HTTP 요청을 할 필요가 없다.
- BASE64 문자열로 변환할 경우 크기가 더 커진다.
이미지 스플리팅
- HTTP 요청시 패킷왕복시간 증가 해결 방법 중 하나, 이미지가 합쳐져있는 하나의 이미지를 다운받고 position을 이용하여 이미지를 표기하는 방법
코드압축
- 코드를 압축하는 방법으로 패킷왕복시간을 줄일 수 있다.
HTTP/1.1
-
HTTP/1.0의 발전 형태 요청 시 TCP 요청을 매번하는 번거로움을 해결하기 위해 Keep-alive 옵션을 두어 TCP 연결을 유지하는 옵션
-
HOL BLOCKING(Head Of Line Blocking)이 발생할 수 있다. HTTP 요청은 이전 요청이 처리되고 응답을 받아야 그다음 요청을 보낼 수가 있다. 이전 요청이 해결되지 않으면 그 뒤의 요청이 대기하게 되며 다운로드가 지연되는 현상을 말한다.
- TCP는 패킷이 손실되면, 재전송을 통해 패킷 손실을 방지할 수 있지만, 순서가 역전이 되지 않도록 후속 패킷이 대기하기 때문에 발생하는 현상
HTTP/2
-
멀티 플렉싱 : 여러 개의 스트림을 사용해서 송수신하는 방법 특정 스트림의 패킷이 손실되어도 나머지 스트림은 정상적으로 작동한다. (HOL BLOCKING이 발생하지 않는다.)
-
헤더 압축 : 허프만 압축 알고리즘을 사용하였다.
-
서버 푸시 : 클라이언트 요청없이 서버가 바로 리소스를 푸시하는 방식
HTTPS
- HTTP는 따로 암호화 과정을 하지 않고, 중간에 공격자가 패킷을 가로채거나 위조할 수 있는 위험성을 가진다. 이를 보완해서 나온 것이 HTTPS 암호화 계층을 거쳐 패킷을 암호화 한다.
- SSL/TLS 통신과정을 거쳐 인증서와 암호알고리즘을 거쳐 안전한 통신과정을 거칠 수 있다.
SSL/TLS
-
전송 계층에서 보안을 제공하는 프로토콜
-
보안 세션을 기반으로 데이터를 암호화하며, 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다.
-
HTTP의 Application 계층과 전송계층(TCP)계층 사이에 위치한다.
SSL HandShake
- 제3자 인증, 공개키 암호화 , 비밀키 암호화를 사용하는데, 이 때 인증메커니즘은 인증기관에 등록된 인증서만 신뢰하는 것을 말하며, 공개키 암호화는 비밀키를 공유하기 위해 사용된다. 비밀키 암호화는 보안 세션 즉, 데이터 통신시 암호화를 위한 것이다.
- 클라이언트의 TCP 3way handshake 수행
- Client Hello 전송
- Server Hello 전송, (인증서, 제공할 수 있는 암호화 알고리즘 리스트 등 제공)
- 클라이언트의 인증서 확인, (인증서는 인징기관의 개인키로 암호화 됨, 공개키로 검증이 가능하다) 서버의 공개키를 획득
- 클라이언트의 비밀키와 서버의 공개키를 통해 랜덤한 대칭키를 암호화하여 보낸다. (이 대칭키는 세션 중 데이터 암호화에 사요용됨)
- 서버는 비밀키를 통해 복호화 , 공유된 대칭키로 암호화하여 통신
공개키 암호화와 비밀키 암호화를 복합적으로 사용하는 이유?
- 공개키는 보안성이 높지만, 계산량이 많기 때문에 데이터 전송에는 적합하지 않다. 실제 데이터 암호화에는 비밀키를 사용하는 대칭키 암호화가 사용된다. 대신, 대칭키는 사용자들끼리 공유및 관리하기가 어렵다. 이 때, 사용자끼리의 공개키 공유를 통해 자신의 비밀키를 통해서 복호화하고 다시, 각자의 비밀 값을 통해 혼합하는 등 이러한 과정을 거치면, 데이터의 기밀성과 인증을 보장할 수 있다.
REFERENCT