[HTTP]HTTP 기본

 

HTTP

Hyper Text Transfer Protocol

HTTP 메시지에 모든 것을 전송

→ HTML, TEXT
→ IMAGE, 음성, 영상, 파일
→ JSON, XML (API)
→ 거의 모든 형태의 데이터 전송 가능
→ 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
지금은 HTTP 시대라고도 할 수 있다.

HTTP 역사

→ HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X
→ HTTP/1.0 1996년: 메서드, 헤더 추가
→ HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
   → RFC2068 (1997) ▷ RFC2616 (1999) ▷ RFC7230~7235 (2014)
→ HTTP/2 2015년: 성능 개선
→ HTTP/3 진행 중: TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

TCP : HTTP/1.1, HTTP/2
UDP : HTTP/3
→ 현재 HTTP/1.1 주로 사용
  → HTTP/2, HTTP/3도 점점 증가

HTTP 특징

→ 클라이언트 서버 구조
→ 무상태 프로토콜(스테이스리스), 비연결성
→ HTTP 메시지
→ 단순함, 확장 가능

---

클라이언트 서버 구조

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

---

무상태 프로토콜

스테이스리스(Stateless)

서버가 클라이언트의 상태를 보존하지 않는다.
→ 장점: 서버 확장성이 높음 ( 스케일 아웃 )
→ 단점: 클라이언트가 추가 데이터 전송

서버가 클라이언트의 상태를 보존하지 않는다라는 말을 이해하기 위해서는 stateful과 stateless의 차이를 알아야 한다.

상태 유지 - Stateful

고객: 이 노트북 얼마인가요?
점원: 100만원 입니다. (노트북 상태 유지)
고객: 2개 구매하겠습니다.
점원: 200만원 입니다. 신용카드,현금중에 어떤 걸로 구매 하시겠어요? (노트북, 2개 상태 유지)
고객: 신용카드로 구매하겠습니다.
점원: 200만원 결제 완료되었습니다. (노트북,2개,신용카드 상태 유지)

무상태 - Stateless

고객: 이 노트북 얼마인가요?
점원1: 100만원 입니다.
고객: 노트북 2개 구매하겠습니다.
점원2: 노트북 2개는 200만원 입니다. 신용카드,현금중에 어떤 걸로 구매하시겠어요?
고객: 노트북 2개를 신용카드로 구매하겠습니다.
점원3: 200만원 결제 완료되었습니다.

상태유지에서는 만약 중간에 다른 점원으로 바뀐다면 개발하는 입장에서는 장애가 일어난다.

하지만, 무상태에서는 중간에 다른 점원으로 바뀌어도 고객이 필요한 정보를 모두 넘기기 때문에 점원이 바뀌어도 장애가 발생하지 않는다.

Stateful, Stateless 차이

→ 상태 유지 : 중간에 다른 점원으로 바뀌면 안된다.
( 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다. )
→ 무상태 : 중간에 다른 점원으로 바뀌어도 된다.
   · 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
   · 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
→ 무상태는 응답 서버를 쉽게 바꿀 수 있다. ▷ 무한한 서버 증설 가능

하지만 이러한 stateless도 한계가 존재한다.

Stateless 실무 한계

· 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
· 무상태
  · 예) 로그인이 필요 없는 단순한 서비스 소개 화면
· 상태 유지
  · 예) 로그인
· 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지
· 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
· 상태 유지는 최소한만 사용

---

비 연결성(connectionless)

클라이언트1이 서버에게 요청을 보내고 응답을 받으면 클라이언트1과 서버는 연결되어있다.

그리고, 클라이언트2와 서버가 요청을 보내고 응답을 받으면 클라이언트1과 클라이언트2는 서버에 연결되어있다.

이렇게 수많은 클라이언트가 한 서버에 요청을 보내고 응답을 받아 한 서버에 연결이 되어있다면

그 서버는 이미 필요한 정보를 보냈음에도 불구하고 계속해서 수많은 클라이언트와 연결을 해야 할 것이다.

그렇게 된다면 서버는 계속해서 자원을 소모하게 될 것이다.

하지만, 클라이언트1이 서버에게 요청을 보내고 응답을 받는 즉시 연결을 해제한다면

아무리 많은 클라이언트와 서버가 연결을 해도 서버의 자원을 최소한으로 사용하기 때문에 괜찮을 것이다.

비 연결성

· HTTP는 기본이 연결을 유지하지 않는 모델
· 일반적으로 초 단위의 이하의 빠른 속도로 응답
· 1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작음
  · 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
· 서버 자원을 매우 효율적으로 사용할 수 있음

하지만 이러한 비 연결성도 단점이 존재한다.

비 연결성 한계와 극복

· TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
· 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등
수많은 자원이 함께 다운로드
· 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
· HTTP/2, HTTP/3에서 더 많은 최적화

여기서 지속 연결(Persistent Connections)은 예전에는 클라이언트에서 서버에게 요청을 보내서

HTML파일을 받고 연결을 종료하고, HTML을 랜더링을 하는데 자바스크립트가 필요해서 다시 서버에게 요청을 보내고 응답을 받고, 또 랜더링을 하다보니 이미지가 필요해서 다시 요청/응답을 반복했다.

이렇게 진행하면 요청과 응답을 받는 시간 계속 추가가 되기 때문에 랜더링을 하는데 시간이 오래 걸린다.

하지만 HTTP 지속 연결을 사용하면 한 번의 연결로 HTML응답, 자바스크립트 응답, 이미지 응답을 모두 처리하고 종료를 하게 된다. 이렇게 해서 반복적인 요청/응답 시간을 줄여서 훨씬 빠른 속도로 랜더링 하게 된다.

이러한 지속 연결은 HTTP/2와 HTTP/3에서 더 많이 최적화가 되었다.

HTTP/3에서는 UDP를 사용하면서 연결하는 시간조차도 단축하게 되었다

스테이스리스를 기억하자
서버 개발자들이 어려워하는 업무

· 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
예) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 → 수만 명 동시 요청

스테이스리스한 방식으로 서버를 설계해야 한다.
무상태로 갈수있는건 최대한 무상태로 가고, 어쩔 수 없는 부분에 한해서만 상태 유지를 하도록 해야 한다.

---

HTTP 메시지

HTTP메시지의 구조는 위 이미지와 같다.

시작라인, 헤더, 공백 라인(CRLF), message body 이렇게 구조를 이루고 있다.

시작 라인

요청 메시지
· 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://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.

요청 메시지 - HTTP 버전
· 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 헤더 - 용도
· HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보,
서버 애플리케이션 정보, 캐시 관리 정보...
· 표준 헤더가 너무 많음
  · https://en.wikipedia.org/wiki/List of HTTP header fields
· 필요시 임의의 헤더 추가 가능
  · helloworld:hihi

HTTP 메시지 바디 - 용도
· 실제 전송할 데이터
· HTML문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

HTTP는 매우 단순하고, HTTP 메시지 또한 매우 단순하다.

이렇게 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술이기 때문이다.

---

출처: [인프런]모든 개발자를 위한 HTTP 웹 기본 지식