[NetWork] HTTP(Hyper Text Transfer Protocol)

̱ HTTP(Hyper Text Transfer Protocol)

 

HTTP 는 문서간에 링크를 통해 연결할 수 있는 프로토콜입니다.

하지만, 이제는 문서뿐 아니라 HTTP 메세지에 모든 것을 전송합니다. 

HTML, TEXT

IMAGE, 음성, 영상, 파일

JSON, XML(API)

거의 모든 형태의 데이터가 전송 가능합니다. 서버간에 데이터를 주고 받을 때도 대부분 HTTP 를 사용합니다.

 

HTTP 역사

HTTP/0.9 1991년: GET 메서드만 지원하고, HTTP 헤더를 지원하지 않습니다.

HTTP/1.0 1996년: 메서드와 헤더가 추가되었습니다.

HTTP/1.1 1997년: 현재 가장 많이 사용하는 버전입니다.

RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

HTTP/2 2015년: 성능이 개선되었습니다.

HTTP/3 진행중: TCP 프로토콜 대신에 UDP 프로토콜을 사용합니. 성능이 개선되었습니다.

 

 HTTP/1.1 에 대부분의 기능이 다 들어있고 HTTP/2 HTTP/3 는 성능 개선에 초점이 맞춰져 있습니다.

 

기반 프로토콜

TCP: HTTP/1.1, HTTP/2

UDP: HTTP/3

현재는 HTTP/1.1을 주로 사용하지만 HTTP/2, HTTP/3 도 점점 증가하고 있는 추세입니다.

TCP 프로토콜는 3 way handshake 과정도 있고 기본적으로 데이터 양이 많아 속도가 느려

그래서 UDP 프로토콜을 사용해 성능을 최적화하기 위해 나온게 HTTP/3입니다.

 

 

크롬 웹 브라우저를 사용해서 개발자 도구를 열어 protocol 을 확인하면 h3 와 h2 가 있는걸 볼 수 있습니다.

여기서 h3가 HTTP/3고 h2가 HTTP/2입니다.

 

 ̱HTTP 특징  

 

 

1. 클라이언트 서버 구조 

클라이언트가 HTTP 요청 메시지를 가지고 서버에 요청을 하고 응답을 대기합니다. 

서버가 HTTP 응답 메시지를 생성해 요청에 대한 응답을 합니다. 이렇게 클라이언트와 서버를 분리해놓으면

비즈니스 로직과 데이터를 서버에 맡길 수 있고, 클라이언트는 UI 와 사용성에 집중할 수 있어 각각 독립적으로

진화할 수 있습니다. 만약 트래픽이 폭주해 고도화가 필요한 경우 클라이언트는 신경쓰지 않고 서버만 개선하면

됩니다.

 

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

무상태 프로토콜은 서버가 클라이언트의 상태를 보존하지 않는 것을 의미합니다.

 

Stateful, Stateless 차이

 

상태 유지 - Stateful

고객: 이 과자는 얼마인가요?

점원: 1000원입니다.

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

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

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

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

 

상태 유지 - Stateful, 점원이 중간에 바뀌면?

고객: 이 과자는 얼마인가요?

점원: 1000원입니다.

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

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

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

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

 

상태 유지 - Stateful, 정리

고객: 이 과자는 얼마인가요?

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

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

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

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

점원: 2000원 결제 완료되었습니다. (과자, 2개, 신용카드 상태 유지)

 

 

 

고객이 클라이언트, 점원은 서버라면 서버는 클라이언트의 상태를 보존합니다.

즉, 클라이언트와 서버간에 송/수신을 하며 단계별 과정을 진행하는데 서버에서 클라이언트가 이전 단계에서 제공한 값을

저장하고 다음 단계에서도 저장한 상태인 것입니다. 이렇게 되면 서버가 멈추거나 하는 다른 여러가지 문제로

해당 서버가 못 쓰게되서 다른 서버를 사용해야 한다면 새로운 서버에서는 이전 서버에서 가지고 있던 상태값들을 가지고

있지 않기 때문에 에러가 발생합니다. 새로운 서버로 변경되면서 기존 서버에 저장된 상태를 새로운 서버에서는 알 수가

없으므로 에러가 발생합니다. 즉, 항상 같은 서버가 유지되어야 합니다.

 

무상태 - Stateless

고객: 이 과자는 얼마인가요?

점원: 1000원입니다.

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

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

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

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

 

무상태 - Stateless, 점원이 중간에 바뀌면?

고객: 이 과자는 얼마인가요?

점원: 1000원입니다.

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

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

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

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

 

무상태 - Stateless 정리

 

 

 

 

서버가 클라이언트의 상태를 보존하지 않습니다. 그렇기에 매번 요청에 모든 상태값들을 전달해줘야 합니다. 

