이 글은 차근차근 코드이그나이터4 강좌 의 내용을 다시 정리한 글입니다.
모든 웹 개발을 할 때 HTTP에 대해서는 반드시 알고 있어야 하므로 차근차근 플라스크 강좌 에서도 동일한 내용을 작성합니다.

HTTP 기초

우리는 글에서 웹서비스를 구축하는 방법을 연습합니다. 웹은 http 프로토콜로 통신하므로 http 프로토콜에 대해서 알아보겠습니다.

HTTP란?

http는 Hyper Text Transfer protocol(하이퍼 텍스트 트랜스퍼 프로토콜)의 약자입니다. 하이퍼 텍스트는 특정 규칙으로 텍스트를 표현하는 방법을 뜻하므로 규칙이 있는 텍스트를 전송하는 통신 규약이라는 뜻입니다.
즉 http는 html을 전송하기 위한 통신 규약으로 시작했습니다.

프로토콜이란?

프로토콜은 서로 다른 컴퓨터 혹은 프로그램간에 데이터(메세지)를 교환하는 형식을 말합니다. 요청자가 어떤 형식으로 요청을 하면 응답자가 요청자의 메세지를 읽은 후 어떤 형식으로 응답할 지를 규정합니다.

http 프로토콜은 1989년 0.9버전부터 시작해서 1.0, 1.1을 거쳐 현재 2.0 버전까지 있습니다. 이 중 1.1까지는 사람이 읽을 수 있는 텍스트 형식 프로토콜이고 2.0부터는 사람이 읽어내기 힘든 이진 프로토콜입니다.

프로토콜의 진화에 대해서는 mdn http 프로토콜의 진화 https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP에 자세히 설명되어 있습니다.

클라이언트와 서버

기본적으로 통신은 요청자와 응답자로 나누어집니다. 요청자는 데이터를 요청하는 사람, 그리고 응답자는 데이터를 응답하는 사람입니다.

http 통신에서 요청자는 클라이언트라고 부릅니다. 가장 대표적인 클라이언트는 구글 크롬, ms 엣지 등 웹 브라우저입니다.
반면 응답자는 서버라고 부릅니다. 서버는 클라이언트의 요청을 기다리고 있다가 클라이언트의 요청이 있으면 요청을 처리해서 응답하는 역할을 합니다. 언제 요청이 올 지 모르기 때문에 서버는 항상 요청을 대기하고 있습니다.

물론 최근에는 클라우드 컴퓨팅의 발달에 의해 서버리스로 동작하는 경우도 있으나, 이 또한 요청 처리 서버가 항상 대기중이 아니라는 의미일 뿐 게이트웨이 역할을 하는 서버는 늘 대기하고 있습니다.

비연결성

기본적으로 http는 비연결성 프로토콜입니다. 한 번 요청과 응답이 끝나면 이전 요청과 응답에 대한 것은 까맣게 잊어버립니다.

이런 비연결성은 http의 구현을 간단하게 해 주었고, 웹이 지금처럼 발전하는 데 큰 역할을 했습니다. 하지만 반대로 직접 웹 서비스를 구현하는 입장에서는 이전에 했었던 요청 내용을 기억하는 것을 직접 구현해야 한다는 오버헤드가 생긴다는 것을 의미하기도 합니다.

최근에는 html5가 나오면서 웹소켓 등으로 연결을 지속하는 방법이 생겼습니다. 이전 버전인 html4까지는 연결 지속이 불가능해서 쿠키와 세션 등으로 직접 클라이언트와 서버 사이를 매핑시켜 주곤 했었습니다.

HTTP 메소드

HTTP 메소드의 정의

클라이언트는 필요할 때 서버에 자원(Resource - 리소스)을 요청하고, 서버는 요청에 따라 자원을 보내주거나, 변경하는 일을 하게 됩니다.

자원을 어떻게 다루느냐에 따라서 http 메소드가 달라집니다. "동사(verb)" 5종류(GET,POST,PUT, PATCH ,DELETE) 와 명사 4종류(HEAD, CONNECT, OPTIONS, TRACE ) 를 합쳐서 총 9개가 있습니다.

GET

서버에 자원 조회를 요청합니다.
가장 기본이 되는 http 메소드로 대부분의 클라이언트는 http 메소드를 특정하지 않는다면 GET 메소드라고 간주합니다.

GET 메소드는 상태를 변화시키지 않으며, 그저 요청한 자원을 클라이언트에 응답합니다.

