HTTP
모든 것이 HTTP
HTTP 메시지에 모든 것을 전송할 수 있다.
- HTML, Text
- Image, 음성, 영상, 파일
- JSON, XML(API)
- 거의 모든 형태의 데이터 전송 가능
- 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용
HTTP 역사
- HTTP/0.9 1991년
- 초기버전
- HTML 문서를 전송하는 용도로 사용.
GET메서드만 지원- HTTP 헤더 없었음.
- HTTP/1.0 1996년
- 다양한 요청 메서드와 상태 코드 지원
- HTTP 헤더 추가됨.
- 클라이언트-서버간 복잡한 통신 가능
- TCP/IP 방식 적용으로 연결 지연, 오버헤드 발생
- HTTP/1.1 1997년: 가장 많이 사용, 가장 중요한 버전
- 지속적 연결(Persistent Connection) 추가
- Keep-Alive 기능 추가
- 파이프라이닝(Pipelining) 기능으로 한번에 여러 개의 요청을 보내 성능이 향상
- 캐싱, 압축, 인증, 프록시 등 다양한 기능 추가
- RFC2068(1997) ➡️ RFC2616(1999) ➡️ RFC7230~7235(2014)
- HTTP/2.0 2015년: 성능 개선 위주로 업그레이드된 버전
- HTTP/3.0 진행중:
- TCP 대신 UDP 프로토콜 사용하는 QUIC(Quick UDP Internet Connection) 프로토콜 사용
- 성능 개선 위주로 업그레이드
기반 프로토콜
TCP: HTTP/1.1, HTTP/2.0
UDP: HTTP/3.0
현재 HTTP/1.1 주로 사용, HTTP/2.0, HTTP/3.0 점점 증가
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
클라이언트 서버 구조
- Request Response 구조
- 클라이언트는 서버에 요청을 보내고 응답을 대기함.
- 서버가 요청에 대한 결과를 만들어서 응답
Stateful & Stateless
상태 유지 Stateful 방식
- 클라이언트, 서버간 연결을 유지하고 서버는 클라이언트의 상태를 가지고 있음.
- 서버는 클라이언트의 상태를 알기 때문에 클라이언트는 요청시 필요한 데이터만 전송하고 서버는 유지 중인 상태 정보를 바탕으로 응답을 생성
- 상태 정보는 쿠키나 세션 등의 방식으로 유지, 쿠키는 클라이언트에서 상태정보를 유지하는 방식이고 세션은 서버에서 상태 정보를 유지하는 방식임.
- 중간에 요청이 다른 서버로 유입되면 오류가 난다.
- 중간에 바뀔 경우 상태 정보를 다른 서버에 미리 알려줘야함.
- 서버 A와 일련의 트랜잭션을 수행하는 도중 A 서버가 다운될 경우 그간 통신했던 모든 상태값이 날아가며 클라이언트는 지금까지 진행한 트랜잭션을 처음부터 다시 해야함.
- 웹 사이트에서 로그인 상태, 장바구니 정보 등을 관리할 때 사용.
- 상태 유지는 최소한만 사용하는 게 좋음.
토큰을 사용하는 OAuth, JWT
쿠키와 세션의 문제점들을 보완하기 위해 토큰( Token )기반의 인증 방식이 도입,
토큰 기반의 인증 방식의 핵심은 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술.
중간에 공격자로부터 토큰이 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로, 보안성을 높은 기술이라 할 수 있다.
무상태 Stateless
- 서버, 클라이언트 간 연결을 유지하지 않고 요청, 응답시 필요한 정보를 모두 전송.
- REST API에서 주로 사용되며 각각의 요청들은 독립적이고 서버는 클라이언트의 상태 정보를 유지하지 않음.
- 서버 확장성 높음 (Scale out), 수평 확장 유리.
- 중간에 요청이 다른 서버로 유입되어도 아무런 문제가 없다.
- 응답 서버를 쉽게 바꿀 수 있다.
- 어떤 서버든 요청 트랜잭션 핸들링 가능, 무한 서버 증설이 가능하다.
- 로그인이 필요없는 단순한 서비스 소개 화면 (선착순 이벤트 등)
- 클라이언트가 추가 데이터를 전송해야함.
- Stateful 프로토콜에 비해 클라이언트에서 서버로 보내는 데이터 양이 많다.
- 클라이언트에서 상태 정보를 유지하므로 보안 문제, 상태 정보의 일관성에 대한 문제가 발생할 수 있음.
무상태 프로토콜 Stateless - 실무에서의 한계
모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
비연결성 Connectionless
연결성 모델(Connection Oriented)
TCP/IP의 경우 기본적으로 연결을 유지한다. 클라이언트는 요청을 보내지 않아도 계속 연결을 유지해야함. 이런 경우 연결을 유지하는 서버의 자원이 계속 소모가 된다.
비연결성 모델(Connectionless)
클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어버리는 성질을 말함. 최소한의 자원으로 서버 유지를 가능하게 함.
장점
HTTP1.0기준으로 HTTP는 기본적으로 연결을 유지하지 않는 모델이다.
비연결성 모델은 트래픽이 많지 않고 빠른 응답을 제공할 수 있는 경우 효율적으로 작동한다.
서버 자원을 매우 효율적으로 사용할 수 있음.
일반적으로 초 단위 이하의 빠른 속도로 응답한다. (1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 적음.)
단점
서버는 클라이언트를 기억하고있지 않으므로 동일한 클라이언트의 모든 요청에 대해, 매번 새로운 연결을 시도/해제의 과정을 거쳐야하므로 연결/해제에 대한 오버헤드가 발생한다.
웹 브라우저로 사이트 요청하면 JS, CSS, 추가 이미지 등 수많은 자원이 함께 다운로드 됨.
TCP/IP 연결을 새로 맺어야 함으로 3 way handshake 시간이 추가된다.
HTTP/2.0, HTTP/3.0에서 더 많은 최적화.
트래픽이 많고 큰 규모의 서비스를 운영할 때에는 비연결성은 한계가 있음.
➡️ HTTP/1.1 버전부터 Keep-Alive 기능을 이용해 지속 연결(Persistent Connection) 방식으로 여러 개의 요청, 응답을 서버, 클라이언트간 연결을 유지하면서 처리하게 됨.
HTTP 메시지
시작 라인
요청 메시지
- start-line = request-line / status-line
- request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
- HTTPS 메서드 (Get: 조회)
- 요청 대상 (/search?q=hello&hl=ko)
- HTTP Version
HTTP 메서드
- 종류:
GET,POST,PUT,DELETE... - 서버가 수행해야할 동작을 지정.
GET: 리소스 조회POST: 요청 내역 처리
요청 대상
absolute-path[?query](절대경로[?쿼리])- 절대 경로 = "/"로 시작하는 경로
- 참고:
*,http://...?x=y와 같이 다른 유형의 경로 지정 방법도 있다.
HTTP Version
응답 메시지
- start-line = request-line / status-line
- status-line = HTTP-version SP status-code SP reason-phrase CRLF
- HTTP 버전
- HTTP 상태 코드 : 요청 성공, 실패를 나타냄
- 200: 성공
- 400: 클라이언트 요청 오류
- 500: 서버 내부 오류
- 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글
HTTP Header
header-field = field-name ":" OWS field-value OWS(OWS: 띄어쓰기 허용)- `field name₩은 대소문자 구분 없음.
- HTTP 전송에 필요한 모든 부가정보
- EX) 메시지 바디의 내용, 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시 관리 정보
- 표준 헤더 리스트가 너무 많으며 필요시 임의의 헤더를 추가할 수 있다.
HTTP Body
- 실제로 전송할 데이터
- HTML 문서, 이미지, 영상, JSON 등 Byte로 표현할 수 있는 모든 데이터 전송 가능
단순함, 확장 가능성
- HTTP는 단순하다.
- 메시지도 매우 단순한 편.
- 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술이다.
