HTTP 기본

모든 것이 HTTP

 

※ HTTP (HyperText Transfer Protocol)

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

 

※ 기반 프로토콜

• TCP는 HTTP/1.1, HTTP/2 를 사용한다.
• UDP는 HTTP/3 를 사용한다.
• 현재 HTTP/1.1 을 주로 사용하며 HTTP/2, HTTP/3 도 점점 증가하는 추세이다.

 

실제로 어떤 프로토콜을 사용하는지 확인할 수 있다.

일단 크롬에 이동해서 F12 를 누르고 검색창에 아무거나 입력한다.

그리고 Name 쪽에 오른쪽 마우스를 클릭한 후 Protocol을 누른다.

 

 

그러면 다음과 같이 Protocol 이 뜨는것을 확인할 수 있다.

 

 

Protocol 아래에 h3 가 있는데 이는 HTTP/3 프로토콜을 사용하는 것을 알 수 있다.

 

※ HTTP 특징

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

 

클라이언트 서버 구조

 

※ 클라이언트 서버 구조

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

 

다음과 같이 클라이언트가 요청을 하고 서버측에서 응답을 하는 구조로 이뤄지는 것을 알 수 있다.

 

 

클라이언트는 복잡한 비즈니스 로직, 데이터가 없으며 단순하게 UI 를 어떻게 그릴지에 대한 초점을 둔다.

반대로 서버는 클라이언트에서 보낸 요청들 즉, 복잡한 비즈니스 로직, 데이터등을 처리하는것에 대한 초점을 둔다.

 

 

Stateful, Stateless

 

※ 무상태 프로토콜 (스테이스리스 - Stateless)

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

 

※ 상태 유지 - Stateful 

• 고객 : 이 노트북 얼마인가요?
• 점원 : 100만원 입니다. (노트북 상태 유지)
• 고객 : 2개 구매하겠습니다.
• 점원 : 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매 하시겠습니까? (노트북, 2개 상태 유지)
• 고객 : 신용카드로 구매하겠습니다.
• 점원 : 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지)

 

동일한 점원이 고객을 응대하면서 자연스럽게 대화를 이어가는 모습이다.

만약에 고객의 질문에 대해서 점원이 바뀌면 어떻게 되는지 살펴보도록 한다.

 

※ 상태 유지 - Stateful, 점원이 중간에 바뀔 경우

• 고객 : 이 노트북 얼마인가요?
• 점원A : 100만원 입니다.
• 고객 : 2개 구매하겠습니다.
• 점원B : 무엇을 2개 구매 하시겠습니까?
• 고객 : 신용카드로 구매하겠습니다.
• 점원C : 무슨 제품을 몇개, 신용카드로 구매하시겠습니까?

 

점원이 바뀌면 고객이 무엇을 구매할 지, 몇 개를 구매할 지에 대해서 알 수가 없다.

즉, 점원A 에서 점원 B로 바뀔 때 어떠한 제품을 구매할 지에 대한 정보가 없기 때문이다.

 

※ 무상태 - Stateless

• 고객 : 이 노트북 얼마인가요?
• 점원 : 100만원 입니다. 
• 고객 : 노트북 2개 구매하겠습니다.
• 점원 : 노트북 2개는 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매 하시겠습니까? 
• 고객 : 노트북 2개를 신용카드로 구매하겠습니다.
• 점원 : 200만원 결제 완료되었습니다. 

 

상태 유지의 경우보다 고객이 어떤 제품을 몇개 구매할지에 대한 정보를 추가해서 말하는 것을 볼 수 있다.

이렇게 말할 경우 점원이 중간에 바뀔 경우 어떻게 점원이 대응할 지에 대해서 살펴보도록 한다.

 

※ 무상태 - Stateless, 점원이 중간에 바뀌는 경우

• 고객 : 이 노트북 얼마인가요?
• 점원A : 100만원 입니다. 
• 고객 : 노트북 2개 구매하겠습니다.
• 점원B : 노트북 2개는 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매 하시겠습니까? 
• 고객 : 노트북 2개를 신용카드로 구매하겠습니다.
• 점원C : 200만원 결제 완료되었습니다. 

 

점원이 바뀌더라도 고객이 어떤 제품, 몇 개, 신용카드를 명확히 명시하기 때문에 동일한 점원이 대응하는 것과 동일한 결과임을 알 수 있다.

 

※ Stateful, Stateless 차이 정리

• 상태 유지 : 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려야 함)
• 무상태 : 중간에 다른 점원으로 바뀌어도 되며, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
• 무상태는 응답 서버를 쉽게 바꿀 수 있다. (무한한 서버 증설이 가능)

 