CRUD(Create Read Update Delete)중 Read에 해당합니다. 데이터베이스 입장에서 보면 select입니다.

POST

서버에 새로운 자원 생성을 요청합니다.

웹 브라우저는 거의 대부분 POST로 CUD를 모두 해결합니다. html에서 데이터를 전송하는 폼(form)에서는 GET과 POST 두개의 메소드만 지원하는 경우가 많기 때문입니다.

새로운 자원을 생성하므로 상태를 변화시킵니다.

CRUD 중 Create 에 해당합니다. 데이터베이스 입장에서 보면 insert입니다.

PUT

클라이언트가 서버의 리소스 식별자를 알고 있다는 전제 하에 서버에 자원 전체 변경을 요청합니다.

PUT은 브라우저에서는 잘 사용하지 않고, 일반적으로는 REST API 설계시 많이 사용됩니다. 물론 jQuery등의 자바스크립트 라이브러리를 이용해서 PUT 메세지를 서버로 전송하는 것은 가능합니다만 쓰는 경우는 드문 편입니다.

자원 변경을 요청하므로 상태를 변화시킵니다.

CRUD 중 Update에 해당합니다. 데이터베이스 입장에서 보면 update입니다.

PATCH

클라이언트가 서버의 리소스 식별자를 알고 있다는 전제 하에 서버에 자원 일부 변경을 요청합니다.

PUT과 PATCH가 다른 점은, PUT은 리소스 전체를 대상으로 하는 데 반해 PATCH는 리소스 일부를 대상으로 한다는 점입니다.

예를 들어서 원본 데이터가 아래 형식으로 있다고 해 보겠습니다.

{
  "id" : 1,
  "name" : "고은연",
  "age" : 13,
  "hobby" : "잠자기"
}

PUT 요청을 합니다.

{
  'age' : 58
}

PUT 요청 결과는 이렇습니다.

{
  'age' : 58
}

PATCH 요청을 합니다.

patch /profile/1

{
  'age' : 58
}

PATCH 요청 결과는 이렇습니다.

{
  "id" : 1,
  "name" : "고은연",
  "age" : 58,
  "hobby" : "잠자기"
}

PATCH는 브라우저에서는 잘 사용하지 않고, 일반적으로는 REST API 설계시 많이 사용됩니다. 물론 jQuery등의 자바스크립트 라이브러리를 이용해서 PATCH 메세지를 서버로 전송하는 것은 가능합니다만 쓰는 경우는 드문 편입니다.

자원 변경을 요청하므로 상태를 변화시킵니다.

CRUD 중 Update에 해당합니다. 데이터베이스 입장에서 보면 update입니다.

DELETE

클라이언트가 서버의 리소스 식별자를 알고 있다는 전제 하에 서버에 자원 삭제를 요청합니다.

DELETE도 PUT처럼 브라우저보다는 REST API에서 주로 사용됩니다.

자원이 없어지는 것을 기대하므로 상태를 변화시킵니다.

CRUD 중 Delete에 해당합니다. 데이터베이스 입장에서 보면 delete입니다.

HEAD, CONNECT, OPTIONS, TRACE

이 외에도 응답 본문 없이 헤더만 보내는 HEAD, 연결 터널을 맺는 CONNECT, 리소스의 옵션을 결정하는 OPTIONS, 메세지 전송을 테스트하는 TRACE등이 있습니다만, 주로 사용하는 것이 아니므로 상세한 설명은 생략하겠습니다.

URI 분리해 보기

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument 형태로 된 주소를 많이 본 적이 있으실 겁니다. 위와 같은 인터넷 주소를 URI(Unique Resource Identifier) 라고 부릅니다. URI를 부분별로 분리해 보겠습니다.

http

http는 프로토콜입니다. 다른 표현으로는 스킴(scheme) 이라고 부르기도 합니다.
웹 자원은 http 혹은 https 프로토콜을 사용합니다.

http 외에도 데이터를 나타내는 data, 로컬 파일을 나타내는 file, 파일 전송 프로토콜인 ftp, 메일 전송을 나타내는 mailto, 전화번호를 나타내는 tel 등도 스킴에 속합니다.
프로토콜 뒤에는 ://를 붙여서 프로토콜이 끝났음을 나타냅니다.

도메인

www.example.com이 도메인에 해당합니다.

도메인은 웹 서버의 주소를 결정하는 이름입니다. 도메인은 ICANN 이라는 곳에서 관리합니다.

