Protocol의 한 종류인 http에 대해 알아보자.

Table of Contents

링크를 클릭하면 해당 내용으로 이동합니다

• About HTTP
  _{HyperText Transfer Protocol}
• HTTP Version
  _{0.9, 1.0, 1.1, 2.0, 3.0}
• HTTP Structure
  _{HTTP Request, HTTP Response}
• HTTP의 특징
  _{Connectionless, Stateless}
• HTTP Methods
  _{GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS}
• HTTP Status Code
  _{1XX, 2XX, 3XX, 4XX, 5XX}
• References

About HTTP

HTTP : HyperText Transfer Protocol
HTTP는 HyperText들의 문서들을 주고 받는데 사용되는 프로토콜이다.
HTTP가 처음 만들어 졌을 때는 HTML만을 전송하고자 하였으나 시간이 흐르면서 다른 모든 종료의 리소스들을 전송할 수 있게 되었다.

HTTP의 용어를 분석해보자
HyperText → 하이퍼텍스트를 기반으로
   _{* HyperText는 한 문서가 또 다른 문서와 연결되어 있는 것을 말한다.}
Transfer  → 데이터를 전송하는
Protocol  → 통신 규약
   _{* protocol은 컴퓨터와 컴퓨터가 정보를 주고 받을때 어떻게 소통할것인지에 대한 규칙과 약속을 뜻한다.}

Protocol
IETF(Internet Engineering Task Force)는 웹브라우저와 웹서버가 서로 통신을 하기 위한 규약을 정해 놓았다. 이 규약을 HTTP라 부른다. HTTP 외에도 다양한 프로토콜이 존재한다. 파일을 전송할시 사용되는 프로토콜로는 FTP(File Transfer Protocol), SFTP(Secure File Transfer Protocol)가 있고 이메일 전송시 사용되는 프로토콜의 종류로는 대표적으로 SMTP(Simple Mail Transfer Protocol), POP3(Post Office Protocol), IMAP(Internet Access Message Protocol)이 있다.

왜 통신의 규칙을 정해놓아야 했을까?
우리는 타인과 소통을 할 때 손을 흔들거나 악수를 한다. 사람은 비언어적 요소(표정, 몸짓, 동작 등)와 언어적 요소(글, 말)를 통하여 상대방에게 의사를 전달할 수 있다. 두 사람간에 온전한 커뮤니케이션이 이루어지기 위해서는 정해진 룰을 따라야 한다. 서로 알아들을 수 있는 언어를 사용하여야 하며 주고받는 단어의 내포된 의미를 서로 이해할 수 있어야 한다.

Illustrated by. Allie Mounce

비언어적인 요소로 대화할 수 없는 컴퓨터는 철저히 언어적 의사소통에 의지할수밖에 없다. 소통상의 문제를 제거하고 명확한 의사소통(Response & Request)을 하기 위해서는 더욱 체계적이고 엄격한 규칙이 필요하다. '무엇을 어떠한 방법으로 언제 얼마만큼 어떻게 통신할 것인가'에 관한 규칙을 미리 정해두고 룰을 따름으로써 데이터를 효율적으로 전달할 수 있게 된다.

• 통신의 기본 전송 단위는 얼마로 할 것인가?
• 어느정도의 데이터 전송 속도를 사용할 것인가?
• 어떤 character set을 이용할 것인가?
• etc

Return to the ToC

HTTP Version

각 Version의 특징을 표를 통해 간단히 살펴보자.
_{* 1.1과 2.0, 그리고 3.0에 대한 차이점은 다른 포스팅에서 자세히 다룬다.}

VERSION	YEAR	ABOUT
0.9	1991	* 간단한 HTML 객체를 받아오기 위해 만들어짐 * GET 메서드만 지원 * 결함이 많은 모델 * 헤더, 버전 번호 비지원
1.0	1996	* Header 추가 * HEAD, POST 메서드 추가 * 멀티미디어 객체 처리 추가
1.0+		* Keep-alive connection 추가 * 가상 호스팅 지원 시작
1.1	1997	* 설계 결함 교정 * PUT, DELETE, TRACE, OPTIONS 메서드 추가 * 잘못된 기능 제거 * 복잡해진 웹앱과 배포를 지원 * 한 연결당 하나의 요청만 처리 가능 (동시 전송 불가)
2.0	2015	* SPDY 프로토콜 기반
3.0	2018	* 웹페이지 로딩 속도 개선 * UDP 기반 프로토콜

Return to the ToC

HTTP Structure

"말하기의 반대는 듣는 것이 아니다.
말하기의 반대는 기다리는 것이다."
-레보비츠-
Woman Illustrated by. Анна Конева

