HTTP(HyperText Transfer Protocol)

서버-클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜
TPC, UDP 80번 포트 사용
접속 도중에 끊기더라도 다시 시작할 필요가 없어 시간 낭비X
상태를 가지고 있지 않는 Stateless 프로토콜

HTTP 요청/응답 헤더

요청 헤더(request header)

GET /xyz.html HTTP/1.1
Host: www.xyz.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: text/html; */*
Cookie: name = value
Referer: http://www.abc.com/abc.html

첫번째 줄은 요청 라인 -> method URI HTTPversion
get method로 /디렉토리의 xyz.html을 요청하는데 사용하는 프토콜의 버전이 1.1이다.

첫번째 줄 다음에 나오는 부분이 요청 헤더에 해당
각각 name : value의 형태로 규정
method 이름은 반드시 대문자
요청 헤더는 대소문자 구분 X, 공백도 자동으로 제거

• Host : 클라이언트에서 요청한 호스트명 및 포트번호
• User-Agent : 클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전
• Accpet : 서버로부터 받는 데이터 중 웹 브라우저가 다룰 수 있는 미디어 타입(media type)
  "*/*"는 특정한 유형이 아닌 일반적인 형태를 다 허용
• Authorization : 인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더
• Cookie : 사용자 하드 디스크에 쿠키가 있는 경우 name-value을 읽어 들여서 웹 서버로 전송
• Referer : 접속한 클라이언트의 주소(바로 직전에 머물렀던 웹 링크 주소)
• Origin : 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타낸다
  요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
  응답 헤더의 Access-Control-Allow-Origin와 관련

응답 헤더(response header)

HTTP/1.1 200 Found
Date: Mon, 10 Feb 1997 23:48:22 GMT
Server: Apache/1.3.9 
Connection: close 
Content-type: text/html; charset=utf-8
Date: Mon, 18 Jul 2019 16:06:00 GMT
Last-Modified: Tues, 11 Feb 2000 22:45:55 GMT

첫번째 줄은 상태 정보를 담고 있는 응답 라인
클라이언트가 요청한 주소가 웹 서버에 있으면 "200 Found", 없으면 "404 Not Found"

첫번째 줄 이후부터 응답 헤더의 각 필드와 값

• Date : 요청된 내용을 수행하는 시간과 날짜
• Server : 서버 소프트웨어 정보
• Set-Cookie : 서버측에서 클라이언트에게 세션 쿠키 정보를 설정
• Expires : 리소스가 지정된 일시까지 캐시로써 유효함
  (응답 컨텐츠가 언제 만료되는지를 나타냄)
• Connection : 접속 상태를 규정
  close인 경우 이번 트랜잭션이 마무리되면 접속을 끊는다
• Allow : 해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트
• Content-type : 보내는 데이터의 미디어 타입
• Last-Modified : 보내는 데이터가 마지막으로 수정된 날짜
• Access-Control-Allow-Origin : 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
  서버에서 이 헤더에 프론트 주소를 적어줘야 에러X
  *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.

HTTP의 동작

1. 사용자가 웹 브라우저에 URL 주소 입력(호스트명과 포트번호를 얻는다)

2. DNS 서버에 웹 서버의 호스트명을 IP 주소로 변경 요청

3. 웹 서버와 TCP 연결(3 way Handshake)

4. 웹 브라우저는 서버에게 HTTP 요청 전송

5. 서버는 웹 브라우저에게 HTTP 응답 전송

6. 서버-클라이언트 연결 해제(4 way Handshake)

7. 웹 브라우저가 웹 문서 출력

암호화가 되지 않은 평문 데이터를 전송하는 프로토콜
-> 중간에서 정보를 가로챌 수 있는 위험성 존재

이러한 문제를 해결하기 위해 HTTPS 등장

HTTPS(HyperText Transfer Protocol over Secure Socket Layer)

HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure

HTTP에 데이터 암호화가 추가된 프로토콜
소켓 통신에서 일반 텍스트를 이용하는 대신 SSL, TLS 프로토콜을 통해 세션 데이터를 암호화
공개키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신
TCP/IP 443번 포트 사용
보안 단계로 인한 서버 부하증가로 인한 처리속도는 최근 네트워크/서버 장비 성능의 증가에 따라 체감할 정도 X

TLS(Transport Layer Security)는 과거 SSL(Secure Socker Layer)에서 이름이 변경 된 것. 아직도 SSL 명칭 많이 사용

공개키 / 개인키 방식

• 공개키 암호화 : 공개키로 암호화 -> 개인키로 복호화
• 개인키 암호화 : 개인키 암호화 -> 공개키로 복호화
• 개인키 : 자신만 가지고 있고 공개되지 않는다.
• 공개키 : 타인에게 제공. 공개키는 유출이 되어도 비공개키를 모르면 복호화 할 수 없기 때문에 안전

대칭키 방식

• 암호화 할 때 사용하는 비밀번호를 키(Key)라 한다.
  대칭키는 동일한 키로 암호화, 복호화 가능
• 대칭키는 매번 랜덤으로 생성되어 누출되어도 다음번에 사용할 때 다른 키 사용되므로 안전
• 공개키보다 빠르게 통신

HTTPS의 동작

SSL 방식을 적용하기 위해서 인증서를 발급받아 서버에 적용시켜야한다.
인증서는 사용자가 접속한 서버가 의도한 서버가 맞는지 보장하는 역할을 해야함.
이러한 인증서를 발급하는 기관을 CA(Certificate Authority)라고 부른다.

1. 인터넷 사이트는 자신의 정보와 공개키를 CA에 제출(인증서 발급 요청)

2. CA는 검증 절차를 거쳐 개인키로 사이트에 제출한 정보를 암호화(인증서 발급)

3. CA는 웹 브라우저에게 공개키를 제공
   (웹 브라우저는 CA 리스트와 각 공개키를 알고 있음)

4. 사용자가 사이트에 접속 -> 자신의 인증서를 웹 브라우저에게 보낸다.

5. 웹 브라우저는 미리 받았던 CA의 공개키로 인증서 복호화하여 검증
   (사이트의 정보와 공개키를 알 수 있게된다)

6. 얻은 사이트 공개키로 대칭키를 암호화해서 다시 사이트에 보냄

7. 사이트는 개인키로 복호화하여 대칭키를 얻게 되고 대칭키로 데이터를 주고받는다.