원래 인터넷 세상의 주소는 IP(Internet Protocol)이라고 불리는 12자리의 숫자로 이루어져 있습니다. 127.0.0.1 (=127.000.000.0001) 처럼 말이죠.
그런데 웹 사이트 주소를 숫자로만 외우기는 너무 어려우니 사람이 식별하기 쉬운 글자로 치환해 놓은 것이 도메인입니다.

우리가 인터넷에 도메인 이름을 입력하면 DNS(Domain Name Server - 도메인 네임 서버 - 네임서버라고 줄여 부르기도 합니다.) 에서 해당 도메인에 해당하는 IP 주소를 검색해서 실제 자원이 위치한 서버의 IP로 연결하게 됩니다.

최근에는 12자리로 이루어진 IPV4(Internet Protocol Version 4)가 부족해짐에 따라 128비트로 이루어진 IPV6로 서버의 주소를 설정하기도 합니다.

포트

80이 포트에 해당합니다. 포트는 :80처럼 :으로 시작하고 숫자로 표기합니다.

포트는 하나의 서버에서 외부와 통신하는 통로의 번호를 나타냅니다.

하나의 서버에는 여러 개의 프로그램이 실행될 수 있는데, 예를 들어 웹서버와 데이터베이스 서버가 동시에 실행되기도 합니다.
웹 서버와 데이터베이스 서버는 둘 다 외부와 통신해야 하는 프로그램이기 때문에 각자 통로가 필요합니다. 따라서 웹서버는 80포트, 데이터베이스 포트는 3306 포트 등으로 각자 통신 통로를 따로 열어두게 됩니다.

HTTP의 기본 포트는 80이기 때문에 도메인 뒤에 :80이 생략되면 웹 브라우저는 기본값을 80이라고 생각합니다. HTTPS의 경우 :443이 기본 포트입니다.

자원의 경로(path)

/path/to/myfile.html 이 경로에 해당합니다. 웹 자원 중 필수적인 요소를 나타낼 때 주로 경로를 이용해 표기합니다.

하나의 웹 서버 안에는 여러개의 자원이 있을 수 있는데, 자원을 식별하는 방법으로 경로가 사용됩니다.

쿼리 스트링(Query String)

?key1=value1&key2=value2이 쿼리 스트링에 해당합니다. 쿼리 스트링은 자원의 경로에 부가적인 정보를 전달할 때 쓰입니다.

쿼리 스트링은 ?로 시작하고 각 항목을 &로 이어붙이며 개별 항목은 키=값 형태로 구성되어 있습니다. 따라서 위 예제를 파이썬 코드로 표기해 보면 아래와 같은 데이터를 서버에 전달합니다.

{
    "key1" : "value1",
    "key2" : "value2"
}

쿼리 스트링은 URI의 일부로 표기되는 파라미터이기 때문에 HTTP GET 메소드에서 주로 사용됩니다.

프레그먼트(fragment)

#SomewhereInTheDocument가 프레그먼트(조각)에 해당하며, 프레그먼트는 문서 내의 위치를 가리키는 식별자입니다.

하나의 자원 주소 내에서 프래그먼트가 있을 경우 브라우저는 프래그먼트의 위치를 찾아 바로 해당 섹션으로 이동하는 특성을 가집니다.

HTTP 요청 형태

클라이언트가 서버로 메세지를 보내 자원을 요청하는 것을 요청(request - 리퀘스트)라고 부릅니다.

HTTP 규약에서 요청 메세지는 아래와 같은 형태로 이루어집니다. 아래 요청은 일반적인 HTTP GET 요청시 요청 메세지입니다.

GET /member HTTP 1.1
Host: github.com/koeunyeon
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

첫번째 줄은 HTTP 메소드, 요청할 자원의 주소, HTTP 프로토콜 버전입니다. 예시에서는 GET 메소드로 /member 자원에 HTTP 1.1 방식으로 접근하라는 의미가 됩니다.

GET /member HTTP 1.1

다음줄부터는 HTTP HEADER라고 부르는데, 요청에 필요한 부가적인 정보들이 들어갑니다.

Host: github.com/koeunyeon
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

각 항목들은 줄바꿈으로 구별되고, 키: 값 형태로 표기됩니다.

HTTP POST 요청시에도 형식은 동일합니다. 다만 HTTP BODY에 요청 본문이 들어가는 형태를 보기 위해 예제를 보겠습니다.

POST /member/edit?member_id=3 HTTP 1.1
Host: github.com/koeunyeon
... 이하 헤더 생략

login_id=my_id&login_pw=my_pw