HTTP 통신 방식은 요청(Response), 응답(Request)의 구조를 갖는다. 요청을 보내는 쪽을 클라이언트(client) 응답을 보내는 쪽을 서버(server)라고 지칭한다. 리소스를 가진 Sever는 24시 항시 켜진채로 Client가 요청을 보내기를 기다린다. 클라이언트가 요청한 리소스가 있다면 해당 리소스를 보내주고 없다면 오류 메세지를 보낸다.

Client는 서비스를 요청하고 Server는 서비스를 제공해준다.

Client	Server
	요청을 기다림
요청을 함
	요청을 처리함
응답을 기다림
	응답을 보냄
응답을 처리함

Server는 Client의 요청을 기다리고 있다가 요청이 들어오게 되면 Connection을 맺을지 말지를 결정한다. 원치 않는 경우에는 연결을 끊어버리지만 그렇지 않을 경우에는 클라이언트의 접속을 받아들인다. 요청을 받은 후에는 client에서 보낸 HTTP 요청 메세지를 읽게된다. 서버는 메세지에 적힌 리소스에 접근한다. 웹서버는 정해진 규격대로 HTTP Response 메세지(Status Code, Header, Body)를 생성한다. 그 후, 만든 응답을 클라이언트에게 전송한다. 마무리 단계로는 transaction에 관한 기록을 로그파일에 남긴다. 일반적으로 기록되는 로그 필드는 아래와 같다.

Log Fields

• HTTP Method
어떤 요청이 어떤일을 했는지 알 수 있는 정보
• HTTP Version : Client & Server
클라이언트-서버 통신시 발생한 문제를 Debugging 하기 위해 유용한 정보
• Client가 요청한 Resource의 URL
어떤 특정 페이지가 제일 인기있는지 알 수 있는 정보
• HTTP Status Code
응답이 성공적으로 이루어졌는지, 만약 실패했다면 원인이 무엇인지에 관한 정보
• Response & Request's Message size
얼마의 바이트를 앱 안팎으로 전송되고 있는가에 대한 정보
• Transaction이 일어난 시간
Timestamp : 요청 날짜와 시간
문제 발생시 그 시간에 받은 요청을 찾아낼 수 있는 정보
• Referer과 User-Agent Header 값

<sub>* Referer은 Phillip Hallam-Baker가 낸 오타이다. 상호운용성(interoperability)을 위해 현재까지 정확한 철자로 고쳐지지않고 사용되고 있다. 여기서의 상호운용성은 특정 버전이 다른 버전에서도 문제 없이 돌아갈 수 있어야 한다는 것을 의미한다. 즉, 이미 수많은 사람들이 사용하고 있는 Referer을 옳바른 맞춤법을 위해 철자를 바로 잡는다면 상호운용성을 해치게 되기에 오타 그대로 사용하는 것이다.
* Log Format으로는 Common Log Format, Combined Log Format, Netscape Extended Log Format, Squid Proxy Log Format 등이 있다.</sub>

HTTP Request와 HTTP Response는 모두 Start Line, Header, Body라는 세 부분으로 나뉜다. 아래에서 각 부분에 대해 자세히 살펴보도록 하겠다.

HTTP Request Structure

Client가 서버에게 요청을 보내는 구조에 대해 자세히 알아보자.

1. Start Line

Start line은 Method, Request Target, Version으로 이루어져 있다.

Method

클라이언트가 서버에게 지시하는 동작을 나타낸다.
다양한 Method가 있지만 제일 자주 쓰는 메서드는 GET과 POST이다. GET은 서버에서 문서를 가져오도록 지시하는 Method이다. POST는 서버에게 처리할 데이터를 보내는 용도로 쓰인다. 그렇기에 GET에는 메시지 본문이 없지만 POST는 메시지 본문(처리해야 할 데이터)을 함께 보내주어야 한다.

Request Target

Request가 보내질 Target이다. URL이나 프로토콜의 절대 경로, 포트, 도메인으로 구성되어 있다. Request Target은 메서드에 따라 다양한 형태를 지닌다.
_{* URI, URL, URN의 차이에 대해 알고싶다면 여기를 클릭하자}

Version

해당 메세지에서 사용중인 HTTP의 Version이 기술된다.
Version에 따라 메세지 구조와 데이터가 다르다. 만약 Request의 Start line이 HTTP/2.0으로 적혀있다면 클라이언트가 2.0까지 알아들을 수 있다는 것을 의미한다.

2. Headers

Headers는 키(Key):값(Value) 으로 이루어져 있으며, 0줄이거나 여러줄로 이루어진다. Headers의 종류로는 General Header, Request Header, Response Header, Entity Header, Extension Header가 있다.
<sub>* Extension Header는 다루지 않겠다.
* Response Header는 아래 HTTP Response Request부분에서 살펴보도록 하겠다.</sub>

General Header 일반 헤더

요청과 응답에 사용 가능한 헤더이다.

