[네트워크]HTTP

HTTP(HyperText Transfer Protocol)는 하이퍼텍스트를 빠르게 교환하기 위한 프로토콜의 일종으로, 

 

클라이언트와 서버가 어떻게 메시지를 교환할지를 정해 놓은 규칙이다.

 

프로토콜의 일종이라 함은 HTTP를 제외하고도 프로토콜이 존재한다는 것을 의미하는데, 대략 아래와 같다.

	계층 이름	주요 프로토콜	기능
4계층	Application Layer	HTTP, DNS, FTP, ...	애플리케이션에 맞추어 통신한다.
3계층	Transport Layer	TCP, UDP, ...	IP와 애플리케이션을 중재해 데이터를 확실하게 전달한다.
2계층	Internet Layer	IP, ICMP, ARP, RARP	네트워크 주소를 기반으로 데이터를 전송한다.
1계층	Network Interface Layer	Ethernet, wifi, ...	장치를 물리적으로 네트워크에 연결, 기기간 전송이 가능하게 한다.

계속해서 클라이언트가 HTTP를 이용해 서버와 주고받는 메시지는 'HTTP 메시지'라고 불리는데,

 

클라이언트는 서버의 구성을 모르는 상태에서 어떻게 리소스를 요청할 수 있을까?

 

이에 대한 대답이 바로 API(Application Programming Interface)이다.

 

여기서 API란 앱을 만드는데 필요한 서브 앱과 프로토콜을 정의하여 상호작용을 돕는 인터페이스 사양이라 말할 수 있다.

 

서버가 구축해놓은 API는 카페의 메뉴판에 비유할 수 있는데,

 

제공하는 메뉴를 명시해 클라이언트가 엉뚱한 메뉴를 주문하는 것을 방지할 수 있다는 점에서 그렇다.

 

HTTP API 디자인에는 Best Practice가 존재하지만(ex. 동사보다 명사를 사용할 것),

 

이에 대해서는 추후에 다루기로 한다.

 

HTTP 요청에는 메서드가 존재하며, 리소스를 조회, 갱신, 삭제하기 위해 사용된다. 주로 사용되는 예는 아래와 같다.

 

요청	메서드
조회(Read)	GET
추가(Creat)	POST
갱신(Update)	PUT or PATCH
삭제(Delete)	DELETE

HTTP 메시지로 돌아오자.

 

지난 글에서, HTTP의 가장 큰 특징 두 가지에 대해 살펴봤었다.

 

• Connectionless - 클라이언트가 요청을 한 후 응답을 받으면 서버가 그 연결을 끊어 버리는 특성
• Stateless - 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며, 상태 정보를 유지하지 않는 특성

관련 글: https://gnidinger.tistory.com/438

[네트워크]웹(WEB)

쉽게 말해 HTTP는 통신 프로토콜일 뿐이므로 현재의 상태를 추적 또는 저장하지 않는다는 뜻이다.

 

상태 저장을 위해선 쿠키-세션이나 API 등 다른 방법이 필요하다. 여기선 무상태성(Stateless)이 중요하다.

 

클라이언트와 서버 사이의 데이터 교환 방식인 HTTP 메시지에도 두 가지 유형이 있는데,

 

• 요청(Request)
• 응답(Reponse)

이 그것이다. 중요한 것은 요청이 없으면 절대 응답이 없다는 부분이다.

 

작동 순서는 클라이언트가 웹 페이지에서 링크를 클릭(요청)하면 새로운 페이지로 이동(응답)하는 식이다.

 

HTTP 메시지는 아래와 같은 텍스트 정보로 이루어져 있으나, 개발자가 모두 직접 입력할 필요는 없다.

 

구성 파일, API, 기타 인터페이스에서 자동으로 완성시켜주기 때문이다.

 

그림에서 볼 수 있듯이 요청(Requests)과 응답(Responses)은 비슷한 구조를 가지고 있다.

 

• Start Line - 요청이나 응답의 상태 표시. 항상 첫 번째 줄에 위치. 응답의 경우 Status Line이라 부른다.
• HTTP Headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
• Empty Line : 헤더와 본문을 구분하는 빈 줄
• Body : 요청이나 응답과 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용.

특별히 Start Line과 HTTP Headers를 묶어 요청이나 응답의 Head라 하며, Payload(전송되는 데이터)는 Body라고 한다.

 

이어서 요청과 응답의 메시지 구조를 뜯어보자.

 

 

요청

 

요청은 클라이언트가 서버에 보내는 메시지이다. 위 그림에서 볼 수 있듯이 크게 세 부분으로 나뉜다.

 

각 요소는 쉽게 말해 제목, 요약, 본문이라고 보면 된다.

 

