본문 바로가기
IT개념/네트워크

[Network] HTTP에 대해

JongHyun99 2021. 7. 20. 15:07
728x90

HTTP란 (HyperTextTransferProtocol)

예전에는 문서간 링크로 연결되는 HTML 문서를 전송하는 프로토콜로 시작되었지만, 지금은 문서뿐만 아니라 모든 것을 HTTP로 전송을 하게 되었다. (HTML, TEXT, JSON, 이미지, 영상 등 거의 모든 형태의 데이터)

서버간 데이터를 통신할 떄도 대부분 HTTP 사용한다.

 

HTTP역사

  • HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 X
  • HTTP/1.0 1996년 : 메서드, 헤더 추가
  • HTTP/1.1 1997년 : 가장 많이 사용되는 버전
  • HTTP/2 2015년 : 성능 개선
  • HTTP/3 진행중 : UDP프로토콜 사용, 성능 개선

2와 3버전은 성능개선의 목적이 크기 때문에 1.1 버전의 공부 중요도가 높다.

 

기반 프로토콜

  • TCP : HTTP/1.1, HTTP/2
  • UDP : HTTP/3
  • 현재 HTTP/1.1를 주로 사용하나 HTTP/2, HTTP/3도 점점 증가한다.

 

클라이언트 서버 구조

HTTP는 클라이언트 서버 구조로 되어있다. (Request Response 구조)

클라이언트가 서버에 요청을 하게되면 응답이 올 때까지 대기하게 된다.

응답이 오면 그 결과로 클라이언트가 동작을 하게된다.

예전에는 클라이언트와 서버의 구분이 없었지만 지금은 구분되어 비즈니스 로직, 데이터 등은 전부 서버에 몰아주게 되고 클라이언트는 UI와 사용성에 집중하게 되었다.

이렇게 별개로 구분되어 통신이 이루어지다보니 클라이언트와 서버의 기술이 독립적으로 발전할 수 있어졌다.

그 덕분에 사용자단인 PC, 핸드폰(아이폰, 안드로이드 등), TV 등 복잡한 로직 필요 없이 UI와 사용성만 집중할 수 있게 됐다.

반대로 서버 단에서는 폭주하는 트래픽에서도 클라이언트를 손 댈 필요 없이 서버부분의 기술만 고민하면 되게 됐다.

 

상태유지, 무상태 프로토콜 (Stateful, Stateless)

상태유지 프로토콜

  • 서버가 클라이언트의 상태를 보존함

 

무상태 프로토콜

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

 

상태 유지 예시 - Stateful

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

 

중간에 점원이 바뀐다면?

  • 고객 : 이 노트북 얼마인가요?
  • 점원A : 100만원 입니다.
  • 고객 : 2개 구매하겠습니다.
  • 점원B : 무엇을 2개 구매하시겠어요?
  • 고객 : 신용카드로 구매하겠습니다.
  • 점원C : 무엇을 몇개를 신용카드로 구매하시겠어요?

 

무상태 예시 - Stateless

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

상태유지는 클라이언트에서 전송할 데이터가 간결하지만 중간에 점원이 바뀌게 되면 장애가 일어나게 된다. (중간에 바뀌게 되면 상태 정보를 미리 알려주어야 함)

무상태에서는 매번 필요한 데이터를 전송해주어야 하지만 중간에 점원이 바뀌어도 문제가 일어나지 않는다.

  • 갑자기 클라이언트가 증가해도 서버을 대거 투입할 수 있음
  • 무상태는 응답 서버를 쉽게 바꿀 수 있다. → 무한한 서버 증설 가능

무상태 프로토콜은 갑자기 서버가 장애가 일어나 교체를 하게 되어도 요청을 아무 지장 없이 처리할 수 있기에 스케일 아웃 (수평 확장)에 유리하다.

 