General
HEADER	NOTE	CODE
Cache-Control	* 캐시 지시자 * 객체가 어떻게 캐시될 것인가에 대한 정보	Cache-Control : no-cache
Connection	* Keep-alive Connection 확장을 지원하는 HTTP/1.0를 위해 사용되기 시작 * 주로 프락시를 위해 사용됨 * close라는 값을 지녔다면 응답이 완료된 후 연결을 닫을것이라는 의미.	connection : close
Date	* 메세지가 생성된 날짜와 시간에 관한 정보	Date : Friday, 09-Aug-19 11:11:11 GMT
Proxy-Connection	* Client와 Proxy의 컨넥션에 대한 옵션을 명시하기 위한 용도 * Connection Header가 Proxy를 통과하게 되는 것을 Client가 미리 안다면 단순히 Connection을 사용하는 대신 Proxy-Connection 헤더를 사용한다 * 단일 프락시에서만 사용하는 것을 권장	Proxy-Connection : Close
Trailer	* 메세지의 끝에 어떤 헤더들이 나오게되는지 알려주기 위한 용도	Trailer : Content-Length
Transfer-Encoding	* HTTP Message를 안전하게 보내기 위해 사용되는 인코딩에 관한 정보 * 안전한 전송을 위해 어떤 인코딩에 Message에 적용되었는지 수신자에게 알려준다 * 여러 인코딩이 사용되었을시 순서대로 나열	Transfer-Encoding : chunked
Upgrade	* Client-Server 통신 프로토콜을 바꾸기 위한 용도	Upgrade : HTTP/2.0
Via	* 메세지가 Proxy와 Gateway를 통과하는 과정을 추적하기 위한 용도 * 메세지가 여러 app을 통과한다면, 각각 Via 문자열에 덧붙여진다.	Via : 1.1 babytiger.com (Baby-Server/1.0)

Request Header 요청 헤더

요청에 대한 부가 정보를 제공한다.

