섹션4. HTTP 기본
1. 모든 것이 HTTP
현재는 모든 형태의 데이터를 HTTP 프로토콜을 사용해 통신한다.
HTML, TEXT
IMAGE, 음성, 영상, 파일
JSON, XML(API)
거의 모든 형태의 데이터 전송 가능
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
지금 HTTP 시대!
HTTP 역사
HTTP/0.9 : ...
HTTP/1.0 : ...
HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전
HTTP/2 2015년 : 성능 개선
HTTP/3 진행중 : TCP 대신에 UDP 사용, 성능 개선
기반 프로토콜
TCP : HTTP1.1, HTTP/2
UDP : HTTP/3
현재 HTTP/1.1 주로 사용
HTTP/2, HTTP/3 도 점점 증가
현재 HTTP/2 가 가장 많이 사용되고 있다.
HTTP 특징
클라이언트 서버 구조
무상태 프로토콜(스테이스리스), 비연결성
HTTP 메시지
단순함, 확장 가능
2. 클라이언트 서버 구조
Request Response 구조
클라이언트는 서버에 요청을 보내고, 응답을 대기
서버가 요청에 대한 결과를 만들어서 응답
해당 구조의 장점
Request Response 구조의 장점은 클라이언트, 서버가 각각 독립적으로 성장할 수 있다는데 있다.
예를 들어, 클라이언트 입장에서는 UI 에 집중하면 되지, 클라이언트에 집중할 필요가 없다. (서버의 경우도 마찬가지)
3. Stateful, Stateless
무상태 프로토콜(Stateless)
서버가 클라이언트의 상태가 보존X
장점 : 서버 확장성이 높다(스케일 아웃)
단점 : 클라이언트가 추가 데이터 전송
Stateful, Stateless 차이
Stateless 는 문맥(context) 을 모르게 때문에, 클라이언트가 부가적인 정보를 서버에 전달해주어야 클라이언트가 원하는 응답을 받을 수 있다.
Stateful (컨텍스트를 알고있다)
고객 : 이 노트북이 얼마인가요?
점원 : 100만원 입니다.
고객 : 2개 구매하겠습니다.
점원 : 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?
고객: 신용카드로 구매하겠습니다.
점원: 200만원 결제 완료되었습니다.
Stateless (컨택스트를 모른다)
고객: 이 노트북 얼마인가요?
점원A: 100만원 입니다.
고객: 2개 구매하겠습니다.
점원B: ? 무엇을 2개 구매하시겠어요?
고객: 신용카드로 구매하겠습니다.
점원C: ? 무슨 제품을 몇 개 신용카드로 구매하시겠어요?
Stateful, Stateless 정리
상태 유지 : 중간에 다른 점원으로 바뀌면 안된다.
중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.
무상태 : 중간에 다른 점원으로 바뀌어도 된다.
갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능
하지만 무상태는 전송되는 데이터 양이 많다는 단점이 있다.
Stateless 실무 한계
모든 것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있다.
조회 페이지는 무상태로 설계하기 쉽다.
로그인과 같은 기능은 상태를 가져야만 한다. 때문에 부가적인 프로세스를 추가한다. (쿠키 세션)
상태 유지는 최소한만 사용하는 것이 유지보수 측면에서 유리하다.
4. 비 연결성(connectionless)
연결을 유지하는 모델
서버의 입장에서 클라이언트와 연결을 유지하기 위한 자원을 소모한다.
연결을 유지하지 않는 모델
서버에 입장에서는 연결을 유지하지 않는다. 때문에 최소한의 자원만 사용할 수 있다.
비 연결성
HTTP 는 기본이 연결을 유지하지 않는 모델
일반적으로 초 단위 이하의 빠른 속도로 응답
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
예를 들어, 웹 브라우저에서 계속 연결해서 검색 버튼을 누르지는 않는다.
서버 자원을 매우 효율적으로 사용할 수 있다.
비 연결성 (한계와 극복)
TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
웹 브라우저로 사이트를 요청하면 HTML 뿐 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드
지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP3 에서 더 많은 최적화
HTTP 초기 - 연결, 종료 낭비
HTTP 지속 연결(Persistent Connections)
스테이스리스를 기억하자
서버 개발자들이 어려워하는 업무
정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
예를 들어, 선착순 이벤트, 명절 KTX 예약, 수강신청 등등 ..
동시간에 발생하는 요청을 해결하는 가장 쉬운 방법
처음 요청을 하면 정적 페이지를 호출해 해당 페이지에서 어느정도 놀다가 요청 버튼을 누르도록 유도한다.
UX 를 개선하는 방향으로 해결한다.
5. HTTP 메시지
start-line 시작 라인
요청 메시지
start-line - request-line / status-line
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
HTTP 메서드 (GET: 조회)
GET,POST,PUT,DELETE ...
요청 대상 (/search?q=hello&hl=ko)
절대 경로를 사용
HTTP Version
응답 메시지
형식
start-line = request-line / status-line
status-line = HTTP-version SP status-code SP reason-phrase CRLF
HTTP 버전
HTTP 상태 코드 : 요청 성공, 실패를 나타냄
200 : 성공
400 : 클라이언트 요청 오류
500 : 서버 내부 오류
이유 문구 : 사람이 이해할 수 있는 짦은 상태 코드 설명 글
HTTP 헤더
형식
header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name은 대소문자 구문 없음
용도
HTTP 전송에 필요한 모든 부가정보
표준 헤더가 너무 많다..
필요시 임의의 헤더 추가 가능
helloworld: hihi
HTTP 바디
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
HTTP 는 매우 단순하고 확장 가능하다!
HTTP는 단순하다.
HTTP 메서드도 매우 단순
크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술!
Last updated