HTTP란?
개발을 공부하기 한참 전부터 웹서핑을 하다 보면 HTTP라는 단어는 심심치않게 목격했던 기억이 납니다. 늘 인터넷 주소 앞에 붙어있었지만, 주소창에서나 잠시 보고 넘길 뿐, 실제로 주소는 www로 시작했다 보니 깊게 생각을 하지 않았던 것 같습니다.
웹 공부를 시작하고나서야 HTTP라는 것의 존재가 확 다가오기 시작했는데, 대충 웹 세계에서의 통신 규약/프로토콜 정도로만 간단하게 이해하고 넘어갔던 것 같습니다. 그런데 막상 생각해보니 누군가 제게 http가 뭐야,라고 물었을 때 '그냥 인터넷 통신 프로토콜 중 하나야' 라고 대답을 할 수는 없지 않나 하는 생각이 들어 한번 정리를 하면 좋겠다는 생각에 다다랐습니다.
HTTP는 OSI 7 계층과 TCP/IP를 기준으로는 애플리케이션 레이어 속하는 프로토콜입니다. 애플리케이션 레이어는 다룰 데이터의 형식과 절차에 관련된 프로토콜이 속하는 층입니다. 쉽게 생각해서, 웹을 기준으로 본다면 수많은 클라이언트와 서버가 서로 통신을 하면서 데이터를 주고받게 되는데, 이때 이 데이터를 어떤 형태로 요청하고 보낼지를 결정하는 규약이라고 생각하면 됩니다. 현대의 웹은 거의 모든 영역이 HTTP 프로토콜을 기반으로 작동하고 있습니다.
그럼 어떤 룰을 지켜야 우리는 HTTP 방식으로 통신한다고 생각을 하게 될까요? 아무래도 여러가지를 내포하고 있어서 한 줄로 정리하기는 어렵지만, 대표적으로는 다음과 같은 특징을 갖고 있습니다.
- Request(요청) & Response(응답)의 형태
- TCP 위에서 동작
- stateless: 상태를 기록하지 않음.
요청과 응답 Request and Response
어떤 사이트에 접속했을 때, 브라우저는 어떻게 수많은 정보를 예쁘게 정리하여 보여주는 걸까요? 이건 우리도 모르는 사이에 순식간에 내 컴퓨터의 웹 브라우저가 여러 통신을 흐름을 통해 우리가 필요로 하는 정보를 요청했고 이에 대해 정보를 갖고 있던 어떤 곳에서(서버일 가능성이 높겠죠) 적절한 요청이라고 판단하여 필요한 데이터를 전달해주었기 때문입니다. 이 일련의 과정을 보면 브라우저는 주소창에 무언가 검색되거나, 사용자가 어떤 행위를 했을 때 지정된 곳으로 '요청'을 보내고 이 요청은 서버에 도달하여 '응답'을 받아냅니다. 그리고 http의 맥락에서 조금 더 세부적으로 살펴보면 이 요청과 응답은 정해진 형식에 맞게 작성되어야 합니다. 그렇지 않다면 프로토콜을 위반한 요청이나 응답이기 때문에 거절을 당하겠죠?
요청과 응답은 각각이 조금 형식이 다릅니다. 각각의 형식에 대해서 간단하게만 정리해보겠습니다. 참고로 http는 평문을 전달합니다. 즉 어떤 특이한 형태가 아닌 형식이 정해진 문자열을 주고받는다고 생각하면 됩니다.
Request 형식
요청 메시지는 아래의 내용을 포함합니다.
- 리퀘스트 라인: 메소드, URI, 버전
- 메시지 헤더: 웹 브라우저의 종류와 버전, 대응하는 데이터 형식 등과 같은 필요 정보 (개행을 하며 한 줄씩 작성합니다). 종류가 상당히 많기 때문에 위키피디아 링크로 대체하겠습니다. https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Request_fields
- (공백 한 줄)
- 메시지 바디: 메소드에 따라 바디에 내용을 넣을 수 있는 경우, 이곳에 추가적인 정보를 기입하여 전달합니다.
위키피디아에서 제공하는 예시는 다음과 같습니다.
GET / HTTP/1.1
Host: www.example.com첫 줄이 리퀘스트 라인, 그다음은 메시지 헤더입니다. 바디는 없는 형태인데, 바디가 있다면 개행이 한번 발생하고 그다음 필요한 내용이 적혀있을 겁니다.
리퀘스트 라인에 대해 좀 더 상세히 이해하기 위해선 메소드와 URI라는 말의 의미를 알아야 하는데, URI의 경우 간단하게 주소라고 생각하면 됩니다. 흔히 우리가 주소창에 검색하는 것과 비슷하고, 필요한 리소스가 있을 곳의 주소인 셈입니다. 상세한 내용은 이 포스팅에서 확인하실 수 있습니다. 위의 예시에서 URI는 Host 뒤에 '/' 붙인 형태입니다. '/'가 무슨 경계를 표현한 게 아니라 호스트명 뒤에 따라올 주소입니다.
그럼 메소드는 무엇일까요. 메서드는 URI를 통해 선택한 리소스에 대해서 어떤 행위를 취할지에 대한 가이드라인입니다. 어떤 걸 사용한다고 해서 반드시 특정 행위를 보장하는 것은 아닙니다만(이는 프로그래머가 HTTP 메서드에 맞게끔 디자인을 잘해주어야 하는 부분입니다), 통신의 성질에 대해 엿볼 수 있는 힌트가 됩니다.
위는 위키피디아에서 정리해둔 메소드의 종류입니다. 대표적으로 많이 사용되는 것이 GET, POST인데 각각의 메서드와 관련된 상세한 내용은 기회가 된다면 별도의 포스팅을 통해 소개하겠습니다.
Response 형식
위와 같이 생긴 요청 메시지를 받았다면 응당 응답이 가야겠죠? 응답의 형식은 아래의 것들을 포함합니다.
- 리스폰스 라인/status line: 버전, 상태 코드, 설명문
- 메시지 헤더: 리퀘스트와 마찬가지로 종류가 많아 위키피디아 링크를 첨부합니다. https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Response_fields
- (공백 한 줄)
- 메시지 바디: 요청에 대한 자료가 담겨있으며 웹에서 html 파일이 가는 경우가 많습니다.
위키피디아에서 제공하는 예시는 다음과 같습니다.
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close
<html>
<head>
<title>An Example Page</title>
</head>
<body>
<p>Hello World, this is a very simple HTML document.</p>
</body>
</html>여기서 한가지 이해하고 넘어가면 좋은 부분은 상태 코드입니다. 요청에 대해 응답을 할 때, 전달된 내용이나 서버 상태 등에 따라 의도된 대로 동작하지 않을 수가 있습니다. 우리가 흔히 주소를 잘못 입력하면 404 Not Found라는 페이지를 볼 수 있는데, 여기서 404는 페이지를 찾을 수 없다는 것에 대한 상태 코드입니다. 상태 코드는 100번대부터 500번대까지 있는데, 앞자리는 크게 어떤 상태인지에 대한 카테고리며, 뒤의 두 숫자에 따라 구체적인 상태를 알 수 있습니다. 이 또한 위에서 리퀘스트 메서드처럼 상세하게 모두 설명하기엔 길기에, 간략하게 카테고리만 설명하게 향후 다른 포스팅에서 소개하겠습니다.
- 100: 정보
- 200: 성공
- 300: 리디렉션
- 400: 클라이언트 에러
- 500: 서버 에러
HTTP response status codes
HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes: Informational responses (100–199), Successful responses (200–299), Redirects (300–399), Client errors (400–4
developer.mozilla.org
TCP와의 연결고리
TCP 또한 네트워크 프로토콜의 종류 중 하나로, IP 프로토콜과 더불어 널리 알려지고 많은 것의 기반이 되는 프로토콜입니다. 그 때문에 네트워크 프로토콜 전반에 대해 이야기할 때도 OSI 7 계층 외에도 TCP/IP 계층이라는 표현이 있습니다. OSI 7 계층에서 TCP는 전송 계층(transport layer)에 속합니다. 여기서도 대충 유추할 수 있는 건, TCP는 데이터의 전송과 관련된 룰을 담당한다는 것입니다.
만약 IP, TCP 등과 관련된 개념이 많이 낯설다면 이전에 작성했던 이 포스팅도 함께 참고해주시면 감사하겠습니다. 이번 포스팅은 HTTP에 초점을 두고 있기 때문에 TCP에 대해 상세하게 다루진 않겠지만, TCP는 웹에서 데이터를 서로 주고 받을 때 안전한 소통을 보장하기 위한 방법입니다.
처음엔 도대체 HTTP와 TCP는 무슨 관계인지, TCP 기반의 통신이라는데 여기서 http는 왜 나오는지 같은 개념이 많이 헷갈렸습니다. 사실 이것이 이번 포스팅을 작성하게 된 계기이기도 한데요, 결론적으로 http2 (현재 3까지 소개가 된 상황이라고 하네요)는 TCP 방식으로 HTTP 메시지를 주고 받습니다. 쉽게 말해 메시지의 형식에 대해 http 가 룰을 제시해주고 이 메시지를 tcp 방식으로 전달하고 있는 것이죠.
포스팅을 작성하며 알아보니 HTTP3도 소개가 된 바 있는데, 3부터는 속도를 위해 UDP를 사용한다고 합니다.
Stateless
상태가 없음, 이라고 직역이 되는 표현으로 RESTful API를 공부할 때도 등장한 개념입니다. 이 말 또한 상세하게 알기 위해선 여러 예시를 살펴봐야 하겠지만, 제 짧은 지식으로 간단하게 요약하면 각각의 요청, 응답의 독립성 보장입니다. 직전에 같은 IP주소에서 똑같은 주소로 요청을 보냈든 말든 다음 요청은 이에 대한 내용을 전혀 모른다는 의미입니다. 요청은 그때그때 필요한 정보를 전달하고 응답을 받아올 뿐입니다. 요청이나 응답의 히스토리에 대해서 HTTP 차원에선 관리할 필요가 없기 때문에 룰이 간단해지는 것입니다.
단, HTTP에서 상태를 관리하지 않을 뿐, 브라우저나 서버는 여러 가지 방식으로 상태를 저장하기도 합니다. 대표적인 예시가 브라우저의 쿠키, 서버의 세션이 있습니다.
마무리하며
위에서도 살짝 언급했지만 이 포스팅을 작성하게 된 계기는 HTTP와 TCP의 연관성이 파악이 안 돼서였습니다. 애초에 다르고 비슷하고 할 내용이 아니라, 둘은 그저 네트워크 프로토콜의 종류 중 하나고, HTTP가 TCP를 기반으로 하는 프로토콜이라는 것을 파악한 것만으로도 큰 수확이 있었다고 생각합니다. 최대한 제 말로 풀어써봤지만, 네트워크 관련된 내용이 늘 자료를 봐도 어렵다고 느끼는 건 용어의 홍수이기 때문이 아닌가 싶습니다. 그리고 그 용어들이 TCP같이 많은 것을 내포하고 있다면 꼬리에 꼬리를 물고 찾다가 지쳐버리기 십상인 것 같습니다. 단순히 이론으로만 접하지 않고 간단하게 웹 서비스를 계속 개발하다 보면 또 자연스럽게 이해되는 부분이 분명 있었습니다. 다음엔 HTTPS, 그리고 위에서 상세하게 다루지 못했던 HTTP 메서드, 상태 코드에 대한 포스팅을 업로드할 수 있으면 좋겠습니다 :)
참고 문서
- 위키피디아 페이지
- MDN
- RFC
RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- 기타
HTTP vs TCP/IP, send data to a web server
TCP vs. HTTP: Definitions and Differences Explained | ExtraHop
- (도서) 그림으로 배우는 네트워크 원리 - Gene
'웹 > 배경지식' 카테고리의 다른 글
| [요약] HTTP 완벽 가이드 - 1부 HTTP: 웹의 기초 (0) | 2022.07.03 |
|---|---|
| SameSite vs SameOrigin (1) | 2021.04.11 |
| CORS, SOP란? (0) | 2021.03.13 |
| REST API의 6가지 특징 (0) | 2020.09.21 |
| URI, URL이란? (0) | 2020.08.30 |