• Start Line

Start Line은 요청의 상태를 표시하며, 메시지의 가장 윗 줄에 들어간다. Start Line은 다시 세 부분으로 나뉜다.

 

1. HTTP Method - 수행할 작업이나 방식에 따른 메서드를 표시한다. GET, PUT, POST, HEAD, OPTIONS 등이 있다.
2. Path - 가져올 리소스의 경로이다. Origin, Absolute, Authority, Asterisk 형식이 있다.
3. Version of the Protocol - HTTP의 버전이다. HTTP/1.1, HTTP/2, HTTP/3 등이 있다.

위에서 한 번 봤지만, 많이 쓰이는 HTTP 메서드를 다시 보자면 아래와 같은 것들이 있다.

 

메서드	기능
OPTIONS	해당 URL에서 지원하는 요청 메세지의 목록을 요청
GET	URL에 해당하는 자료의 전송을 요청
POST	서버에서 처리할 수 있는 자료를 보낸다. 멱등성*을 보장하지 않는다.
PUT	지정한 URL에 지정한 데이터를 저장할 것을 요청
PATCH	지정한 URL의 데이터를 부분적으로 수정할 것을 요청
DELETE	지정한 URL의 정보를 제거할 것을 요청

*멱등성 - 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질

 

• Headers

Headers는 요청에 대한 추가 정보를 제공한다. 위 그림에서 보듯이 기본 구조가 있으며, 역시 크게 세 그룹으로 나뉜다.

 

1. Request Headers - 가져올 리소스나 클라이언트에 대한 정보가 담긴다. 요청의 구체화, 컨텍스트 제공, 제약 추가를 할 수 있다.
2. General Headers - 요청과 응답 메시지 모두에서 쓰이지만 메시지에 적용되지는 않는 헤더이다. 현재 시간, 캐시 제어 등이 포함된다.
3. Representation(Entity) Headers - Body에 담긴 컨텐츠의 길이나 MIME 타입 등을 포함하고 있다.

 

• Body

 

Body에는 해당 요청의 실제 내용이 담기며, 생략할 수도 있다.

 

예를 들면 GET, HEAD, DELETE, OPTIONS와 같이 서버에 리소스를 요청만 하는 경우에는 Body가 필요하지 않다.

 

Body는 크게 두 종류로 나뉜다.

 

1. Single-Resource bodies(단일-리소스 본문) - 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성
2. Multiple-Resource bodies(다중-리소스 본문) - 여러 파트로 구성된 Body. 각 파트마다 다른 정보를 지닌다.

 

응답

 

응답은 서버가 클라이언트에게 보내는 메시지이다. 큰 틀은 요청과 같다.

 

• Status Line

 

응답의 첫 줄은 Status Line이라고 불린다. 응답의 상태를 나타내기 위해 다음과 같은 정보들이 담긴다.

 

1. Version of the Protocol - HTTP의 버전이다. HTTP/1.1, HTTP/2, HTTP/3 등이 있다.
2. Status Code - 요청의 결과를 나타낸다(200, 302, 404 등).
3. Status Message - 상태 코드에 대한 설명

자주 쓰이는 상태 코드는 아래 표와 같다.

 

Status Code	의미
200	요청 성공
304	요청에 대한 응답이 수정되지 않음. 클라이언트에 캐시되어 있는 버전 사용
403	서버가 요청 거부. 사용자를 차단했거나, index.html이 없거나 권한이 없는 경우
404	찾는 리소스가 없음
500	내부 서버 오류. 설정, 퍼미션, 문법 문제일 경우가 많다.

 

• Headers

응답의 헤더는 요청과 동일한 구조를 갖는다. 역시 세 그룹으로 나눌 수 있다.

 

 

1. Response Headers - 위치, (서버의) 이름, 버전 등 응답에 대한 부가적 정보 표시
2. Representation(Entity) Headers - Body에 담긴 콘텐츠의 길이나 MIME 타입 등을 포함
3. General Headers - 요청과 응답 메시지 모두에서 쓰이지만 메시지에 적용되지는 않는 헤더. 현재 시간 등이 포함

 

• Body

 

요청과 마찬가지로 응답의 가장 마지막에 위치한다. 201, 204 등의 코드의 경우엔 생략 가능하다.

 

아래와 같이 두 종류로 나눌 수 있다.

 

• Single-Resource Bodies(단일-리소스 본문)
  
  
  • 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의
  • 길이를 모르는 단일-리소스 본문은 Transfer-Encoding이 Chunked로 설정되어 있으며, 파일은 Chunk로 나뉘어 인코딩
• Multiple-Resource Bodies(다중-리소스 본문) - 서로 다른 정보를 담고 있는 Body