[인프런 김영한 강의 정리 - 인터넷과 http- 3 ] -3. HTTP 기본과 Scale out

본 게시물은 인프런 강의(김영한 강사님의 '모든 개발자를 위한 http 강의)를 듣고 정리한 메모입니다. 

 

1.모든 것이 http

모든 서비스가 http 네트워크 위에서 일어나고 있다.
http : Hypertext Transfer Protocol
문서간 전환을 할 수 있는 html을 담는 것을 넘어서 영상, 이미지 모두 http를 통해서 전송한다.

• http의 역사:
• http 1.1버전 이후로는 http 2 버전, 3버전이 있는데 성능개선과 관련이 있으므로 1.1버전에 주력해서 공부를 하는 것이 좋다.
  • (http3: UDP기반이다.)

2. 클라이언트 서버 구조

http의 특징: 클라이언트 서버 구조이다.
클라이언트가 서버에 요청을 하면 응답을 대기하는 상태가 되고, 서버는 클라이언트의 요청을 대기하고 있다가 요청이 들어오면 응답한다.

 

3. Statefull, Stateless⭐️

Stateless : 서버가 클라이언트의 상태를 보존하지 않는다. 서버의 context(문맥)을 저장하지 않는다 : 어떠한 맥락에서 요청하는지를 저장하지 않기 때문에,
클라이언트가 서버에 요청할 때는 매번 요청을 처음부터 구체화해서 적는다.
ex) 점원에게 무엇을 살 건지, 얼마나 살 건지, 무엇으로 결제할 건지, 한꺼번에 말한다: 어느 점원에게나 부탁해도 되게끔.. (저 TV 2개 신용카드로 살게요.)

이와 다른게 Statefullness:

ex) 점원 A와 대화하면서, 이야기 하던 물건을 얼마나 살건지만 이야기 한다. (저 그거 2개 살게요.) (신용카드로 살게요. )

* Stateless를 유지할 때 점원입장에서 좋은 점:
어떤 점원에게 부탁을 해도, 요구에 응해줄 수 있다.
중간에 다른 점원으로 바뀌어도 요구에 응해줄 수 있다.
→ 요청이 많아져도 서버를 대거 투입할 수 있다. (무한한 서버 증설 가능)
→ 장애 대응에 효과적이다. (장애 시 다른 서버가 응답가능)

→ Scale out:  수평 확장에 유리하다.

💡 스케일 아웃(Scale-out)은 장비를 추가해서 확장하는 방식을 말한다.
기존 서버만으로 용량이나 성능의 한계에 도달했을 때, 비슷한 사양의 서버를 추가로 연결해 처리할 수 있는 데이터 용량이 증가할 뿐만 아니라 기존 서버의 부하를 분담해 성능 향상의 효과를 기대할 수 있다.
서버를 추가로 확장하기 때문에 수평 스케일링(horizontal scaling)이라고도 불린다.
클라우드 서비스에서는 자원 사용량을 모니터링하여 자동으로 서버를 증설(Scale Out)하는 Auto Scaling 기능도 있다.
출처: https://tecoble.techcourse.co.kr/post/2021-10-12-scale-up-scale-out/

 

* Stateless의 한계점

- 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다. (그냥 단순 서비스 소개 화면 vs 로그인 유지해야하는 경우)

- 로그인한 사용자의 경우는 해당 상태를 서버에 유지해야한다 : 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지한다.

-상태유지는 최소한만 사용하도록 한다.

 

4. 비연결성

연결을 유지하지 않으면, 서버가 불필요한 클라이언트와 연결되어 서버 자원을 소모하고 연결을 지속하지 않아도 되는 장점이 있다. 

 

* Persistent Connections (HTTP 지속 연결)
→ http는 기본이 연결을 유지하지 않는 모델이다. 일반적으로 초 단위 이하의 빠른 속도로 응답할 수 있으며, 서버 자원을 매우 효율적으로 사용할 수 있다.

→  데이터를 보낼 때마다 연결을 새로 한다면 연결과 종료가 낭비될 수 있으므로 (ex: html, CSS, javascript를 보낼 때마다 매번 새로 연결하는 경우) 연결을 유지하면서 데이터를 모두 보내고, 종료하도록 한다.

 

 

 

5. HTTP 메시지

HTTP 메시지 문법
기본 구조:

start line
-----------------
header
-----------------
empty line(CRLF)
-----------------
message body

다시 말하면

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

a. start- line

    <HTTP 요청 메시지>
start-line : request-line

= method SP request-target SP HTTP-version CRLF
(SP는 스페이스)

• method: GET, POST, PUT, DELETE (GET: 리소스 조회, POST : 요청 내역 처리)
• request-target : 요청 대상(/search?q=hello&hl=ko) : ‘/’로 시작하는 절대 경로(주로) + [?query] 
  
  • (절대경로가 아닐수도 있다)
• HTTP version : http의 버전

GET /search?q=ebang&hl=ko HTTP 1.1
HOST: www.google.com
→ 한국어로 ebang을 google.com에서 검색한 결과를 HTTP 프로토콜을 통해 요청한다. 버전은 1.1

    <HTTP 응답 메시지>
start-line : status-line

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

• HTTP version
• status-code
  • 200 : OK
  • 400 : 클라이언트 요청 오류
  • 500 : 서버 내부 오류
• reason-phrase: 오류 시 사람이 이해할 수 있는 짧은 코드 설명 글

 

 

b. HTTP header

field-name”:” OWS filed-value OWS 
(OWS : 띄어쓰기 허용.)

• field-name은 대소문자 허용, :랑은 띄어쓰기는 안됨.

용도: HTTP 전송에 필요한 모든 부가 정보를 담고 있다.
(ex 메시지 바디의 내용, 크기, 압축, 인증, 요청 클라이언트(브라우저)정보, 서버 애플리케이션 정보, 캐시 관리 정보 등)
표준 헤더가 많고, 임의의 헤더도 추가할 수 있다.(클라이언트와 서버가 약속한 헤더라면..)

 

c. HTTP body

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