-
HTTP 웹 기본 지식 3편CS/네트워크 2024. 12. 1. 23:06
HTTP (Hyper Text Transfer Protocol)
- HTTP란 웹 상에서 클라이언트와 서버 간에 데이터를 주고 받기 위한 프로토콜(약속)이다.
- HTTP에 담을 수 있는 데이터:
- HTML, TEXT, 이미지, JSON 등 거의 모든 형태의 데이터 전송 가능하다.
- 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용
- 지금은 "HTTP 시대".
단, 특수한 경우 TCP를 직접 사용해서 전달할 수도 있다. - 1997년에 만든 HTTP/1.1 를 잘 알아두어야 한다. 그 이유는 아직까지 잘 먹히니께 + 그것의 연장선이여
HTTP 특징
- 클라이언트 <-> 서버 구조
- 무상태 프로토콜(stateless)
- 비연결성
- 단순함 확장 가능
이제부터 특징을 하나씩 자세히 알아보자.
클라이언트와 서버 구조
- 클라이언트는 Request(요청)을 서버에 날리고 응답을 대기
- 서버는 요청에 대한 결과를 만들어 Response(응답)을 클라이언트에 보낸다.
클라이언트-서버 구조의 주요 장점 중 하나는, 클라이언트와 서버가 독립적으로 작동할 수 있다는 점이다.
클라이언트는 요청/응답만 신경:
클라이언트는 HTTP 요청을 보내고 응답을 받을 뿐, 서버 내부에서 어떤 로직이 실행되는 지 알 필요가 없다.
예를 들어, 클라이언트가 요청을 보낸다면, 서버가 데이터베이스 구조를 바꾸거나, 캐싱을 도입하거나, 등등
서버 로직을 최적화해도 응답만 동일하다면 클라이언트에는 영향이 없다. 단, 요청/응답 규칙만 지키면된다.
따라서 서버 로직의 자유로운 변경이 가능하다.무상태 프로토콜 (Stateless)
- 서버가 클라이언트의 상태를 보존하지 않는다.
- 장점: 서버 확장성이 높다. (스케일 아웃)
- 단점: 클라이언트가 추가 데이터 전송이 필요하다.
그렇다면 왜 서버가 클라이언트의 상태를 보존하지 않는다는 점이 서버 확장성이 높은 지 알아보자.
예를 들어, 철수가 시장에 가서 사과 2개를 사려고 한다.
철수: 사과 얼마예요.
직원1: 1,000원입니다.
(직원1이 배 아파서 화장실을 가버렸다.)
철수: 2개 주세요. 카드로 결제할게요.
직원2: 어떤 거 2개 드릴까요?
위 대화에서 직원1과 직원2는 다른 사람이다. 그 둘은 의사소통을 하지 않아. 철수가 원하는 걸 모른다. 따라서 직원2가 어떤 거를 2개 드릴까요 라고 물어본 것이다.
아래 예시를 보자.
철수: 사과 2개 카드로 결제할게요 -> 클라이언트의 추가 데이터
직원1: 네, 2,000원 결제 하겠습니다.
철수가 "사과 2개를 카드로 결제할게요" 라는 정보만 있으면 어떤 직원에게 말해도 결제가 가능할 것이다. 즉, 중간에 다른 점원으로 바뀌어도 된다. 만약 stateful(상태유지) 하다면 중간에 직원이 바뀔 경우 새롭게 업데이트를 해주거나, 다시 처음부터 해야할 것이다.(사과 주시고, 2개 주시고, 카드로 결제할게요 라는 내용을 업데이트) 하지만 Stateless 하다면 상태를 보관하지 않고 바로 응답만 하면 된다. 따라서 직원1이 갑자기 배가 아파 다른 곳으로 가도 직원2가 대신 그 일을 처리해주면 된다.
정리
Stateful: 상태를 보관하고 있어야 함. -> 상태 유지 비용
Stateless: 상태를 보관하고 있지 않아도 됨. -> 클라이언트의 추가 데이터 전송, 서버1이 장애나도 서버2가 처리하면 된다.실무에서 Stateless의 한계
- 모든 것을 무상태로 설게할 수 있는 경우도 있고 없는 경우도 있다.
- 무상태
- 로그인이 필요없는 단순한 서비스 소개 화면
- 상태 유지
- 로그인
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지하여야 한다.
- 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지하여야 한다.
- 상태 유지는 최소한만 사용한다.
- 무상태의 경우 전송되는 데이터량이 많다.
- 왜냐면 클라이언트가 뭐가 필요한 지 다 말해야 될 거 아님. 사과, 2개, 카드,.. 등
비연결성(connectionless)
- 우선, 연결을 유지하는 모델의 경우 클라이언트1, 클라이언트2, 클라이언트3 이 있을 때, 서버는 각 클라이언트와 계속 연결을 유지할 것이다. 그러면 서버 자원을 소모할 것이다.
- 연결을 유지하는 모델의 경우 각 클라이언트와 요청/응답이 끝나면 연결을 끊어버린다. 따라서 최소한의 자원 유지가 가능하다.
- HTTP는 기본이 연결을 유지하지 않는 모델이다.
- 일반적으로 초 단위 이하의 빠른 속도로 응답한다.
- 1시간 동안 수천명이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적다.
- 예를 들어, 웹 브라우저에서 계속 연속해서 모든 사용자가 검색 버튼을 누르지 않고, 다른 것도 읽고 그러자나.
- 비연결성으로 구현하였을 때, 서버 자원을 매우 효율적으로 사용할 수 있다.
비연결성 한계와 극복
- TCP/IP 연결을 새로 맺어야 한다. -> TCP 3 way handshake를 다시 해야함 -> 그만큼 시간 추가 -> 사용자 입장에서 좀 단점이지 -> 느릴 수 있으니깐
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS, css, 추가 이미지 등.. 수많은 자원이 함께 다운로드
- 클라이언트 서버
- 연결 --------------------->
- <----요청/응답 HTML--->
- 종료
- 연결 --------------------->
- <----요청/응답 JS ----->
- 종료
위 과정을 거치니깐 하나 할 때마다 연결하고 요청/응답 하고 종료.... 매우 느리겠지?
따라서 현재는 HTTP 지속 연결(Persistent Connections)를 사용한다.
HTML, JSS,..등을 다 주고 받고 연결을 종료한다.
Stateless를 기억하자
- 서버 개발자들이 어려워 하는 업무라고 한다.
- 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 !!
- 예를 들어, 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록 등.. -> 수만명 동시 요청이 들어온다.
따라서 우리는 최대한 Stateless 하게 설계를 해야 한다.
첫 페이지는 로그인도 필요 없는 HTML 파일 올린다. 정적 페이지.
무상태로 갈 수 있는 건 최대한 무상태로 가야한다.HTTP 메시지
- 모든 것이 HTTP 이다 !! -> 모든 형태의 데이터 전송이 가능하다.
start-line GET /search?q=hello&hl=ko HTTP/1.1 header Host: www.google.com CRLF message body- 위는 HTTP 요청 메시지의 한 예시이다. 요청 메시지도 body를 가질 수 있다.
- start-line = requeset-line:
- method SP(공백) request-target SP HTTP-version
- HTTP method: GET(조회)
- 그 외에도 POST, PUT, DELETE 등이 있다.
- 서버가 수행해야 할 동작을 지정한다.
- 요청 대상: /search?q=hello&hl=ko
- 절대경로 + 쿼리로 이루어짐.
- key-value 쌍으로, 쿼리는 ?로 시작하고 추가는 &로
- 참고로 다른 유형의 경로지정 방법도 있다.
- 절대경로 + 쿼리로 이루어짐.
start-line HTTP/1.1 200OK header Content-type: text/html;charset=UTF-8 Content-Length: 3423 CRLF message body <html> .... </html>- 위는 HTTP 응답 메시지의 한 예시이다.
- start-line = status-line
- HTTP-version SP status-code SP reason-pharse
- HTTP 상태 코드: 클라이언트의 요청에 대한 성공 혹은 실패를 나타냄.
- 200: 성공
- 400: 클라이언트 요청 오류
- 500: 서버 내부 오류
둘의 차이는 요청과 응답의 start-line이 다르다.
HTTP/1.1 을 기반으로 요청/응답을 해야하는 경우 공백 라인(CRLF)가 필수적이다. 그 이유는 헤더와 본문(메시지 바디)을 명확히 구분하기 위함이다. 메시지 구조를 일관되게 정의하기 위함도 있다. 마지막으로 프로토콜 명세에서 이를 필수적으로 요구하기 때문에 CRLF는 필수적이다.
HTTP header의 용도
- HTTP 전송에 필요한 모든 부가 정보
- 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청, 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보
- 즉, 메시지 바디 빼고 모든 메타 데이터가 다 들어가 있제?
- 필요시 임의의 헤더 추가기능 -> 그걸 쓰는 클라이언트-서버만 사용할 수 있겠지?
HTTP 메시지 바디의 용도
- 실제로 전송할 데이터
- HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능하다.
단순함 확장 가능
- HTTP 는 단순하다. 스펙도 읽어볼만...하다고 한다.
- HTTP 메시지도 매우 단순
- 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술
HTTP 정리
1. HTTP 메시지에 모든 것을 전송할 수 있다.
2. HTTP 역사 HTTP/1.1 을 기준으로 학습
3. 클라이언트 - 서버 구조
4. 무상태 프로토콜 (stateless)
5. 비연결성(connectioness)
6. 단순함, 확장 가능
7. 지금은 HTTP 시대'CS > 네트워크' 카테고리의 다른 글
HTTP 웹 기본 지식 4편 (2) 2024.12.02 HTTP 웹 기본 지식 2편 (2) 2024.12.01 HTTP 웹 기본 지식 1편 (1) 2024.12.01 [네트워크] 클라이언트 - 서버 모델 (2) 2024.10.31 Socket, Port, TCP connection 개념 (0) 2024.05.22