중간에 서버1이 장애가 나면 클라이언트는 처음부터 다시 요청을 해야하는 문제점이 있다.

왜냐하면 서버1에서 상태 유지로 노트북, 2개를 저장했지만 장애가 났으므로 서버2, 서버3 중 하나를 연결해서 처음부터 요청, 응답 과정을 반복해야 한다.

 

 

반대로 무상태인 경우 클라이언트 측에서 정보를 포함(노트북, 2개)해서 전달한다.

따라서 서버1이 장애가 날지라도, 서버2, 서버3 으로 요청과 응답을 반복하지 않고 현재 포함된 정보들을 통해 요청만 하면 서버측에서 응답을 할 수 있다.

 

※ 스케일 아웃 - 수평 확장 유리

 

무상태일 경우 상태 유지보다 서버를 더 많이 늘릴 수 있으며 수평 확장에 유리하다.

 

※ Stateless 실무 한계점

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

 

Connectionless

 

※ 연결을 유지하는 모델

 

 

클라이언트 마다 서버와 연결할 경우 서버는 연결을 계속 유지해야 하며, 서버 자원 소모가 발생한다.

 

※ 연결을 유지하지 않는 모델

 

 

클라이언트와 서버는 서로 필요할 경우 TCP/IP 연결을 하여 요청과 응답을 주고받고 바로 TCP/IP 연결을 종료시킨다.

이러한 모델은 서버는 연결 유지를 하지 않으며, 최소한의 자원을 유지하는 점이 있다.

 

※ 비 연결성 (Connectionless)

• HTTP는 기본으로 연결을 유지하지 않는 모델이다.
• 일반적으로 초 단위의 이하의 빠른 속도로 응답을 한다.
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
• 서버 자원을 매우 효율적으로 사용할 수 있다.

 

※ 비 연결성 한계와 극복

• TCP/IP 연결을 새로 맺어야 한다. (3 way handshake 시간 추가)
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드된다.
• 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다.
• HTTP/2, HTTP/3에서 더 많은 최적화가 일어난다.

 

※ HTTP 초기 (연결, 종료의 낭비)

 

 

클라이언트와 서버가 연결이 되면 요청과 응답을 주고받고 바로 종료하는 메커니즘이다.

따라서 연결 종료가 총 3번이 일어나면서 HTML, 자바스크립트, 이미지 등에 대한 요청, 응답을 처리하므로 총 0.9초가 소요되는 것을 확인할 수 있다.

 

※ HTTP 지속 연결 (Persistent Connections)

 

 

 

HTTP 메시지

 

 

참고로 요청 메시지도 body 본문을 가질 수 있다. (Message body)

 

※ 시작 라인 (요청 메시지)

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

• start-line = request-line / status-line
• request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
• HTTP 메서드 (GET: 조회)
• 요청 대상 (/search?q=hello&hl=ko)
• HTTP Version (HTTP/1.1)

 

① 요청 메시지 - HTTP 메서드

• 종류 : GET, POST, PUT, DELETE ...
• 서버가 수행해야 할 동작을 지정한다. (GET : 리소스 조회, POST : 요청 내역 처리)

 

② 요청 메시지 - 요청 대상

• absolute-path[?query] (절대경로[?쿼리])
• 절대경로는 "/" 로 시작하는 경로를 의미한다.

 

③ 요청 메시지 - HTTP 버전

• HTTP Version

 

※ 시작 라인 (응답 메시지)

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

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

• start-line = request-line / status-line
• status-line = HTTP-version SP status-code SP reason-phrase CRLF
• HTTP-version (HTTP/1.1)
• status code : 요청 성공과 실패를 나타낸다. (200 : 성공, 400 : 클라이언트 요청 오류, 500 : 서버 내부 오류)
• reason-phrase : 사람이 이해할 수 있는 짧은 상태 코드 설명 글이다. (ex : OK)

 

※ HTTP 헤더

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

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

• header-field = field-name ":" OWS field-value OWS (OWS : 띄어쓰기 허용)
• field-name은 대소문자 구분하지 않는다. (filed-value는 대소문자 구분함)

 

※ HTTP 헤더 용도

• HTTP 전송에 필요한 모든 부가정보가 들어있다. (ex : 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등등)
• 표준 헤더가 너무 많다.
• 필요시 임의의 헤더 추가가 가능하다. 

 

※ HTTP 메시지 바디 용도

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

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

• 실제 전송할 데이터를 말한다.
• HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터를 전송한다.