HTTP 기본

HTTP는?

• HTTP : HyperText Transfer Protocol
• HTML과 같은 하이퍼미디어 문서를 전송하기 위한 프로토콜이다, 웹 브라우저와 웹 서버간의 커뮤니케이션을 위해 디자인되었지만, 다른 목적으로 사용 가능하다.
• 이미지, 음성, 영상, 파일, JSON, XML(API) 등 거의 모든 형태의 데이터를 담아 전송할 수 있다.
• 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다고 한다.
  • TCP를 직접 연결하는 경우는 거의 게임 서버나 특수한 경우에만 사용한다.
• HTTP는 클라이언트가 요청을 생성하기 위한 연결을 한 다음 응답을 받을 때까지 대기하는 전통적인 클라이언트-서버 모델을 따른다.

HTTP의 역사

• HTTP/0.9 - 1991년 : GET 메서드만 지원, HTTP 헤더 X
• HTTP/1.0 - 1996년 : 메서드, 헤더 추가
• HTTP/1.1 - 1997년 : 가장 많이 사용하고 우리에게 가장 중요한 버전
  • 대부분의 기능이 다 들어있고 HTTP/2 와 HTTP/3는 거의 성능 개선에 초첨이 맞춰져있다.
• HTTP/2 - 2015년 : 성능 개선
• HTTP/3 - 진행중 : TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

• TCP : HTTP/1.1, HTTP/2 는 TCP 프로토콜 위에 동작한다.
• UDP : HTTP/3는 UDP 기반으로 동작한다.
• 현재는 HTTP/1.1을 주로 사용하고, HTTP/2와 HTTP/3도 점점 증가하는 추세이다.

HTTP의 특징

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

클라이언트 서버 구조

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

• 이전에는 분리하지 않았다.
• 지금은 비즈니스 로직과 데이터는 서버에 넣고, 클라이언트는 UI와 사용성에 집중하는 편이다.
• 이렇게 하면 클라이언트와 서버가 각자 독립적으로 진화할 수 있다는 장점이 있다.
• 예시로 사용자가 많아 DB를 고도화해야 한다면 클라이언트를 건드릴 필요 없이 서버만 최적화하면 된다.

무상태 프로토콜(Stateless)

• HTTP의 중요한 특징 중 하나는 무상태 프로토콜을 지향한다느 것이다.
• 서버가 클라이언트의 상태를 보존하지 않는다는 의미이다.
• 반대로 Stateful은 상태를 유지한다는 것을 의미한다.
• Stateful과 Stateless 차이
  • 매장에서 물건을 구매한다고 가정한다면
  • 상태 유지
    • 중간에 다른 점원으로 바뀌면 안 된다.
    • 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.
  • 무상태
    • 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
    • 무상태는 응답 서버를 쉽게 바꿀 수 있다.
• 무상태는 스케일 아웃이라고 하고, 수평 확장에 유리하다.
  • 큰 이벤트를 할 때 백엔드 장비를 수십대 이상 증가시켜서 해결할 수 있다.
• 실무에서의 한계
  • 모든 것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있다.
  • 무상태 예시) 로그인이 필요 없는 단순한 서비스 소개 화면
  • 상태 유지 예시) 로그인한 상태를 서버에 유지해줘야 할 때
  • 일반적으로 브라우저 쿠키와 서버 세션을 조합해서 상태를 유지한다.
    세션이 날라간다면 로그인이 풀린다.
  • 상태유지는 최소한으로만 사용하는게 좋다.
  • 웹 어플리에킹션을 설계할 때는 최대한 무상태로 설계하는 것을 원칙으로 한다.

비연결성(connectionless)

• TCP/IP는 기본적으로 연결을 유지한다.
  • 만약 클라이언트 1, 2, 3 과 서버가 연결되어 있는 상태에서 클라이언트 1, 2는 아무런 요청도 하지 않고 대기 중, 오직 클라이언트 3만이 요청을 하고 서버가 응답을 해주고 있는 상황에서도 클라이언트 1, 2 과 서버는 연결이 유지되어야 한다. 즉 서버 자원을 소모한다.
• 만약 연결을 유지하지 않는 모델이 있다면?
  • 서로 필요한 것만 주고 받고 즉시 연결을 끊는다.
  • 서버 입장에서는 요청을 주고 받을 때만 자원을 사용하면 된다.
  • 최소한의 자원으로 서버를 유지할 수 있다.
