HTTP는 무엇일까?

date
Dec 24, 2021
slug
http
author
status
Public
tags
HTTP
HTTPS
summary
프론트엔드 로드맵
type
Post
thumbnail
frontend.png
category
💻 Develop
updatedAt
Feb 27, 2023 01:26 AM

1. HTTP란?

HTTP(Hyper Text Transfer Protocol)의 약자로 서버와 클라이언트가 서로 데이터를 주고받기 위해 사용되는 통신 규약을 말한다.
  • 1989년 팀 버너스-리에 의해 처음 설계되어 인터넷을 통한 월드 와이드 웹(우리가 아는 www) 기반에서 전 세계적인 정보 공유를 이루는데 큰 역할을 했습니다.
  • HTTP는 웹에서만 사용하는 프로토콜로 TCP/IP 기반으로 한 지점에서 다른 지점(서버와 클라이언트)으로 요청과 응답을 전송합니다.

2. HTTP의 특징

  • HTTP 메시지는 HTTP 서버와 클라이언트에 의해서 해석이 된다.
  • TCP/IP를 이용하는 응용 프로토콜이다.
  • HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다.
  • HTTP는 연결을 유지하지 않는 프로토콜이기 때문에 요청/응답(request/response)방식으로 동작한다.
 
서버: 어떤 자료에 대한 접근을 관리하는 네트워크 상의 시스템(요청에 대한 응답을 보내준다.) 클라이언트: 그 자료에 접근할 수 있는 프로그램
notion image

Request(요청)

클라이언트 --메시지--->서버를 요청이라고 하고 요청을 보낼때는 요청에 대한 정보를 담아 서버로 보낸다.
 
Request Method (요청의 종류)
  • GET: 자료를 요청할 때 사용
  • POST: 자료의 생성을 요청할 때 사용
  • PUT: 자료의 수정을 요청할 때 사용
  • DELETE: 자료의 삭제를 요청할 때 사용
Request HTTP 메시지 예시
GET https://notion.so/@junmyung HTTP/1.1    //시작줄
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)... //헤더
Upgrade-Insecure-Requests: 1 //헤더
  1. 시작줄 (첫줄)첫 줄은 시작줄로 메서드 구조 버전으로 구성되었다.
      2. GET: HTTP Method https://notion.so/@junmyung : 사이트 주소 HTTP/1.1 : HTTP 버전
  1. 헤더 (두번째 줄부터)두번째 줄부터는 헤더이며 요청에 대한 정보를 담고 있다.
  1. 본문 (헤더 뒤부터)본문은 요청을 할 때 함께 보낼 데이터를 담는 부분이다. 예시에는 단순히 주소로만 요청을 보내고 있기 때문에 본문이 비어있다.

Response(응답)

서버 --메시지---> 클라이언트를 응답이라고 부르고 서버가 요청에 대한 답변을 클라이언트에 보내는 것이다.
Status Code(상태 코드)
상태 코드에는 많은 종류가 있다. 모두 숫자 3자리로 이루어져 있으며, 아래와 같이 크게 다섯 가지로 나눌 수 있다.
  • 1xx (조건부 응답): 요청을 받았으며 작업을 계속한다.
  • 2xx (성공): 클라이언트가 요청한 동작을 수신하여 이해했고, 승낙했으며, 성공적으로 처리했음을 가리킨다.
  • 3xx (리다이렉션 완료): 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
  • 4xx (요청 오류): 클라이언트에 오류가 있음을 나타낸다.
  • 5xx (서버 오류): 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.
Response HTTP 메시지 예시
HTTP/1.1 200 OK     //시작줄
Connection: keep-alive    //헤더
Content-Encoding: gzip
Content-Length: 35653
Content-Type: text/html;

<!DOCTYPE html><html lang="ko" data-reactroot=""><head><title...
  1. 시작줄첫 줄은 버전 상태코드 상태메시지로 구성되어 있고, 200은 성공적인 요청이었다는 뜻이다.
  1. 헤더 (두번째 줄부터)응답에 대한 정보를 담고 있다.
  1. 본문 (헤더 뒤)응답에는 대부분의 경우 본문이 있다. 보통 데이터를 요청하고 응답 메시지에는 요청한 데이터를 담아서 보내주기 때문이다. 응답 메시지에 HTML이 담겨 있는데 이 HTML을 받아 브라우저가 화면에 렌더링한다.

3. HTTPS?

HTTPS (Hyper Text Transfer Protocol Secure) 뒤에 S가 붙는것은 보안을 뜻한다. HTTP의 암호화 버전인 셈이다. 이것은 대개 클라이언트와 서버 간의 모든 커뮤니케이션을 암호화 하기 위하여 SSL이나 TLS을 사용한다. 이 커넥션은 클라이언트가 민감한 정보를 서버와 안전하게 주고 받도록 해준다.
S가 secure을 뜻하는 만큼 기존의 HTTP 사이트보다 안전하다는 뜻이다. 무엇으로부터 안전할까? 크게 둘로 나뉜다.
  • 내가 어떤 웹사이트에 보내는 정보를 다른 누군가가 훔쳐보지 못하게 한다.
  • 접속한 사이트가 진짜인지, 신뢰할 수 있는 사이트인지를 판별해준다.
