HTTP 기본

모든 개발자를 위한 HTTP 웹 기본 지식

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

강의를 들으며 생각 정리

 

모든 것이 HTTP

---

HTTP(HyperText Transfer Protocol)은 초기에 하이퍼텍스트 형태의 HTML 파일을 지원하기 위해 나왔지만 현재는 거의 모든 형태의 데이터 전송이 가능하다.

HTML, TEXT 뿐만 아니라 이미지, 음성, 영상 혹은 JSON, XML과 같은 API 등 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

 

HTTP는 HTTP/1.1, HTTP/2, HTTP/3 처럼 버전이 업그레이드 되고 있는데 가장 많이 사용하고 중요한것이 HTTP/1.1이다. 나머지 2, 3은 1.1에서 성능 개선 정도의 기능이 추가된 것이다.

 

HTTP 특징

• 클라이언트, 서버 구조
• 무상태 프로토콜, 비연결성
• HTTP 메시지
• 단순함, 확장 가능

위 특징들을 자세히 살펴보자.

 

 

클라이언트 서버 구조

---

HTTP의 특징 중 하나는 클라이언트와 서버 구조로 되어 있다는 것이다.

클라이언트가 HTTP 메소드를 통해서 데이터를 요청하면 서버는 요청에 대한 결과를 만들어서 응답한다.

 

이렇게 분리함으로써 클라이언트와 서버가 각각 독립적으로 진화할 수 있다는 것이 핵심이다.

 

비즈니스 로직, 데이터는 서버에다 UI 등은 클라이언트에 배치함으로써

클라이언트는 복잡한 비즈니스 로직에 신경쓰지 않고 UI를 어떻게 그릴지만 고민하면 되고 서버 입장에서도 클라이언트에 손댈 필요 없이 백엔드쪽만 신경쓰면 된다.

 

 

Stateful, Stateless

---

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

 

예시를 통해 알아보자.

 

Stateful - 상태 유지

다음과 같은 일반적인 상황이 있다.

고객: 이 노트북 얼마인가요? 

점원: 100만원 입니다. 

 

고객: 2개 구매하겠습니다. 

점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? 

 

고객: 신용카드로 구매하겠습니다. 

점원: 200만원 결제 완료되었습니다.

 

여기서 만약 점원이 중간에 바뀐다면 어떻게 될까?

고객: 이 노트북 얼마인가요? 

점원A: 100만원 입니다. 

 

고객: 2개 구매하겠습니다. 

점원B: ? 무엇을 2개 구매하시겠어요?

 

고객: 신용카드로 구매하겠습니다. 

점원C: ? 무슨 제품을 몇 개 신용카드로 구매하시겠어요?

 

이처럼 점원이 바뀌면 고객과 점원 간에 원활한 통신이 이루어지지 않는다.

Stateful을 정리하자면 다음과 같다.

고객: 이 노트북 얼마인가요? 

점원: 100만원 입니다. (노트북 상태 유지) 

 

고객: 2개 구매하겠습니다. 

점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? (노트북, 2개 상태 유지) 

 

고객: 신용카드로 구매하겠습니다. 

점원: 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지)

 

점원 입장에서 고객의 요청에 따른 상태를 유지하기 때문에 고객-점원 연결이 중간에 바뀌면 곤란해진다.

 

Stateless - 무상태

같은 예시를 통해 Stateless를 알아보자.

고객: 이 노트북 얼마인가요? 

점원: 100만원 입니다. 

 

고객: 노트북 2개 구매하겠습니다. 

점원: 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? 

 

고객: 노트북 2개를 신용카드로 구매하겠습니다. 

점원: 200만원 결제 완료되었습니다.

 

무상태에서는 점원이 고객의 상태를 유지하지 않기 때문에 고객 입장에서 계속 앞선 데이터를 제공해주어야 한다.

여기서 점원이 중간에 바뀐다면 어떻게 될까?

고객: 이 노트북 얼마인가요?

점원A: 100만원 입니다. 

 

고객: 노트북 2개 구매하겠습니다. 

점원B: 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? 

 

고객: 노트북 2개를 신용카드로 구매하겠습니다. 

점원C: 200만원 결제 완료되었습니다.

 

무상태 경우에는 중간에 점원이 바뀌어도 고객이 데이터를 계속 제공하기 때문에 문제 없다.

 

정리

상태 유지 : 중간에 다름 점원으로 바뀌면 안된다.

 

무상태 : 중간에 다른 점원으로 바뀌어도 된다.

-> 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. 즉, 무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다. -> 무한한 서버 증설이 가능하다.

이처럼 무상태는 스케일 아웃이라고 하는 서버 수평 확장에 유리하다.

 

<무상태 - 실무 한계>

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

예시)

무상태 - 로그인이 필요 없는 단순한 서비스 소개 화면

상태 유지 - 로그인

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 한다. -> 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지를 한다.

단, 상태 유지는 최소한만 사용하는 것이 좋다.

 

 

비 연결성(connectionless)

---

클라이언트 - 서버 연결을 유지하는 모델은 서버 자원이 빠르게 소모되는 문제가 있다.

 

그래서 HTTP는 연결을 유지하지 않는 모델을 사용함으로써 최소한의 서버 자원을 유지한다. 즉, 클라이언트와 서버간의 데이터 요청, 응답이 끝나면 연결을 끊어버린다.

 

그러나 비연결성 역시 한계가 존재한다.

1. TCP/IP 연결을 새로 맺어야 한다 - 3 way handshake 시간 추가
2. 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css 등 수 많은 자원이 함께 다운로드된다.

지금은 HTTP 지속 연결 (Persistent Connections)로 문제를 해결한다. 지속 연결은 기본은 비연결성인데, 성능 최적화를 위해서 약간의 연결 유지를 가져간다고 생각하면 된다.

 

 

HTTP 메시지

---

HTTP는 특정 메시지 형식으로 메시지를 주고 받는다. 크게 요청 메시지와 응답 메시지로 나뉜다. 예시는 다음과 같다.

 

 

시작 라인

시작 라인(start-line)은 요청 메시지에서 request-line, 응답 메시지에서 status-line으로 구분한다.

 

요청 메시지

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

-> GET /search?q=hello&hl=ko HTTP/1.1

 

1.  HTTP 메서드 : 서버가 수행해야 할 동작 지정 (GET : 리소스 조회, POST : 요청 내역 처리 등)
2. 요청 대상 : 일반적으로 절대경로를 사용한다.
3. HTTP 버전

응답 메시지

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

-> HTTP/1.1 200 OK

 

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

 

HTTP 헤더

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

->

Host: www.goggle.com   (요청 메시지)

->

Content-Type: text/html;charset=UTF-8

Content-Length: 3423 (응답 메시지)

 

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보다. (메시지 바디의 내용, 크기 등)

참고로 field-name은 대소문자 구분 없다.

 

HTTP 메시지 바디

실제 전송할 데이터이다.

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

 

 

+) HTTP는 앞서 본 것과 같이 메시지 전송을 편리하게 하기 위한 다양한 기능들을 제공한다. 무엇보다 단순하고 확장이 가능하다는게 큰 장점이다. 크게 성공하는 표준 기술은 대체로 단순하지만 확장 가능한 기술인 경우가 많다.