HTTP(HyperText Transfer Protocol)

5 분 소요


👉 이어서 읽기를 추천합니다.

0. 들어가면서

서버 개발자라면 가장 많이 접하게 되는 프로토콜입니다. 브라우저가 서버로부터 웹 페이지를 요청할 때 사용합니다. 데이터를 주고 받는 REST API 통신 HTTP 프로토콜을 기반으로 동작합니다. HTTP 프로토콜에 대한 이해도를 높이기 위해 포스트로 정리하였습니다.

1. HTTP(HyperText Transfer Protocol) 란?

Wiki
HTTP(HyperText Transfer Protocol)는 WWW(W3) 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다.

HTML(HyperText Markup Language)
HTML은 웹 페이지를 만들기 위한 언어이며, 브라우저에서 동작하는 언어입니다.

프로토콜(Protocol)
프로토콜이란 통신하는 개체 간에 서로 알아볼 수 있는 데이터 형태로 송수신을 하자는 약속입니다.

HTTP는 클라이언트와 서버가 HTML 문서를 주고 받는데 사용하는 프로토콜입니다. 대표적으로 HTML 문서를 주고 받지만, 경우에 따라서 JSON, Plain Text, XML 문서 등의 형태로도 데이터를 주고 받습니다. 이번 포스트에선 HTML 문서 송수신을 예시로 정리하였습니다.

브라우저가 웹 페이지를 보여주는 과정

사용자는 다음의 과정을 통해 브라우저에서 웹 페이지를 볼 수 있습니다.

  1. 사용자가 브라우저의 주소창에 URL 주소를 작성합니다.
  2. 브라우저는 해당 URL에 대응하는 서버(호스트)로 사용자의 요청을 전달합니다.
  3. 서버는 전달 받은 사용자 요청에 대해 적절한 처리 후 응답합니다.
  4. 서버의 응답을 전달 받은 브라우저는 사용자가 볼 수 있도록 HTML 문서를 화면으로 시각화(rendering)합니다.

2. HTTP 데이터 형태

2.1. 클라이언트 요청

클라이언트는 다음과 같은 메세지 형태로 서버에게 데이터를 요청합니다.

  • Request Line - 요청 방법(method), 경로, 프로토콜 버전
  • Request Headers - 기타 헤더 정보
  • Request Message Body - 사용자가 추가적으로 전달하는 정보

HTTP Message Format 형식(Request Message & Response Message)

2.2. 서버 응답

서버는 다음과 같은 메세지 형태로 클라이언트에게 응답합니다.

  • Status Line - 프로토콜 버전, 상태 코드, 상태 메세지
  • Response Header - 기타 헤더 정보
  • Response Body - 서버가 클라이언트에게 전달하는 정보

HTTP Message Format 형식(Request Message & Response Message)

3. HTTP 특징

HTTP 통신은 어떤 특징들이 있는지 알아보겠습니다.

3.1. 비연결성(Connectionless)

서버가 클라이언트에게 응답을 보낸 후 맺어진 연결을 끊어버리는 것을 의미합니다. 서버는 불특정 다수 클라이언트들을 위해 서비스를 제공합니다. 한번 요청한 클라이언트와 연결을 계속 유지하는 것은 리소스 사용 측면에서 서버에게 많은 부담을 줍니다. 그렇기에 서버는 클라이언트의 요청에 대한 응답 후 연결을 유지하지 않습니다.

클라이언트 입장에서 생각해보면, 다소 불편함이 있습니다. 비연결성 특징은 클라이언트가 아직 필요한 요청이 더 있음에도 불구하고 매 요청마다 새로운 연결과 해제 과정을 수행시킵니다.

3.2. 무상태(Stateless)