서버가 클라이언트의 상태를 보존하지 않기 때문에 서버가 멈추거나 징에가 나서 해당 서버가 못 쓰게 되더라도

다른 서버를 생성해 사용하더라도 문제가 되지 않습니다. 또한 갑자기 클라이언트 요청이 증가해도 서버를

대거 투입할 수 있습니다. 무상태는 응답 서버를 쉽게 바꿀 수 있어 무한한 서버 증설이 가능합니다.

 

무상태의 실무 한계

모든것을 무상태로 설계가 가능한 경우도 있고 없는 경우도 있습니다. 

무상태

ex) 로그인이 필요 없는 단순한 이벤트 페이지

상태 유지

ex) 로그인을 해야하는 경우

 

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

사용해 상태를 유지합니다. 상태 유지는 최소한으로만 사용합니다.

매번 요청에 필요한 데이터를 전부 작성해야 하기 때문에 보내야 하는 데이터가 너무 많습니다. 

 

비 연결성(connectionless)

 

연결을 유지하는 모델

TCP/ IP 연결은 연결을 유지합니다.

 

 

클라이언트1이 요청을 보내고

 

 

 

클라이언트2와 클라이언트3이 요청을 보내도 클라이언트1의 요청은 유지됩니다. 

 

 

다시 클라이언트1이 요청하면 응답을 할 수 있습니다. 클라이언트2와 클라이언트3과는 통신을 하지 않아도

연결을 계속 유지하고 있으므로 서버의 자원을 계속해서 소모합니다.

 

연결을 유지하지 않는 모델

 

 

TCP/ IP 연결을 하고 요청과 응답을 합니다. 

 

 

요청과 응답이 완료되면 연결을 끊습니다.

 

 

 

이 후에 다른 클라이언트와의 연결도 요청과 응답을 하고 바로 끊어냅니다.

즉 요청과 응답을 주고 받을 때만 연결을 해 서버가 유지하는 자원을 최소한을 줄이는 것이죠.

HTTP 는 기본이 연결을 유지하지 않는 모델입니다.일반적으로 초 단위 이하의 빠른 속도로 응답하여

1시간 동안 수 천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작습니다.

ex) 웹 브라우저에서는 계속 연속해서 검색 버튼을 누르지 않습니다.

서버 자원을 매우 효율적으로 사용할 수 있습니다.

 

비 연결성 한계와 극복

 

 

매번 요청할 때마다 TCP/ IP 연결을 새로 맺어야 합니다. - 3 way handshake 시간 추가

웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등

수 많은 자원이 함께 다운로드합니다.

지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결했습니다.

HTTP/2, HTTP/3에서는 이런 부분이 훨씬 더 최적화되었습니다.

스테이스리스를 기억합시다!

스테이트리스하게 설계해서 같은 시간에 딱 맞추어 발생하는 대용량 트래픽이 발생해도

서버를 증설해서 대응할 수 있게 해야합니다. 

ex) 선착순 이벤트, 명절 KTX 예약, 수강 신청

ex) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 -> 수만명 동시 요청

 

3. HTTP 메시지

 

 

HTTP 요청 메시지의 구조와 HTTP 응답 메시지의 구조는 다릅니다.

 

 

 

HTTP 요청 메시지 시작 라인

 

 

start-line = request-line / status-line

HTTP 요청 메시지 시작 라인은 크게 request-line 과 status-line 로 나뉘어져 있습니다.

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

 

HTTP 메서드 (GET: 조회)

요청 대상 (/search?q=hello&hl=ko)

HTTP Version

 

 

HTTP 메서드

메서드 종류: GET, POST, PUT, DELETE...

HTTP 메서드는 서버가 수행해야 할 동작을 지정합니다.

GET: 리소스 조회

POST: 요청 내역 처리

 

 

요청 대상

absolute-path[?query] (절대경로[?쿼리])

절대경로= "/" 로 시작하는 경로를 의미합니다.

참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있습니다.

 

 

HTTP 버전 

HTTP Version

 

HTTP 응답 메시지 시작 라인

 

 

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 헤더 용도

HTTP 헤더에는 HTTP 전송에 필요한 모든 부가정보를 담고 있습니다. HTTP 메시지 바디에 적혀있지 않는

필요한 메타데이터 정보가 다 들어있다고 보면 됩니다.

ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보,

서버 애플리케이션 정보, 캐시 관리 정보... 

표준 헤더가 너무 많습니다 

필요시 임의의 헤더 추가 가능 • helloworld: hihi

 

HTTP 메시지 바디 용도

실제 전송할 데이터를 담고 있습니다.

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

 

4. 단순함, 확장 가능

HTTP는 몹시 단순하고 HTTP 메시지도 매우 단순합니다. 단순하기에 확장이 쉽고 유연한 기술입니다.