이것을 어떤 방식으로 활용할까?

'대칭키'의 개념

메시지를 보내는 쪽과 받는 쪽이 메시지를 암호화하고, 이를 다시 메시지로 바꾸는 즉 복호화하는 방식을 공유한다.
예를 들어 임의의 문자열이 있다고 치면 상대방에게 보내고자 하는 메시지를 이 '키'와 함께 어떤 알고리즘에 넣고 돌린다. 그러면 전혀 알 수 없는 암호문이 만들어지는데 이것을 '암호화'라고 부른다.
해당 암호문을 받은 사람이 이 메시지를 보려고 한다면 이 '키'값을 알고, 알고리즘을 거꾸로 돌리면 된다. 이 과정을 '복호화'라고 한다. 대신 '키'를 알지 못하면 절대 이 암호문을 해독할 수 없다.
ex) 주는사람: 4 (메시지) * 3 (키&알고리즘) = 12(암호문)

받는사람: 12 (암호문) / 3 (키&알고리즘) = 4(메시지)
단점: 어쨋든 서로가 같은 키를 가지고 있어야 되는데 '키'를 보낼때 위험성이 있다.

'비대칭키'의 개념

대칭키의 보완한 새 방식은 1970년대에 수학자들에 의해 개발이 되었는데 이것이 비대칭키, 또는 공개키라 불리는 시스템이다.(개발자들은 공개키 라고 부른다.)
여기에는 두개의 '키'가 사용되는데 각가 A키와 B키라고 가정하면 이 두개의 '키'는 한쌍이다. 서로 다르기 때문에 '비대칭키'라고 불린다.
대칭키 시스템에서는 하나의 키로 암호화를 하면 같은 키로 복호화를 할 수 있었지만, 여기서는 A키로 암호화 하면 B키로만 복호화 할 수 있다. 반대로 B키로 암호화를 하면 A키로만 풀 수 있게된다.
ex) 네이버는 A키를 가지고 있으면서 B키(공개키)를 대중들에게 뿌린다.
그러면 사람들은 네이버에 접속하여 정보를 보낼때 B키(공개키)로 암호화해서 보내게 되는데,
이것은 같은 키인 B키(공개키)로는 풀 수 없기 때문에 중간에서 가로챈다고 하더라도 소용없게 되는것이다.

Certificate Authority

네이버가 우리에게 뿌린 공개키 이것이 정품인지 확인할 수 있어야 한다. 네이버가 아니라 네이놈의 공개키 일수도 있기 때문이다.
이것을 인증해주는 공인된 민간기업들이 있는데 Certificate Authority, 줄여서 CA 라고 부른다. 아무나 차릴 수 없고 철저하고 엄격한 인증과정을 거쳐야 CA를 할 수 있다. 우리가 쓰는 크롬이나 사파리, 파이어폭스, 익스플로러 등의 프로그램에는 CA들의 목록이 내장되어 있다.
서버와 클라이언트는 아직 서로를 신뢰하기 전에 먼저 탐색 과정을 거치게 되는데 이것을 HandShake(악수) 라고 합니다. 먼저 클라이언트는 랜덤 데이터를 서버에 보내고, 서버측도 무작위로 데이터를 생성해 클라이언트로 보내게 된다. 이때 해당 서버의 인증서도 같이 실어서 보내게 된다.
이런 과정을 HandShake(악수)했다고 표현한다. 이제 클라이언트는 이 인증서가 진짜인지 브라우저에 내장된 CA들의 정보를 통해 확인하게 된다. 이때 비대칭키 시스템을 사용한다. 해당 인증서들은 CA의 인증을 받았기 때문에 CA가 가지고 있는 개인키로 암호화가 되어있다. 인증서가 진짜라면 브라우저에 저장된 CA의 공개키로 복호화할 수 있게된다. 복호화를 할 수 있다는건 해당 인증서를 암호화한 CA가 진짜라는것을 의미한다. 복호화 할 수 없다면 브라우저 주소창에 Not secure메시지가 뜨게 되면서 해당 인증서가 안전하지 않다는 것이다.
복호화된 인증서에는 서버의 공개키도 포합되어 있다. 그럼 이제 비대칭키 방식을 이용해서 계속 데이터를 주고받는다?!
결론은 NO이다. 이제부터는 대칭키 방식과 비대칭키 방식을 혼합해서 사용한다.
Why? 비대칭키 방식으로 데이터를 암호화 & 복호화 하는것은 대칭키로 할때보다 컴퓨터에 훨씬 큰 부담을 주기 때문이다. 사이트를 이용할때 주고받을 다량의 데이터를 일일이 암호화, 복호화하는건 무리란 얘기이다.
대칭키는 위험할수 있다고 하지 않았나? 그래서 대칭키를 주고 받을때 비대칭키 방식을 써서 암호화가 진행되고 주고 받은 다음 복호화 과정을 거친다. 이런 과정을 거치면 서로 안전하게 대칭키를 주고 받을 수 있다.