HTTP 통신의 비연결성으로 인해 발생하는 특징입니다. 서버는 클라이언트의 요청에 대해 응답 후 연결을 유지하지 않기 때문에 클라이언트의 상태를 모릅니다. 서버 입장에서는 항상 새로운 클라이언트로부터 요청을 받는 것 입니다. 무상태 특징은 클라이언트에게 편리한 서비스를 제공하는 것을 제약합니다. 이런 문제를 해결하기 위해 쿠키(cookie)와 세션(session)을 사용합니다.
자세한 내용은 Cookie and Session 포스트를 읽어보길 바랍니다.

4. HTTP 동작 과정

  1. 사용자가 웹 브라우저를 통해 찾고 싶은 웹 페이지의 URL 주소를 입력합니다.
  2. 브라우저는 사용자가 입력한 URL 주소 중에서 도메인 네임(domain name) 부분을 DNS 서버에서 검색합니다.
    • 예를 들어, 'https://www.naver.com/' URL 주소에서 도메인 이름은 'naver.com'입니다.
    • 실제 네트워크에서 통신은 IP 주소를 기반으로 수행되기 때문에 해당 URL과 매칭되는 IP 주소를 DNS 서버에서 찾아야합니다.
  3. 웹 페이지 URL 정보와 찾은 IP 주소는 HTTP 기반의 요청 메세지로 작성됩니다.
  4. HTTP 요청 메세지는 해당 IP 주소를 가진 서버로 전달됩니다.
  5. 서버는 해당 요청에 대해 적절한 수행 후 클라이언트에게 HTTP 응답 메세지를 전달합니다.
  6. HTTP 응답은 다시 네트워크를 거쳐 클라이언트에게 전달됩니다.
  7. 클라이언트 측에 도착한 HTTP 응답 메세지는 HTTP 프로토콜에 의해 웹 페이지를 만들기 위한 HTML 문서로 변환됩니다.
  8. 변환된 HTML 문서는 웹 브라우저에 의해 웹 페이지로 출력되며, 사용자가 이를 볼 수 있습니다.

http://tcpschool.com/webbasic/works


5. HTTP methods

클라이언트가 요청 시 사용하는 HTTP 메소드들에 대해 알아보겠습니다.

5.1. 주요 메소드

가장 많이 사용되는 요청 방식들입니다. 알고 있어야하고 각 메소드들이 어떤 특징을 가지는지 파악하고 있어야합니다.

5.1.1. GET 메소드

  • 서버 측에 존재하는 자원에 대한 요청입니다.
  • 요청 파라미터가 URL에 노출되어 보안에 취약합니다.

5.1.2. POST 메소드

  • 서버에 새로운 자원을 생성할 때 사용합니다.
  • 클라이언트는 서버로 정보를 보낼 때, HTTP 메세지에 담아서 제출합니다.
  • 새로운 자원이 생기면 'Location' 헤더에 새로이 작성된 리소스의 URL 주소 정보를 담아 응답합니다.

5.1.3. PUT 메소드

  • 서버에 존재하는 자원을 변경합니다.
  • POST 방식처럼 정보를 제출하지만 정보 갱신 위주로 사용됩니다.
  • PUT 메소드는 클라이언트가 서버 측 구현에 관여하는 것이므로 주로 POST 메소드를 사용합니다.

5.1.4. DELETE 메소드

  • 존재하는 자원에 대한 삭제를 요청할 때 사용합니다.
  • 서버는 요청에 해당하는 리소스를 삭제합니다.
  • 통상 동일한 구현이 가능한 POST 메소드 방식으로 대체됩니다.

5.2. 기타 메소드

주로 사용되지는 않지만, 함께 정리하였습니다.

5.2.1. CONNECT 메소드

5.2.2. HEAD 메소드

  • 메세지 헤더(문서 정보)를 취득할 때 사용합니다.
  • GET 요청과 비슷하지만 실제 문서를 요청하는 것은 아닌 메소드입니다.

5.2.3. TRACE 메소드

  • 요청 리소스가 수신되는 경로를 보여줍니다.
  • 해당하는 리소스까지 이동하면서 loop-back 메세지를 전달합니다.

