Network
[Network] HTTP 기본
mxruhxn
2024. 10. 10. 22:29
728x90
반응형
HTTP란?
: hypertext transfer protocol의 약자로, HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜로 시작하였으나, 현재는 모든 형태의 데이터를 전송하는 프로토콜로 사용 중
HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 서버 간 통신 시에도 대부분 http 프로토콜로 연결한다.
HTTP 역사
- HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
- HTTP/1.0 1996년: 메서드, 헤더 추가
- HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
- RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014) HTTP/2 2015년: 성능 개선
- 멀티플렉싱(한 번의 연결로 여러 요청을 동시에 처리하는 기능)
- 헤더 압축 기능
- 등등..
- HTTP/3 진행중: 기존의 TCP 대신 UDP 기반의
QUIC
프로토콜을 사용, 성능 개선
위 버전중에 가장 중요한 HTTP는 1997년에 나온 HTTP/1.1
HTTP/1.1 버전에 우리가 사용하는 거의 모든 HTTP 기능이 들어있으며, 이후에 나온 버전들은 거의 개선에 초점
HTTP 특징
- 클라이언트 - 서버 구조
- Request - Response 구조
- 클라이언트는 서버에 요청을 보내고, 응답을 대기
- 서버는 요청에 대한 결과를 만들어 클라이언트에게 반환
- 비즈니스 로직과 데이터 로직은 서버에, 클라이언트는 UI에 집중 => 역할 분리
- 무상태 프로토콜
- HTTP는 상태를 저장하지 않는다(
Stateless
) - 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없다
- 상태를 유지하지 않기 때문에 의존성이 없고, 확장성은 높아진다 -> 스케일 아웃이 용이하여 부하 분산 가능
- 상태를 유지해야 하는 경우, 항상 같은 서버를 호출해야 하고, 서버에 장애가 발생한다면 큰 문제가 발생한다. -> 스케일 아웃이 어렵다
- 상태가 필요한 경우, 쿠키, 세션, JWT 같은 기술을 활용할 수 있다.
- HTTP는 상태를 저장하지 않는다(
- 비 연결성(connectionless)
- 연결은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖이다. 신뢰할 수 있거나 메시지 손실이 없는 연결이 필요한데, 이에 가장 적합한 방식이 TCP 프로토콜이므로, HTTP는 TCP 표준에 의존한다.
- 기본적으로 연결을 유지해야하는 TCP/IP와는 반대의 개념
- TCP/IP의 경우, 서버 연결이 계속 유지되므로 서버 자원이 소모된다는 단점
- HTTP는 서버 연결을 유지 하지 않아도 되어, 최소한의 자원을 유지할 수 있다는 장점
- 한번 서버에 요청을 하더라고, 그 이후에 연결을 유지하지 않기 때문에 서버 자원을 효율적으로 사용할 수 있다.
- 하지만, 단점은 매 요청마다 TCP 연결을 위해 3 way handshake가 발생하여 서버의 자원과 시간(3 way handshake 시간)이 낭비
- 또한, 웹 브라우저 요청 시 HTML 하나만 받아오는게 아니라, 자바스크립트, css, 이미지등 수많은 파일들을 불러오는데, 연결이 되지 않는다면 파일 하나하나당 매번 요청을 보내야한다는 불편함이 있다.
- 이를 개선하기 위해 HTTP/1.0 버전 부터 Keep-Alive 라는 기능을 이용해 지속 연결(Persistent Connection) 방식을 도입하여, 클라이언트 간 연결을 유지하면서 더 효율적으로 처리하게 됨
- HTTP 메세지
- 시작 라인(start-line)
- 요청 메세지: request-line이라고 불린다.
- 구조:
method request-target HTTP-version CRLF(엔터)
- 구조:
- 응답 메세지: status-line이라고 불린다.
- 구조:
HTTP-version status-code reason-phrase CRLF
- 구조:
- 요청 메세지: request-line이라고 불린다.
- 헤더 (header)
- HTTP 전송에 필요한 모든 부가 정보를 담기 위한 부분
- name:value 형태이고, 필드 이름은 대소문자 구분 없음
- 메세지의 바디 내용 크기, 압축, 인증, 요청 클라이언트 정보, 서버 정보, 캐시 관리 등 여러 부가 정보가 들어감
- 표준 헤더 종류는 굉장히 많고, 임의로 헤더를 추가해서 보낼 수 있음
- 공백 라인(CRLF, empty line)
- 바디 (message body)
- 실제 전송할 데이터를 담고있다
- 예를 들어, HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터가 바디가 될 수 있다.
- 시작 라인(start-line)
HTTP Keep-Alive
- Keep-Alive란?
- persistent connection을 맺는 기법 중 하나로, HTTP/1.0+부터 지원.
- 하나의 TCP connection을 활용해서 여러 개의 HTTP request/response를 주고받을 수 있도록 해줌
- keep-alive 옵션은 설계상 여러 문제점(e.g. proxy 문제)이 생기면서 HTTP/1.1 부터는 사용되고 있지 않지만 여전히 많은 웹 애플리케이션에서 사용하고 있음
- Keep-Alive 옵션
max(MaxKeepAliveRequest)
: keep-alive connection을 통해서 주고받을 수 있는 request의 최대 갯수. 이 수보다 더 많은 요청을 주고받을 경우 connection은 closetimeout(KeepAliveTimeout)
: 커넥션이 idle한 채로 얼마동안 유지될 것인가를 의미. 이 시간이 지날 동안 request가 없을 경우에 connection은 close
- 여전히 많이 쓰이고는 있지만, HTTP/2와 HTTP/3에서는 이를 대신해 더 발전된 연결 관리 기법(특히 HTTP/2의 멀티플렉싱)이 도입되었음
728x90
반응형