[TIL] HTTP: Hypertext Transfer Protocol

HTTP 란?

HTTP(Hypertext Transfer Protocol)은 여러가지 정보 취득이나 발신에 사용하는 인터넷의 핵심 프로토콜이다.

HTTP의 메세지는 사람이 읽을 목적으로 전달되는 것이 아닌, HTTP 서버와 HTTP 클라이언트(브라우저)가 읽고 해석할 목적으로 전단된다.

즉, HTTP는 조회형 프로토콜로서 서버의 80번 포트에 설정된 소켓에서 HTTP 요청과 응답을 교환함으로써 통신을 수행한다. 이때 HTTP는 TCP 서비스를 이용한다.

---

HTTP 트랜잭션

HTTP에서 클라이언트와 서버 간의 요청과 응답과정을 알아보자.

HTTP에서 클라이언트에서 서버로 보내는 명령은 요청(request) 메세지에 들어있고, 요청에 대한 파일 내용, 그 외의 정보는 응답(response) 메세지에 들어있다.

HTTP는 stateless 프로토콜이기 때문에 클라이언트에 대한 정보는 서버에 저장되어있지 않다.

HTTP 트렌잭션

 

 

요청(request) 메세지 구조

 

request 메세지 구조

 

1. Request-line

HTTP request 메세지의 첫 번째 줄은 request-line 이다.

request- line은 Method, URL, HTTP version 3개의 필드로 구성된다. 

Method 필드는 Requst Type을 나타낸다. 아래는 주요 Method이다.

Method 이름	설명
OPTIONS	대상 리소스에 대해 사용가한 HTTP 메서드를 확인한다.
GET	서버로부터 데이터를 가져온다. (Read) ex) 웹페이지 요청
HEAD	데이터의 헤더를 가져온다.
POST	서버로 데이터 전송, 새로운 리소스 생성한다.  (멱등성을 보장하지 않는다.) ex) 사용자 로그인, 댓글 작성
PUT	서버에 리소스를 덮어쓰기(전체 수정)한다. (Update) ex) 사용자 프로필 업데이트
DELETE	서버의 리소스를 삭제한다. (Delete) ex) 게시글 삭제
PATCH	리소스를 부분적으로 업데이트한다. (Update)

 

 

2. Request-header-line

HTTP request 메세지의 두 번째 줄은  Request-header-line이다. 이 라인은 없을 수도 있다.

각 헤더 라인은 서버로 추가 정보를 전송한다.

 

일부 헤더 이름:

requset header	설명
Accept	클라이언트가 받아들이는 문서 형식 지정
Accept-Language	클라이언트가 받아들일 수 있는 언어 지정
Accept-Encoding	클라이언트가 받아들이는 문자 코드의 부호화 방식 지정
Accept-Charset	클라이언트가 선호하는 문자 인코딩 지정
DNT	Do Not Tracking의 줄임말. 추적을 금지함
Cookie	쿠키 정보 설정
Host	호스트 이름과 포트 번호 지정
Referer	현재 요청된 페이지의 이전 웹 페이지 주소 유입 경로 파악 가능
User-Agent	클라이언트 애플리케이션 정보(PC, Mobile 브라우저) 어떤 환경에서 주로 접속하는지 통계 어떤 종류의 환경에서 장애가 발생하는지 파악 가능

참고: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

 

 

응답(response) 메세지 구조

 

response 메세지 구조

 

1. Status-line

status-line에는 HTTP 버전, 상태 코드, 상태 문구 3개의 필드가 있다.

상태 코드 필드는 요청의 상태를 나타낸다.

 

100 범위: 요청 수신 후 처리 중 상태 (잘 사용하지 않음)

200 범위: 요청이 성공적으로 처리됨

300 범위: 클라이언트를 또 다른 URL로 재지정(리다이렉션, 요청 완료를 위해 추가 행동이 필요한 상태)

400 범위: 클라이언트 사이트 오류

500 범위: 서버 사이트 오류

 

