HTTP 기본

모든 것이 HTTP다

HTTP: HyperText Transfer Protocol

 

그러나, 지금은 HTML 뿐만 아니라 TEXT, IMAGE, 영상, 파일 등

거의 모든 형태의 데이터를 HTTP로 전송한다

서버 간에 데이터를 주고 받을 때(API)도 대부분 HTTP를 사용한다 - JSON, XML

 

HTTP 메시지에 모든 것을 전송하는, 지금은 HTTP의 시대다.

 

HTTP 버전

HTTP/0.9 : GET 메서드만 지원, HTTP 헤더X

HTTP/1.0 : 메서드, 헤더 추가

HTTP/1.1 : 주로 사용. 대부분의 기능이 들어 있음.

HTTP/2 : 성능 개선

HTTP/3 : 성능 개선, TCP 대신에 UDP 사용(UDP 프로토콜 위에 애플리케이션 레벨에서 성능 최적화하여 새로 설계)

 

---

 

왜 이렇게 HTTP가 널리 쓰이게 됐을까?

HTTP 특징

1. 클라이언트 서버 구조
2. 무상태 프로토콜(Stateless), 비연결성(connectionless) -> 서버의 증식 및 효율적 사용
3. HTTP 메세지        
4. 단순함, 확장 가능

이러한 특징이 어떠한 장점을 갖는지 알아보겠다.

 

1. 클라이언트와 서버 구조

Request Response 구조.

요청을 보내고 응답을 기다린다

장점: 클라이언트와 서버, 양쪽이 독립적으로 진화할 수 있다.

예를 들어 더 많은 트래픽을 소화하려면 서버만 손보면 된다.

 

---

 

2. HTTP는 Stateless 프로토콜

서버가 클라이언트의 상태를 보존하지 않는다.

 

Q. Stateless한 성격의 장단점이 무엇일까?

장점: 서버 확장성이 높다(Scale out)

단점: 클라이언트가 데이터를 추가로 더 전송해야 한다.

 

Stateful, Stateless의 차이

• Stateful : 상태 유지
  서버가 클라이언트의 이전 상태를 보존 
  진행해오던 작업의 맥락 정보를 보낼 필요가 없어 클라이언트의 데이터 전송량이 줄어든다.
  따라서 항상 같은 서버가 유지되어야 한다.
  
  

  

  단점: 서버1이 장애가 나면 처음부터 다시 진행해야한다.

  
  
• Stateless: 상태 유지 x
  상태를 유지하지 않으므로 서버가 바뀌어도 된다
  그래서 갑자기 클라이언트 요청이 증가하면 서버를 대거 투입할 수 있다.
  
  아무 서버나 호출해도 된다. 필요한 정보, 맥락을 클라이언트가 전부 보내기 때문이다.
  단점은 데이터를 너무 많이 보내야 한다는 것.
  

  

  클라이언트는 맥락 정보를 다 보낸다. 중간에 서버1이 장애가 나면 다른 서버가 응답하면 된다.

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

 

그러나 모든 것을 Stateless로 설계할 수 있는 건 아니다

로그인이 필요 없는 단순한 서비스 소개 화면 등은 stateless로 가능하다.

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

이런 경우엔 stateful하게 설계해야 한다

(보통 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지)

stateful은 최소한만 사용하자

 

---

 

3. HTTP는 연결을 유지하지 않는 모델(connectionless)

기본적으로 HTTP는 연결을 유지하지 않는 비연결성 모델이다.

Q. 왜 그렇게 만들었을까?

서버의 자원을 효율적으로 사용하기 위함.

※ 연결/종료를 너무 자주하는 문제가 있을 수 있어 Persistent Connections로 문제 해결.

 

연결을 유지하는 경우와 유지하지 않는 경우를 비교해보자

• 연결을 유지하는 모델의 경우
  연결을 유지하는데 서버의 자원이 낭비된다

만약 클라이언트가 수만대라면..?

• 연결을 유지하지 않는 모델
  최소한의 자원으로 서버를 유지할 수 있다

 

Q. 이렇게 연결을 끊어버려도 문제가 되지 않을까?

일반적으로 수천명이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적다.

(인터넷을 이용할 때 검색하고 한참본 후에야 다시 검색하지 않는가?)

따라서 HTTP의 비연결적 특성으로 인해 서버 자원을 매우 효율적으로 사용할 수 있다

 

Q. 단점 및 해결?

하지만 사용자 입장에선 단점이다.

매번 TCP/IP 연결을 새로 맺어야 한다.. 이때 3 way handshake 시간이 추가된다..

또한 웹 브라우저로 요청할 때, HTML 하나만이 아니라 js, css 파일, 이미지 등 수많은 자원이 함께 다운로드 된다..

(HTML을 렌더링 하려고 봤더니 JS가 필요하네? 이미지가 필요하네?)

HTTP 초기 버전에서는 아래와 같이 매번 연결/종료 과정을 거쳤다.

HTTP 초기 - 연결/종료 낭비

 

지금은 HTTP 지속 연결(persistent connections)로 문제를 해결

연결/종료 낭비를 획기적으로 줄여버렸다

HTTP 2,3은는 더 빠르게 동작한다. 특히 3는 UDP를 쓰면서 연결 속도를 확 줄여버렸다.

 

서버 개발자들이 어려워하는 업무

이벤트 등으로 같은 시간에 딱 맞춰어 발생하는 대용량 트래픽 → 수만 명이 '동시에' 요청

그럼 비연결성이고 나발이고 소용이 없다. 진짜 동시 요청이 많아지므로..

 

이럴 땐 Stateless를 기억하자. 서버를 증설하는 수밖에 없다.

최대한 stateless하게 설계하는 게 중요하다.

그래야 서버를 확 증설할 수 있다.

 

---

 

HTTP 메시지

HTTTP 메시지의 구조: 시작 라인 - 헤더 - 바디

 

1. 시작 라인

요청과 응답에 대한 개요

start-line = request-line (요청) / status-line (응답)

• 요청 메시지 : method, request-target, HTTP-version
  ex) GET /search?q=hello&hl=ko HTTP/1.1
  - method: 서버가 수행해야 할 동작 지정 (GET, POST, PUT, DELETE…)
  - request-target: 절대 경로[? 쿼리]      ※절대경로 : /로 시작하는 경로
  

• 응답 메시지 : HTTP-version, status-code, reason-phrase
  ex) HTTP/1.1 200 OK
  - status-code: 요청 성공, 실패를 나타냄
  - reason-phrase: 사람이 이해할 수 있는 짧은 상태 코드 설명 글 
  

 

2. HTTP 헤더

HTTP 전송에 필요한 모든 부가 정보. body를 제외한 모든 메타데이터

예) 바디의 내용, 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...

 

• 구조 = field-name: field-value

field-name: field-value

• 표준 헤더 필드는 너무 많음
  (나중에 따로 정리하겠다)
  
• 필요시 임의의 헤더 추가 가능
  약속한 클라이언트와 서버는 이해할 수 있다

 

3. HTTP 메시지 바디

실제 전송할 데이터

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

 

---

 

 

이처럼..

HTTP는 단순하다. HTTP 메시지도 매우 단순하다.

단순하지만 확장 가능하다.

성공하는 서비스들은 단순하지만 확장 가능하다.

 

---

 

참고 자료 & 이미지 출처
모든 개발자를 위한 HTTP 웹 기본 지식 (김영한 님)
컴퓨터 네트워킹 : 하향식 접근 7판 (JAMES F.KUROSE)