네트워크 심화 3. HTTP

HanSungUk·2022년 7월 13일

TIL 네트워크

HTTP / 네트워크

목록 보기

8/9

네트워크 심화 3. HTTP

현재 코드스테이츠 강의를 통해 프론트엔드를 학습하고 있습니다.
본 포스트는 해당 강의에 대한 내용 정리를 목적으로 합니다.

학습목표

HTTP 메세지 구조를 이해한다.
HTTP의 무상태성과 비연결성에 대해 이해한다.
HTTP 헤더 중 바디를 설명하는 헤더인 표현헤더에 대해 이해한다.
HTTP 헤더 중 요청과 응답에서 주로 사용되는 헤더에 대해 이해한다.
HTTP 헤더 중 서버에 요청하는 컨텐츠를 협상할 수 있는 협상 헤더에 대해 이해한다.

1. HTTP의 특징

HTTP/1.1, HTTP/2는 TCP 기반이며 HTTP/3는 UDP 기반 프로토콜입니다.

클라이언트 서버 구조
- Request Response 구조
- 클라이언트는 서버에 요청을 보내고, 응답을 대기
- 서버가 요청에 대한 결과를 만들어 응답
무상태 프로토콜 - Stateless
- 서버가 클라이언트의 상태를 보존하지 않음
- 장점 : 서버 확장성 높음(스케일 아웃)
- 단점 : 클라이언트가 추가 데이터 전송
  만약 위의 예제처럼 상태 유지가 되어야 하는 프로토콜이라면 클라이언트 A의 요청을 서버 1이 기억하고 있기 때문에 항상 서버 1이 응답해야합니다.
  하지만 서버 1이 장애가 난다면 유지되면 상태 정보가 다 날아가 버리므로 처음부터 다시 서버에 요청해야 합니다.
  무상태 프로토콜이라면 클라이언트 A가 요청할 때 이미 필요한 데이터를 다 담아서 보내기 때문에 아무 서버나 호출해도 됩니다.
  만약 서버 1에 장애가 생기더라도 다른 서버에서 응답을 전달하면 되기 때문에 클라이언트는 다시 요청할 필요가 없습니다.
  또한 무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능합니다.

무상태는 다음과 같은 한계를 가지고 있습니다.
로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만
로그인이 필요한 서비스라면 유저의 상태를 유지해야되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지합니다.

비연결성(Connectionless)

TCP/IP의 경우 기본적으로 연결을 유지합니다.
연결을 유지하는 모델에서는 클라이언트 1,2는 요청을 보내지 않더라고 계속 연결을 유지해야 합니다. 이러한 경우 서버의 자원이 계속 소모됩니다.

비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊습니다. 이를 통해 최소한의 자원으로 서버 유지를 가능하게 합니다.

위 비연결성의 특징을 정리하면 다음과 같습니다.

HTTP 1.0기준으로 HTTP는 연결을 유지하지 않는 모델입니다.
일반적으로 초 단위 이하의 빠른 속도로 응답합니다.
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작습니다.

또한 비연결성은 다음과 같은 한계를 지닙니다.

TCP/IP 연결을 새로 맺어야 하기 때문에 3 way handshake 시간이 추가됩니다.
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드 됩니다.
현재는 HTTP 지속 연결(Persistent Connections)로 문제를 해결하고 있습니다.

2. HTTP Headers의 종류와 특징

2.1 표현 헤더(Representation Headers)

HTTP 메시지는 헤더와 바디로 구분할 수 있습니다.
데이터 메시지 본문(Message body)을 통해서 표현(Representation)데이터를 전달합니다.
여기서 데이터를 실어 나르는 부분을 페이로드(Payload)라고 합니다.
표현은 요청이나 응답에서 전달할 실제 데이터를 뜻하며, 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공합니다.

HTTP 헤더는 다음과 같은 형식을 따르고 HTTP 전송에 필요한 모든 부가 정보를 담기 위해 사용합니다.

Content-Type: 표현 데이터의 형식
Content-Encoding: 표현 데이터의 압축 방식
Content-Language: 표현 데이터의 자연 언어
Content-Length: 표현 데이터의 길이

Transfer-Encoding은 전송 시 어떤 인코딩 방법을 사용할 것인가를 명시합니다.
그러나 현재는 Transfer-Encoding보다는 Content-Encoding을 사용하며, Transfer-Encoding을 사용하는 경우 chunked의 방식으로 사용합니다.

chunked 방식의 인코딩은 많은 양의 데이터를 분할하여 보내기 때문에 전체 데이터의 크기를 알 수 없습니다.

2.2 HTTP 요청/응답 주요 헤더

2.2.1 요청(Request)에서 사용되는 헤더

From: 유저 에이전트의 이메일 정보
- 일반적으로 잘 사용하지 않음
- 검색 엔진에서 주로 사용
- 요청에서 사용
Referer: 이전 웹 페이지 주소
- 현재 요청된 페이지의 이전 웹 페이지 주소
- A -> B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
- Referer를 사용하면 유입경로 수집 가능
- 요청에서 사용
- referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐
User-Agent: 유저 에이전트 애플리케이션 정보
- 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
- 통계 정보
- 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
- 요청에서 사용
- 예시) user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/
  537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
Host: 요청한 호스트 정보(도메인)
- 요청에서 사용
- 필수 헤더
- 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
- 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
- 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
- 응답 헤더의 Access-Control-Allow-Origin와 관련
Authorization: 인증 토큰을 서버로 보낼 때 사용하는 헤더
- "토큰의 종류 + 실제 토큰 문자"를 전송
- 예시) Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

2.2.2 응답(Response)에서 사용되는 헤더

Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- 응답에서 사용
- 예시)
  Server: Apache/2.2.22 (Debian)
  Server: nginx
Date: 메시지가 발생한 날짜와 시간
- 응답에서 사용
- 예시)
  Date: Tue, 15 Nov 1994 08:12:31 GMT
Location: 페이지 리디렉션
- 웹 브라우저는 3xx 응답의 결과에 Location헤더가 있으면, Location위치로 리다이렉트(자동 이동)
- 201(Created): Location값은 요청에 의해 생성된 리소스 URI
- 3xx(Redirection): Location값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
Allow: 허용 가능한 HTTP 메서드
- 405(Method Not Allowed)에서 응답에 포함
- 예시)
  Allow: GET, HEAD, PUT
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
- 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
- 예시)
  Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
  Retry-After: 120(초 단위 표기)