상태 코드와 상태 문구:

상태	상태 코드	상태 문구	설명
성공	200	OK	클라이언트의 요청이 정상 처리됨
	201	Creat	새로운 리소스 생성
	204	No Content	요청은 성공했지만, 응답 데이터가 없음 ex) 저장, 작성 버튼 클릭
	206	Patial Content	정보의 일부를 응답함
리다이렉션	301	Moved Permanently	요청된 자원은 다른 URL로 이동함 ( 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다. )
	304	Not modified	요청한 리소스는 수정되지 않음 캐시 목적으로 사용. 클라이언트가 캐시된 데이터를 조회하도록 유도
	308	Permanent Redirect	리다이렉트시 요청 메서드와 본문이 유지된다.
클라이언트 오류	400	Bad Request	정확하지 않은 요청 ex) GET 메소드로 만들어진 API인데 POST로 보낸경우
	401	Unauthorized	인증되지 않은 리소스임
	404	Not Found	요청된 URI(리소스)가 서버 상에 없음
	408	Requst Timeout	요청이 타임아웃 되었다.
서버 오류	500	Internal Server Error	서버 내부에 문제 발생
	501	Not Implemented	클라이언트가 요청한 기능을 지원하지 않음
	503	Service Unavailable	서비스 이용 불가

 

 

2. Response-header-line

HTTP response 메세지의 두 번째 줄은  Response-header-line이다. 이 라인은 없을 수도 있다.

각 헤더 라인은 클라이언트에게 추가 정보를 전송한다.

 

일부 헤더 이름:

response header	설명
Server	요청을 처리하는 ORIGIN 서버의 Software 정보
Date	HTTP 요청이 발생한 날짜와 시간
Location	생성된 리소스 URI, 리다이렉트 주소 1) 응답코드 3xx와 함께 응답되면 리다이렉트 주소 2) 응답코드 201(Created)와 함께 응답되면 생성된 리소스의 URI
Allow	허용 가능한 HTTP Method 405 (Method Not Allowed)와 함께 응답된다.
Retry-After	다음 요청까지 대기 해야하는 시간 503 (Service Unavailable)와 함께 서비스가 언제까지 사용이 불가한지 알려준다. (초단위/날짜 단위)
Set-Cookie	클라이언트의 웹 브라우저에 쿠키를 설정 보안에 민감한 개인정보 등은 저장하지 않는다.
Last-Modified	웹 페이지의 최종 갱신일
ETag	웹 페이지 식별을 위한 유일한 정보를 지정

 

---

HTTP의 연결

HTTP 1.0은 비영속적 연결을 사용하지만, HTTP 1.1은 영속적 연결을 기본으로 규정한다.

 

1. 비영속적 연결(nonpersistent connection)

비영속적 연결에서는 각 요청/응답에 대해 하나의 TCP 연결이 만들어진다.

 

동작단계:

① 클라이언트가 TCP 연결을 열고 요청을 보낸다

② 서버는 응답을 보내고 연결을 닫는다.

③ 클라이언트는 end-of-file 표시가 나타날 때까지 데이터를 읽고 연결을 닫는다.

 

장점:

서버 자원을 효율적으로 사용할 수 있다.

 

단점:

요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야하기 때문에 요청에 대한 응답 시간이 증가한다.

 

2. 영속적 연결(persistent connection)

서버는 응답을 전송한 후, 이후의 요청을 위해 연결을 열어놓은 상태로 유지한다.서버는 클라이언트의 요청에 따라 혹은 타임아웃이 될 경우 닫힌다.

 

서버는 보통 각 응답에 데이터의 길이를 송신한다. 하지만 문서가 동적으로 생성되는 경우 데이터의 길이를 알 수 없는 경우가 생긴다.  이 경우 서버는 클라이언트에게 길이를 알 수 없다는 것을 알리고, 데이터 전송 후 연결을 끊음으로서 클라이언트에게 데이터의 끝을 알린다.