네트워크 심화 - HTTP

YoungJoon Suh·2022년 4월 20일
0

HTTP/1.1, HTTP/2는 TCP 기반이며 HTTP/3는 UDP 기반 프로토콜입니다.
HTTP의 특징
1. 클라이언트 서버 구조

  • Request Response 구조
  • 클라이언트는 서버에 요청을 보내고, 응답을 대기
  • 서버가 요청에 대한 결과를 만들어 응답
  1. 무상태 프로토콜 (Stateless), 비연결성 (Connectionless)
    HTTP에서는 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜입니다.
    장점: 서버 확장성 높음 (스케일 아웃)
    단점: 클라이언트가 추가 데이터 전송
    점원 A가 고객의 상태를 기억하고 있는 것을 상태를 유지하다고 합니다.
    무상태에서는 고객이 자신의 주문을 기억하고 있다면 중간에 다른 점원으로 바뀌어도 주문을 할 수 있습니다.
    만약 갑자기 고객이 증가하더라도 무상태에서는 점원을 대거 투입할 수 있습니다.
  • 상태 유지: 중간에 다른 점원으로 바뀌면 안됨.
    (중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.)

  • 무상태: 중간에 다른 점원으로 바뀌어도 된다.
    갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
    갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
    무상태는 응답 서버를 쉽게 바꿀 수 있다. 무한한 서버 증설 가능
    앞서 말한 예제처럼 상태 유지가 되어야 하는 프로토콜이라면 클라이언트 A의 요청을 서버 1이 기억하고 있기 때문에 항상 서버 1이 응답해야합니다.
    만약 서버 1이 장애가 난다면 유지되던 상태 정보가 다 날아가 버리므로 처음부터 다시 서버에 요청해야 합니다.
    무상태 프로토콜이라면 클라이언트 A가 요청할 때 이미 필요한 데이터를 다 담아서 보내기 때문에 아무 서버나 호출해도 됩니다.

만약 서버 1에 장애가 생기더라도 다른 서버에서 응답을 전달하면 되기 때문에 클라이언트는 다시 요청할 필요가 없습니다.
무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능합니다.

무상태의 한계
로그인이 필요 없는 단순한 서비스 소개 화면은 무상태로 설계할 수 있다.
로그인이 필요한 서비스라면 유저의 상태를 유지해야 하기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지합니다. 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지(e.g. 브라우저 쿠키, 서버 세션)
상태 유지는 최소한만 사용

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

TCP/IP의 경우 기본적으로 연결을 유지합니다.
연결을 유지하는 모델에서는 클라이언트 1, 2는 요청을 보내지 않더라고 계속 연결을 유지해야 합니다. 이러한 경우 연결을 유지하는 서버의 자원이 계속 소모가 됩니다.

비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고나면 TCP/IP 연결을 끊습니다. 이를 통해 최소한의 자원으로 서버 유지를 가능하게 합니다.

비 연결성 - connectionless

  • HTTP는 기본이 연결을 유지하지 않는 모델
  • 일반적으로 초 단위 이하의 빠른 속도로 응답
  • 1 시간 동안 수천명이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음. (e.g. 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.)

트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동합니다.
트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 비연결성은 한계를 보입니다.

비 연결성 - Connectionless
한계와 극복

  • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드
  • 해당 자원들을 각각 보낼 때마다 연결 끊고 다시 연결하고를 반복하는 것은 비효율적이기 때문에 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결합니다.
  • HTTP/2, HTTP/3에서 더 많은 최적화

HTTP 초기에는 각각의 자원을 다운로드하기 위해 연결과 종료를 반복해야 했습니다.

HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료합니다.

  1. HTTP 메시지
  2. 단순함, 확장 가능
profile
저는 서영준 입니다.

0개의 댓글