• 비연결성
  • HTTP는 기본이 연결을 유지하지 않는 모델이다.
  • 일반적으로 초 단위 이하의 빠른 속도로 응답한다.
  • 한 시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청하는 수십개 이하로 매우 작다.
    • 우리가 웹 서비스를 사용할 때 연속적으로 어떤 요청을 하지는 않기 때문이다.(티켓팅 같은 경우는 몰?루)
    • 웹툰을 예시로 들면 웹 페이지에서 웹툰 하나를 클릭한 후 화면 표시 되면 내가 원하는 회차를 선택하고 본다 와 같이 연속적인 행동이 이어지되 같은 버튼을 단시간에 여러번 누르는 경우는 극히 적다.
      • 서버 자원을 매우 효율적으로 사용할 수 있다.
• 비연결성의 한계
  • 요청을 할 때마다 TCP/IP 연결을 새로 맺어야 한다. -> 3 way handshake 시간이 추가된다.
  • 웹 브라우저로 사이트를 요청하면 HTML 만이 아니라 CSS, JavaScript를 포함한 이미지와 같은 많은 리소스가 함께 다운로드 된다.
  • 요청할 때마다 자원을 받고 연결을 끊으면 너무 비효율적이라 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결했다.
    • HTTP/2 와 HTTP/3 에서 더 많은 최적화가 이뤄졌다.
      • HTTP 초기에는 html을 받고 연결 종료 -> CSS 받고 연결 종료 -> JS 받고 종료 ... 반복
      • 현재는 HTTP 지속 연결을 통해 서버에 요청하고 다 받은 다음 종료된다.
• stateless가 중요하다고 한다.
  • 서버 개발자들이 가장 공들이는 업무라고 한다.
    • ex) 같은 시간에 대용량 트래픽이 발생하는 경우
  • 최대한 Stateless하게 설계하는게 중요하다
    • 그래서 첫 페이지는 로그인이 필요없는 정적 페이지를 하나 만든다.
    • 순수 HTML 파일만 두고, 그 페이지에서 사람들이 무언가 볼 수 있는 화면을 구성한 후 버튼을 누르게 유도한다.

HTTP 메시지

• HTTP는 요청 메시지와 응답 메시지의 구조가 약간 다르다.
  • 시작 라인 : 요청 메시지
    • 1) method 2) request-target 3) HTTP-version CRLF(Enter)
    • 1) HTTP 메서드
      • 종류 : GET, POST, PUT, DELETE 등
        • GET : 존재하는 자원에 대한 요청
        • POST : 새로운 자원을 생성
        • PUT : 존재하는 자원에 대한 변경
        • DELETE : 존재하는 자원에 대한 삭제
    • 2) request-target(요청대상)
      • absolute-path[?query] (절대경로[?쿼리])
      • 절대경로 = "/"로 시작하는 경로
    • 3) HTTP-version(HTTP 버전)
      • 말 그대로 버전이다. HTTP/1.1, HTTP/2 등
  • 시작 라인 : 응답 메시지
    • 1) HTTP-version 2) status-code 3) reason-phrase CRLF(Enter)
    • 1) HTTP-version
      • 위와 동일
    • 2) status-code(HTTP 상태 코드)
      • 200 : 성공
      • 400 : 클라이언트 요청 오류
      • 500 : 서버 오류
      • 물론 위에 적은 것외에도 상태 코드는 아주 많지만 대략적으로 앞자리(백의 자리)가 어떤 숫자냐에 따라 어떤 오류가 났구나 정도만 알아도 대강 괜찮은듯 하다.(정확한 코드는 필요할 때 구글에 치면 나온다)
        • 300 번대 : 리다이렉션 (클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도)
    • 3) reason-phrase(이유 문구)
      • 사람이 이해할 수 있는 짧은 상태 코드 설명 글
  • HTTP 헤더
    • header-field = field-name ":" OWS field-value OWS (OWS = 띄어쓰기 허용)
    • Host: www.google.com => 가능 , Host : www.google.com => 불가능
    • field-name는 대소문자 구분이 없지만 value는 있으니 주의
    • 용도
      • HTTP 전송에 필요한 모든 부가정보가 들어가 있다.
        • ex) 메시지 바디의 내용, 크기, 압축, 인증, 요청 클라이언트의 정보 등
      • 표준 헤더가 많다.
      • 필요 시 임의의 헤더를 추가할 수 있다. -> 약속한 클라이언트랑 서버만 이해 가능
  • HTTP 메시지 바디
    • 용도
      • 실제 전송할 데이터가 들어가 있다.
      • HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있다.

• 더 궁금할 경우 참조 [https://developer.mozilla.org/ko/docs/Web/HTTP]