[인강노트-웹지식] 3. HTTP 기본

봄도둑·2022년 5월 4일

web 김영한 웹 인프런

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

목록 보기

3/7

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의 내용을 정리한 노트입니다. 블로그에 있는 자료를 사용하실 때에는 꼭 김영한님 강의 링크를 남겨주세요!

1. HTTP

1-1. HTTP 개요

HTTP

HTML을 전송하는 프로토콜에서 시작
음성, 이미지, 영상, 파일부터 시작해서 JSON, XML 등 거의 모든 형태의 데이터 전송 가능
서버간 데이터를 주고 받을 때도 대부분 HTTP 사용
HTTP/1.1 버전을 가장 많이 사용, 가장 중요한 버전 → 여기에 모든 기능, 스펙이 들어 있음
- 대다수의 네트워크 관련된 책들은 RFC2616 버전으로 기술되어 있지만 우리는 신규 스펙인 RFC 7230~7235 버전을 봐야 함
- 물론 HTTP/2, 3 버전도 구글과 네이버를 중심으로 많이 사용되고 있음
기반 프로토콜
- 1.1 버전과 2버전은 TCP, 3버전은 UDP 기반

HTTP 특징

클라이언트 서버 구조
무상태 프로토콜(stateless), qldusruftjd
HTTP 메시지
단순함, 확장 가능

2. HTTP의 핵심 특징

2-1. 클라이언트 서버 구조

클라이언트 서버 구조

쉽게 말해서 클라이언트와 서버를 분리함.
비즈니스 로직과 데이터는 서버에, 클라이언트는 UI를 그리고 사용성에 좀 더 집중하는 구조 → 이러한 구조로 인해 클랑이언트와 서버가 독립적으로 진화 가능
서로 관리하는 영역이 달라지고 불필요한 것들에 대해서 신경 쓰지 않아도 되기 때문에 서버와 클라이언트는 자기들이 맡은 부분에만 집중할 수 있음

2-2. 무상태 프로토콜(stateless)

서버가 클라이언트의 상태를 보존 하지 않음
보다 쉬운 예시로 stateless를 이해해보자!
stateful 예시
- 점원은 고객의 상태를 기억(보존)하고 있음 → 그렇기 때문에 최종 구매에 고객은 결제 수단(신용카드)만 말하면 점원은 알아서 200만원을 긁으면 됨.
stateless 예시
- 고객이 요청할 때 마다 점원이 바뀐다고 생각해보자
- 점원이 고객의 상태를 알지 못함(고객의 상태를 유지하지 않음) → 고객이 현재 자신의 상태에 대한 정보를 주지 않으면 점원은 고객이 무슨 응답을 필요로 하는지 알 수 없음 → 점원이 고객에 대한 상태를 보존하지 않기 때문에 고객은 자신의 상태에 대한 정보를 전달해야 함.
stateless와 stateful의 차이
- stateful은 서버가 클라이언트의 상태를 보존하고 있음 → 다른 점원(서버)로 바뀌게 되면 문맥(context)가 사라짐 → 즉, 다른 점원(서버)로 바뀌면 안됨.
- 반대로 stateless는 중간에 점원이 바뀌어도 문맥이 끊기지 않음
- 갑자기 고객이 증가해도 점원을 대거 투입 가능 → 고객이 자신의 상태를 전달하기 때문에 점원은 고객의 상태를 몰라도 응대에 문제가 없기 때문 → 클라이언트의 요청이 늘어나도 서버를 늘릴 수 있음
- 이것에 대한 강점으로 응답 서버를 쉽게 바꿀 수 있음!
stateful 도식화
- 요청을 보낸 클라이언트A는 반드시 서버1이 응답해야 함
stateless 도식화
- 클라이언트는 자신의 상태에 대한 정보와 요청을 같이 서버에 보냄 → 서버1이 응답해도 되지만, 전담하지 않음(서버2, 3이 응답해도 문제 없음)
- 서버는 응답만 하고 상태는 보관하지 않음.
- 서버1이 죽어도 클라이언트의 상태에 대한 정보가 있기 때문에 서버2가 자연스럽게 응답해도 문제가 없음
- 이러한 이유로 스케일 아웃(수평 확장)에 유리 → 어차피 다른 녀석이 응답할텐데 같은 기능을 하는 서버군을 여러 개 늘릴 수 있음
실무 한계
- 로그인의 기능 같은 경우 상태를 유지해야 함 → 서버가 로그인을 했다는 상태를 가지고 있어야 함.
- 이러한 한계를 극복하기 위해 브라우저의 쿠키와 서버의 세션을 사용
- 상태 유지는 최소한, 어쩔 수 없을 때 사용
- 클라이언트가 매번 자신의 상태를 보내기 때문에 클라이언트 쪽에서 데이터가 많이 전송됨.

2-3. 비연결성

연결유지모델

클라이언트와 서버가 통신하지 않아도 계속 연결을 유지하고 있는 모델
서버가 계속 연결을 유지하고 있기 때문에 서버의 자원이 크게 낭비됨

연결을 유지하지 않는 모델

요청, 응답이 종료되면 tcp, ip 연결을 끊어버림
서버는 연결을 유지할 필요가 없으며 최소한의 자원만 유지
HTTP는 기본적으로 연결을 유지하지 않는 모델
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
서버 자원을 효율적으로 사용할 수 있음
매번 요청이 올 때마다 TCP/IP 연결을 새로 맺어야 함 → 3 way handshake를 매번 진행 → HTTP의 지속 연결(Persistent Connections)로 문제 해결
- 지속 연결 : HTML 페이지 하나를 받을 때 까지 일단 연결은 해놓음 → 하나의 요청과 응답이 끝날 때마다 연결 종료가 아니라 일단 연결 해놓고 일정 시간뒤 연결을 끊어버리는 등의 방법을 이용
stateless → 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 → 서버 개발자들이 어려워하는 업무
- 최대한 stateless하게 설계해야 함
- 가령, 첫 페이지는 로그인이 필요없는 정적 페이지 → 여기서 참여 버튼을 누르게 하는 방식등으로 설계