[모든 개발자를 위한 HTTP 웹 기본 지식]섹션4. 모든 것이 HTTP

dev_lee·2025년 3월 15일

[인프런]모든 개발자를 위한 HTTP 웹 기본 지식

목록 보기

3/4

HTTP(HyperText Transfer Protocol)

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

HTTP의 특징

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

클라이언트 서버 구조

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

클라이언트와 서버를 분리하면 좋은 점

클라이언트와 서버의 역할을 분리하면, 서버는 비즈니스 로직과 데이터 관리에 집중하고, 클라이언트는 UI와 사용자 경험에 집중할 수 있다.

또한, 클라이언트와 서버는 각각 독립적으로 진화할 수 있다. 클라이언트의 UI가 변경되어도 서버에는 영향을 미치지 않으며, 서버의 환경이 바뀌어도 클라이언트에 지장이 없다.

무상태(Stateless) 프로토콜

서버가 클라이언트의 상태를 보존하지 않는다
장점 : 서버 확장성 높음(스케일 아웃)
단점 : 클라이언트가 추가 데이터 전송

Stateful, Stateless

상태 유지 - Stateful

클라이언트와 서버 간의 연결이 유지되며,서버가 이전 요청의 상태를 기억한다(문맥이 보존된다).

점원이 중간에 바뀌면(서버가 중간에 종료되면)? 장애가 발생하는 것

항상 같은 서버가 유지 되어야 한다.
서버를 확장하기가 어렵다.
중간에 서버가 장애나면? 컨택스트 문맥이 사라지는 것이다.

무상태 - Stateless

클라이언트의 각 요청이 독립적이며, 서버는 이전 요청의 상태를 기억하지 않는다.

고객이 필요한 데이터를 그때그때 다 점원에서 넘긴다.
점원이 바뀌어도 문제 없다.

중간에 점원이 바뀐다면(= 중간에 서버가 에러가 난다면)?

애초에 필요한 데이터를 다 담아서 전송하기 때문에 중간에 서버가 장애가 나면 다른 서버로 중계하면 된다.

정리

상태 유지
- 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다)
무상태
- 중간에 다른 점원으로 바뀌어도 된다.
- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설이 가능하다.
스케일 아웃 (수평 확장을 하는데 유리하다)

Stateless 실무 한계

모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
무상태
- ex) 로그인이 필요 없는 단순한 서비스 소개 화면
상태 유지
- ex) 로그인
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
- 서버의 세션이 날아가거나 세션 서버가 죽어버리면 전체적으로 로그인이 다 풀리게 된다.
상태 유지는 최소한만 사용

Stateless 단점

Stateful에 비해 서버에 데이터를 많이 전송해야한다.

번외)스테이스리스한 방식의 설계를 기억하자!

서버 개발자들이 어려워하는 업무

정말 같은 시간에 딱 맞춰 발생하는 대용량 트래픽 (ex. 선착순 이벤트)
최대한 스테이스리스하게 설계하는게 중요하다
-> 이런 대용량 트래픽이 올 때 서버를 늘려 대응할 수 있는 부분이 많아진다.

영한님이 사용하는 해결 방법
첫 페이지에 정적 페이지를 두고 그 안에서 콘텐츠를 보게 한 다음 이벤트 참여 버튼을 누르도록 한다.

비연결성(connectionless)

연결을 유지하는 모델

클라이언트1이 서버에 요청을 보내면 클라이언트와 서버가 연결이 되고, 연결이 계속 유지된다.
클라이언트2가 서버에 요청을 보낼 때도 클라이언트1은 요청을 보내지 않음에도 계속 연결이 유지된 상태이다.
-> 서버의 자원이 계속 소모된다.

연결을 유지하지 않는 모델

클라이언트가 서버에 요청을 보내면 클라이언트와 서버가 연결되고, 요청이 종료되면 연결을 끊는다.
-> 최소한의 자원만 사용

HTTP는 기본적으로 연결을 유지하지 않는 모델

일반적으로 초 단위의 이하의 빠른 속도로 응답
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이
하로 매우 작음
- ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
서버 자원을 매우 효율적으로 사용할 수 있음

비연결성 한계와 극복

한계

각 요청 마다 TCP/IP 연결을 새로 맺어야 한다.-> 3 way handshake 시간 추가
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등
등 수 많은 자원이 함께 다운로드

극복

지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP/3에서 더 많은 최적화

