정리 노트

HTTP 프로토콜 본문

개념 정리

HTTP 프로토콜

꿈만 꾸는 학부생 2023. 7. 21. 17:24
728x90

이 포스트는 국민대학교 소프트웨어학부 '컴퓨터 네트워크' 강의를 듣고 요약하는 포스트입니다. 원하시는 정보가 없을 수도 있습니다. 이 점 유의 바랍니다. 오류 지적은 매우 환영합니다!


HTTP(HyperText Transfer Protocol)

HTTP 프로토콜은 기본적으로 서버-클라이언트 구조에서 사용하는 프로토콜입니다.

프로토콜을 통해 클라이언트는 URL 경로 상에 있는 서버의 저장소의 것을 요청하고 서버는 요청한 클라이언트에서 객체(웹 페이지 같은 것)를 줍니다. 그렇기에 HTTP 프로토콜에서는 기본적으로 요청(request)과 응답(response)이 존재합니다.

HTTP/(version)

HTTP 프로토콜은 내부적으로 TCP 프로토콜을 사용합니다. 클라이언트에서 HTTP 프로토콜을 통한 서버와의 연결을 초기화할 때, 내부적으로 TCP 연결이 이루어집니다. 서버와 데이터를 주고받는 것이 끝나면 TCP 연결을 닫습니다. 위와 같은 연결 방식을 non-persistent(HTTP/1)한 방식이라고 합니다. 이 방식은 서버에서 1개의 객체를 받을 때마다 1개의 connection을 연결해야 합니다. 즉, 여러 객체(파일)를 받으려면 총 HTTP 응답 시간은 (2 *  RTT(packet이 클라이언트와 서버 사이를 왔다 갔다 하는 시간) + 객체(파일) 전송 시간) * 객체 수입니다.

Persistent(HTTP/1.1)한 방법을 사용하면, 하나의 connection에서 여러 객체를 주고받을 수 있습니다. 즉 여러 객체를 받으면 총 HTTP 응답 시간은 2 *  RTT + 객체(파일) 전송 시간 * 객체 수가 됩니다. 그리고 HTTP/1.1부터는 pipelining을 통해 여러 요청을 한 번에 다룰 수 있게 됩니다.

source: https://velog.io/@pppp0722/HTTP-1.0-1.1-2.0-%ED%86%B5%EC%8B%A0-%EC%B0%A8%EC%9D%B4
source: https://velog.io/@pppp0722/HTTP-1.0-1.1-2.0-%ED%86%B5%EC%8B%A0-%EC%B0%A8%EC%9D%B4

여러 개의 데이터를 요청할 때, 보내주는 데이터의 용량에 따라 전송 시간에 차이가 생깁니다. HTTP/1.1 까지는 요청한 순서대로 처리하기 때문에 만약 클라이언트에게 처음으로 보내주는 데이터의 용량이 매우 큰 경우, 다음에 보내줄 데이터의 용량은 매우 적더라도 이전의 데이터 전송이 끝날 때까지 기다려야 합니다. 이러한 문제를 HOL(Head-Of-Line blocking) 문제라 하는데, 이를 해결하기 위해 HTTP/2 가 등장합니다.

source: https://withbundo.blogspot.com/2021/02/httphol-head-of-line-blocking.html

HTTP/2에서는 전송할 데이터들을 프레임 단위로 나눠서 프레임 별로 전송해 HOL 문제를 최소화했습니다.

HTTP/2 예시 그림

예를 들어 클라이언트에서 O1, O2, O3 순서로 객체들을 서버에 요청했다고 합시다. 요청받은 객체들은 프레임 별로 나눠서 O1 프레임 -> O2 프레임 -> O3 프레임 순서로 클라이언트에게 보내집니다. 이렇게 보내면 용량이 적은 O2 데이터를 클라이언트가 먼저 받을 수 있게 됩니다. 이런 방식을 통해 HTTP/2는 HOL 문제를 최소화했습니다.

 

추가적으로, 3년 전에 HTTP/3가 새로 공개됐다고 합니다. 이 포스트를 적고 있는 지금 알게 된 사실이고, 현재 이에 대한 글들을 읽는 중입니다. HTTP/3에 대해 궁금하신 분들은 아래의 글을 읽어보시길 바랍니다.

 

HTTP/3는 왜 UDP를 선택한 것일까?

는 의 세 번째 메이저 버전으로, 기존의 HTTP/1, HTTP/2와는 다르게 UDP 기반의 프로토콜인 을 사용하여 통신하는 프로토콜이다. HTTP/3와 기존 HTTP 들과 가장 큰 차이점이라면 TCP가 아닌 UDP 기반의 통

evan-moon.github.io

메시지 형식

HTTP 요청 메시지의 형식은 아래의 그림과 같습니다.

source: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=allstar927&logNo=90161809512

그리고 응답 메시지 형식은 아래의 그림과 같습니다.

source: https://www.geeksforgeeks.org/state-the-core-components-of-an-http-response/

HTTP와 state

HTTP 프로토콜은 클라이언트의 상태(state)를 저장하지 않습니다. 이러한 특징을 stateless 하다고 합니다. 프로토콜에서 클라이언트의 상태를 저장하지 않기 때문에 서버나 클라이언트에서 여러 방법을 통해 상태를 저장합니다.

쿠키(cookie)

클라이언트가 초기에 특정 사이트에 접속하면 서버에서 클라이언트의 웹 브라우저에 작은 데이터 조각을 전송하는데, 이를 쿠키라 합니다. 브라우저는 쿠키를 저장해 놓았다가, 동일한 서버에 재 요청 시 가지고 있던 쿠키를 같이 전송합니다. 서버에서는 요청으로 들어온 쿠키를 가지고 이전의 요청과 지금 들어온 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단합니다. 이를 이용하면 클라이언트의 상태를 유지할 수 있습니다.

 

쿠키는 다음과 같은 정보들을 가지고 있습니다.

  • Name: 쿠키 이름
  • Value: 쿠키 값
  • Expires: 쿠키 만료 날짜
  • Domain: 쿠키가 사용하는 도메인
  • Path: 쿠키 반환 경로
  • Secure: 보안 연결 설정
  • HttpOnly: HTTP 외의 다른 통신 프로토콜에서 사용 가능 여부 설정

세션(Session)

쿠키를 얘기하면 항상 같이 나오는 것으로 세션이 있습니다. 세션은 쿠키를 기반으로 하지만 정보를 서버 측에 저장한다는 점에서 차이를 가지고 있습니다. 서버에서 관리하므로 클라이언트 측에 저장하는 쿠키보다 보안은 좋지만 세션이 많아질수록 서버 측의 메모리도 많이 필요해진다는 점이 있습니다.

 

참고 자료

쿠키와 세션의 개념: https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies

 

HTTP 쿠키 - HTTP | MDN

HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이

developer.mozilla.org

쿠기의 구성 요소: https://velog.io/@xchdtk/HTTP-%EC%BF%A0%ED%82%A4Cookie-%EC%84%B8%EC%85%98Session%EC%9D%98-%EC%9D%B4%ED%95%B4

 

[HTTP] - 쿠키(Cookie)의 이해

HTTP 쿠키(Cookie) 쿠키(Cookie)란? HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한

velog.io

 

728x90

'개념 정리' 카테고리의 다른 글

KDD(Knowledge Discovery in Database)  (0) 2023.09.04
이메일 프로토콜  (0) 2023.07.25
간단한 데이터베이스의 설계 설명  (0) 2023.07.16
Bloom Filters  (0) 2023.06.13
Reservoir Sampling  (0) 2023.06.11