인프런 HTTP 강의 정리 #3

1 . 모든 것이 HTTP (HyperText Transfer Protocol)

HTTP는 하이퍼 텍스트를 주고 받기 위한 규칙으로, 거의 모든 형태의 데이터를 전송할 수 있다.

 

- HTTP 특징

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

2 . 클라이언트 서버 구조

클라이언트는 서버에 요청을 보내고, 서버는 요청에 대한 결과를 만들어서 응답한다.

 

이때 클라이언트와 서버를 개념적으로 분리해서 각각 독립적으로 진화할 수 있도록 하는 것이 중요하다.

• 클라이언트 : UI, UX, 사용성에 집중
• 서버 : 비즈니스 로직, 데이터 처리에 집중

3 . Stateful, Stateless

1) 상태 유지 (Stateful)

 

중간에 점원이 바뀌는 경우를 가정해보자.

 

-> 상태 유지의 경우 중간에 다른 점원으로 바뀌면 안 된다. 바뀌는 경우 상태 정보를 다른 점원에게 미리 알려줘야 한다.

 

2) 무상태 (Stateless) 

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

중간에 점원이 바뀌는 경우를 가정해보자.

 

 

-> 무상태의 경우 중간에 다른 점원으로 바뀌어도 된다. 갑자기 클라이언트의 요청이 증가해도 서버를 대거 투입할 수 있다는 것이다. 즉 무상태에서는 응답 서버를 쉽게 바꿀 수 있으며, 무한한 서버 증설이 가능하다.

 

3) Stateful 정리

상태 유지에서는 항상 같은 서버가 유지되어야 한다. 아래와 같은 상황에서 서버1은 클라이언트 A가 요청한  노트북, 2개라는 상태를 모두 유지해야 한다.

 

만약 상태 유지의 상황에서 중간에 서버에 장애가 발생하면 어떻게 될까?

-> 서버1에서 장애가 발생하면, 클라이언트A는 결제를 처음부터 다시 해야 한다.

 

4) Stateless 정리

무상태에서는 아무 서버나 호출해도 된다. 아래 상황에서 클라이언트A가 모든 정보를 담아서 서버1에 요청을 하면, 서버1은 상태를 보관하지 않고 응답만 한다.

 

만약 무상태의 상황에서 중간에 서버에 장애가 발생하면 어떻게 될까?

-> 만약 서버1에서 장애가 발생하면, 중계 서버가 서버 2번으로 요청을 던진다.

 

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

무상태에서는 이벤트를 하는 경우 서버를 확장시킬 수 있다.

 

5) 실무 한계

무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다. 그렇지만 가능한 무상태로 설계하고, 상태 유지는 최소한만 사용하자!

• 무상태 : 로그인이 필요없는 단순한 서비스 소개 화면
• 상태 유지 : 로그인

4 . 비연결성(connectionless)

클라이언트는 필요한 요청, 응답이 끝나면 서버와 연결을 종료한다. 연결 종료 시 서버와 연결이 유지된 클라이언트는 없다.

 

HTTP는 기본이 연결을 유지하지 않는 모델이다. 초 단위 이하의 빠른 속도로 응답이 가능하며, 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다. 또한 서버의 자원을 매우 효율적으로 사용 가능하다.

 

- 비 연결성의 한계

• TCP/IP의 연결을 새로 맺어야 한다 -> 3 way handshake 시간 추가
• 웹 브라우저로 사이트 요청시 HTML뿐만 아니라 자바스크립트, css, 추가 이미지 등 많은 자원이 함께 다운로드된다

-> 이를 해결하고자 HTTP 지속 연결(Persistent Connections)을 사용한다!

 

1) HTTP 초기 - 연결, 종료 낭비

 

연결 -> 자원 요청/HTML 응답 -> 종료

 

2) HTTP 지속 연결

 

연결 -> 자원 요청/ HTML 응답 -> 자원 요청/ 자바스크립트 응답 -> ... -> 종료

더이상 필요한 자원이 없을 때까지 연결을 유지한 후 한 번에 종료한다. 이 경우 시간이 더욱 감소함을 알 수 있다.

 

- Stateless와 Connectionless의 차이

• Stateless : 클라이언트 서버 사이에 상태를 유지하지 않는다
• Connectionless : TCP/IP 커넥션 연결을 지속하지 않는다

5 . HTTP 메시지

[start-line]

1. HTTP 요청 메시지 구조

 

- 시작 라인(start-line)

start-line = request-line 

request-line = method (공백) request-target (공백) HTTP-version (엔터)

• method : HTTP 메서드
• request-target : 요청 대상
• HTTP-version : HTTP 버전

1) HTTP 메서드

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

2) 요청 대상

• absolute-path[?query] (절대경로[?쿼리])
• 절대경로= "/"로 시작하는 경로

2. HTTP 응답 메시지 구조

 

- 시작 라인(start-line)

 

start-line = status-line

status-line = HTTP-version (공백) status-code (공백) reason-phrase (엔터)

• HTTP-version :  HTTP 버전
• status-code : HTTP 상태 코드(요청의 성공, 실패를 나타낸다)  ex) 200: 성공, 400 : 요청 오류, 500 : 서버 내부 오류
• reason-phrase : 이유 문구(사람이 이해할 수 있는 짧은 상태 코드 설명 글)  ex) OK

[HTTP 헤더]

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)

 

- field-name은 대소문자 구분X, field-value는 대소문자 구분O

 

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

[HTTP 메시지 바디]

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