지속 연결(Persistent Connections, Keep-Alive)

한 번의 TCP 연결을 유지한 상태에서 여러 개의 HTTP 요청/응답을 주고받을 수 있도록 하는 방식

연결을 "재사용" 한다는것 이 중요 포인트

지속 연결이 없는 경우

HTTP 각 요청마다 새로운 TCP/IP 연결 생성
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등
등 수 많은 자원들도 요청되므로 각각의 요청마다 TCP/IP 연결 생성
요청을 보낼때 마다 TCP 3-way handshake가 수행되므로 네트워크 성능이 저하될 가능성이 있다.

지속 연결 적용한 경우

TCP 연결을 한 번 맺고, 여러 개의 HTTP 요청/응답을 처리할 때 연결을 재사용한다.

HTTP 메시지

start-line
header
empty line
message body

시작 라인

요청 메세지(request-line)

GET /search?q=hello&hl=ko HTTP/1.1

method SP(공백) request-target SP HTTP-version CRLF(엔터)

method(HTTP 메서드)
- 서버가 수행해야 할 동작 지정
- 종류 : GET, POST, PUT, DELETE...
  - GET: 리소스 조회
  - POST: 요청 내역 처리
request-target(요청 대상)
- absolute-path?query
- 절대경로= "/" 로 시작하는 경로
- 참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.
HTTP-version(HTTP 버전)

응답 메세지(status-line)

HTTP/1.1 200 OK

HTTP-version SP status-code SP reason-phrase CRLF

HTTP-version(HTTP 버전)
status-code(상태 코드)
- 요청 성공, 실패를 나타냄
- 200: 성공
- 400: 클라이언트 요청 오류
- 500: 서버 내부 오류
reason-phrase(이유 문구)
- 사람이 이해할 수 있는 짧은 상태 코드 설명 글

HTTP 헤더

field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name은 대소문자 구문 없음
field-value는 대소문자 구분

HTTP 전송에 필요한 모든 부가정보
- ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보,
  서버 애플리케이션 정보, 캐시 관리 정보 등
표준 헤더가 너무 많음
- https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
필요시 임의의 헤더 추가 가능
helloworld: hihi

요청 메세지

HTTP/1.1
Host: www.google.com

응답 메세지

Content-Type: text/html;charset=UTF-8
Content-Length: 3423

HTTP 메세지 바디

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

요청 메세지

요청 메시지도 body 본문을 가질 수 있음

응답 메세지

<html>
<body>...</body>
</html>

단순함 확장 가능

• HTTP는 단순하다. 스펙도 읽어볼만...
• HTTP 메시지도 매우 단순
• 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술

HTTP 정리

HTTP 메시지에 모든 것을 전송
HTTP 역사 HTTP/1.1을 기준으로 학습
클라이언트 서버 구조
무상태 프로토콜(스테이스리스)
HTTP 메시지
단순함, 확장 가능
지금은 HTTP 시대

dev_lee

이전 포스트

[모든 개발자를 위한 HTTP 웹 기본 지식]섹션3. URI와 웹 브라우저 요청 흐름

다음 포스트

[모든 개발자를 위한 HTTP 웹 기본 지식]섹션4. 모든 것이 HTTP

[인프런]모든 개발자를 위한 HTTP 웹 기본 지식

HTTP(HyperText Transfer Protocol)

HTTP의 특징

클라이언트 서버 구조

클라이언트와 서버를 분리하면 좋은 점

무상태(Stateless) 프로토콜

Stateful, Stateless

상태 유지 - Stateful

무상태 - Stateless

정리

Stateless 실무 한계

Stateless 단점

번외)스테이스리스한 방식의 설계를 기억하자!

비연결성(connectionless)

연결을 유지하는 모델

연결을 유지하지 않는 모델

HTTP는 기본적으로 연결을 유지하지 않는 모델

비연결성 한계와 극복

지속 연결(Persistent Connections, Keep-Alive)

HTTP 메시지

시작 라인

요청 메세지(request-line)

응답 메세지(status-line)

HTTP 헤더

요청 메세지

응답 메세지

HTTP 메세지 바디

요청 메세지

응답 메세지

단순함 확장 가능

HTTP 정리

[모든 개발자를 위한 HTTP 웹 기본 지식]섹션3. URI와 웹 브라우저 요청 흐름

[모든 개발자를 위한 HTTP 웹 기본 지식]섹션5. HTTP 메서드

0개의 댓글