[HTTP] 3. HTTP 기본
모든 개발자를 위한 HTTP 웹 기본 지식 (김영한) 강의 수강 후 정리한 자료입니다.
❗모든 것이 HTTP 시대, HTTP에 대해 알아보자❗
✨ HTTP
정의
: HyperText Transfer Protocol
- HTML, Text, API, 영상 등 모든 것을 주고 받을 때 HTTP를 사용한다.
- 현재는 HTTP/1.1 버전을 가장 많이 사용하고 있다.
- HTTP/1.1과 HTTP/2는 TCP 기반, HTTP/3은 UDP 기반 프로토콜 사용
특징
- 클라이언트 서버 구조
- 무상태 프로토콜(stateless), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
특징을 조금 더 살펴보자
✨ 클라이언트 서버 구조
- Request Respose 구조라고도 함.
- 클라이언트는 서버에 요청을 보내고, 응답을 대기
- 서버가 요청에 대한 결과를 만들어서 응답
- 클라이언트와 서버를 분리하는 것이 중요함.
-> 분리함으로써 자신의 역할에 집중하게 됨.
✨ 무상태 프로토콜 (Stateless)
- 서버가 클라이언트의 상태를 보존하지 않는다.
- 장점 : 서버 확장성 높음 (스케일 아웃)
- 단점 : 클라이언트가 추가 데이터를 전송 해야 함.
Stateful과 Stateless
- Stateful은 현재 상태를 저장하는 반면, Stateless는 현재 상태를 모름. 즉, 초기화된다고 생각하면 쉬움.
ex) 노트북을 사고 싶은 경우, 노트북 구매하겠습니다. -> 2개 구매할게요.
-
Stateful인 경우 노트북이라는 상태를 유지하고 추가로 2개를 구매한다고 이해. 즉, 상태가 유지되며 기존 상태에 새로운 상태를 추가하는 것.
-
Stateless인 경우 상태를 유지하지 않으므로 무엇이 2개인지 모름. 즉, 요청을 보낼 때 노트북 2개 구매하겠습니다. 라고 처음부터 다시 보내야 함.
=> 노트북 구매 시 점원이 바뀌어 다시 처음부터 설명해야 하는 것과 같은 이치.
Stateless 장점
무상태가 서버 확장성이 높은 이유는, 서버가 하나의 클라이언트만 잡고 있지 않기 때문이다.
상태를 유지하는 경우, 하나의 서버가 하나의 클라이언트를 관리해야하기 때문에 클라이언트가 갑작스럽게 증가하면 서버 입장에서 확장이 어렵다.
반면, 무상태의 경우 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있어 확장성이 높은 것이다. 또한, 응답 서버를 쉽게 바꿀 수 있어 무한한 서버 증설이 가능하다.
심지어 stateful에서 서버 장애가 나면 다시 처음부터 요청을 보내야 한다는 단점이 있다.
Stateless 단점
그러나 상태를 유지해야 하는 경우 대응이 느리다.
ex) 로그인
따라서 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지하기 위해 브라우저 쿠키와 서버 세션 등을 이용해 상태를 유지하는 방식으로 설계한다.
어쨌든 상태 유지는 최소한만 사용.
또한, 데이터를 너무 많이 보내야 한다는 단점이 있다.
✨ 비 연결성 (connectionless)
비 연결성 모델의 필요성
연결을 유지하는 모델과 연결을 유지하지 않는 모델이 있다.
TCP/IP 같은 경우에는 기본적으로 연결을 유지함.
그러나 서버는 연결을 계속 유지함으로써 서버 자원이 소모되는 단점이 있다. (놀고 있는 서버가 생길 수도 있음)
서버는 연결 유지 X, 요청과 응답이 끝나면 연결을 끊음. 이렇게 함으로써 최소한의 자원을 유지시킬 수 있다.
비 연결성
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위 이하의 빠른 속도로 응답
장점
1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작음
-> 왜? 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않으므로 연결을 유지하지 않고 있기 때문이다.
그렇기에 서버 자원을 매우 효율적으로 사용할 수 있다.
한계
- TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML + JS + CSS + 이미지 등 수많은 자원을 다시 다운 받아야 한다
극복
- HTTP 지속 연결 (Persistent Connections)로 문제 해결
- HTTP/2, HTTP/3에서 더 많은 최적화가 이루어지고 있음
✨ HTTP 메시지
구조
- 요청라인 or 상태라인은 시작 라인으로도 불림
- Blank Line (or empty Line, CRLF) : 헤더의 끝을 빈 줄로 식별하므로 무조건 있어야 함.
-> cf) CRLF: 줄바꿈 문자(“\n”)를 지칭하는 단어. EOF라고도 부른다. - 요청 메시지도 body 본문을 가질 수 있음.
- HTTP 요청 메시지의 경우 HTTP 메서드 (GET, POST 등)으로 시작하는 반면, HTTP 응답 메시지는 HTTP 버전과 상태 코드로 시작한다.
Start Line는 크게 request-line과 Status-Line으로 분류된다.
Start Line - 요청 메시지
start line = request-line / status-line
request-line = [method] SP(공백) [request-target(path)] SP [HTTP-version] CRLF(엔터)
-
여기서 Method란 HTTP 메서드로, 서버가 수행해야 할 동작을 지정한다.
-> ex) GET, POST, PUT, DELETE … -
Path는 “절대 경로”로 들어감.
Start line - 응답 메시지
start line = request-line / status-line
status line = [HTTP-version] SP [status-code] SP [reason-phrase] CRLF
- HTTP 상태 코드 : 요청 성공, 실패를 나타냄 (200, 400, 500 …)
- reason-phrase : 사람이 이해할 수 있는 짧은 상태 코드 설명 글 (200 OK에서 OK를 나타냄)
HTTP 헤더
- header-feild = field-name “:” OWS fild-value OWS
OWS : 띄어쓰기 허용
용도
- HTTP 전송에 필요한 모든 부가 정보를 담고 있음
ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증 등 - 표준 헤더가 너무 많음
- 필요 시 임의의 헤더 추가 가능
HTTP 메시지 바디
용도
- 실제 전송할 데이터
- HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능