5.2.4. OPTIONS 메소드

  • 서버 측에서 제공하는 메소드가 무엇인지 확인할 때 사용합니다.
  • 서버는 헤더 정보에 Allow: GET,POST,HEAD 와 같은 방식으로 자신이 처리할 수 있는 요청을 전달합니다.

5.2.5. PATCH 메소드

  • 리소스의 부분만 수정하는데 사용합니다.
  • 서버가 자원을 수정하기 위해 동봉된 엔티티를 처리하는 방식에서 PUT 메소드와 차이가 있습니다.
  • https://tools.ietf.org/html/rfc5789#section-2

5.3. HTTP 요청 메소드 별 특징 요약

HTTP 메소드 RFC 요청에 Body 존재 여부 응답에 Body 존재 여부 안전 멱등(Idempotent) 캐시 가능
GET RFC 7231 아니오
HEAD RFC 7231 아니오 아니오
POST RFC 7231 아니오 아니오
PUT RFC 7231 아니오 아니오
DELETE RFC 7231 아니오 아니오 아니오
CONNECT RFC 7231 아니오 아니오 아니오
OPTIONS RFC 7231 선택 사항 아니오
TRACE RFC 7231 아니오 아니오
PATCH RFC 5789 아니오 아니오

6. HTTP Status Code

서버가 클라이언트에게 전달해주는 응답의 상태를 의미합니다. 어떤 응답 코드들이 있는지 확인해보도록 하겠습니다. 캡틴 판교님의 포스트를 참고하였습니다.

6.1. 1xx - 정보 교환

100번대의 상태 코드는 서버와 클라이언트 사이의 정보 교환을 위해 사용합니다.

  • 100 - Continue.
    • 클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내주길 바랍니다.
    • HTTP 1.1에서 처음 등장하였습니다.
  • 101 - Switching Protocols.
    • 서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것입니다.
    • HTTP 1.1에서 처음 등장하였습니다.

6.2. 2xx - 성공

200번대의 상태 코드는 대부분 성공을 의미합니다.

  • 200 - OK.
    • 요청에 대한 성공 응답 코드입니다.
  • 204 - No Content.
    • 성공했으나 응답 본문에 데이터가 없습니다.
  • 205 - Reset Content.
    • 성공했으나 클라이언트의 화면을 새로 고침하도록 권고합니다.
  • 206 - Partial Conent.
    • 성공했으나 일부 범위의 데이터만 반환합니다.

6.3. 3xx - 리다이렉션

300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우입니다.

  • 300 - Multiple Choices.
    • 최근에 옮겨진 데이터를 요청한 것 입니다.
  • 301 - Moved Permanently.
    • 요청한 자원이 새 URL에 존재합니다.
  • 303 - See Other.
    • 요청한 자원이 임시 주소에 존재합니다.
  • 304 - Not Modified.
    • 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고합니다.

6.4. 4xx - 클라이언트 에러

400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우입니다. 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생합니다.

  • 400 - Bad Request.
  • 401 - Unauthorized.
    • 권한 없이 요청한 것입니다. Authorization 헤더가 잘못된 경우입니다.
  • 403 - Forbidden.
    • 서버에서 해당 자원에 대해 접근 금지라는 응답입니다.
  • 405 - Method Not Allowed.
  • 409 - Conflict.
    • 최신 자원이 아닌데 업데이트하는 경우입니다.

6.5. 5xx - 서버 에러

500번대 상태 코드는 서버 쪽에서 오류가 난 경우입니다.

  • 501 - Not Implemented.
    • 요청한 동작에 대해 서버가 수행할 수 없는 경우입니다.
  • 503 - Service Unavailable.
    • 서버가 과부하 또는 유지 보수로 내려간 경우입니다.

REFERENCE

카테고리:

업데이트:

댓글남기기