Hypertext Transfer Protocol. 클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 규약. 서버와 클라이언트의 사이에서 통신을 어떻게 주고받아야하는지 정해둔 규칙.

HTTP 프로토콜은 대략 3가지 특징을 가지고 있다.

1. HTTP 프로토콜의 3가지 특징.

1. Client - Server 구조.

클라이언트가 요청(Request)을 하면, 서버는 응답(Response)한다. 클라이언트와 서버는 각각 독립되어 있는 개념이다.

2. 무상태성. (Stateless)

서버는 클라이언트의 상태State를 소유하지 않는다. 서버가 클라이언트의 상태를 소유한다는 것은, 작업이 진행되는 동안 서버와 클라이언트가 계속 연결되어있어야 한다는 뜻이고 이는 곧 연결을 유지하는데 자원을 지속적으로 소모해야 한다는 뜻이다. 서버와 클라이언트의 숫자, 규모 등이 커질 수록 이는 무시할 수 없는 심각한 문제점으로 다가오게 된다.

그런데 반대로 이전 상태를 서버에서 저장하고 있지 않기 때문에, 아래와 같은 상황의 문제가 발생하게 된다.

손님: 노트북 모델 Z의 가격은 얼마인가요?
직원A: 100만원입니다.

손님: 이 모델 2개 구매하겠습니다.
직원B: 어떤 모델 말씀이실까요?

손님: 카드로 결제하겠습니다.
직원C: 어떤 모델을 몇 개 구매하시는 건가요?
출처 : HTTP 프로토콜의 특징

따라서 클라이언트는 서버에 요청을 보낼 때, 응답을 받기위해 필요한 모든 정보를 하나씩 추가해 나가면서 요청을 보내야 한다.

손님: 노트북 모델 Z의 가격은 얼마인가요?
직원A: 100만원입니다.

손님: 노트북 모델 Z를 2개 구매하겠습니다.
직원B: 200만원입니다. 카드로 결제하시나요, 현금으로 결제하시나요?

손님: 노트북 모델 Z 2대를 카드로 결제하겠습니다.
직원C: 총 200만원 결제되었습니다. 감사합니다.

• 로그인 등의 경우에는 무상태성을 유지하면서 기능을 어떻게 구현하지?
  로그인을 했다는 정보를 웹 스토리지, 서버 세션, 토큰 등을 이용해서 저장해두고 요청시 사용한다.

3. 비연결성. (Connectionless)

위에서 언급한 무상태성의 설명에서 연장되는 이야기. 서버가 클라이언트의 상태를 소지하고 있지 않기 때문에 클라이언트와 서버의 연결은 지속적이지 않다. 필요한 때만 요청을 보내고 응답을 받기 때문에 연결에 필요한 자원을 아낄 수 있다.

다만 연결 - 요청 - 응답 - 연결종료의 과정이 많이 발생되는 것도 자원을 소모하는 일이기 때문에 트래픽이 엄청나게 많은 서비스의 경우라면 비연결성의 특징이 장점으로 작용하는 것은 아니다.

2. HTTPS?

HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure.

기존 HTTP 프로토콜에서는 통신에 내용되는 데이터를 암호화하지 않았기 때문에, 정보가 중간에서 탈취될 수 있다는 위험성을 내포하고 있었다. 이 문제를 보완하기 위해 TLS Transport Layer Security이라는 개념을 기존 HTTP에 결합하여 통신 과정에서 일반 텍스트를 사용하지 않고 암호화된 데이터를 사용하여 통신의 안전을 보장한다.

• TLS Transport Layer Security?
  네트워크에서 데이터를 암호화하여 주고받는 규약. 넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에 기반한 기술이기에 SSL이라 부르는 경우도 있다. 자신을 신뢰할 수 있음을 알리기 위해 전자 서명이 포함된 인증서를 사용하며, 도청을 방지하기 위해 통신 내용을 암호화한다.

3. HTTP Method. 출처

HTTP는 클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식을 정해둔 규약이다. 이를 HTTP Method라고 하는데, 총 9 종류가 존재한다.

자주 사용되는 5가지 Method.

GET : 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경)
DELETE : 리소스 삭제

• 리소스를 조회할 때는 POST를 사용해도 되지만, GET 메서드는 캐싱이 가능하기에 GET을 사용하는 것이 유리하다.

• 캐싱?
  자주 사용되는 데이터를 임시로 복사해두는 임의의 장소를 캐시Cache라고 하며, 여기에 데이터를 저장하는 행위를 캐싱Caching이라고 한다.

  리소스를 조회하는 역할은 GET이 맡고있기 때문에 GET Method 사용시에만 데이터 캐싱이 이루어진다. GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환하여 불필요한 요청이 들어가지 않도록 한다.
  

• 멱등성idempotent
  연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질. GET은 단지 리소스를 조회하기만 하는 역할이기 때문에 요청을 반복하더라도 응답이 동일하다. 반면 POST는 리소스를 새로 생성 혹은 갱신할 때 사용하기 때문에 매번 응답이 다를 수가 있다.

나머지 4가지 Method.

HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

• HEAD?
  GET과 동일하지만 서버에서 Body를 Return 하지 않음.

  응답의 상태 코드만 확인할때와 같이 Resource를 받지 않고 오직 찾기만 원할 때 사용. (일종의 검사 용도)

  서버의 응답 헤더를 봄으로써 Resource가 수정 되었는지 확인 가능.

• TRACE?
  이 메서드도 일종의 검사용.

  서버에 도달 했을 때의 최종 패킷의 요청 패킷 내용을 응답 받을 수 있다.

  요청의 최종 수신자는 반드시 송신자에게 200(OK) 응답의 내용(Body)로 수신한 메세지를 반송해야 한다.

  최초 Client의 요청에는 Body가 포함될수 없다.

• OPTION?
  예비 요청(Preflight)에 사용되는 HTTP 메소드.

  예비 요청이란 본 요청을 하기 전에 안전한지 미리 검사하는 것이라고 보면 된다.

  서버의 지원 가능한 HTTP 메서드와 출처를 응답 받아 CORS 정책Visit Website을 검사하기 위한 요청이다..

• CONNECT?
  참조.

4. HTTP 상태코드

내용 출처 : [웹 프로그래밍] HTTP 상태 코드 표(100 ~ 500) 전체 요약 정리

HTTP 프로토콜을 이용해서 클라이언트에서 서버에 요청을 보낼 때, 서버에서는 응답에 처리 결과를 상태 코드status code를 같이 반환한다.

상태 코드는 세 자리 숫자로 되어 있는데 첫 번째 숫자는 HTTP 응답의 종류를 구분하는 데 사용하며, 나머지 2개의 숫자는 세부적인 응답 내용 구분을 위한 번호이다. 현재 100~500번 대까지 상태 코드가 정의되어 있는데 첫 번째 자리 숫자에 따라 다음과 같이 5가지로 분류해서 사용하고 있다.

1XX: Informational(정보 제공)

임시 응답으로 현재 클라이언트의 요청까지는 처리되었으니 계속 진행하라는 의미입니다. HTTP 1.1 버전부터 추가되었습니다.

2XX: Success(성공)

클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미입니다.

3XX: Redirection(리다이렉션)

완전한 처리를 위해서 추가 동작이 필요한 경우입니다. 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미입니다.

4XX: Client Error(클라이언트 에러)

없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미합니다.

5XX: Server Error(서버 에러)

서버 사정으로 메시지 처리에 문제가 발생한 경우입니다. 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우를 의미합니다.

각 세부 코드들의 개별 의미는 해당 출처를 참조.