1. 모든 것이 HTTP
HTTP(HyperText Transfer Protocol)
HyperText: 링크로 문서를 연결할 수 있는 HTML
HTTP: HyperText를 전송하는 프로토콜
HTTP 메시지에 모든 것을 전송할 수 있다.
ex. HTML, TEXT, IMAGE, 음성, 영상, 파일, {API: JSON, XML}
거의 모든 형태의 데이터를 전송 가능하며, 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
HTTP 역사
- HTTP/0.9 (1991년): GET 메서드만 지원, HTTP 헤더 없음
- HTTP/1.0 (1996년): 메서드와 헤더 추가됨
- HTTP/1.1 (1997년): 가장 많이 사용, 우리에게 가장 중요한 버전
- 대부분의 기능이 들어 있음
- 이걸 기반으로 성능을 개선한 게 2, 3버전
- 두 차례에 걸쳐 개선 (1999년, 2014년)
- HTTP/2 (2015년): 성능 개선
- HTTP/3 (ing): TCP 대신 UDP 사용, 성능 개선
기반 프로토콜
TCP를 직접 연결하는 경우는 게임 서버 등 복잡한 실시간 환경에서만 사용하는 경우가 많다.
TCP: HTTP/1.1, HTTP/2
- 느리고 복잡함
UDP: HTTP/3
- 빠르고 단순함
지금은 HTTP/1.1을 주로 사용하지만, HTTP/2와 HTTP/3도 점점 증가하는 추세이다. (개발자 모드에서 확인 가능)
2. 클라이언트 서버 구조
Request-Response 구조
클라이언트: 서버에 요청을 보내고 응답을 대기함
서버: 들어온 요청에 대한 결과를 만들어 응답
클라이언트와 서버를 개념적으로 분리하는 것이 중요하다.
비즈니스 로직과 데이터는 서버가 맡고, 클라이언트는 UI와 UX 등에 집중하게 해야 한다.
이렇게 하면 서버와 클라이언트가 독립적으로 진화할 수 있다.
3. Stateful, Stateless
상태 유지 프로토콜 - Stateful
서버가 클라이언트의 이전 상태를 보존함
a. 장점
클라이언트가 추가 데이터를 전송하지 않아도 됨
b. 한계
서버가 바뀔 때마다 정보가 날아가기 때문에 오류가 생길 수 있음
서버를 교체한다면 정보를 넘겨줘야 함 -> 복잡하고 어려운 경우가 많음
무상태 프로토콜 - Stateless
서버가 클라이언트의 이전 상태를 보존하지 않음
a. 장점
클라이언트가 서버에 필요한 정보를 모두 제공하기 때문에 서버 확장성이 높고, 수평 확장이 유리함 (scale out)
응답 서버를 쉽게 바꿀 수 있기 때문에 무한으로 서버 증설이 가능함
따라서 클라이언트 요청이 증가하거나 서버에 장애가 생기더라도 서버를 대거 투입 가능함
b. 한계
클라이언트가 추가 데이터를 전송해야 함
- 서버에 필요한 모든 데이터를 전송해야 응답 받을 수 있음
모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있음
- 무상태: ex. 로그인이 필요 없는 단순 서비스 소개 화면
- 상태 유지: ex. 로그인
- 로그인 사용자의 경우 로그인 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해 상태를 유지함
- 상태 유지는 장애가 날 확률이 높기 때문에 최소한만 사용해야 함
c. 서버 개발자들이 어려워하는 임무
같은 시간에 딱 맞춰 발생하는 대용량 트래픽의 경우
- ex. 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
- ex. 저녁 6시 선착순 100명 치킨 할인 이벤트
Stateless 상태를 유지해야 수 만명이 동시에 요청하더라도 서버를 무한히 늘려 대처할 수 있음
- 이벤트 신청 전 정적 HTML 화면을 만들어 사람들이 최대한 동시에 요청하지 않도록 하기도 함
4. 비 연결성(connectionless)
연결을 유지하는 모델과 유지하지 않는 모델
a. 연결을 유지하는 모델(연결성)
서버는 연결을 계속 유지하고, 요청이 없더라도 서버 자원을 계속 소모하게 됨
b. 연결을 유지하지 않는 모델(비 연결성)
서버는 연결을 유지하지 않고, 요청에 응답을 한 뒤 연결을 종료함
- 따라서 최소한의 자원을 유지할 수 있음
비 연결성의 특징 및 한계
a. 특징
HTTP는 기본적으로 Non-Persistent(비 연결성)
- 보통 초 단위 이하의 빠른 속도로 응답하기 때문에 1시간 동안 수 천명이 서비스를 사용하더라도 실제 서버에서 동시에 처리하는 요청은 수 십개 이하로 매우 적음
- 따라서 이 특징 덕분에 서버 자원을 매우 효율적으로 사용할 수 있음
b. 한계와 극복
TCP/IP 연결을 매번 새로 맺어야 함
- 3-way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드 됨
- 자원마다 연결 및 종료 진행
HTTP 지속 연결(Persistent Connections)로 문제 해결
- HTTP/2와 HTTP/3에서 더 많은 최적화가 진행 중임
- 요청이 끝날 때까지 연결을 유지함
5. HTTP 메시지
HTTP 메시지 구조
시작 라인, 헤더, 공백 라인(CRLF), message body로 이루어지며, 요청 메시와 응답 메시지로 나눌 수 있음
HTTP 요청 메시지 - 시작 라인
start-line == request-line / status-line
request-line = method SP(공백) request-target SP HTTP-version CRLF(줄바꿈)
a. 시작 라인 - HTTP 메서드
서버가 수행해야 할 동작을 지정
- GET: 리소스 조회
- POST: 요청 내역(생성 등) 처리
- PUT: 요청 내역(수정 등) 처리
- DELETE: 리소스 삭제
b. 시작 라인 - 요청 대상
절대경로[?query]: "/"로 시작하는 경로
참고: *, http://...?x=y 와 같이 다른 유형의 경로 지정 방법도 있음
c. 시작 라인 - HTTP 버전
보통은 HTTP/1.1을 사용함
HTTP 응답 메시지 - 시작 라인
start-line == request-line / status-line
status-line = HTTP-version SP(공백) status-code SP reason-phrase CRLF(줄바꿈)
a. 시작 라인 - HTTP 버전
보통은 HTTP/1.1을 사용함
b. 시작 라인 - HTTP 상태 코드
요청 성공 또는 실패를 나타냄
- 200: 성공
- 300: 리다이렉트
- 400: 클라이언트 오류
- 500: 서버 내부 오류
c. 시작 라인 - 이유 문구
사람이 이해할 수 있는 짧은 상태 코드 설명 글
ex. 200 OK, 404 Not Found
HTTP 헤더
a. 헤더 형식
header-field == field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용)
field-name은 대소문자 구분 없음
ex. HTTP 요청 메시지의 Host: www.google.com
ex. HTTP 응답 메시지의 Content-Type: text/html;charset=UTF-8, Content-Length: 3423
b. 헤더 용도
HTTP 전송에 필요한 모든 부가 정보가 담김
ex. 메시지 바디 내용, 크기, 압축, 인증 정보, 요청 클라이언트의 브라우저 정보, 캐시 관리 정보, 서버 애플리케이션 정보
표준 헤더가 정말 많음 -> 뒷 섹션에서 정리
필요시 임의의 헤더 추가 가능
- 약속한 클라이언트와 서버 끼리만 이해할 수 있음
HTTP 메시지 바디
실제 전송할 데이터로, HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터를 전송 가능함
HTTP 정리
표준 기술로, 단순하며 확장 가능함
- HTTP도, HTTP 메시지도 단순하고 확장하기 쉬움
