이번 글에서는 HTTP의 메세지요청과 응답구조에 대해서 알아보고자 한다.
HTTP란?
HTTP는 HyperText Transfer Protocol(하이퍼텍스트 전송 프로토콜)의 줄임말이다.
HTTP는 HTML과 같은 문서를 전송하기 위한 Application Layer Protocol(애플리케이션 계층 프로토콜)이다.
웹 브라우저와 웹 서버의 소통을 위해 디자인 되었다.
조금 더 자세하게 알아보자
여기서 말하는 HyperText Transfer Protocol(하이퍼텍스트 전송 프로토콜)이란 World Wide Web에서 데이터를 전송하고 수신하는데 사용되는 응용프로그램 계층 프로토콜이다.
HTTP는 인터넷 데이터 통신의 기초이며 웹 페이지 가져오기, 파일전송, 양식 데이터 제출 등에 사용되는 프로토콜이다.
HTTP의 주요 구성 요소에 대해 간략하게 알아보자.
HTTP의 주요 구성 요소
- 하이퍼텍스트 : HTTP는 웹 페이지, 이미지, 비디오 또는 문서와 같은 다른 리소스로 연결될 수 있는 하이퍼링크가 포함된 텍스트인 하이퍼텍스트를 전송하기 위해 설계되었다.
이러한 하이퍼링크는 웹을 대화형으로 만들고 상호연결되게 만든다. - 전송 : HTTP는 클라이언트(일반적으로 웹 브라우저)와 웹 서버간에 데이터를 포맷하고 전송하는 방법을 지정한다.
리소스를 요청하고 응답하기 위한 규칙과 규약을 정의한다. - 프로토콜 : HTTP는 서로 다른 컴퓨터와 시스템이 인터넷을 통해 서로 통신할 수 있도록 하는 규칙과 규약의 집합니다.
이 규칙들은 요청과 응답이 어떻게 구성되고 처리되어야 하는지를 지시한다.
HTTP는 TCP(Transmission Control Protocol)와 같은 기본 전송 계층 프로토콜을 통해 작동하므로 안정적이고 순서 있는 데이터 전달이 보장된다.
2021년 9월에 마지막으로 업데이트한 HTTP버전은 HTTP/1.1이다.
그러나 HTTP/2와 HTTP/3은 웹 통신의 성능, 보안 및 효율성을 향상시키기 위해 개발되었다.
새로운 버전들은 다중화, 헤더 압축, 보안 연결(HTTP)지원 등의 기능을 도입했다.
정리하자면, HTTP는 클라이언트(일반적으로 웹 브라우저)와 웹 서버간에 하이퍼텍스트 및 기타 데이터의 전송을 가능하게 하는 프로토콜로, World Wide Web의 기반을 형성하며, 웹 요청 및 응답의 형식과교환 방식을 제어하여 사용자가 인터넷 상의 콘텐츠에 접근하고 상호 작용할 수 있도록 한다.
TCP(Transmission Control Protocol)란 무엇일까?
TCP(Transmission Control Protocol)는 인터넷 프로토콜(IP) 제품군의 핵심 프로토콜 중 하나이다.
IP 네트워크를 통해 장치 간에 안정적인 연결 지향 통신을 제공하는 역할을 한다.
TCP는 발신자와 수신자간에 데이터가 정확하고 올바른 순서로 전송되도록 보장하여 인터넷 통신의 중요한 구성 요소이다.
- 신뢰성 : TCP는 승인 및 재전송을 사용하여 송신자와 수신자 간에 데이터가 정확하고 올바른 순서로 전송되도록 보장한다.
- 연결지향 : 데이터 전송 전에 연결을 설정하며 설정을 위한 3방향 핸드셰이크 기능을 제공한다.
- 순서있는 데이터 전달 : TCP는 데이터가 전송된 순서와 동일한 순서로 전달되도록 보장하며, 이는 데이터 순서에 의존하는 애플리케이션에 필수적이다.
- 흐름 제어 : 데이터 전송 속도를 동적으로 조정하여 혼잡을 방지하고 네트워크 성능을 최적화한다.
- 오류감지/수정 : 전송 중 오류를 감지하고 수정하여 데이터 무결성을 보장한다.
- 전이중(Full-Duplex) : 동시 양방향 통신을 지원한다.
- 포트기반 : 포트 번호를 사용하여 특정 애플리케이션이나 서비스를 식별한다.
TCP는 웹 브라우징, 이메일, 파일 전송과 같이 안정적인 데이터 전달이 필요한 애플리케이션에 필수적이다.
데이터 무결성과 순서를 보장하므로 데이터 손실이나 잘못된 전달이 용납되지 않는 상황에 적합하다.
HTTP의 특징
- 무상태성(Stateless) : HTTP는 특정 상태를 유지하지 않는 특징이 있다.
- 비 연결성(Connectionless) : HTTP는 실제로 요청을 주고 받을 때만 연결을 유지하고 응답을 주고나면 서버와의 연결을 끊는다.
무상태성(Stateless)
HTTP는 상태 비저장 프로토콜로 간주된다. 즉, 클라이언트에서 서버로의 각 요청은 독립적으며 이전 요청에 대한 정보를 전달하지 않는다.
즉, 서버는 특정 클라이언트와의 과거 상호 작용에 대한 정보를 유지하지 않는다.
실제로 무상태성이 의미하는 바는 다음과 같다
- 세션 없음 상태 : 일부 다른 프로토콜이나 시스템과 달리 HTTP는 클라이언트와 서버 간의 지속적인 세션이나 연결을 유지하지 않는다.
클라이언트의 각 요청은 별도의 격리된 트랜잭션으로 처리된다. - 이전 요청에 대한 메모리 없음 : 서버는 동일한 클라이언트의 이전 요청을 기억하지 않는다.
즉, 모든 요청에는 서버가 이를 이해하고 처리하는 데 필요한 모든 정보와 컨텍스트가 포함되어야 한다.
개별 클라이언트와 관련된 서버 측에는 고유한 메모리나 상태가 없다. - 확장성 : 상태 비저장 특성으로 인해 서버 구현이 단순화되고 확장성이 향상된다. 서버는 복잡한 세션 정보를 유지할 필요가 없기 때문에 많은 수의 동시 클라이언트를 효율적으로 처리할 수 있다.
- 신뢰성 : 요청이 실패하거나 연결이 끊어지면 각 요청이 자체적으로 포함되므로 클라이언트는 서버 상태에 대해 걱정하지 않고 간단히 요청을 재시도할 수 있다.
HTTP자체는 상태 비저장이지만 웹 애플리케이션은 일반적으로 쿠키, 세션 토큰, URL 매개변수와 같은 기술을 사용하여 사용자 세션을 유지하고 상태 정보를 저장하기 위한 매커니즘을 구현하는 경우가 많다.
이러한 매커니즘을 통해 웹 애플리케이션은 HTTP의 기본 무상태 특성에도 불구하고 사용자에게 연속성과 개인화 감각을 제공할 수 있다.
비연결성(Connectionless)
HTTP는 또한 연결 없는 프로토콜로 간주된다. 이것은 각 요청-응답 주기가 클라이언트와 서버간의 지속적인 연결 없이 독립적으로 작동함을 의미한다.
비연결성의 의미는 다음과 같다
- 지속적인 연결 없음 : 클라이언트가 HTTP요청을 보내고 응답을 받은 후 일반적으로 클라이언트와 서버간의 연결이 닫힌다.
둘 사이에는 진행 중인 긴 수명 연결이 없다. 이를 통해 서버 리소스를 절약하고 서버가 많은 클라이언트를 동시에 처리할 수 있다. - 단기 트랜잭션 : 각 HTTP 트랜잭션은 짧은 수명을 가지며 단일 데이터 교환에 초점을 맞춘다.
응답이 전송되면 연결이 닫히고 이후 요청에서는 필요한 경우 새 연결을 설정해야 한다. - 프로토콜 오버헤드 : HTTP의 비연결성은 각 요청에 대해 새로운 연결을 설정해야 할 수 있기 때문에 일부 프로토콜 오버헤드를 발생시킨다.
그러나 이 오버헤드는 일반적으로 확장성과 단순성의 이점보다 더 크다.
HTTP는 기본적으로 연결이 없지만 여러 요청과 응답을 HTTP keep-alive(영구 연결)와 같은 메커니즘을 통해 여러 요청 및 응답을 하나의 영구 연결을 통해 전송할 수 있으므로 각 요청에 대한 연결 설정과 관련된 오버헤드를 줄일 수 있다.
HTTP messages(HTTP 메세지)
HTTP메세지는 클라이언트(일반적으로 엡 브라우저 또는 애플리케이션)와 서버 간의 기본 통신 수단이다.
이러한 메세지는 웹사이트를 탐색하거나, 서버에 데이터를 보내거나, 웹 서비스와 상호작용할 때 교환된다.
HTTP메세지는 웹 리소스(ex. HTML페이지, 이미지 또는 API데이터)를 요청하고 웹 서버로부터 응답을 받는 데 필수적이다.
요청과 응답이라는 두가지 주요 유형으로 구성된다.
HTTP 요청 메세지
HTTP 요청 메세지는 클라이언트가 웹 서버에 리소스를 요청하기 위해 전송한다.
일반적으로 다음 구성 요소가 포함된다.
- 요청라인 : 여기에는 수행할 작업, 리소스의 URL(Uniform Resource Lacator) 및 사용중인 HTTP버전을 지정하는 HTTP메서드(ex. GET, POST, PUT, DELETE)가 포함된다.
- 헤더 : HTTP헤더는 요청 또는 요청을 수행해야 하는 클라이언트에 대한 추가정보를 제공하는 키-값 쌍이다.
일반적인 헤더에는 "User-Agent"(클라이언트에 대한 정보), "Host"(서버 도메인) 및 "Accept"(클라이언트가 허용하는 미디어 유형)가 포함된다. - 본문(선택사항) : 경우에 따라 HTTP요청에 메세지 본문이 포함될 수 있다. 이것은 양식 제출이나 JSON페이로드와 같은 데이터를 서버로 보내기 위해 POST와 같은 메서드와 함께 자주 사용된다.
다음은 예제코드는 HTTP요청의 예제코드이다.
// 요청라인은 HTTP 메서드, URL 및 HTTP 버전을 포함한다.
GET /example-page.html HTTP/1.1
//Host는 헤더로 요청에 대한 추가 정보를 제공하는 다양한 키-값 쌍을 포함한다.
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
HTTP 메서드와 해당 요청 형식에 대해서
- GET
- 목적 : 서버에서 데이터를 검색한다.
- 요청 형식 : GET요청은 일반적으로 요청 본문 없이 전송된다. 모든 정보는 URL자체에 쿼리 매개변수로 포함된다.
다음은 GET 요청에 대한 예제코드이다.
GET /api/users?id=123
- POST
- 목적 : 처리할 데이터를 서버에 제출한다. 새로운 리소스를 만드는데 자주 사용된다.
- 요청 형식 : POST요청에는 일반적으로 JSON 또는 form-encoded 형식으로 서버에 전송할 데이터가 포함된 요청 본문이 포함된다.
다음은 POST 요청에 대한 예제코드이다.
POST /api/users
Content-Type: application/json
{
"name": "Patato Kim",
"email": "potatokim@example.com"
}
- PUT
- 목적 : 서버의 기존 리소스를 업데이트 한다. 전체 리소스를 새 데이터로 대체한다.
- 요청 형식 : POST와 유사하게 PUT요청에는 업데이트된 데이터가 포함된 요청 본문이 포함된다.
다음은 PUT 요청에 대한 예제코드이다.
PUT /api/users/123
Content-Type: application/json
{
"name": "Patato Kim",
"email": "potatokim@example.com"
}
- PATCH
- 목적 : 서버의 기존 리소스를 부분적으로 업데이트 한다. 전체 리소스를 교체하는 것이 아니라 변경 사항만 포함한다.
- 요청 형식 : PUT과 유사하지만 요청 본문에는 업데이트 해야 하는 필드만 포함된다.
다음은 PATCH 요청에 대한 예제코드이다.
PATCH /api/users/123
Content-Type: application/json
{
"email": "newemail@example.com"
}
- DELETE
- 목적 : 서버의 리소스를 삭제한다.
- 요청 형식 : DELETE요청은 삭제할 리소스만 지정하므로 일반적으로 요청 본문이 없다.
다음은 DELETE 요청에 대한 예제코드이다.
DELETE /api/users/123
- OPTIONS
- 목적 : 대상 리소스에 대한 통신 옵션에 대한 정보를 검색한다. 서버가 특정 HTTP메소드에 허용하는지 확인하는데 자주 사용된다.
- 요청 형식 : OPTIONS 요청은 간단하며 요청 본문이 필요하지 않는다.
다음은 OPTIONS 요청에 대한 예제코드이다.
OPTIONS /api/resource
위에 적힌 것들은 가장 일반적으로 사용되는 HTTP 메소드이다.
HEAD, CONNECT, TRACE 등과 같은 특정 사용 사례가 있지만 일상적인 웹 개발자에서는 덜 일반적이다.
어떤 HTTP방식을 사용할지는 서버의 리소스에 대해 수행할 작업에 따라 결정된다.
HTTP 응답 메세지
요청된 리소스를 제공하거나 오류를 표시하기 위해 웹 서버에서 HTTP응답 메세지를 보낸다.
일반적으로 다음 구성요소가 포함된다.
- 상태 줄 : 여기에는 HTTP버전, 3자리 상태 코드(ex. 성공 시 200, 찾을수 없을시 404 등) 및 간단한 텍스트 상태 메세지가 포함된다.
- 헤더 : 요청 헤더와 유사하게 응답 헤더는 서버 응답에 대한 추가 정보를 제공한다.
일반적인 헤더에는 "Content-type"(응답의 데이터 유형), "Content-Length"(응답 본문의 길이) 및 "Server"(서버 소프트웨어에 대한 정보)가 포함된다. - 본문(선택사항) : 응답 본문에는 클라이언트로 다시 전송되는 실제 데이터가 포함된다.
예를 들어 HTTP페이지의 경우 HTTP콘텐츠는 응답 본문에 배치된다.
다음 예제코드는 HTTP응답의 예제코드이다.
// 상태 표시줄은 HTTP 버전, 상태 코드 및 간략한 상태 메세지가 포함되어잇다.
HTTP/1.1 200 OK
// 헤더는 응답에 대한 정보와 함께 키-값 쌍을 포함한다.
Content-Type: text/html
Content-Length: 1234
// 본문
<html>
<head>
<title>Example Page</title>
</head>
<body>
Content content
</body>
</html>
본문에서는 HTML, JSON, 이미지 또는 기타 데이터일 수 있는 응답의 실제 콘텐츠를 포함한다.
이것은 HTTP메세지의 일반적인 구조이지만 특정 헤더와 해당 값은 특정 사용 사례, 서버 구성 및 클라이언트 요구사항에 따라 크게 달라질 수 있다는 점을 인식하는 것이 중요하다.
또한 HTTP/2 및 HTTP/3과 같은 최신 버전의 HTTP에서는 헤더와 데이터가 전송되는 방식에 대한 최적화 및 변경사항이 도입되어 프로토콜이 더욱 효율적으로 만들어졌다.
그러나 기본 요청-응답 개념은 HTTP 전반에 걸쳐 일관되게 유지된다.
HTTP메세지는 구조화되고 표준화된 방식으로 클라이언트와 서버 간의 정보 교환을 촉진하여 World Wide Web이 작동할 수 있도록 한다.
이를 통해 웹 콘텐츠 검색, 서버로 데이터 전송, 웹 기반 애플리케이션 및 서비스에 중요한 기타 다양한 상호 작용이 가능하다.
'개발공부 > 기술면접준비' 카테고리의 다른 글
CSR과 SSR의 차이점에 대해서 (0) | 2023.09.06 |
---|---|
[CSS] 간단한 로그인 폼 컴포넌트를 가운데 위치시키려면 CSS를 어떻게 작성해야 할까?(centering) (0) | 2023.09.06 |
[HTML] <li>요소는 왜 <ul>요소의 자식 요소여야만 할까 (0) | 2023.09.05 |
[HTML] <link>요소가 <head>요소 내에 위치하는 이유와 <script>요소가 <body>가 끝나기 직전의 위치에 존재하는 이유 (0) | 2023.09.04 |
[JavaScript] 클로저(Closure) (0) | 2023.08.31 |