위의 예제는 HTTP POST 형식으로 /member/edit?member_id=3 의 자원을 요청합니다. URI는 GET이든 POST든 동일합니다.

중간에 보면 한 칸 공백이 있습니다. 공백 위는 헤더(header), 공백 아래는 바디(body)라고 부릅니다.
예시에서 헤더는 이 부분입니다.

POST /member/edit?member_id=3 HTTP 1.1
Host: github.com/koeunyeon
... 이하 헤더 생략

바디는 나머지 부분입니다.

login_id=my_id&login_pw=my_pw

POST의 경우 서버로 전달하는 데이터를 바디에 담아 전달합니다. 위 예제에서는 아래와 같은 데이터를 전달했습니다.
소스코드

{
    "login_id": "my_id",
    "login_pw": "my_pw"
}

HTTP 응답 형태

클라이언트 요청에 대해서 서버가 응답하는 것을 응답(response - 리스폰스)라고 부릅니다.
HTTP 규약에서 응답 메세지는 아래와 같은 형태로 이루어집니다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Status: 200 OK

<html>
    ...
</html>

응답 첫번째 줄은 프로토콜,상태코드, 상태 메시지 세 개의 항목으로 구성됩니다.
소스코드

HTTP/1.1 200 OK

프로토콜 : HTTP/1.1
상태코드 : 200
상태 메시지 : OK

두번째 줄 부터는 응답 헤더라고 불리며, 클라이언트가 응답을 해석할 수 있도록 필요한 정보들을 제공합니다.

Content-Type: text/html; charset=utf-8
Status: 200 OK

HTTP 요청과 마찬가지로 공백 한 줄 이후 응답 바디(본문)가 시작됩니다.


<html>
    ...
</html>

본문의 내용은 일반적인 HTML일 수도 있고, JSON 혹은 XML 형식이거나, 단순 텍스트일 수도 있습니다.
HTTP 응답 본문은 HTTP 상태 코드에 따라 있을 수도 있고 없을 수도 있습니다.

주요 HTTP 응답 코드

HTTP 주요 응답 코드에 대해서 간단하게 알아보겠습니다. 모든 응답 코드에 대해 궁금하다면 MDN HTTP 상태 코드 https://developer.mozilla.org/ko/docs/Web/HTTP/Status 를 참고하세요.

코드	메세지	뜻
200	OK	요청이 성공했습니다.
301	Moved Permanently	요청한 리소스가 영구적으로 이동했습니다. 브라우저나 크롤러 등 클라이언트는 영구 이동을 기억하고 같은 리소스가 요청될 경우 캐시 등을 통해 서버에 리소스를 다시 요청하지 않을 수 있습니다.
302	Found	요청한 리소스가 임시로 이동했습니다. 클라이언트는 다음번 같은 리소스 요청시에도 서버에 요청을 합니다. 주로 POST 등으로 서버 리소스를 변경하고 나서 다른 페이지로 이동할 때 사용합니다.
400	Bad Request	서버가 요청을 이해할 수 없습니다.
401	Unauthorized	인증되지 않았습니다.
403	Forbidden	인증은 되었지만 서버 리소스에 접근할 권한이 없습니다.
404	Not Found	요청한 리소스를 찾을 수 없습니다.
405	Method Not Allowed	요청한 리소스는 요청한 메소드에 반응하지 않습니다. 주로 반드시 POST, PUT, DELETE 등 리소스를 변경하는 메소드만 허용하는 리소스를 GET 등으로 요청할 때 응답하는 코드입니다.
408	Request Timeout	서버가 지정한 시간보다 처리 시간이 오래 걸려서 연결을 끊습니다.
429	Too Many Requests	특정 시간 내에 하나의 클라이언트가 너무 많은 요청을 보냈습니다. 많은 서버들은 DDOS 공격 등을 방지하기 위해 짧은 시간 동안 너무 많은 요청이 있는 것을 방지하고는 합니다.
500	Internal Server Error	서버에 오류가 발생했습니다. 주로 프로그램이 예상하지 못한 상황에서 오류가 났을 경우 나오는 코드입니다.
502	Bad Gateway	메시지가 게이트웨이를 거치는 동안 오류가 발생했습니다. 주로 인프라쪽 문제일 경우가 많습니다.
503	Service Unavailable	서버가 아직 준비가 되지 않았습니다. 주로 정기점검 등 임시로 서비스의 접근을 막은 상태에서 게이트웨이나 로드밸런서 등에서 임시 페이지를 걸어놓았을 경우 사용됩니다.
504	Gateway Timeout	게이트웨이가 정상 시간 내에 응답할 수 없습니다. 서버에서 처리 시간이 너무 긴 것일 수도 있고, 게이트웨이에 부하가 걸려서 처리를 못하는 상황일 수도 있습니다.

