HTTP 기본

HTTP(HyperText Transfer Protocol)

HTTP 메시지에 모든 것을 담아서 전송

- HTML, TEXT

- IMAGE, 음성, 영상, 파일

- JSON, XML (API)

- 거의 모든 형태의 데이터 전송 가능

- 서버 간에 데이터를 주고 받을 때도 대부분 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 사용, 성능 개선

 

기반 프로토콜

TCP: HTTP1.1, HTTP/2

UDP: HTTP/3

현재 HTTP/1.1 주로 사용

HTTP/2, HTTP/2도 점점 증가

 

HTTP 특징

1. 클라이언트 서버 구조
2. 무상태 프로토콜(스테이스리스), 비연결성
3. HTTP 메시지
4. 단순함, 확장 가능

---

1. 클라이언트 서버 구조

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

---

 

2. 무상태 프로토콜(스테이스리스)

: 서버가 클라이언트의 상태를 보존하지 않음

장점: 서버 확장성이 높음(스케일 아웃)

단점: 클라이언트가 추가 데이터 전송

 

Stateful, Stateless 차이

Stateful: 상태 유지

- 서버가 클라이언트의 이전 상태를 보존(문맥 보존)

- 중간에 서버가 바뀌면, 서비스 장애 발생 → 항상 같은 서버가 유지되어야 함

ex) 중간에 다른 점원으로 바뀌면 안됨(중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려야함)

- 문제점: 클라이언트는 한 서버와 계속 통신을 해야하는데, 중간에 해당 서버가 죽어버리면 클라이언트는 처음부터 다시 요청해야함 

 

Stateless: 무상태

- 클라이언트가 필요한 데이터를 그때그때 서버에게 전달하므로, 중간에 서버가 바뀌어도 아무 문제 없음 → 아무 서버나 호출해도 됨

- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입 가능

- 무상태는 응답 서버를 쉽게 바꿀 수 있음 → 무한한 서버 증설 가능

ex) 중간에 다른 점원으로 바뀌어도 됨(갑자기 고객이 증가해도 점원 대거 투입 가능)

- 중간에 서버가 장애가 발생해도, 클라이언트는 다른 서버로 요청할 수 있음

- 스케일 아웃: 수평 확장 유리

- 대용량 트래픽이 발생하는 경우 유용

- 문제점: 데이터를 너무 많이 보냄

무상태의 한계점

모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있음

무상태

ex) 로그인이 필요없는 단순한 서비스 소개 화면

상태 유지

 ex) 로그인

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지

일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지

상태 유지는 최소한만 사용

 

 

---

3. 비 연결성(connectionless)

TCP/IP는 연결을 유지함 

연결을 유지하는 모델의 경우

클라이언트1과 서버가 연결을 한 후 데이터를 주고 받음, 그 이후 클라이언트2와 서버가 연결을 한 후 데이터를 주고 받음(이때, 클라이언트1은 서버와 계속 연결을 유지함) → 이런 경우, 요청/응답을 주고 받지 않는 클라이언트와도 연결을 유지해야 하므로 서버 자원이 소모됨

 

연결을 유지하지 않는 모델의 경우

클라이언트1과 서버가 연결을 한 후 데이터를 주고 받은 후(요청, 응답) 연결을 끊어버림, 그 후 클라이언트2와 서버가 연결을 한후 데이터를 주고 받은 후 연결을 끊음(서로 필요한 것만 주고 받고 연결을 끊음) → 이러한 경우, 서버 입장에서는 자원을 현재 요청을 주고 받을 때만 연결을 하고 끊어버려서, 서버가 유지하는 자원을 최소한으로 줄임

단점: 데이터를 주고 받기 위해서는 연결을 유지하는 과정이 항상 있어야함

 

비 연결성

• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
  • ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
• 서버 자원을 매우 효율적으로 사용 가능

단점

TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가

웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드

지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결

HTTP/2, HTTP/3에서 더 많은 최적화

 

HTTP 지속 연결: 연결 후, 요청/응답이 끝날 때까지 연결 유지(내부 방식에 따라 다름-몇 초동안 유지 등등)

[초기 HTTP 동작 원리]

[HTTP 지속 연결 동작 원리]

---

HTTP 메시지

HTTP 요청 메시지와 HTTP 응답 메시지의 구조는 다름

HTTP 메시지 구조

- 공백 라인은 무조건 있어야 함

HTTP 요청 메시지

요청 메시지도 body 본문을 가질 수 있음

HTTP 응답 메시지

 

1) 시작 라인

요청 메시지

start-line=request-line/status-line

request-line=method SP(공백) request-target SP HTTP-version CRLF(엔터)

• ⭐️ HTTP 메서드(GET: 조회)
  • 종류: GET, POST, PUT, DELETE
  • 서버가 수행해야 할 동작 지정
  •   GET: 리소스 조회
  •   POST: 요청 내역 처리
• 요청 대상(/search?q=hello&hl=ko)
  • absolute-path[?query] (절대경로[?쿼리])
  • 절대경로="/"로 시작하는 경로
• HTTP Version

응답 메시지

start-line=request-line/status-line

status-line = HTTP-version SP status-code SP reason-phrase CRLF

• HTTP 버전
• HTTP 상태 코드: 요청 성공, 실패를 나타냄
  • 200: 성공
  • 400: 클라이언트 요청 오류
  • 500: 서버 내부 오류
• 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글

 

2) HTTP 헤더

header-field = field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용)

field-name은 대소문자 구문 없음

<용도>

• HTTP 전송에 필요한 모든 부가 정보 포함
  • ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저)정보, 서버 애플리케이션 정보, 캐시 관리 정보...
• 표준 헤더가 너무 많음
• 필요시 임의의 헤더 추가 가능

 

3) HTTP 메시지 바디

<용도>

• 실제 전송할 데이터
• HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능