HTTP 웹 기본 지식 - HTTP 기본

"인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 작성한 글입니다."

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

HTTP(HyperText Transfer Protocol)

HTTP 메시지에 아래의 모든것이 담겨서 전송된다.

- HTML, TEXT

- IMAGE, 음성, 영상, 파일

- JSON, XML(API)

 

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

 

* TCP와 UDP 의 각 기반 프로토콜

- TCP : HTTP/1.1, HTTP/2

- UDP : HTTP/3

- 현재 HTTP/1.1 을 주로 사용한다. (HTTP/2, HTTP/3 도 점점 증가하고 있다.)

 

HTTP 의 특징

- 클라이언트 - 서버 구조이다.

- 무상태 프로토콜(Stateless) 이며, 비연결성의 특징을 가지고 있다.

- HTTP 메시지를 통해서 통신하며, 단순하고, 확장 가능하다.

 

* 클라이언트 서버 구조

- HTTP 통신은 클라이언트 서버 구조이다.

- 클라이언트에서 서버로 요청을 보내고(Request), 서버로부터 돌아오는 응답(Response) 을 클라이언트가 대기하는 방식으로 통신이 진행된다.

- 서버가 요청에 대한 결과를 만들어서 응답 메시지를 클라이언트로 전송한다.

단순해 보이지만 이와 같이 클라이언트, 서버로 분리를 해놓은 것이 굉장히 중요하다.

특히나 이렇게 분리를 함으로서 비즈니스 로직이나 데이터 같은 것들은 서버에 밀어넣고, 클라이언트 측은 UI 와 같은 사용성에 집중한다. 이렇게 설계하면 클라이언트 분야와 서버 분야가 각각 독립적으로 발전해 나갈 수 있다.

즉, 클라이언트와 서버는 서로 각각이 맡고 있는 책임에만 집중해서 기술을 발전시켜 나가면 되는 것이다.

 

무상태 프로토콜(Stateless)

- 서버가 클라이언트의 상태를 보존하지 않는다.(반대로 Stateful 은 서버가 클라이언트의 상태를 보존한다.)

- 장점 : 서버의 확장성이 높다(스케일 아웃)

- 단점 : 클라이언트가 추가 데이터를 전송해야 한다.

 

Stateful, Stateless 의 차이점

- 상태 유지 : 중간에 다른 서버로 변경되면 안된다.(중간에 다른 서버로 바뀔 때 상태 정보를 다른 서버에게 미리 알려줘야 한다.)

만약 클라이언트의 요청이 들어오던 도중 서버가 다운 되어버리면 클라이언트는 다른 서버에서 요청을 처음부터 다시 해야한다.

- 상태 유지(Stateful) : 항상 같은 서버가 유지되어야 한다.

- 무상태 : 중간에 다른 서버로 바뀌어도 된다.

갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

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

무상태(Stateless) - 아무 서버나 호출해도 된다.

이와 같은 장점들로 인해 무상태는 스케일 아웃, 즉 수평 확장에 유리하다.

 

* 하지만 무상태도 한계가 있다.

- 클라이언트에서 서버로 요청을 보낼 때 전송시켜야 하는 데이터의 양이 많다.

- 모든 것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있다.

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

- 상태 유지 : 로그인

- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지

- 일반적으로 브라우저와 쿠키와 서버 세션들을 사용해서 상태를 유지한다.

- 상태 유지는 최소한만 사용해야 한다.

 

* 비연결성(Connectionless)

연결을 유지하는 모델의 경우

TCP/IP 연결의 경우 기본적으로 연결이 유지된 상태로 계속 존재하게 된다.

그런데 여기서 서버와 연결하려는 클라이언트의 숫자가 많아지면 클라이언트 들과 계속해서 연결을 유지해야 하기 때문에 서버 입장에서는 지속적으로 서버의 자원이 소모된다.

이런 방식의 경우 단점은 한 클라이언트의 요청을 처리하는 동안에도 요청이 들어오지 않은 다른 클라이언트와의 연결을 계속 유지하고 있어야 한다는 것이다.

 