각 프로토콜 예시

  • 로그인이 필요 없는 단순한 서비스 소개 화면에서는 무상태 프로토콜 사용
  • 로그인이 필요한 서비스(개인정보조회 등)에는 상태유지 프로토콜 사용

로그인 등 의 상태를 세션, 쿠키 등을 이용하여 유지한다.

상태유지는 최소한만 사용하여야 함

 

비 연결성 (connectionless)

TCP/IP 경우에는 연결을 유지한다.

여러개의 클라이언트가 하나의 서버에 연결될 때 서버는 모든 클라이언트와 연결을 계속 해서 유지되어야 한다. 서버 자원이 소모되어 비효율적이다.

HTTP는 여기서 응답을 받은 직후 연결을 바로 끊어버린다. 즉, TCP/IP 통신 과정에서 연결을 받은 뒤 끊어버리는 것이다. 다시 연결을 해야하면 요청할 때 연결을 한다. 이것이 HTTP의 작동 원리이다.

이 방법으로 최소한의 자원으로 서버를 유지할 수 있다.

 

특징

  • HTTP는 연결을 유지하지 않는 모델
  • 일반적으로 초 단위 이하의 빠른 속도로 응답
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다
  • 서버 자원을 매우 효율적으로 사용할 수 있음

 

한계와 극복

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

 

HTML 지속연결

보통 응답을 받으면 HTTP는 연결을 끊어버리지만 (TCP를 끊음)

헤더에 아직 받을 데이터가 남아있으니 연결을 지속하겠다는 신호를 담아서 연결과 해제 과정 없이 데이터를 받아서 서버에서 문서를 받을 때 소요되는 시간과 자원을 아낄 수 있다. (keep-alive 헤더 등을 사용)

 

HTTP 메시지

 

HTTP 메시지 구조

  • 시작라인 (start-line)
  • 헤더 (header)
  • 공백 라인 (mpety line / CRLF)
  • 본문 (message body)

 

예) HTTP 요청 메시지

// HTTP 요청 메시지 예시
GET /search?q=hello&hl=ko HTTP/1.1  //시작 라인
HOST: www.google.com  //헤더
//공백 라인

(요청 메시지도 본문을 가질 수 있음)

 

 

예) HTTP 응답 메시지

// HTTP 응답 메시지 예시
HTTP/1.1 200 OK  //시작 라인
Content-Type: text/html;charset=UTF-8  //헤더
Content-Length: 3423                   //헤더

// 본문
<html>                 
    <body>..<body>
</html>

 

시작라인

요청 메시지

start-line : request-line

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

  • method : HTTP 메서드 표기 (GET : 조회, POST : 요청 내역 처리)
  • request-target : 요청 대상 절대경로 표기 (/search?q=hello&hi=ko)
  • HTTP Version : HTTP 버전 표기 (HTTP/1.1)

 

응답 메시지

 

start-line : status-line

status-line : HTTP-version SP status-code SP reason-pharse CRLF

  • HTTP-version : http 버전 표기
  • status-code : 상태코드 (200 : 성공, 400 : 클라이언트 요청 오류, 500 : 서버 내부 오류)
  • reason-pharse : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

 

HTTP 헤더

  • header-field = field-name ":" OWS field-value OWS (OWS는 띄어쓰기를 해도 되고 안해도 된다는 뜻)
  • filed-name은 대소문자 구분 없음

 

용도

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

 

HTTP 메시지 바디

헤더에서 한칸 띄우고 바디가 들어간다.

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

'IT개념 > 네트워크' 카테고리의 다른 글

[Network] 1-1. 데이터 통신과 통신망  (0) 2022.03.05
[Network] HTTP 상태코드  (0) 2021.07.27
[Network] URI와 웹브라우저 요청 흐름  (0) 2021.07.20
[Network] 인터넷 통신규칙(프로토콜)  (0) 2021.07.20
[Network] Proxy Server  (0) 2021.07.19

'IT개념/네트워크' Related Articles

티스토리툴바