김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의 내용을 정리한 노트입니다. 블로그에 있는 자료를 사용하실 때에는 꼭 김영한님 강의 링크를 남겨주세요!

1. HTTP

1-1. HTTP 개요

HTTP

• HTML을 전송하는 프로토콜에서 시작
• 음성, 이미지, 영상, 파일부터 시작해서 JSON, XML 등 거의 모든 형태의 데이터 전송 가능
• 서버간 데이터를 주고 받을 때도 대부분 HTTP 사용
• HTTP/1.1 버전을 가장 많이 사용, 가장 중요한 버전 → 여기에 모든 기능, 스펙이 들어 있음
  • 대다수의 네트워크 관련된 책들은 RFC2616 버전으로 기술되어 있지만 우리는 신규 스펙인 RFC 7230~7235 버전을 봐야 함
  • 물론 HTTP/2, 3 버전도 구글과 네이버를 중심으로 많이 사용되고 있음
• 기반 프로토콜
  • 1.1 버전과 2버전은 TCP, 3버전은 UDP 기반

HTTP 특징

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

2. HTTP의 핵심 특징

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

클라이언트 서버 구조

• 쉽게 말해서 클라이언트와 서버를 분리함.
• 비즈니스 로직과 데이터는 서버에, 클라이언트는 UI를 그리고 사용성에 좀 더 집중하는 구조 → 이러한 구조로 인해 클랑이언트와 서버가 독립적으로 진화 가능
• 서로 관리하는 영역이 달라지고 불필요한 것들에 대해서 신경 쓰지 않아도 되기 때문에 서버와 클라이언트는 자기들이 맡은 부분에만 집중할 수 있음

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

• 서버가 클라이언트의 상태를 보존 하지 않음

• 보다 쉬운 예시로 stateless를 이해해보자!

• stateful 예시

  

  • 점원은 고객의 상태를 기억(보존)하고 있음 → 그렇기 때문에 최종 구매에 고객은 결제 수단(신용카드)만 말하면 점원은 알아서 200만원을 긁으면 됨.

• stateless 예시

  

  • 고객이 요청할 때 마다 점원이 바뀐다고 생각해보자

  • 점원이 고객의 상태를 알지 못함(고객의 상태를 유지하지 않음) → 고객이 현재 자신의 상태에 대한 정보를 주지 않으면 점원은 고객이 무슨 응답을 필요로 하는지 알 수 없음 → 점원이 고객에 대한 상태를 보존하지 않기 때문에 고객은 자신의 상태에 대한 정보를 전달해야 함.

    

• stateless와 stateful의 차이

  • stateful은 서버가 클라이언트의 상태를 보존하고 있음 → 다른 점원(서버)로 바뀌게 되면 문맥(context)가 사라짐 → 즉, 다른 점원(서버)로 바뀌면 안됨.
  • 반대로 stateless는 중간에 점원이 바뀌어도 문맥이 끊기지 않음
  • 갑자기 고객이 증가해도 점원을 대거 투입 가능 → 고객이 자신의 상태를 전달하기 때문에 점원은 고객의 상태를 몰라도 응대에 문제가 없기 때문 → 클라이언트의 요청이 늘어나도 서버를 늘릴 수 있음
  • 이것에 대한 강점으로 응답 서버를 쉽게 바꿀 수 있음!

• stateful 도식화

  

  • 요청을 보낸 클라이언트A는 반드시 서버1이 응답해야 함

• stateless 도식화

  

  • 클라이언트는 자신의 상태에 대한 정보와 요청을 같이 서버에 보냄 → 서버1이 응답해도 되지만, 전담하지 않음(서버2, 3이 응답해도 문제 없음)
  • 서버는 응답만 하고 상태는 보관하지 않음.
  • 서버1이 죽어도 클라이언트의 상태에 대한 정보가 있기 때문에 서버2가 자연스럽게 응답해도 문제가 없음
  • 이러한 이유로 스케일 아웃(수평 확장)에 유리 → 어차피 다른 녀석이 응답할텐데 같은 기능을 하는 서버군을 여러 개 늘릴 수 있음

• 실무 한계

  • 로그인의 기능 같은 경우 상태를 유지해야 함 → 서버가 로그인을 했다는 상태를 가지고 있어야 함.
  • 이러한 한계를 극복하기 위해 브라우저의 쿠키와 서버의 세션을 사용
  • 상태 유지는 최소한, 어쩔 수 없을 때 사용
  • 클라이언트가 매번 자신의 상태를 보내기 때문에 클라이언트 쪽에서 데이터가 많이 전송됨.

2-3. 비연결성

연결유지모델

• 클라이언트와 서버가 통신하지 않아도 계속 연결을 유지하고 있는 모델
• 서버가 계속 연결을 유지하고 있기 때문에 서버의 자원이 크게 낭비됨

연결을 유지하지 않는 모델

• 요청, 응답이 종료되면 tcp, ip 연결을 끊어버림
• 서버는 연결을 유지할 필요가 없으며 최소한의 자원만 유지
• HTTP는 기본적으로 연결을 유지하지 않는 모델
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
• 서버 자원을 효율적으로 사용할 수 있음
• 매번 요청이 올 때마다 TCP/IP 연결을 새로 맺어야 함 → 3 way handshake를 매번 진행 → HTTP의 지속 연결(Persistent Connections)로 문제 해결
  • 지속 연결 : HTML 페이지 하나를 받을 때 까지 일단 연결은 해놓음 → 하나의 요청과 응답이 끝날 때마다 연결 종료가 아니라 일단 연결 해놓고 일정 시간뒤 연결을 끊어버리는 등의 방법을 이용
• stateless → 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 → 서버 개발자들이 어려워하는 업무
  • 최대한 stateless하게 설계해야 함
  • 가령, 첫 페이지는 로그인이 필요없는 정적 페이지 → 여기서 참여 버튼을 누르게 하는 방식등으로 설계

3. HTTP 메시지

HTTP 메시지 구조

• 공백 라인은 무조건 있어야 함.

시작라인

• HTTP 메소드 : 서버가 수행해야할 동작을 의미
• 요청 대상은 절대 경로에 query를 붙여서 들어감. 그 뒤에는 HTTP version이 들어감
• status code : 요청 처리 결과를 나타냄

HTTP 헤더

• HTTP 전송에 필요한 모든 부가 정보
• body 빼고 필요한 메타정보가 들어가 있음
• 필요하다면 임의의 헤더를 넣을 수 있음

HTTP 메시지 바디

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

블로그에 있는 자료를 사용하실 때에는 꼭 김영한님 강의 링크를 남겨주세요!
(강의 링크 : https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard)