[HTTP_김영한] HTTP 기본

혯승·2023년 2월 2일

http

HTTP

목록 보기

4/4

HTTP

HTTP (HyperText Transfer Protocol)

📌 현재는 HTTP 시대! HTTP 메세지에 모든 것을 전송

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

📑HTTP의 역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년: 메서드, 헤더 추가
• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
• RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

HTTP/2와 HTTP/3은 성능이 개선일 뿐이므로 HTTP/1.1스펙을 잘 알아야함.

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용
• HTTP/2, HTTP/3 도 점점 증가

HTTP 특징

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

📌클라이언트 서버 구조

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

✔️ 클라이언트와 서버를 분리하는 것이 중요!

클라이언트 : UI, 사용성 중점
서버 : 비지니스 로직, 데이터 중점
ex) 트래픽 과부화가 생기면 백엔드가 그 부분만 고민.
(php → java로 언어 변경)

📌무상태 프로토콜 (Stateless)

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

Stateful(상태유지) vs Stateless(무상태)

Stateful (상태유지) 예시 - 클라이언트 이전 상태 보존

점원 1명

고객 : 이 노트북 얼마인가요?
점원 : 100만원 입니다.(노트북 상태 유지)

고객 : 2개 구매하겠습니다.
점원 : 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?(노트북, 2개 상태유지)

고객 : 신용카드로 구매하겠습니다.
점원 : 200만원 결제 완료되었습니다.(노트북, 2개, 신용카드 상태유지)

점원이 중간에 바뀐다면?

고객 : 이 노트북 얼마인가요?
점원A : 100만원 입니다.

고객 : 2개 구매하겠습니다.
점원B : ? 무엇을 2개 구매하시겠어요?

고객 : 신용카드로 구매하겠습니다.
점원C : ? 무슨 제품을 몇 개 신용카드로 구매하시겠어요?

점원이 원하는 고객의 데이터가 없음

Stateless (무상태) 예시 - 점원이 중간에 바뀐다면?
- 고객의 데이터를 그때그때 넘겨줌

점원 1명

고객 : 이 노트북 얼마인가요?
점원 : 100만원 입니다.

고객 : 노트북 2개 구매하겠습니다.
점원 : 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?

고객 : 노트북 2개를 신용카드로 구매하겠습니다.
점원 : 200만원 결제 완료되었습니다.

점원이 중간에 바뀐다면?

고객 : 이 노트북 얼마인가요?
점원A : 100만원 입니다.

고객 : 노트북 2개 구매하겠습니다.
점원B : 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?

고객 : 노트북 2개를 신용카드로 구매하겠습니다.
점원C : 200만원 결제 완료되었습니다.
상태 유지(Stateful) : 중간에 다른 점원으로 바뀌면 안됨.
(중간에 다른 점원을 바뀐다면 고객 상태 정보를 다른 직원에게 미리 알려야함.)
상태를 보존하기 때문에 항상 같은 서버가 유지되어야함.

무상태(Stateless) : 중간에 다른 점원으로 바뀌어도 됨.
갑자기 고객이 증가해도 점원을 대거 투입 가능.
→ 즉, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입 가능!!!
상태를 보존하지 않기 때문에 아무 서버나 호출해도됨. 장애 발생시 다른 서버가 응답 가능.

📌 무상태는 응답 서버를 쉽게 바꿀 수 있음. → 무한한 서버 증설 가능

스케일 아웃 : 수평 확장 유리

Stateless 실무 한계

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

📌비 연결성(connectionless)

연결을 유지하는 모델

: 여러 개의 클라이언트의 요청에 응답해도 연결이 종료되지 않고 서버와 연결을 계속 유지. → 서버 자원 소모
ex) 클라이언트 3과 통신해도 클라이언트1,2와 지속 연결중

연결을 유지하지 않는 모델

: 클라이언트의 요청에 응답하면 즉시 TCP/IP 연결을 종료 → 최소한의 자원 사용

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

비 연결성의 한계와 극복

한계

새롭게 TCP/IP 연결할 때마다 3way handshake 시간이 추가됨
사이트 요청시 HTML, 자바스크립트, css등 다양한 리소스가 함께 다운로드

극복

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

📌HTTP 메시지

✉️HTTP 메시지 구조

: 시작 라인, 헤더, 공백 라인(필수), 본문

공식 스펙

HTTP-message = start-line
                      *( header-field CRLF )
                      CRLF
                      [ message-body ]

📤HTTP 요청 메시지

📌 요청 메시지도 message-body를 가질 수 있음

시작 라인 (start line)

: request-line

request-line = method SP request-targat SP HTTP-version CRLF

- SP(공백), CRLF(엔터)

method : HTTP 메소드 (GET : 조회)
- 서버가 수행해야 할 동작 지정
- 종류 : GET(리소스 조회), POST(요청 내역 처리), PUT(수정), DELETE(삭제)
request-targat : 요청 대상, path, query (/search?q=hello&hl=ko)
- absolute-path[?query] (절대경로[?쿼리])
- 절대경로 : "/"로 시작하는 경로
HTTP Version : HTTP 버전(HTTP/1.1)

HTTP 헤더

header-field = field-name":" OWS field-value OWS

- OWS(띄어쓰기 허용)

field-name은 대소문자 구분 없음
field-name : (Host)
field-value : (www.google.com)

📥HTTP 응답 메시지

시작 라인 (start line)

: status-line

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

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

HTTP 헤더

header-field = field-name":" OWS field-value OWS

- OWS(띄어쓰기 허용)

field-name은 대소문자 구분 없음
field-name : (Content-Type), (Content-Length)
field-value : (text/html;charset=UTF-8), (3423)

용도

HTTP 전송에 필요한 모든 부가정보(meta정보)
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...

ex) Request URL: https://m.search.naver.com/search.naver?sm=mtp_sly.hst&where=m&query=hello&acr=1

HTTP 메시지 바디

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

혯승

이전 포스트

[HTTP_김영한] HTTP 기본

HTTP

HTTP

HTTP (HyperText Transfer Protocol)

📑HTTP의 역사

기반 프로토콜

HTTP 특징

📌클라이언트 서버 구조

📌무상태 프로토콜 (Stateless)

Stateful(상태유지) vs Stateless(무상태)

Stateless 실무 한계

📌비 연결성(connectionless)

연결을 유지하는 모델

연결을 유지하지 않는 모델

비 연결성의 한계와 극복

📌HTTP 메시지

✉️HTTP 메시지 구조

📤HTTP 요청 메시지

시작 라인 (start line)

HTTP 헤더

📥HTTP 응답 메시지

시작 라인 (start line)

HTTP 헤더

용도

ex) Request URL: https://m.search.naver.com/search.naver?sm=mtp_sly.hst&where=m&query=hello&acr=1

HTTP 메시지 바디

[HTTP_김영한] URI와 웹 브라우저 요청 흐름

0개의 댓글