HTTP와 HTTPS

HTTPS는 Hyper Text Transfer Protocol Secure의 약자입니다. S가 Secure - 보안의 약자임에서 알 수 있듯이 클라이언트와 서버 사이의 통신 규약에 보안을 더한 것입니다.

구체적으로는 RSA 알고리즘으로 브라우저와 서버 사이에 암복호화 키를 교환한 다음 핸드쉐이킹을 통해 전달할 데이터를 암호화하는 과정을 거칩니다.

최근에는 검색 엔진이 HTTPS를 더 선호하기도 하고, 브라우저에 HTTP일 경우 보안 인증서가 없어서 안전하지 않은 사이트라고 표기되는 경우가 많아 많은 사이트가 HTTPS를 적용합니다.

HTTPS 인증서는 공인된 인증 기관에서 구매할 수 있는데, 연간 3-5만원 사이입니다. 이 외에 무료로 쓸 수 있는 인증서는 letsencrypt가 있습니다.

만약 AWS같은 클라우드 서비스에서 로드밸런서를 사용하신다면 Amazon에서 발급한 인증서를 무료로 사용 가능합니다.

mime type

mime type은 서버가 클라이언트에 응답할 때 문서의 종류를 나타내기 위한 표현 방식입니다. 클라이언트는 이 정보를 받아서 이미지를 보여줄 지, 첨부 파일인지, HTML 문서인지, 동영상 파일인지 구분할 수 있습니다.

mime type은 type/subtype 구조로 표현되어집니다. 예를 들면 아래와 같습니다.

text/plain
text/html
image/jpeg
image/png
audio/mpeg
audio/ogg
audio/*
video/mp4
application/octet-stream

가장 많이 사용되는 형식 몇 개는 아래와 같습니다.

이름	설명
application/octet-stream	이진 파일입니다. 대부분의 경우 HTTP 헤더의 `Content-Disposition: attachment`와 함께 사용되어 브라우저는 첨부파일을 다운로드하는 용도로 사용합니다.
text/plain	일반 텍스트입니다.
text/css	html 문서의 모양을 구성하는 CSS(Cascading Style Sheet) 파일입니다.
text/html	html 문서입니다.
image/jpeg	jpg 이미지입니다.
image/png	png 이미지입니다.

더 많은 MIME 타입 정보가 필요하시다면 MIME 타입 - HTTP | MDN - https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types에 방문하세요.

REST

REST(Representational State Transfer)는 2000년 로이 필딩의 박사 논문에서부터 시작된 웹의 아키텍쳐입니다. 웹상의 문서 뿐만 아니라 동영상, 첨부 파일 등을 하나의 리소스로 표현하고, 리소스를 어떻게 다룰지를 동사(GET,POST,PUT,DELETE)로 표현하는 방식입니다.

REST는 자원을 어떻게 할 지를 동사와 리소스로 표현합니다. 예제로 사용자를 나타내는 users 라는 자원을 REST로 표기해 보겠습니다.

GET /users : 사용자 목록을 불러옵니다.
GET /users/1 : 식별자(id)가 1인 사용자의 정보를 불러옵니다.
POST /users : 사용자를 생성합니다. 사용자 정보는 HTTP BODY를 통해 요청됩니다.
PUT /users/1 : 사용자 정보 전체를 수정합니다. 수정할 사용자 정보는 HTTP BODY를 통해 요청됩니다.
PATCH /users/1 : 사용자 정보 일부를 수정합니다. 수정할 사용자 정보는 HTTP BODY를 통해 요청됩니다.
DELETE /users/1 : 사용자 정보를 삭제합니다.

현대의 웹 개발은 브라우저와 서버간의 통신 뿐만 아니라 서버와 서버 사이의 API(Application Programming Interface) 통신을 넘어 MSA(Micro Service Architecture)로 흘러가고 있습니다. 이 때 각 리소스 표현을 단일화하기 위해 주로 REST가 사용되고, REST를 통해 데이터를 교환하는 것을 RESTFUL하다고 표현합니다.

2021년 기준으로 대부분의 데이터 교환 형식은 JSON(JavaScript Object Notation)을 채택합니다.

HTTP 기초

댓글