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년: 가장많이 사용, 우리에게 가장 중요한 버전
- HTTP/2 2015년: 성능개선
- HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선
기반 프로토콜
- TCP: HTTP/1.1, HTTP/2
- UDP: HTTP/3
- 현재 HTTP/1.1 주로 사용
- HTTP/2, HTTP/3 도 점점 증가
HTTP1.1이나 2같은 경우에는 TCP를 기반으로 동작
HTTP3는 UDP 기반으로 동작 (3handshak 등으로 인한 TCP성능을 UDP를 개조하여 더 좋은 성능으로 개선 가능)
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(스테이스리스), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
클라이언트 서버 구조
- Request Response 구조
- 클라이언트는 서버에 요청을 보내고, 응답을 대기
- 서버가 요청에 대한 결과를 만들어서 응답
클라이언트는 서버로 요청을 하고 응답이 올때까지 기다린다. 이렇게 클라이언트와 서버를 분리를 하는것이 중요하다. 비즈니스 로직과 데이터를 서버에 집중하고 클라이언트는 UI와 사용성에 집중한다. 그러면 클라이언트와 서버가 각각 독립적으로 진화할 수 있다.
예를 들어서 클라이언트가(PC, 휴대폰, 등) UI와 화면에 집중을 하고 서버가 비즈니스 로직에 집중하여 서로 독립적으로 사용할 수 있다는 것이다.
또 서버가 터졌을때 서버만 고치면 되고 클라이언트는 그것에 대해 전혀 손을 대지 않아도 된다는 점이 등이 있기 때문에 이런 구조가 형성되었다.
무상태 프로토콜
Stateful, Stateless 차이
Stateful 상태유지
Stateful - 중간에 점원이 바뀌면?
Stateless 무상태
Stateless - 중간에 점원이 바뀌면?
정리
상태 유지 : 중간에 다른 점원으로 바뀌면 안된다.
(중간에 다른 점원으로 바뀔때 상태 정보를 다른 점원에게 미리 알려줘야 한다.)
무상태 : 중간에 다른 점원으로 바뀌어도 된다.
- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. 즉,
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능
상태 유지의 경우, 클라이언트 A가 요청을 했을때 그에 맞는 서버가 응답을 하는 방식이다.
이렇게 되면 서버를 늘리기가 어려워진다.
중간에 서버1이 장애가 난다면 클라이언트A는 결제를 처음부터 다시 해야한다.
서버는 상태를 보관하지 않고 필요한 응답만 한다.
서버1이 장애가 되면 서버2로 보내면 된다.
그러므로 서버 확장에 유리하다.
Stateless 실무 한계
- 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
- 무상태 - 로그인이 필요없는 단순한 서비스 소개 화면
- 상태유지 - 로그인
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
- 상태 유지는 최소한만 사용
로그인했다는 상태를 서버에 유지해야하기 때문에 일반적으로는 브라우저의 쿠키와 서버의 세션을 조합하여 상태를 유지하는 기능을 사용한다.
세션이 죽거나 날아가게 되면 로그인이 풀리는 경우 등의 한계가 또 있지만, 그렇다 하더라도 상태 유지는 최소한으로 사용해야 한다.
비연결성
연결을 유지하는 모델
연결을 유지하지 않는 모델
비연결성
- HTTP는 기본이 연결을 유지하지 않는 모델이다.
- 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
- 서버의 자원을 매우 효율적으로 사용할 수 있다.
비연결성 한계와 극복
- TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간이 추가된다.
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바 스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드
- 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
- HTTP/2, HTTP/3에서 더 많은 최적화
초기 HTTP
초기에는 연결을 하고 요청/응답을 한 후 종료하고 또 다음걸 받기 위해 연결하고 요청/응답을 한 후 종료하는 방식이였다. 하지만 이 방법은 시간이 오래 걸리기 때문에 지속연결(Persistent Connections)가 나왔다.
HTTP 지속 연결(Persistent Connections)
처음에 연결을 하면 내부 메커니즘에 따라 연결을 유지한 상태로 있으면 그 사이에 요청/응답을 계속 한다. 이렇게 속도가 훨씬 더 빠르게 진행을 할 수 있다.
스테이스리스를 기억하자
서버 개발자들이 어려워 하는 업무
- 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
- 예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
- 수만명이 동시에 요청
- 그래도 최대한 스테이스리스하게 설계하는 것이 중요하다.
보통 이벤트 로그인 필요없는 정적 페이지를 하나 뿌린다. (순수한 HTML)
그 후에 시간을 보내도록 한다. (영상을 본다던지 등)
그러면 요청을 좀 나눠서 보내도록 할 수 있다.
HTTP 메시지
HTTP 메시지는 시작라인, 헤더, 공백라인, 바디로 이루어져 있다.
시작 라인
요청메시지
- start-line = request-line / status-line
- request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
- HTTP 메서드 (GET: 조회)
- 요청 대상(/search?q=hello&hl=ko)
- HTTP Version
요청메시지 - HTTP 메서드
종류 - GET, POST, PUT, DELETE...
서버가 수행해야 할 동작 지정
- GET: 리소스 조회
- POST: 요청 내역 처리
요청메시지 - 요청 대상
absolute-path[?query](절대경로[?쿼리])
절대경로 - "/"로 시작하는 경로
요청메시지 - HTTP 버전
버전
응답 메시지
start_line = request-line / status-line
status-line = HTTP-version SP status-code SP reson-phrase CRLF
HTTP 버전
HTTP 상태 코드: 요청 성공, 실패를 나타냄
- 200: 성공
- 400: 클라이언트 요청 오류
- 500: 서버 내부 오류
이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글 (OK)
HTTP 헤더
header-field = field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용)
field-name은 대소문자 구문 없음
Host:띄어쓰기는 되지만 Host 띄어쓰기 :는 안된다.
HTTP 헤더 용도
HTTP 전송에 필요한 모든 부가 정보
메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...
표준 헤더가 너무 많다.
필요시 임의의 헤더 추가 가능
HTTP 메시지 바디
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
단순함 확장 가능
- HTTP는 생각보다 단순해서 읽을만 하긴 하다.(보고 싶다면 뭐..)
- 메시지도 매우 단순
- 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술