Request
HEADER	NOTE	CODE
Accept	* Client가 Server에게 자신이 받을수 있는 Media Type에 관한 정보를 알려주기 위한 용도	Accept : text/*, image/gif
Accept-Charset	* Client가 Server에게 자신이 가장 선호하는 Charset에 대해 알려주기 위한 용도	Accept-Charset : iso-latin-1
Accept-Encoding	* Client 자신이 어떤 인코딩을 받을 수 있는지에 관한 정보	Accept-Encoding : gzip
Accept-Language	* 사용가능한 언어	Accept-Language : en
Expect	* Server가 어떻게 동작하기 원하는지에 관한 정보	Expect : 100-continue
From	* 누구로부터 요청이 왔는가에 관한 정보 * 값에는 클라이언트 유저의 인터넷 이메일 주소가 들어간다. * 하지만 개인정보 이슈가 있기 때문에 Client 구현자들은 이 헤더를 사용할 시 유저들에게 알려 주어야 한다.	From : coco@gmail.com
Host	* Client가 요청을 보내길 원하는 기계의 인터넷 Host Name과 Port번호를 Server에게 알려주기 위한 용도	Host : www.example.com:80
If-Modified-Since	* 조건부 요청	If-Modified-Since : Friday, 09-Aug-19 11:11:11 GMT
If-Match	* 조건부 요청 * Client나 캐시가 이미 갖고 있는 resource를 갱신하기 위한 용도, resource는 변경이 있을때만 return	If-Match : "19b19a-457b-31345cc"
If-None-Match	* 조건부 요청 * Client가 보낸 태그의 목록과 Server가 가진 엔터티 태그들과 비교하여 상응하는 태그가 하나도 없을시에만 return	If-None-Math: "19b19a-457b-31345cc"
If-Range	* 조건부 요청	If-Range : "19b19a-457b-31345cc"
If-Unmodified-Since	* If-Modified-Since 의 쌍둥이 * 서버는 이 헤더의 날짜 값을 보고 그 날짜 이후에 변경이 없었을 때만 그 객체를 반환한다	If-Unmodified-Since : Friday, 09-Aug-19 11:11:11 GMT
Max-Forwards	* 요청이 지나가는 프락시나 다른 중개자들의 개수를 제한하기 위한 용도 * TRACE Method에 의해서만 사용됨 * TRACE 요청시 Max-Forwards 헤더가 없다면 전달 횟수가 제한이 없다는 것을 의미	Max-Forwards : 5
Pragma	* 지시자를 메세지와 함께 넘겨주기 위한 용도 * 지시자들은 캐시 동작을 제어 * Proxy와 Gateways는 Pragma 헤더를 지워서는 안된다.	Pragma : no-cache
Proxy-Authorization	* Proxy가 App에게 자신의 신원 증명이 담긴 요청을 보내라는 인증 요구를 할 때 사용 * 홉과 홉 사이의 현재 connection에만 적용되는 헤더	Proxy-Authorization : Basic YnJpYW4t9Gd89Hk6T3ch
Referer	* Client가 얻은 URL이 어디로부터 비롯된 것인지 Server에게 알려주기 위한 용도 * Server는 로깅이나 다른 작업을 더 잘 할 수 있게 된다. * Referer헤더는 유저가 링크를 클릭했을 시에만 브라우저에 의해 삽입됨 * 개인정보 침해의 논란이 있음 : 사용자가 자신이 방문한 페이지를 알리고 싶지 않는 경우	Referer : https://www.amazon.com
TE	* Client가 chunk 인코딩을 통해 보내진 응답의 트레일러에 들어있는 헤더를 다룰 수 있는지 여부를 알려주기 위해 사용	TE : chunked
User-Agent	* Client App이 자신의 신원을 밝히기 위해 사용 * 자유로운 포멧 * Web Browser마다 다르다 * Browser 시장 점유율 통계를 알수 있다	User-Agent : Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1

Entity Header 엔티티 헤더

본문의 크기와 컨텐츠, 리소스를 설명하는 헤더이다.

Entity
HEADER	NOTE	CODE
Content-Base	* Entity 안에서 발견된 상대 URL을 해석할 때 사용할 수 있는 절대 URL	Content-Base : http://babytiger.netlify.com/
Content-Encoding	* 객체에 어떤 인코딩이 수행될 수 있는지 명시하기 위한 용도 * Server는 이 헤더를 기반으로 응답을 보내기 전에 먼저 압축할 수 있다. * Client에게 어떤 유형 혹은 인코딩의 유형이 객체에 적용되었는지 말해준다. Client는 이 헤더를 토대로 메시지를 디코딩할수 있다. * 인코딩은 수행된 순서대로 배열되야 한다.	Content-Encoding : compress, gzip
Content-Language	* Client에게 객체를 이해하기 위해 알고있어야 하는 자연어가 무엇인지 알려주기 위한 용도	Content-Language : de-DE, en-CA
Content-Length	* Entity 본문의 길이나 크기를 알려주기 위한 용도	Content-Length : 3470
Content-Location	* Server가 Client를 새 URL로 리다이렉트하기 위한 용도	Content-Location: /http
Content-MD5	* 메세지 본문에 대한 무결성 검사를 제공하기 위한 용도 * 값은 메세지 본문에 대한 MD5 요약	Content-MD5 : Q2h1Y2sgSW51ZwDLaXR6IQ==
Content-Range	* 문서의 특정 범위를 전송해달라는 요청에 대한 응답 * 현재 전송하고 있는 entity가 문서에서 어디에 해당하는지 위치(범위) 및 길이를 제공한다. * 길이 대신 (*)가 적혀있다면 전체 길이를 알 수 없었음을 의미	Content-Range : bytes 200-1000/67589
Content-Type	* 메세지에 담긴 객체의 미디어 타입에 관한 정보	Content-Type : text/html; charset=UTF-8
ETag	* 메세지에 담긴 Entity를 위한 Entity tag를 제공 * 리소스를 식별하는 수단으로 사용	ETag : "33a64df551425fcc55e4 d42a148795d9f25f89d4"
Expires	* 응답이 더 이상 유효하지 않게 되는 시간을 알려주기 위한 용도 * Client는 해당 일시가 만료되기 전까지 Sever에게 캐시된 사본이 여전히 유효한지 물어보지 않아도 된다.	Expires : Wed, 21 Oct 2019 12:12:12 GMT
Last-Modified	* 해당 Entity가 마지막으로 변경된 시간에 대한 정보	Last-Modified : Wed, 21 Oct 2019 12:12:12 GMT
Range	* Entity의 일부분이나 범위에 대한 요청에 사용 * 값은 메세지에 들어있는 Entity의 범위	Range : bytes=500-1500

3. Body

Request의 실제 메세지가 담기는 부분이다.
Body는 없는 경우(GET, DELETE, OPTIONS etc)도 많다.

HTTP POST Request의 예)
Header와 Body를 구분짓기 위한 규칙으로 Header의 마지막은 반드시 빈줄(Blank Line)으로 끝나야 한다.

HTTP Response Structure

Server에서 전송하는 HTTP Response 또한 Status Line, Header, Body 라는 세 부분으로 나뉜다.

1. Status Line

Client로 부터 받은 응답에 대한 Feedback이다. 상태코드(Status code)를 통하여 성공 또는 에러에 관한 메세지를 전달한다. Status Line은 HTTP Version, Status Code, Status Text로 구성되어 있다. Response에서의 HTTP Version에 관한 정보는 맨 앞에 위치한다.(Request에서의 HTTP Version은 start line의 맨 끝에 위치)

2. Headers

Header는 반드시 필요한 부분이 아니다. 아무것도 전달할 Header가 없다면 빈칸으로 처리한다.

Response Header 응답 헤더

응답에 대한 부가 정보를 제공한다.

Response
HEADER	NOTE	CODE
Accept-Ranges	* Server가 받아들일 수 있는 리소스의 특정 범위를 Client에게 알려주는 용도	Accept-Ranges : bytes
Age	* Client에게 응답이 얼마나 오래 됬는지 알려주는 용도 * 값은 초 단위의 변화량	Age : 60
Allow	* Client에게 특정 리소스에 대해 어떤 HTTP Method가 지원 가능한지에 대한 정보	Allow : GET, POST
Authorization	* Client는 자신을 인증하기 위해 Server에게 Authorization 헤더를 보낸다. 이 헤더의 값은 사용되는 인증 scheme에 달려 있다.	Authorization : Basic YWxhZGRpbjpvcGVuc2VzYW1l
Location	* 요청한 resource가 새로운 위치로 옯겨진 경우 사용 * 요청으로 인해 새 resource가 만들어 진 경우 해당 위치로 클라이언트를 보내기 위해 사용	Location : /index.html
Proxy-Authenticate	* Proxy가 App에게 자신의 신원 증명이 담긴 요청을 보내라는 인증요구를 위한 용도 * 현재 connection에 대한 인증을 요구	Proxy-Authenticate : Basic realm="Access to the internal site"
Public	* Server가 Client에게 자신이 지원하는 Method를 알려주는 용도	Public : OPTIONS, GET, HEAD, POST
Retry-After	* Client가 resource에 대한 요청을 언제 다시 시도할 수 있는지에 관한 정보 * 동적인 resource를 만들어내는 server가 새로 생성된 resource로 클라이언트를 redirect 하려고 하는데, 그 리소스가 생성되기까지 시간이 필요할 때 유용하게 사용된다.	Retry-After : 120
Server	* Server가 Client에게 자신이 누구인지 알려주는 용도 * 서버의 이름, 서버에 대한 주석 * 자유로운 형식	Server : Apache/2.4.1 (Unix)
Title	* Entity 의 제목을 알려주는 용도 * 초기 HTTP/1.0 확장의 일부로 주로 서버가 사용할 수 있는 명확한 제목을 가진 HTML page를 위해 사용	Title : CNN Interactive
Vary	* Client요청에 들어있는 어떤 헤더가 서버측 협상에 사용되는지 Client에게 알려주기 위한 용도	Vary: User-Agent
Warning	* 요청중에 어떤 일이 일어났는지에 대한 정보 * 상태 코드나 메세지를 통해서 전할 수 없었던 추가 정보를 보낸다	Warning : 113
WWW-Authenitcate	* Client에 대해 인증 scheme을 이용한 인증요구를 하기 위해 401 Unauthorized 응답에서 사용	WWW-Authenticate : Basic realm = "Your Private Profile"

3. Body

Body부분도 Header와 마찬가지로 반드시 전달해야 하는 부분이 아니기에 빈칸이 될 수 있다.

HTTP Response 예)

HTTP의 특징

Connectionless

HTTP는 비연결 지향이다. 비연결 지향이라 함은 연결을 유지하고 있지 않다는 것을 말한다. 클라이언트가 서버에게 요청을 보내고, 서버가 클라이언트에게 응답을 보낸 후에는 즉시 연결을 끊는다.

대부분의 경우 적은수의 서버가 많은 클라이언트의 요청을 받아들인다. 서버는 수백 수천 그 이상의 연결을 받아들이기 위해 Connectionless의 장점을 취한 것이다. 그로인해 오버헤드를 줄일수 있고 더 많은 메세지를 받아들일 수 있다.

하지만 비연결성으로 인한 불편함도 발생하게 되었는데 이는 동일한 클라이언트의 요청을 지속적으로 새롭게 연결을 시도해야 한다는 점이다. 이는 높은 연결비용을 야기시켰다. 이에 대한 해결책으로 Keep-Alive가 있다.

Keep-Alive

Keep-Alive을 이용하면 Connection을 맺기 위해 발생하는 준비 작업 시간이 절약된다. 연결이 유지되고 있기에 TCP로 인한 지연시간에 영향을 받지 않음으로 더 빠른 데이터 전송이 가능해진다.

Keep-Alive 기능을 사용하고자 한다면 Header에 Connection 필드를 사용하면 된다.
      Connection : Keep-Alive → Keep-Alive를 사용함을 의미
      Connection : close      → Keep-Alive를 사용하지 않음을 의미
Keep-Alive에 관한 요청을 받았다고 반드시 사용해야 하는 것은 아니다. 서버는 언제든지 Keep-Alive 연결을 끊을 수 있다.

Stateless

HTTP는 stateless 프로토콜이다. State 는 ‘상태’를 의미한다. 상태가 없다는 것은 요청과 응답의 상태를 저장하지 않는다는 것을 말한다. 서버는 클라이언트가 보낸 요청에 대해 단순히 응답만 하고 그동안의 상태를 기억하지 않는다. 모든 요청-응답은 독립적인 transaction이 된다.

HTTP의 Stateless 라는 특징으로 인해 발생하게 되는 문제는 유저가 매번 새로운 인증(로그인과 같은)을 해주어야 한다는 것이다. 이런 단점을 해결하기 위해 쿠키(Cookie), 세션(Session), OAuth, JWT등과 같은 방법을 사용하게 된다.
_{* Cookie, Session, OAuth, JWT는 다른포스트에서 자세히 다룰 것이다.}

Return to the ToC

HTTP Methods

HTTP Methods의 종류로는 CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE가 있다. 이 중에서 7까지 메서드에 대해 알아보겠다. 안전한 메서드(Safe Method)
GET과 HEAD는 안전한 메서드에 속한다. 안전하다는 의미는 해당 메서드를 통해 서버에 있는 리소스를 변경하지 않는다는 것을 의미한다. 안전한 메서드는 데이터 요청만 하기에 서버에 영향(수정, 삭제)을 주지 않는다.

GET

• 서버에서 특정 리소스를 가져오고자할 때 사용.

POST

• 서버가 처리해야 할 데이터를 보낼 때 사용.

POST는 서버에 입력 데이터를 전송하기위해 설계된 메서드이다.

HEAD

• 서버에서 특정 리소스에 대한 헤더만 가져오고자할 때 사용.

Server는 Entity 본문을 반환해주지 않는다. Client는 리소스를 가져오지 않고도 헤더에 담긴 내용으로 특정 정보를 알아낼 수 있다.

PUT

• 서버에게 Request 메세지의 본문을 저장할 때 사용.

PUT 메서드를 통해 서버에 문서를 작성 또는 변경할 수 있다. 그로인해 인증이 필요한 경우가 대다수이다.

DELETE

• 서버의 리소스를 삭제할 때 사용.

TRACE

• 메세지가 Proxy를 거쳐 서버에 도달하는 과정을 추적하고자할 때 사용.

주로 진단을 위해 사용되는 TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도착했을 때에 어떻게 보이게 되는지 알려준다. Client가 보낸 TRACE 요청은 Server에서 loopback 진단을 한다. 요청 전송의 마지막 단계에서 Server는 자신이 받은 요청 메세지를 본문에 넣어 TRACE 응답을 되돌려준다.

OPTIONS

• 서버가 어떤 메서드를 수행할 수 있는지 확인하고자할 때 사용.

클라이언트는 OPTIONS를 통해 웹서버에게 여러 가지 종류의 지원 범위에 대해 물어볼 수 있다. 여러 리소스에 접근하기 전에 어떤 방법으로 접근하는 것이 최선인지 알아 낼 수 있다.

Return to the ToC

HTTP Status Code

상태코드(Status Code)는 5개의 그룹으로 나뉜다.

• 1xx Informational
• 2xx Success
• 3xx Redirectional
• 4xx Client Error
• 5xx Server Error

1xx Informational

정보성 상태 코드

• 100 Continue
  클라이언트의 요청 시작 부분의 일부가 받아들여졌고 클라이언트는 나머지를 계속 이어서 보내야함을 의미. 100 Continue는 Client App이 Server에 Entity본문을 전송하기 전에 그 본문을 서버가 받아들일 것인지에 관한 여부를 확인하기 위하여 도입되었다.
• 101 Switching Protocols
  서버가 프로토콜을 바꾸었음을 의미
• 102 Processing
  처리 시간이 걸릴때 전송하는 상태코드

2xx Success

성공 상태 코드

• 200 Ok
  클라이언트 요청이 서버에서 정상적으로 처리됬음을 의미. Entitiy 본문은 Client가 요청한 리소스를 포함하고 있다.
• 201 Created
  서버에 개체가 성공적으로 생성됬다는 것을 의미.
• 202 Accepted
  클라이언트의 요청은 접수되었지만 서버는 아직 동작을 수행하기 전이라는 것을 의미. 서버는 요청의 처리가 언제 완료될 것인지에 관한 정보를 보내주는 것이 좋다.
• 203 Non-authoritative Information
  클라이언트의 요청은 정상적으로 접수했지만 원하는 리소스가 다른 소스로부터 비롯됬음을 의미.
• 204 No Content
  서버가 보낸 Response에는 본문없이 Status Line과 Header만 존재함을 의미. 주로 웹브라우저를 새 문서로 이동시키지 않고 refresh 하고자 할 때 사용한다.
• 205 Reset Content
  브라우저를 위한 상태 코드이다. 브라우저에게 현재 페이지에 있는 HTML Form에 있는 모든 값을 비우도록 하기 위해 사용.
• 206 Partial Content
  일부분 또는 특정 범위의 요청이 성공했음을 의미. 범위 요청의 성공.
• 207 Multi-Status
  여러개의 부가적 요청들의 각각의 응답을 성공시켰음을 의미.
• 208 Already Reported
  이미 응답하였음을 의미.
• 226 IM Used
  응답이 성공하였고 그 응답은 하나 이상의 인스턴스를 포함함을 의미.

3xx Redirectional

리다이렉션 상태 코드

리다이렉션 상태코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치에 관한 정보를 알려주거나 그 리소스의 내용 대신 다른 대안을 알려준다.

• 300 Multiple Choices
  클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청했을시 리소스의 목록과 함께 반환한다. 클라이언트는 목록의 리스트 중 하나를 선택할 수 있다.
• 301 Moved Permanently
  요청한 URL이 옮겨 졌을시 사용하는 상태 코드. 서버는 클라이언트에게 보내는 응답 Header에 Location을 보내줘야 한다. Location 값은 해당 리소스가 존재하고 있는 새로운 URL이다.
• 302 Found
  301과 비슷한 의미를 갖고 있다. 클라이언트는 Location Header로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다. 이후의 요청은 원래 URL을 사용하게 된다.
• 303 See Other
  클라이언트에게 리소스를 다른 URL에서 가져와야 한다고 알려주고자 할때 쓴다. 새 URL은 Response의 Location Header에 적혀있다.
• 304 Not Modified
  클라이언트가 조건부로 요청한 리소스가 최근에 수정되지 않았을 경우 서버가 보내는 코드.
• 305 Use Proxy
  리소스에 접근하기 위하여 반드시 Proxy를 사용해야 함을 의미.
• 307 Temporay Redirect
  임시 Redirect. 클라이언트는 Location Header로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용. 이후의 요청에서는 원래 URL을 사용.
• 308 Permanent Redirect
  영구 Redirect. 대부분의 인터넷 브라우저에서 지원하지 않는다.

4xx Client Error

클라이언트 에러 상태 코드

클라이언트가 보내는 요청이 서버에서 다룰수 없는 경우 Client Error 상태 코드가 사용된다.

• 400 Bad Request
  클라이언트가 잘못된 요청을 보냈을시 사용되는 코드.
• 401 Unauthorized
  리소스를 얻기위해서는 인증해야 할 필요가 있다는 것을 의미한다.
• 402 Payment Required
  현재 사용되는 상태 코드는 아니다. 미래에 사용될 가능성을 위해 준비된 상태 코드.
• 403 Forbidden
  클라이언트 요청이 서버에 의해 금지되었음을 의미한다. 서버가 왜 요청이 금지되었는지 알려주고 싶다면 그 이유를 Entity 본문에 포함시키면 된다. 하지만 403 상태 코드 자체가 서버에서 금지된 이유를 숨기고자 사용하는 경우가 대부분이기에 상태 코드만 전송한다.
• 404 Not Found
  클라이언트가 요청한 페이지를 찾을 수 없는 경우 사용.
• 405 Method Not Allowed
  해당 리소스에 대해 서버에서 지원하지 않는 메서드의 요청을 받았을시 사용. 사용가능한 메서드가 무엇인지에 관한 정보를 Allow Header에 포함시켜 클라이언트에게 보내줘야 한다.
• 406 Not Acceptable
  주어진 URL에 대한 리소스 중 클라이언트가 받아들일 수 있는 것이 없는 경우 사용.
• 407 Proxy Authentication Required
  401과 비슷하지만 리소스에 대해 인증을 요구하는 Proxy Server용 이다.
• 408 Request Timeout
  클라이언트의 요청을 완수하기에 오랜 시간이 걸리는 경우, 서버에서 408 상태 코드로 응답을 보낸뒤 연결을 끊을 수 있다.
• 409 Conflict
  클라이언트가 보낸 요청이 충돌을 일으킬수 있을 경우 409를 보낸다. 응답 메세지에는 충돌에 대해 설명하는 본문을 포함시킨다.
• 410 Gone
  404외 비슷하다. Gone은 클라이언트가 요청한 리소스를 이전에는 서버가 갖고 있었지만 현재는 갖고 있지 않다는 의미이다. 주로 웹사이트를 유지하면서 발생하는 상황이다. 서버 관리자가 클라이언트에게 리소스가 제거됬다는 것을 알려주기 위해 사용된다.
• 411 Length Required
  요청 메세지에 Content-Length Header가 있는 경우 사용한다.
• 412 Precondition Failed
  클라이언트가 조건부 요청을 했지만 그 중 하나라도 실패했을 대 사용한다. 조건부 요청은 클라이언트가 Expect Header를 포함한 경우이다.
• 413 Payload Too Large
  클라이언트가 서버가 처리할 수 있는 한계를 벗어난 크기의 요청을 했을시 사용되는 코드이다.
• 414 Request-URI Too Long
  서버가 처리할 수 있는 URL의 길이를 넘어선 경우 서버에서 보내는 코드이다.
• 415 Insupported Media Type
  서버가 이해할 수 없거나 지원하지 않는 유형의 Entity를 클라이언트가 보냈을 때 사용되는 코드이다.
• 416 Requested Range Not Satisfiable
  클라이언트가 보낸 요청 메세지의 리소스의 특정 범위가 잘못되었을 때 사용한다.
• 417 Expectation Failed
  클라이언트가 보낸 Expect 요청을 서버가 수행할 수 없는 경우 사용된다.
• 418 I’m a teapot
  만우절 장난으로 만들어진 코드. 서버가 찻주전자이기에 커피 내리기를 거절했다는 의미이다.
• 421 Misdirected Request
  클라이언트가 보낸 요청이 응답을 할 수 없는 서버로 전송되었을 경우.
• 422 Unprocessable Entity
  클라이언트가 보낸 요청의 문법도 알맞고 서버가 요청을 이해했지만 요청된 지시를 따를 수 없을때 사용.
• 423 Locked
  리소스에 대한 접근을 잠가두었을 시 사용.
• 424 Failed Dependency
  서로 의존관계에 있는 리소스중를 가져오는데 실패한 경우이다. 리소스를 가져오기 위해 연쇄적인 action이 요구되는데 action중 하나가 실패했을 경우 보내는 코드이다.
• 426 Upgrade Required
  클라이언트가 현재 사용한 프로토콜은 거부하지만 만약 다른 프로토콜로 업그레드 한다면 해당 리소스를 보내 줄 수 있음을 의미.
• 428 Precondition Required
  클라이언트의 조건부 요청이 필요한 경우 서버가 보내는 코드.
• 429 Too Many Requests
  유저가 너무 많은 요청을 짧은 시간에 보냈을 경우 사용된다.
• 431 Request Header Fields Too Large
  클라이언트가 요청한 헤더필드가 너무 클 경우 보내는 코드. 서버는 만약 클라이언트가 사이즈를 줄여서 다시 보낸다면 받아줄 의사가 있음을 표현한다.
• 444 Connection Closed Without Response
  응답 없이 컨넥션을 끊음을 의미한다.
• 451 Unavailable For Legal Reasons
  클라이언트가 요청한 리소스가 정부에 의해 검열된 불법적인 리소스일시 서버에서 보내는 코드.
• 499 Client Closed Request
  클라이언트가 요청을 닫은 경우 사용.

5xx Server Error

서버 에러 상태 코드

클라이언트가 올바른 요청을 보내었지만 서버쪽에서 제대로 처리하지 못했을 경우 사용되는 상태 코드들이다.

• 500 Internal Server Error
  내부 서버 오류. 서버가 요청을 처리할 수 없는 에러를 만났을때 사용.
• 501 Not Implemented
  구현 되지 않음. 클라이언트가 서버의 능력을 뛰어 넘은 요청을 하였을시 사용. 예를들어 서버에서 지원하지 않는 메서드를 사용했을 경우.
• 502 Bad Gateway
  Proxy나 Gateway처럼 행동하는 Server가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답을 만났을때 사용.
• 503 Service Unavailable
  일시적으로 서버를 사용할 수 없음. 현재는 서버가 요청을 처리할 수는 없지만 나중에는 요청을 처리해 줄 수 있음을 의미.
• 504 Gateway Timeout
  게이트웨이 시간 초과. 다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한 Gateway나 Proxy에서 온 응답을 말한다.
• 505 HTTP Version Not Supported
  지원하지 않는 HTTP Version. 서버가 지원하지 않는 버전의 프로토콜로 된 요청을 받았을 경우.
• 506 Variant Also Negotiates
  서버의 내부 구성 오류가 발생한 경우.
• 507 Insufficient Storage
  용량이 부족한 경우.
• 508 Loop Detected
  무한 루프가 감지된 경우.
• 510 Not Extended
  클라이언트가 보낸 요청을 처리하기 위해서 서버의 추가적인 확장이 필요한 경우.
• 511 Network Authentication Required
  네트워크 읽기 시간초과 오류
• 599 Network Connect Timeout Error
  네트워크 연결 시간초과 오류

Return to the ToC

References

• [MDN] HTTP
• Application Layer
• Evolution of HTTP
• From Hypertext to the World Wide Web
• HTTP
• HTTP request and response examples
• HTTP Status Codes
• HTTP 프로토콜
• Let’s Build A Web Server. Part 1.
• RFC 7540
• The birth of the Web
• The importance of protocols and standards
• What Happens When You Click a Link?
• Why Are Network Protocols Needed?
• Why was 80 Chosen as the Default HTTP Port and 443 as the Default HTTPS Port?
• 프로토콜이란 무엇인가