[HTTP] HTTP 웹 기본 지식 3) HTTP 기본

HTTP 웹 기본 지식

Session 3 HTTP 기본

1. 모든 것이 HTTP

1) HTTP(HyperText Transfer Protocol)

HTTP 메시지에 모든 것을 전송(HTML, JSON, XML, 이미지, 음성, 영상, 파일 등) 거의 모든 형태의 데이터 전송가능

서버 간에 데이터를 주고받을 때도 대부분 HTTP 사용

 

2) HTTP 역사

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

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

HTTP/1.1 : 가장 많이 사용, 중요한 버전

HTTP/2 : 성능개선

HTTP/3 : 진행중, TCP대신 UDP사용, 성능 개선

 

3) 기반 프로토콜

TCP : HTTP/1.1, HTTP/2

UDP : HTTP/3

현재 HTTP/1.1 주로 사용 ▶ 2, 3도 증가하고 있음

TCP는 3way handshake, 기본 데이터 양이 많아 속도가 빠른 메커니즘이 아님 → UDP 기반으로 서능을 최적화해 나온 것이 HTTP/3

 

4) HTTP 특징

클라이언트 서버 구조

무상태 프로토콜(스테이스리스), 비연결성

HTTP 메시지

단순함, 확장 가능

---

2. 클라이언트 서버 구조

1) 클라이언트 서버 구조

Request Response 구조

클라이언트는 서버에 요청을 보내고 응답을 대기, 서버가 요청에 대한 결과를 만들어서 응답

클라이언트와 서버를 개념적으로 분리

클라이언트 UI, UX, 사용성에 집중

서버 비즈니스 로직, 데이터 처리에 집중

클라이언트와 서버는 각각 독립적으로 진화가능함

예) 트래픽이 100배 증가했을때 서버에서 기술 고도화에만 집중

---

3. Stateful, Stateless

1) 무상태 프로토콜 Stateless

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

서버 확장성이 높다(스케일 아웃)

단점으론 클라이언트가 추가 데이터를 전송해야 함

 

2) Stateful

서버가 클라이언트의 이전 상태를 보존

 

2-1) Stateful 예제

3) Stateless 예제

 

4) Stateful과 Stateless의 차이

상태유지 Stateful : 중간에 다른 점원으로 바뀌면 안 된다. 바뀌면 상태 정보를 다른 점원에게 알려주어야 한다.

무상태 Stateless : 중단에 다른 점원으로 바뀌어도 된다. 고객이 갑자기 증가해도 점원을 대거 투입 가능

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

스케일 아웃-수평 확장 유리

5) Stateless 실무 한계

모든 것을 무상태 설계 할 수 없다. 상태 유지는 최소한만 사용

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

로그인 ▶ 브라우저 쿠키와 서버 세션 등 사용해 상태유지

클라이언트가 데이터를 너무 많이 보냄

---

4. 비 연결성(connectionless)

1) 연결을 유지하는 모델

모든 클라이언트와 연결을 유지해 서버 자원 소모가 많다.

 

2) 연결을 유지하지 않는 모델

클라이언트와 요청-응답이 끝나면 연결을 종료한다.

서버는 연결을 유지하지 않아 최소한의 자원을 사용할 수 있다.

 

3) 비 연결성

HTTP는 기본이 연결을 유지하지 않는 모델

초 단위의 이하의 빠른 속도로 응답

수천 명이 서비스 사용을 해도 실제 거버에서 동시 처리하는 요청은 수십 개 이하로 매우 작음

서버 자원을 매우 효율적으로 사용 가능

▶ 서버 입장에서 연결을 유지하지 않는 것이 자원의 가용성을 높일 수 있다.

 

4) 비 연결성의 단점

매번 TCP/IP 연결을 새로 맺어야 함 - 3-way handshake 시간 추가

웹 브라우저로 사이트를 요청하면 HTML, 자바 스크립트, CSS 등 수많은 자원이 함께 다운로드

▶ HTTP 지속 연결(Persistent Connections)로 문제 해결

▶ HTTP/2, HTTP/3에서 더 많은 최적화

 

5) HTTP 초기-연결, 종료 낭비

자원을 받을 때마다 연결, 종료 반복

 

 

6) HTTP 지속 연결

html 등 자원 다 받을 때까지 연결 유지, 다 받고 연결 종료

---

5. HTTP 메시지

1) HTTP 메시지 구조

start-line 시작라인

header 헤더

공백 라인

message body 메시지 바디

 

2) 시작 라인 start-line

request-line과 status-line으로 구성

요청 메시지는 request-line

응답 메시지는 status-line

 

2-1) 요청메시지 request-line

method SP request-target sp HTTP-version CRLF

method : HTTP 메서드(GET 조회)

SP : 공백

request-target : 요청 대상으로 path(/search?q=hello&hl=ko)

HTTPversion : HTTP의 버전

CRLF : 공백라인

 

2-1-1) HTTP 메서드

서버가 수행해야 할 동작을 지정

GET, POST, PUT, DELETE 등

 

2-1-2) request-target 요청대상

absolute-path 절대경로 사용

 

2-2) 응답메시지 status-line

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

HTTP-version : HTTP 버전

SP : 공백

status-code : 상태코드 요청 성공, 실패를 의미(200 성공, 400 클라이언트 요청 오류, 500 서버 내부 오류)

reason-phrase : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

CRLF : 공백라인

 

3) 헤더 header

header-field = field-name ":" OWS field-value OWS

OWS : 띄어쓰기 허용

HTTP 전송에 필요한 모든 부가정보가 담겨있다.

메시지 바디 내용, 바디 크기, 압축 등 표준 헤더가 너무 많음

필요시 임의의 헤더 추가 가능

field-name은 대소문자 구분 X

 

4) HTTP 메시지 바디

실제 전송할 데이터

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

 

5) HTTP는 단순함 확장 가능

HTTP는 단순, 메시지도 단순

표준 기술은 단순하지만 확장 가능한 기술