on
[HTTP&네트워크] HTTP
[HTTP&네트워크] HTTP
[HTTP(HyperText Transfer Protocol)]
초기에는 HTML을 전송하는 용도로 사용되었지만, TEXT, 이미지, 음성, JSON 등 거의 모든 형태의 데이터 전송이 가능.
HTTP이 여러 버전이 있지만 1.1 버전을 가장 많이 사용한다. HTTP 1.1 이후 2.0 3.0 버전이 있긴 하지만 성능 개선을 중점으로 이루어졌다. 1.1과 2.0은 주로 TCP 프로토콜을 기반으로 하지만, 3.0은 이 전글에서 언급했듯이 UDP 프로토콜을 사용한다. (현재는 2와 3을 점점 많이 사용한다고 한다)
HTTP의 특징으로
1. 클라이언트 서버 구조를 가진다.
2. 무상태 프로토콜(Stateless)와 비연결성
3. HTTP 메시지
4. 단순함과 확장성
을 가진다.
[클라이언트-서버 구조]
클라이언트 서버 구조는 이전 글에서 본 것처럼,
클라이언트가 서버에 Request(요청)을 보내면 응답을 대기. 서버는 요청에 맞는 Response(응답)을 보내는 구조로 되어 있다는 것이다.
이런 클라이언트-서버의 단순한 구조는 프론트엔드와 백엔드의 분리를 가져왔다.
그래서 클라이언트는 UI/UX에 집중적으로 발전할 수 있으며, 백엔드는 트래픽에 대응하는 서버 아키텍처 등 각각의 분야의 집중적으로 발전할 수 있다는 장점을 가져왔다.
(그래서 트래픽이 아무리 증가하더라도 프론트엔드 쪽에서는 신경쓸 필요 없이, 백엔드를 고도화시켜 발전하면 해결할 수 있다던가, 백엔드가 php 에서 스프링으로 기술 스택이 변경된다 하더라도 프론트엔드의 변경점이 없도록 분리되어 있는 장점이 있다.)
[무상태(Stateless) 프로토콜]
서버가 클라이언트의 상태를 보존하고 있지 않다는 것을 무상태 프로토콜이라고 한다. 반대는 상태유지(Stateful).
상태유지(Stateful)란?
상태유지란 서버가 클라이언트에 관해 Context(문맥)를 유지하고 있다는 것이다.
무상태(Stateless)란?
반대로, 서버가 클라이언트에 관해 Context(문맥)를 유지하지 않고 있다는 것이다.
예를 들어, 클라이언트의 요청이 [1. 아이폰의 정보]를 요청하고, 다음 요청에는 [2. 수량 2개], 다음 요청에는 [3. 신용카드 결제] 총 3번의 요청을 나눠서 들어왔다고 가정해보자.
상태유지의 경우, 1번 요청에서 아이폰을 2번 요청에서 수량 3번 요청에서 신용카드 결제 라는 하나의 문맥을 유지하고 있기 때문에, 클라이언트가 [아이폰 2개를 신용카드 결제를 통해 구매요청] 라는 결과를 도출한다.
반면, 무상태의 경우, 1번 요청에서는 아이폰 정보, 2번 요청에서는 수량에 대한 대상을 모르기 때문에 모를 뿐더러 3번 요청 또한 마찬가지이다. ( 예전에 영화 '첫 키스만 50번째' 라는 영화를 봤는데, 비슷한 맥락이다.)
그래서 무상태의 경우, 아이폰의 구매를 요청하기 위해서는 결과적으로 [아이폰 2개를 신용카드로 결제] 요청을 보내야 서버에서 이해하고 해당 요청을 처리할 수 있다.
이는 서버가 한 대일 경우지만, 만약 중계 서버가 여러개의 서버를 두고 서비스를 한다고 가정해 보자.
상태유지의 경우, 중계서버가 각 요청이 동일한 서버에게 전달되야만 해당 요청이 완료된다.
반면, 무상태의 경우, 하나의 요청에 추가적인 정보를 더 담아야 하기 때문에, 어떠한 서버가 응답을 하더라도 처리할 수 있다는 장점이 있다. 그렇기 때문에 서버의 확장이 매우 유리하다.
하지만, 실제적으로 무상태로 모든 것을 설계할 수 있다고 장담할 수 없다는 한계가 있다. 예를 들면, 로그인이 필요한 기능들은 상태를 유지해야 한다. 그래서 이를 보완하기 위한 방법으로 브라우저 쿠키 또는 서버 세션 등을 사용해서 상태유지를 할 수 있도록 만든다. (하지만 상태유지는 최소한만 사용해서 Stateless 하게 만들어야 한다.)
[비 연결성]
연결성이란, 클라이언트와 서버가 요청 및 응답을 하기위해 연결이 되면, 이를 지속적으로 유지를 하는지에 대한 유무를 말한다.
연결성은 클라이언트와 연결을 유지하고 있으며, 연결을 유지하는 동안 서버의 자원을 지속적으로 소모하고 있다.
비연결성은 한번의 요청에 대해 응답을 보내고 나면, TCP/IP 연결을 종료시켜 버리는 것이다.
그렇기 때문에, 서버 자원을 매우 효율적으로 사용할 수 있다는 장점이 있다.
하지만, 매 요청마다 클라이언트와 TCP/IP 연결을 새로 맺어야 하기 때문에, 이전 글에서 알아본 3 way handshake를 매번 해야 한다.
그리고 사이트를 요청하면 해당 사이트를 구동하기 위한 자바스크립트, css, 이미지 등 추가적으로 필요한 자원을 함께 다운로드 해야 하기 때문에, 각 자원에 대한 연결 및 종료가 이루어지면서 불필요한 연결 과정이 많이 생긴다는 점이다.
(이를 보완하기 위해 지속연결이라는 방법이 있는데, 지속연결이란 한번의 연결에 필요한 자원을 모두 응답한 뒤 연결을 종료하는 것을 말한다.)
(같은 시간에 동시에 트래픽이 몰리는 것이 서버개발자가 어려워하는 업무라고 한다. 예를 들어 선착순 이벤트, 티켓 예매, 수강신청 등등.. 이럴때는 Stateless 한 설계가 가장 중요하다고 한다.)
[HTTP 메시지]
HTTP 메시지 구조
start-line
header
empty line(CRLF) ** 공백 라인. 반드시 들어가야 한다.
message body
츌처: 인프런-김영한님, 모든 개발자를 위한 HTTP 웹 기본 지식 강의
요청 메시지의 경우: request-line, 해당 요청의 HTTP 메서드를 명시해주며, 요청 path 와 query parameter, HTTP 버전을 명시해준다.
응답 메시지의 경우: status-line, HTTP 버전, HTTP 상태코드 를 명시해서, 해당 요청에 대한 상태와 메시지를 담아서 명시해준다.
field-name 과 field-value 를 ":(콜론)" 을 통해 HTTP 전송에 필요한 부가정보들을 보내준다. 즉 필요한 meta 정보들을 헤더에 명시해준다.
실제 전송할 데이터에 해당한다.
from http://devcabinet.tistory.com/32 by ccl(A) rewrite - 2021-11-28 01:00:42