[TIL] HTTP와 HTTP의 특징

 

🤓배움 요약하기

HTTP가 무엇인가요?
HTTP는 HTML이나 리소스를 전송하기 위한 프로토콜입니다. 

HTTP의 특징과 장점은 무엇인가요?
서버가 클라이언트의 상태를 보관하지 않는 stateless하다는 특징에서 서버의 확장성을 높일 수 있다는 장점이 있습니다.
그리고 연결을 유지하지 않는 비연결성이라는 특징에서 서버 자원을 효율적으로 사용할 수 있다는 장점이 있습니다. 

HTTP 메세지 구조에 대해서 알려주세요.
HTTP는 시작라인, 헤더, 공백, 메세지 바디로 구성되어 있습니다.
request의 시작라인에는 HTTP 메서드, 요청대상, HTTP Version이 들어있고, response의 시작라인에는 HTTP Version과 응답코드가 들어있습니다. 
헤더에는 HTTP 전송에 필요한 모든 부가정보가 들어있습니다. 
메세지 바디는 실제 전송할 데이터가 들어있습니다. 

 

✔️ HTTP란?

HTTP(HyperText Transfer Protocol)는 HTML이나 Text를 문서 간의 링크를 통해서 연결할 수 있는 프로토콜

 

- 지금은 모든 것을 이 HTTP 프로토콜에 담아서 전송한다. 

- HTML, Text 뿐만 아니라 이미지, 음성, 영상, 파일, JSON, XML(서버끼리 통신할 때 사용) 등등 거의 모든 형태의 데이터를 전송할 수 있다. 

- 서버 간에 데이터를 주고 받을 때오 대부분 HTTP를 사용한다

지금은 HTTP 시대!

---

✔️ HTTP 역사

• HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년 : 메서드, 헤더 추가
• HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전 (대부분의 기능이 들어있음)
• HTTP/2   2005년 : 성능 개선
• HTTP/3     진행중 : TCP 대신 UDP 사용, 성능 개선

 

---

✔️ 기반 프로토콜

• TCP : HTTP/1.1, HTTP/2는 TCP위에 동작한다.  
• UDP : HTTP/3는 UDP 기반으로 개발되어있다. (TCP는 3way-handshake, 기본적으로 내장되어있는 데이터 많음, 자체가 속도가 빠른 메커니즘이 아님 ) => UDP 프로토콜 위에 그냥 성능 최적화를 해서 나온 것이 HTTP/3이다. 

---

✔️ HTTP의 특징

1. 클라이언트와 서버 구조

클라이언트가 HTTP 메세지를 통해 서버에 요청하고, 응답이 올때까지 기다린다. 

서버가 요청에 대한 결과를 만들어서 응답을 하면 응답 결과를 받고 클라이언트가 동작한다. 

 

클라이언트과 서버를 개념적으로 분리시키는 것이 중요하다!

비지니스 로직이랑 데이터 같은 것들은 모두 서버에 밀어넣는다. 그리고 클라이언트는 UI와 사용성에 집중한다. 

👉 이렇게 되면 클라이언트와 서버가 각각 독립적으로 진화할 수 있다.

 

클라이언트는 복잡한 데이터를 다룰 필요가 없고 그냥 UI를 어떻게 그릴지에 집중할 수 있고, 

서버는 트래픽이 초과가 되면 클라이언트는 상관없이 서버의 아키텍처를 어떻게 할지, 백엔드 코드를 어떻게 고도화할지 만을 고민하면 된다.  

 

2. 무상태 프로토콜(stateless)

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

 

◆ 장점

서버의 확장성이 높기 때문에 무한한 서버 증설이 가능하다. (스케일 아웃)

 

◆ 실무 한계 & 단점

1. 클라이언트가 추가 데이터 전송

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

 

ex)

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

 

로그인 👉 상태 유지

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

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

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

 

3. 비연결성

case1. 연결을 유지하는 모델

지금 당장 사용하지 않아도 클라이언트와 서버는 연결을 유지하고 있다. 그래서 서버의 자원이 계속 소모된다는 단점이 있다. 

 

case2. 연결을 유지하지 않는 모델

요청하고 응답받으면 볼일 끝났으니까 연결을 끊는다. 그래서 서버는 유지하는 자원을 최소한으로 줄일 수 있다.

 

• HTTP는 기본적으로 연결을 유지하지 않는 모델이다. 
• 일반적으로 초 단위 이하의 빠른 속도로 응답할 수 있다. 
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다. (수천개의 클라이언트와 연결되어 있는게 아니니까)

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

• 장점 : 서버 자원을 매우 효율적으로 사용할 수 있다. 

 

◆ 실무 한계 & 단점

• TCP/IP 연결을 새로 맺어야 한다. (3 way handshake 시간이 추가되서 사용자 입장에서는 단점.)
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수많은 자원이 함께 다운로드되는데 이때마다 3 way handshake 시간이 추가된다. 
• 지금은 HTTP 지속 연결(persistent connections)로 문제 해결하고 있다. 
• HTTP/2, HTTP/3에서 더 많은 최적화가 되었다.

 

4. HTTP 메시지

HTTP 메세지 구조

공식 스펙

HTTP-message = start-line

                               *(header-field CRLF)

                              CRLF

                               [message-body]

 

---

■시작 라인 (요청 메세지)

start-line = request-line / status-line

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

 

• HTTP 메서드 = 서버가 수행해야할 동작을 지정한다. 

(GET: 리소스 조회 / POST: 요청 내역처리 /PUT: 전체 수정/ PATCH: 부분 수정/ DELETE: 삭제)

• 요청대상 (/search?q=hello&hl=ko) = absolute-path라고 하는 절대경로로 시작한다. (절대경로는 '/'로 시작하는 경로임)
• 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 전송에 필요한 모든 부가정보가 들어있다. (메세지 바디 빼고 필요한 메타 데이터가 다 들어있다고 생각하자!)

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

• 표준 헤더가 너무 많다.
• 필요시 임의의 헤더 추가가 가능하다. (약속한 클라이언트와 서버만 이해할 수 있게 된다. )

 

■HTTP 바디

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

 

5. 단순함, 확장 가능 

• HTTP는 단순하다.
• HTTP 메세지도 매우 단순하다.
• 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술이다. 

 

 

 

---

😃 잘못된 개념 전달이 있다면 댓글 부탁드립니다. 저의 성장에 큰 도움이 됩니다🤓