히히심 2024. 11. 29. 17:32
728x90

1. HTTP (HyperText Transfer Protocol) 

: HTTP 메시지에 모든 것을 전송한다. (HTML, TEXT, IMAGE, 영상, 음성, 파일, JSON, XML...) 

 

HTTP 역사

- HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더X
- HTTP/1.0 1006년 : 메서드, 헤더 추가
- 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도 점점 증가하고 있다.

Protocol에 h2, h3가 적용되어 있는 걸 볼 수 있다.

 

2. HTTP 특징

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

 

1) 클라이언트 서버 구조

  • Request - Response 구조
  • 클라이언트는 ? 서버에 요청을 보내고, 응답을 대기한다.
  • 서버는 ? 요청에 대한 결과를 만들어서 응답한다. 
  • 클라이언트와 서버를 분리한다는 개념. 양쪽이 독립적으로 진화가 가능하다.

 

2) 무상태 프로토콜 (Stateless)

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

ex) Stateful (상태 유지) vs. Stateless (무상태)

- Stateful 상태 유지는 서버가 클라이언트의 이전 상태를 보존한다. 중간에 점원이 바뀌면 안된다

즉, 응답 서버를 쉽게 바꿀 수가 없다

Stateful

 

- Stateless 무상태는 서버가 클라이언트의 이전 상태를 보존하지 않으므로 점원이 중간에 바뀌어도 같은 결과이다. 

즉, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있으므로, 무한한 서버 증설이 가능하다!!

Stateless

Stateless 실무 한계
- 모든 것을 무상태로 설계가 가능한 것은 아니다.  
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 한다.. -> 일반적으로는 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지. 
- 상태 유지는 최소한만 사용.

 

3) 비연결성 (connectionless) 

- 서버가 연결을 계속 유지하면 서버의 자원이 계속 소모된다. 

- 서버가 연결을 유지하지 않으면 (비연결성) 최소한의 자원을 유지한다. 

 

  • HTTP는 기본적으로 연결을 유지하지 않는 모델. 
  • 일반적으로 초 단위 이하의 빠른 속도로 응답. 
  • ex. 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음.. 
  • 서버 자원을 매우 효율적으로 사용할 수 있음. 
(여기서 호기심...!!!? 티켓팅 할 때에는 같은 요청을 수천명이 한 번에 요청을 하게되는데 이때는 어떤 식으로 처리하는 걸까?? 궁금하다) 라고 썼는데 김영한님이 강의 끝에 추가 설명을 해주셨다. 
이럴 때에는 최대한 stateless하게 설계하는 것이 중요하다. 그래야 대용량 트래픽이 올 때 서버를 확 늘려서 대응할 수 있게 된다. 
그래서 보통 첫 페이지는 로그인도 필요없는 정적 페이지를 넣고 (아무 상태가 없는) 그 안에서 이벤트 참여 버튼을 누르게 하거나 한다...! 
이에 대해서는 좀 더 공부하며 따로 글을 적어보려고 한다. 

 

- 비연결성의 한계와 극복

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

 

4) HTTP 메시지

 

- 시작 라인 (start-line)

a) 요청 메시지 (request-line) 

  • request-line = method SP(공백) request-target(path) SP HTTP-version CRLF(엔터)
  • 1) method 메서드 : HTTP 메서드 (GET, POST, PUT, DELETE) 
  • 2) request-target 요청 대상 : / 절대경로 absolute-path [?query]
  • 3) HTTP-version HTTP 버전

b) 응답 메시지 (status-line)

  • status-line = HTTP-version SP status-code SP reason-phrase CRLF
  • 1) HTTP-version HTTP 버전
  • 2) status-code HTTP 상태 코드 : 요청 성공/실패를 나타냄 (200: 성공, 400: 클라이언트 요청 오류, 500: 서버 내부 오류)
  • 3) reason-phrase 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글 

 

- HTTP 헤더 (header)

a) 헤더 분석

  • header-field = field-name":" OWS(띄어쓰기 허용) field-value OWS
  • 1) field-name (대소문자 구분 없음)
  • 2) field-value (대소문자 구분)

b) 용도

  • HTTP 전송에 필요한 모든 부가정보
  • ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시 관리 정보
  • 표준 헤더가 너무 많음
  • 필요시 임의의 헤더 추가 가능

- 메시지 바디 (message body)

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

 

 

 

 


** 해당 내용은 김영한님의 강의를 수강하며 정리한 것입니다.

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

 

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

김영한 | 실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., [사진] 📣 확인해주세요!본 강의는 자바 스프링 완전 정복 시리즈의 세 번째 강의입니다. 우아한형제들 최연

www.inflearn.com

 

 

[사담 part : 아무것도 모르고 요청 응답 형식을 다시 짚어서 배우니 이해가 쏙쏙 된다. 포스트맨으로 API 요청 시 조작했던 부분들이 이런 형식으로 구성되어 있었다는 것...! 그리고 무상태성의 중요성이 서버 증설을 위한 것이었다는 것! 그래서 최대한 무상태성을 유지하며 개발하는 방법을 찾아야 한다는 것이다. 그래야 다른 서버로 대체가 가능하니까~!~! ]

728x90