HTTP (HyperText Transfer Protocol)
: HTML과 같은 문서를 전송하기 위한 프로토콜
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 대화를 나눈다.
- HTTP를 이용해 주고받는 메시지는 HTTP Messages라고 부른다.
- 클라이언트와 서버 간의 통신은 요청(Request)과 응답(Response)으로 구성되며, 요청이 있어야만 응답이 온다.
➡️ 클라이언트가 HTTP Messages 양식에 맞춰 요청을 보내면, 서버도 HTTP Messages 양식에 맞춰 응답한다.
프로토콜(Protocol)
: 클라이언트와 서버가 통신을 할 때 지켜야 하는 통신 규약
주요 프로토콜
*OSI 7 Layers : 프로토콜이 속해있는 계층을 표시한다.
HTTP의 특징 : 무상태성(Stateless)
: 무상태성(stateless)은 HTTP의 큰 특징 중 하나로, HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP는 클라이언트나 서버의 상태를 확인하지 않는다는 것이다.
- 클라이언트에서 발생한 상태를 HTTP 통신은 추적하지 않는다.
ex) 사용자가 쇼핑몰에서 로그인, 상품을 클릭해 상세 화면으로 이동, 상품을 카드에 담거나 로그아웃 하는 것 등... - HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않는다.
➡️ 대신에, 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있다.
HTTP Messages
- HTTP Messages에는 요청(Requests)과 응답(Responses), 두 가지 유형이 있다.
- HTTP Messages는 몇 줄의 텍스트 정보로 구성된다.
- 구성 파일, API, 기타 인터페이스에 HTTP Messages를 자동으로 완성하므로, 개발자는 이 메시지를 직접 작성할 필요가 없다.
HTTP Messages의 구조
| 명칭 | 내용 |
|---|---|
| start line / status line | 요청/응답의 상태 |
| HTTP headers | 전송에 필요한 모든 부가 정보 |
| empty line | 헤더와 본문을 구분하는 빈 줄 |
| body | 요청/응답과 관련된 데이터 또는 문서. 요청/응답의 유형에 따라 선택적으로 사용한다. |
- 여기서 start line과 HTTP headers를 묶어 요청/응답의 헤드(head),
- payload는 body라고 이야기한다.
페이로드(payload)
: 전송되는 데이터
함께 전송되는 헤더와 메타 데이터를 제외한, 보내고자 하는 데이터 그 자체
페이로드(payload)란? 개념 설명
HTTP Request와 Response는 비슷한 구조를 가지고 있지만, 각 요소마다 가지고 있는 정보가 다르다. 아래에서 하나씩 자세히 살펴보자.
HTTP Requests
: 클라이언트가 서버에게 보내는 HTTP 메시지
Start line
HTTP Requests의 start line에는 세 가지 요소가 있다.
: method, 요청 대상, HTTP 버전
1. method
: 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP 메소드를 표시한다.
| 요청 | 메소드 |
|---|---|
| GET | 서버로부터 리소스를 얻는다. ex) 웹 페이지, 이미지 등.. |
| POST | 서버에 데이터를 전송한다. ex) 채워진 회원가입 양식.. |
| PUT | 서버에 데이터를 전송해 기존 리소스를 완전히 대체하며, 해당 리소스가 없으면 생성한다. |
| PATCH | 서버에 데이터를 전송해 리소스를 부분적으로 수정한다. |
| DELETE | 서버에서 해당 리소스를 삭제한다. |
| HEAD | GET 메소드와 동일한 응답을 요구하지만, body를 제외하고 반환한다. |
| CONNECT | 클라이언트가 프록시를 통해 서버와 SSL 통신을 하고자 할 때 사용한다. |
| OPTIONS | 어떤 HTTP 메소드에 응답해줄 수 있는지 물을 때 사용한다. |
| TRACE | 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다. |
2. 경로나 쿼리
: 찾고자 하는 리소스가 저장되어 있는 서버의 경로
이 형식은 HTTP 메소드마다 다르다.
origin 형식
: ?와 쿼리 문자열이 붙는 절대 경로
GET, POST, HEAD, OPTIONS 등의 메소드와 함께 사용한다.
POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
absolute 형식
: 완전한 URL 형식
프록시에 연결하는 경우 대부분 GET 메소드와 함께 사용한다.
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
authority 형식
: 도메인 이름과 포트 번호로 이루어진 URL의 일부분
HTTP 터널을 구축하는 경우, CONNECT 메소드와 함께 사용한다.
CONNECT developer.mozilla.org:80 HTTP/1.1
asterisk 형식
: OPTIONS 메소드와 함께 별표(*) 하나로 서버 전체를 표현한다.
OPTIONS * HTTP/1.1
3. HTTP version
: HTTP 버전에 따라 HTTP 메시지의 구조가 달라지므로, start line에 HTTP 버전을 함께 입력해야 한다.
Headers
- "헤더 이름 : 값"을 입력한다.
- 이때 헤더 이름은 대소문자 구분이 없는 문자열이며, 값은 헤더에 따라 다르다.
- 헤더에는 여러 종류가 있고, General headers, Request headers, Reprsentation headers로 나눌 수 있다.
| 그룹 | 설명 |
|---|---|
| General headers | 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더 |
| Request headers | fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더 - User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화한다. - Referer처럼 컨택스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있다. |
| Reprsentation headers | 이전에는 Entity headers로 불렸으며, body에 담긴 리소스의 정보를 포함하는 헤더 ex) 콘텐츠 길이, MIME 타입 등.. |
Body
- 모든 HTTP Requests에 body가 필요하지는 않다.
ex) GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우 body 필요 X - POST나 PUT같은 일부 요청은 데이터를 업데이트하기 위해 body를 사용한다.
- body는 다음과 같이 두 종류로 나눌 수 있다.
| body의 종류 | 구성 |
|---|---|
| Single-resource bodies (단일 리소스 본문) | 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성 |
| Multiple-resource bodies (다중 리소스 본문) | 여러 파트로 구성된 body에서는 각 파트마다 다른 정보를 지닌다. 보통 HTML form과 관련이 있다. |
HTTP Responses
: 서버가 클라이언트에게 보내는 HTTP 메시지
Status line
HTTP Responses의 status line에는 두 가지 요소가 있다.
: HTTP 버전, 상태 코드 & 상태 텍스트
1. HTTP 버전
: 현재 프로토콜의 버전을 나타낸다.
HTTP/1.1
2. 상태
: 요청에 대한 결과를 상태 코드와 상태 텍스트로 나타낸다.
상태 코드
-
1xx(정보) : 요청을 받았으며 프로세스를 계속 처리중
-
2xx(성공) : 요청을 성공적으로 처리
200 OK: 요청이 성공적으로 수행됨201 Created: 요청이 성공해서 새로운 리소스가 생성됨202 Accepted: 요청을 수신했지만 아직 처리가 완료되지 않음204 No Content: 요청이 성공했지만 응답 페이로드 본문에 보낼 내용이 없음
-
3xx(리다이렉트) : 요청 완료를 위해 웹 브라우저에서 추가 작업 조치가 필요
- 영구적인 리다이렉션 : 요청받은 리소스의 URI가 다른 곳으로 영구적으로 이동됨
301 Moved Permanently,308 Permanent Redirect - 일시적인 리다이렉션 : 일시적인 변경
302 Found,303 See Other,307 Temporary Redirect - 특수한 리다이렉션 : 결과 대신 캐시를 사용
304 Not Modified
- 영구적인 리다이렉션 : 요청받은 리소스의 URI가 다른 곳으로 영구적으로 이동됨
-
4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
400 Bad Request: 잘못된 문법이나 메시지를 요청해서 서버가 이해할 수 없음401 Unauthorized: 클라이언트가 해당 리소스에 대한 인증이 필요함 (로그인)403 Forbidden: 서버가 요청을 이해했지만 승인을 거부함. 인증은 되었지만, 접근 권한이 불충분한 경우404 Not Found: 요청 리소스를 찾을 수 없음
-
5xx(서버 오류) : 서버가 정상 요청을 처리하지 못함
500 Internal Server Error: 서버 내부 문제로 오류 발생502 Bad Gateway: 서버 간의 유효하지 않은 응답을 받은 경우503 Service Unavailable: 서버가 일시적으로 요청을 처리할 준비가 되지 않음. 유지보수를 위해 작동이 중단되거나 과부하가 걸린 서버
Headers
(Responses headers는 Requests headers와 동일한 구조를 가지고 있다.)
- "헤더 이름 : 값"을 입력한다.
- 이때 헤더 이름은 대소문자 구분이 없는 문자열이며, 값은 헤더에 따라 다르다.
- 헤더에는 여러 종류가 있고, General headers, Responses headers, Reprsentation headers로 나눌 수 있다.
| 그룹 | 설명 |
|---|---|
| General headers | 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더 |
| Responses headers | 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더 - Vary, Accept-Ranges와 같이 상태줄에 넣기에는 공간이 부족했던 추가 정보를 제공한다. |
| Reprsentation headers | 이전에는 Entity headers로 불렸으며, body에 담긴 리소스의 정보를 포함하는 헤더 ex) 콘텐츠 길이, MIME 타입 등.. |
Body
- 모든 HTTP Responses에 body가 필요하지는 않다.
ex)201,204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않다. - body는 다음과 같이 두 종류로 나눌 수 있다.
| body의 종류 | 구성 |
|---|---|
| Single-resource bodies (단일 리소스 본문) | - 길이가 알려진 단일 리소스 본문은 두 개의 헤더(Content-Type과 Content-Length)로 정의한다.- 길이를 모르는 단일 파일로 구성된 단일 리소스 본문은 Transfer-Encoding이 chucked로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있다. |
| Multiple-resource bodies (다중 리소스 본문) | 서로 다른 정보를 담고있는 body이다. |
❔ 학습 후 궁금한 점
- OSI 7 계층이 무엇인지?
이 글은 아래 링크를 참고하여 작성한 글입니다.
https://www.webdevdrops.com/en/http-primer-for-frontend-developers-f091a2070637/
[10분 테코톡] 코카콜라의 HTTP 메서드와 상태코드
