HTTP와 HTTPS 프로토콜

우리는 하나의 서비스를 제작할 때, 크게 3가지로 나눈다.

 

1. 사용자들이 직접 접하는 클라이언트

2. 클라이언트로부터 요청 받은 내용을 추려 전달해주는 서버

3. 데이터를 저장하는 데이터베이스

 

보통은 서버에서 데이터베이스까지 관리하는 경우가 많다.

 

클라이언트와 서버는 서로 통신을 하여 데이터를 주고 받아야 하는데 이때 사용되는 통신 프로토콜이 Http 프로토콜이다.

 

HTTP 프로토콜이란?

Http 프로토콜은 정보(데이터)를 송·수신하도록 설계된 프로토콜이다.

 

기본적으로 요청과 응답으로 나누어지며,

 

요청은 클라이언트가 서버에 데이터를 요청할 때 사용되며, 구성 요소는 다음과 같다.

 

요청 구성 요소

1. 요청 Header

Hearder는 클라이언트가 사용하는 브라우저 및 앱, 요청되는 데이터와 같은 핵심 정보를 전달한다.

이때 정보는 Key-Value의 형태로 전달

 

2. URL

URL은 하나의 주소로 우리가 데이터를 요청할 때 그에 맞는 URL로 요청을 보내 원하는 데이터를 얻어올 수 있다.

예를 들어

• naver.com

• google.com

모두 URL이며, 해당 URL로 접속을 하면 서버에서 이에 맞는 데이터를 넘겨주면서 우리가 알고 있는 naver, google 화면이 사용자에게 보여지게 된다.

3. 메서드

우리는 URL로 요청을 보낼 때 반드시 동반되어 같이 전송해야 하는 것이 있다.

 

그것이 바로 메서드이다.

 

URL로 요청만 보내면 서버 입장에서는 데이터를 수정하는 것인지, 데이터를 삭제할 것인지, 기존의 데이터를 받아가기만 할 건지 알 수 있는 방법이 없다.

 

따라서 메서드를 동반하여 우리가 원하는 요청을 서버에게 명확하게 알려주어야 한다.

 

메서드의 종류는 다음과 같다.

 

GET

URL에 해당하는 데이터만 받아 올 경우 사용된다.

 

POST

클라이언트에서 어떠한 데이터를 함께 보내 이에 맞는 데이터를 요청할 때 사용된다.

Ex) 로그인 할 때 아이디와 비밀번호를 서버로 전송하여 계정 유무를 확인할 때 사용

 

PUT

데이터를 수정할 때 사용된다.

Ex) 비밀번호 변경

 

DELETE

데이터를 삭제할 때 사용된다.

 

응답 구성요소

1. 상태 코드

요청에 대한 결과를 나타내주는 코드

 

100번대 - 임시 응답 / 지금까지의 요청은 완료되었으니 계속 진행

 

200번대 - 성공

 

300번대 - 추가 동작 필요

 

400번대 - 클라이언트 에러 / 요청 내용 중 잘못된 것이 있음

 

500번대 - 서버 에러 / 서버에서 처리 과정 중에 생긴 에러

 

2. Header

요청과 마찬가지로 핵심 정보가 담겨온다.

 

3. Body

요청한 데이터들이 담겨 오며, 형태는 주로 Json

{
  "user": [
    {
      "name": "Hong",
      "age": 29,
      "email": "abc@google.com"
    },
    {
      "name": "Kim",
      "age": 39,
      "email": "abcd@google.com"
    }
  ]
}

 

Version

HTTP 1.1 (표준)

• 지정한 TimeOut 동안 Connection을 닫지 않고 열어 두고 사용
  
  • HTTP Keep-Alive라고 하며, 이는 HTTP Header를 통해 Client와 Server가 주고 받으며 확인한다.
  • HTTP Keep-Alive는 TCP Connection 내에서 동작한다.

HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=10, max=500

HTTP/1.1 200 OK
Connection: Close

• PipeLining으로 연속적으로 요청을 받을 수 있음
  • 요청에 대한 응답이 오래 걸릴 경우, 뒤의 요청이 Blocking 될 수 있음 ( Head Of Line Blocking)

• 연속 된 요청의 Header 중복 발생

 

HTTP 2.0

• Mutiplexed Streams
  • 하나의 Connection 내에 여러 양방향 Stream을 통해 동시에 여러 요청 처리
  • 메시지는 이진화 된 텍스트인 Frame으로 나뉘어 요청마다 구분되는 Stream을 통해 전달
• Stream Prioritization
  • Stream에 우선순위 부여
• Server Push
  • Server에서 Cilent에게 필요한 추가적인 리소스를 Push
• Header Compression
  • 요청과 응답의 헤더 메타데이터를 압축해서 오버헤드 감소

---

HTTPS

HTTP의 단점

1. 암호화 되지 않은 데이터 통신

2. 신뢰성 - 사이트가 안전한 사이트인지 확인이 불가능하다.

 

Hypertext Transfer Protocol Secure

HTTPS의 S는 Secure로 HTTP에 보안을 추가한 프로토콜이다.

HTTP의 단점을 보완하기 위해 SSL을 이용하여 보안을 강화하였다.

 

SSL/TLS

암호화 기반 인터넷 보안 프로토콜

• 개인 정보 보호
• 인증
• 데이터 무결성

대칭키과 공개키

HTTPS는 대칭키와 공개키를 사용하여 데이터를 보호한다.

 

대칭키

• 서로 같은 키를 갖고 데이터를 암호화 및 복호화

 

공개키

• 서로 다른 키를 사용
• A키로 데이터를 암호화하면 B키로만 복호화를 할 수 있다.
• 하나는 서버에서 비공개로 사용하고, 유저에게 다른 키를 공개하여 사용한다.

공개키로 데이터를 암호화하여 통신할 수 있으며, 사이트에서 사용하는 공개키를 신뢰할 수 있는 기관에서 인증해줌으로써 HTTPS를 사용하는 사이트의 신뢰성을 보장할 수 있다.

신뢰할 수 있는 기관을 CA라 부르며 크롬, 사파리와 같은 브라우저에는 CA들의 목록이 내장되어 있다.

 

과정

1. 처음 클라이언트가 서버에 HandShake를 통해 서버의 인증서를 받음
2. CA를 통해 확인 (공개키)
3. CA에 인증된 인증서는 CA의 개인키로 암호화가 되어있다.
4. 즉, 인증 된 인증서라면 브라우저에 있는 CA의 공개키로 복호화가 가능하다.
5. 복호화 된 인증서에는 서버의 공개키가 포함되어 있다.
6. 공개키를 사용하여 대칭키를 암호화하여 주고 받고, 데이터는 대칭키로 암호화하여 사용한다. (모든 데이터를 공개키로 암호화 및 복호화하는 것은 컴퓨터에 많은 부하를 주기 때문)