연결을 유지하지 않는 모델의 경우

TCP/IP 연결을 한 이후 클라이언트의 요청을 받고 해당 응답에 대한 처리가 완료되면 TCP/IP 연결을 종료시킨다.

(딱 서로 필요한 정도오만 요청과 응답을 주고 받고 끝내는 것이다.)

이후 다른 클라이언트들 에게도 똑같은 방식으로 요청에 대한 응답이 이루어지고 난 이후 TCP/IP 연결을 끊어버린다.

이렇게 통신 모델을 설계한 경우 서버 측에서는 클라이언트와 연결하고 응답을 처리해주는 과정에서 소모되는 자원을 최소화 시킬 수 있게된다.

 

* HTTP 비연결성 특징

- HTTP 는 기본적으로 연결을 유지하지 않는 모델이다.

- 일반적으로 초 단위 이하의 빠른 속도로 응답한다.

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

예시 : 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.

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

 

그런데 이 비연결성 특징은 한계가 있다.

- TCP/IP 연결을 매 요청마다 새로 맺어야 한다. - 3 way handshake 작업을 수행하는 시간이 추가된다.

- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드 된다.

- 지금은 HTTP 지속 연결(Persistent Connections) 로 문제가 해결되었다.

- HTTP/2, HTTP/3 에서 더 많은 최적화가 이루어졌다.

 

* HTTP 지속 연결(Persistent Connections) 의 경우 대략적인 소요 시간

무상태(Stateless) 를 기억하자.

서버 개발자들이 어려워하는 업무는 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽을 처리해야 하는 경우이다.

예시 : 선착순 이벤트, 명절 KTX 예약, 대학교 학과 수업 등록 등등

 

 

HTTP 메시지

HTTP 메시지 구조는 다음과 같다.

시작 라인

* 요청 메시지

- start-line : start-line 은 크게 request-line 과 status-line 으로 나뉘어져 있는데, 여기서 request-line 이 요청 메시지에 해당한다.

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

여기서 method 는 GET 과 같은 HTTP 메소드, request-target 은 요청 대상(/search?q=hello&hi=ko), HTTP-version 은 말 그대로 HTTP 버전을 의미한다.

 

* 요청 메시지 - HTTP 메소드

종류 : GET, POST, PUT, DEL 등

- 서버가 수행해야 할 동작을 지정한다.

    - GET : 리소스 조회, POST : 요청 내역 처리(리소스를 서버 측으로 넘겨줄 테니 요청을 처리해 달라는 의미)

 

* 요청 메시지 - 요청 대상

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

- 절대 경로는 "/" 로 시작하는 경로를 의미한다.

 

* 요청 메시지 - HTTP 버전

- HTTP Version 은 말 그대로 사용하는 HTTP 의 버전을 말한다.

 

* 응답 메시지

- start-line 에서 status-line 에 해당한다.

- status-line = HTTP-version SP, status-code SP, reason-phrase CRLF

- HTTP-version 은 HTTP 버전, status-code 는 HTTP 상태 코드를 의미한다.

(200 : 성공, 400 : 클라이언트 요청 오류, 500 : 서버 내부 오류)

- 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

 

 

* HTTP 헤더

- header-field = field-name ":" OWS, field-value OWS (OWS : 띄어쓰기 허용)

- field-name 은 대소문자 구분이 없다.

 

* HTTP 헤더의 용도

- HTTP 전송에 필요한 모든 부가정보가 들어있다.

예시 : 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등이 들어있다.

- 표준 헤더가 너무 많다.

- 필요시 임의의 헤더를 추가하는게 가능하다.(물론 그 경우 약속된 서버와 클라이언트 간에만 헤더의 내용을 이해할 수 있을 것이다.)

 

* HTTP 메시지 바디의 용도

- 실제 전송할 데이터가 포함된다.

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

 

* 단순하며 확장 가능하다는 특징

- HTTP 는 단순하다.

- HTTP. 메시지 또한 매우 단순하다.

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