HTTP

Judo·2021년 1월 28일
http
0

김영한님의 강의를 통해 배운 내용을 기록
강의 링크

HTTP

  • HyperText Transfer Protocol

  • HTTP 메시지에 모든 것을 전송할 수 있다.

    • HTML, TEXT
    • IMAGE, 음성, 영상, 파일
    • JSON, XML (API)
    • 거의 모든 형태의 데이터를 전송 가능
    • 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

    역사

  • HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X

  • HTTP/1.0 1996년: 메서드, 헤더 추가

  • HTTP/1.1 1997년: 가장 많이 사용

  • HTTP/2 2015년 : 성능 개선

  • HTTP/3 진행중 : TCP 대신 UDP 사용, 성능 개선

    HTTP 특징

  • 클라이언트 - 서버 구조

  • 무상태 프로토콜(stateless), 비연결성

  • HTTP 메시지

  • 단순함, 확장 가능

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

  • Request, Response 구조
  • 클라이언트는 서버에 요청을 보내고, 응답을 대기
  • 서버가 요청에 대한 결과를 만들어서 응답

과거엔 클라이언트와 서버가 통합되어 있었다. 하지만 시간이 지나면서 클라이언트와 서버가 분리되었다. 분리하면서 각자 독립적인 역할을 갖게 되었는데 클라이언트는 UI에 초점을 두고, 서버는 비지니스로직, 데이터에만 초점을 둔다. 이렇게 역할을 나누게 되면 각각 독립적으로 진화를 할 수 있어 좋다.

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

  • 서버가 클라이언트의 상태를 보존하지 않는다.
    • 상태 유지(stateful)
      • 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.)
    • 무상태(stateless): 중간에 다른 점원으로 바뀌어도 된다. 요청마다 고객이 필요한 정보를 다 넘기기 때문에
      • 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
      • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
      • 무상태는 응답 서버를 쉽게 바꿀 수 있다. => 무한한 서버 증설 가능
      • 스케일아웃(수평 확장 유리)
      • 중간에 서버에 장애가 발생해도 서버 변경 가능
  • 장점은 서버 확장성이 높다
  • 단점은 클라이언트가 추가 데이터 전송

stateless 실무 한계

  • 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
  • 무상태
    • 로그인이 필요없는 단순한 서비스 소개 화면
  • 상태 유지
    • 로그인
  • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
  • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
  • 상태 유지는 최소한만 사용

3. 비연결성(connectionless)

  • TCP/IP 는 기본적으로 연결을 유지한다.
    • 연결을 유지하게 되면 클라이언트의 요청이 없어도 계속 연결을 유지하기 때문에 서버 자원 소모가 크다.

연결을 유지하지 않는 모델

  • 요청 - 응답이 이루어지면 연결을 끊어버리는 방식
  • 이 방식은 서버는 연결 유지가 필요없기 때문에 최소한의 자원 사용
  • HTTP는 기본이 연결을 유지하지 않는 모델
  • 일반적으로 초 단위 이하의 빠른 속도로 응답
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
    • 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
  • 서버 자원을 매우 효율적으로 사용할 수 있다.

비연결성 한계와 극복

  • TCP/IP 연결을 새로 맺어야하는데 이는 3 way handshake 시간이 추가되어서 비효율적
  • 웹 브라우저로 사이트를 요청하면 HTML, CSS, JS, 이미지 파일 등 수 많은 자원이 함께 다운로드. 자원을 하나하나 요청할 때마다 연결 - 끊기 를 반복하면 너무 비효율적
  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결함
  • HTTP/2, HTTP/3에서 더 많은 최적화가 이루어짐.

HTTP 초기 - 연결, 종료 낭비

  • 각각 요청마다 연결, 종료를 반복하기 때문에 비효율적임.

HTTP 지속 연결(Persistent Connections)

  • 내부적으로 일정시간을 정해서 파일들을 다 받을때까지 연결을 유지한다. 전보다 효율적이다.

3. HTTP 메시지

시작라인(요청 메시지)

  • HTTP 메서드(GET: 조회)
    • 종류: GET, POST, PUT, DELETE
  • 요청 대상(/search?q=hello&hl=ko)
    • absoulte-path[?query]
    • 절대경로: "/"로 시작하는 경로
  • HTTP version(HTTP/1.1)

시작라인(응답메시지)

  • HTTP version
  • HTTP 상태코드
    • 200번대: 성공
    • 400번대: 클라이언트 요청 오류
    • 500번대: 서버 내부 오류
  • 이유문구: 사람이 이해할 수 있는 짧은 상태 코드 설명

HTTP 헤더

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

HTTP 메시지 바디

  • 실제 전송할 데이터
  • HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능
profile
Judo
즐거운 코딩
이전 포스트

URI와 웹 브라우저 요청 흐름

다음 포스트

HTTP 메서드

0개의 댓글