녕의 학습 기록

[HTTP] HTTP 기본 본문

Dev/HTTP

[HTTP] HTTP 기본

kjyyjk 2022. 12. 23. 12:23

 학습 내용 

HTTP의 기본 특성


* HTTP(Hyper Text Transfer Protocol)

 

현재 HTTP의 버전은 3까지 있고 주로 1.1 / 2 / 3 버전을 사용.

 

가장 중요한 것은 HTTP/1.1 이고 HTTP/2 와 HTTP/3 은 이를 개선시킨 것이다.

 

1.1과 2 버전은 TCP프로토콜 위에서, 3버전은 UDP프로토콜 위에서 동작한다.

 

앞에서 학습했듯이 TCP는 3-wayhandshake 로 비교적 느리고, UDP레벨에서 성능을 최적화 한 것이 바로 3버전.

 

HTTP는 다음과 같은 특징을 지녔다.

 

- 클라이언트 서버구조

- 무상태 프로토콜( stateless )

- 비연결성

- HTTP 메시지

 

* HTTP - 클라이언트 서버구조

 

HTTP는 클라이언트 서버구조이다.

 

말 그대로 클라이언트와 서버가 분리되어있고, 서로 통신.

 

클라이언트가 서버에 요청을 보내면 서버에서 응답이 올 때까지 기다리는 구조이다.

 

" Request Response 구조 "

 

중요한 것은 클라이언트와 서버의 역할을 분리하는 것

 

클라이언트는 ui에 전념하고, 서버는 비즈니스 로직과 데이터 처리에 전념하게끔 해야한다

 

이렇게 해야 클라이언트는 클라이언트 대로, 서버는 서버대로 독립적으로 진화할 수 있다.

 

* HTTP - Stateless

 

HTTP는 무상태 프로토콜이다.

 

무상태란 말을 처음 봤을 때 어떤 개념인지 잘 와닿지 않았다.

 

무상태는 서버가 클라이언트의 상태를 보존하지 않는 것이다.

( 반대로 서버가 클라이언트의 상태를 보존하는 것은? --> stateful )

 

예를 들어보겠다

 

내가 도미노 피자에 피자를 시키려고 전화했을 때

종업원은 나에게 어떤 피자를 시킬 것인지 물어보고, 나는 쉬림프 피자를 시킨다고 한다.

또 종업원은 어떤 사이즈로 시킬 것이냐고 물어보고 나는 라지 사이즈로 시킨다고 한다.

 

위에서 두번째 물었을 때 나는 사이즈에 관한 정보만 넘겼는대도 주문은 문제 없이 진행되었다.

왜냐면 종업원(서버)이 앞에서 대답한 피자 종류(클라이언트의 상태)를 기억(보존) 하고 있기 때문.

 

하지만 피자 종류를 대답하고 갑자기 종업원이 바뀐다면(서버 추가/ 변경)?

 

내가 라지사이즈 달라고 하면 앞에서 말한 정보를 모르기 때문에 무슨 피자 시키시는 데요?라고 할 것이다.

(교체 종업원끼리 인수인계 하지 않는 이상)

 

상태 보존적인 stateful로 했을 때 서버가 변경되면 차질이 생기는 것.

 

하지만 무상태 stateless로 하였을 때는??

 

서버가 클라이언트의 상태를 보존하지 않기 때문에 때마다 모든 정보를 넘겨줘야한다.

 

마치 종업원의 모든 대답에 " 쉬림프 피자 / 라지 사이즈 / 카드 계산 " 이라고 답하는 것과 같이.

 

이렇게 되면 중간에 어떤 종업원이 와도 주문은 차질 없이 진행된다.

 

이처럼 무상태는 응답 서버를 쉽게 바꿀 수 있다.

 

즉, 무한한 서버 증설이 가능!!

 

 

한계로는 모든 것을 무상태로 설계하지는 못하고, 최소한의 상태 유지를 해주어야한다.

( like 로그인 상태 유지 )

 

그리고 계속 모든 데이터를 넘기니, 데이터를 너무 많이 보낸다는 단점도 있다.

 

어쨌거나 웹 Application은 최대한 무상태로 설계해야한다.

 

* HTTP - 비연결성

 

서버가 여러 클라이언트와 데이터를 주고 받으며 연결을 계속 유지하고 있는 모델이라면,

서버의 자원이 계속 소모된다. 이는 곧 단점.

 

클라이언트와 서버 간에 TCP/IP 연결 후에 클라이언트 요청, 서버 응답 후 연결을 끊으면 최소한의 자원 유지 가능

 

HTTP가 바로 이처럼 기본적으로 연결을 유지하지 않는 모델임.

 

연결을 유지할 필요가 없는 게, 1시간 동안 수천명이 서비스를 이용한다고 해도

정말 한 순간에 수천명이 동시에 버튼을 클릭할 경우는 없기 때문이다.

 

덕분에 서버의 자원을 효율적으로 사용 가능하다.

 

단점이 있다면 계속 끊었다 연결했다 하기 때문에 TCP/IP 의 3-way handshake 시간이 추가된다.

 

지금은 다음 그림처럼 지속 연결로 한계를 극복한 상태

 

기존에는 요청마다 연결을 새로 했지만 한 번 연결에 여러 요청응답을 처리하고 종료

* HTTP - 메세지

 

HTTP 메시지에 거의 모든 것을 전송 가능하다.

( Html, Text, Image, 음성, 영상, 파일, json 등등 )

 

HTTP 메시지는 시작라인 / 헤더 / 공백라인(CRLF) / message body 로 이루어져 있다.

 

HTTP 응답 메시지 - 각각 start line / Header / CRLF

요청 메시지의 시작 라인은  request-line 으로

 

method(GET) / request-target(/search?q=hello&hi=ko) / HTTP버전 으로 이루어져있다.

 

 

응답 메시지의 시작 라인은 status-line 으로

 

HTTP버전 / status-code(200) / reason-phrase(이유문구) / CRLF 으로 이루어져있다.

 

Header 에는 field-name(Host 나 Content-Type 등) ":" field-value 로 구성

 

Header는 HTTP 전송에 필요한 모든 부가 정보를 담고 있고,

Message Body는 실제로 전송할 데이터를 담고 있다.

 


 다음 학습 내용 

 

HTTP 메서드

 

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

 

'Dev > HTTP' 카테고리의 다른 글

[HTTP] HTTP 상태코드  (0) 2022.12.27
[HTTP] HTTP 메서드 활용  (0) 2022.12.25
[HTTP] HTTP 메서드  (0) 2022.12.25
[HTTP] URI 와 웹의 흐름  (0) 2022.12.21
[HTTP] 인터넷 네트워크  (0) 2022.12.21