[HTTP] 3. HTTP 기본

안녕하세요!

또 인프런 김영한 강사님 강의를 보고 왔어요~~

정리 시작해보겠습니다!

고고!!

---

1. HTTP에 관하여..

HyperText Transfer Protocol

HTTP 메시지에는 모든 것을 전송할 수 있습니다.

HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON (API), XML (API) 등 거의 모든 형태의 데이터 말이죠!

서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용합니다.

실무에서 TCP 프로토콜 직접 연결은 특수한 상황 아니면 잘 없습니다.

 

지금은 HTTP 시대!!

 

1-1. HTTP의 역사

• HTTP/0.9 1991년: GET 메서드만 지원했고, HTTP 헤더가 없었습니다.
• HTTP/1.0 1996년: 메서드와 헤더를 추가했습니다.
• HTTP/1.1 1997년: 현재 가장 많이 사용하고 있고, 우리에게 가장 중요한 버전입니다. (대부분의 기능이 들어있습니다)
• HTTP/2 2015년: 기존의 1.1 버전에서 성능을 개선하였습니다.
• HTTP/3 ~ing: TCP 대신에 UDP를 사용했고, 1.1 버전에서 성능을 개선하였습니다. 

 

1-2. 기반 프로토콜

• TCP 기반: HTTP/1.1, HTTP/2
• UDP 기반: HTTP/3 (속도 빨라지게 하려고 UDP를 사용해 최적화)
• 현재에는 HTTP/1.1을 주로 사용하고 있습니다.
  • HTTP/2와 HTTP/3도 점점 사용량이 증가하고 있습니다.

 

1-3. HTTP 특징

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

---

2. HTTP 특징1 - 클라이언트 서버 구조

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

클라이언트와 서버 분리

 옛날에는 클라이언트와 서버를 분리하지 않았습니다.
그러나, 지금은 클라이언트와 서버를 분리해서
서버에는 business logic(비지니스 로직)과 데이터를 넣고, 클라이언트는 사용성과 UI에 집중을 하게끔 했습니다.


분리할 때의 장점

클라이언트와 서버가 각각 독립적으로 진화가 가능합니다.

 

클라이언트 서버 구조

---

3. HTTP 특징2 - 무상태 프로토콜 (Stateless)

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

이게 뭔 말이지? 예제로 설명하겠습니다.

 

• 장점: 서버 확장성이 높습니다. (스케일 아웃)
• 단점: 클라이언트가 추가적으로 데이터를 많이 전송해야 합니다.

 

3-1. Stateful과 Stateless 차이

Stateful과 Stateless의 차이는 예제로 보면 이해가 쉽기에 예제로 정리했습니다.

 

3-1(1). Stateful과 Stateless 차이 (상태 유지 - Stateful)

상태 유지 - Stateful 예제

 

예제를 보면 고객과 점원의 일상적인 대화인 것을 알 수 있습니다.

두꺼운 글씨를 자세히 보고 밑에로 넘어가보도록 하겠습니다.

 

3-1(2). Stateful과 Stateless 차이 (상태 유지 - Stateful, 만약에 점원이 중간에 바뀌면?)

상태 유지 - Stateful 서버 오류 예제

 

어라? 점원이 바뀌었네요?

점원이 바뀌면서 고객이 하는 말을 이해를 못하고 있습니다.

 

3-1(3). Stateful과 Stateless 차이 (상태 유지 - Stateful, 정리)

상태 유지 - Stateful 예제 정리

 

이제 손님은 클라이언트, 점원은 서버라고 생각하면 됩니다.

 

따라서, Stateful은 서버가 클라이언트의 이전 상태를 보존합니다.

그러므로, 다른 서버(점원)로 바뀌면 오류가 납니다.

일일이 서버에게 다 따로 알려줘야해요!! 처음부터 다시 시작해야하고!! 얼마나 비효율적이에요!

 

3-1(4). Stateful과 Stateless 차이 (무상태 - Stateless)

무상태 - Stateless 예제

 

이 예제 역시 고객과 점원의 일상적인 대화인데요.

두꺼운 글씨 눈여겨 보고 밑에로 넘어가보도록 하겠습니다.

 

3-1(5). Stateful과 Stateless 차이 (무상태 - Stateless, 만약에 점원이 중간에 바뀌면?)

무상태 - Stateless 서버 오류 예제

 

여기서도 또 점원이 바뀌었어요!

근데, 아까와의 차이점이 보이시나요?

분명 점원이 바뀌었는데 아까 Stateful 때랑은 다르게 대화가 원활하게 잘 이어가는 것을 볼 수 있습니다.

 

즉, Stateless는 기존 서버가 아닌 다른 서버로 바뀌어도 오류가 나지 않습니다.

클라이언트가 필요한 데이터를 바로바로 넘기기 때문이죠.

 

3-1(6). Stateful과 Stateless 차이 정리

위에서 얘기한 예제를 토대로 Stateful과 Stateless 차이를 정리해보겠습니다.

• 상태 유지(Stateful): 중간에 다른 서버(점원)로 바뀌면 안됩니다.
  • 중간에 다른 서버(점원)로 바뀔 때, 상태 정보를 다른 서버(점원)에게 미리 알려줘야 합니다.
• 무상태(Stateless): 중간에 다른 서버(점원)로 바뀌어도 됩니다.
  • 갑자기 클라이언트(고객) 요청이 증가해도 서버(점원)을 대거 투입할 수 있습니다.
• 무상태는 응답 서버를 쉽게 바꿀 수 있습니다. -> 무한한 서버 증설이 가능합니다!!

 

3-2. 상태 유지 - Stateful

이제 위에서 얘기한 Stateful과 Stateless에 관해서 그림으로 보여드리겠습니다.

예제를 봤으므로 이제 그림이 이해가 가겠죠?

 

• 항상 같은 서버가 유지되어야 합니다.

 

클라이언트A는 서버1이랑만 통신을 해서 서버를 더 늘리기 어렵습니다.

처음 요청할 때 데이터를 한 번에 보내지 않기 때문입니다.

 

• 중간에 서버가 장애가 나면?

 

중간에 서버1이 장애가 나면 클라이언트A는 처음부터 다시 해야합니다.

서버2와 서버3은 서버1이 갖고 있던 데이터가 없기 때문이죠.

 

3-3. 무상태 - Stateless

• 아무 서버나 호출해도 됩니다.

 

클라이언트A가 요청을 할 때 부터 데이터를 다 가지고서 요청을 보냅니다.

아무 서버나 답해라!

 

• 중간에 서버가 장애가 나면?

 

서버1이 고장 나도 서버2가 답할 수 있습니다.

 

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

 

서버를 무한대로 놔둬도 빠르게 통신이 가능합니다.

 

• 실무 한계
  • 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있습니다.
    • 무상태 예시: 로그인이 필요 없는 단순한 서비스 소개 화면
    • 상태 유지 예시: 로그인 (Stateless의 한계)
  • 로그인 한 사용자의 경우에는 로그인 했다는 상태를 서버에 유지합니다.
  • 일반적으로 브러우저 쿠키와 서버 세션 등을 사용해서 상태를 유지합니다.
  • 그 외에도 데이터를 너무 많이 보낼 수 있다는 한계가 있습니다.
  • 상태 유지는 최소한만 사용!!
    • 로그인 같은 기능을 위해서 상태 유지를 사용은 하되, 최소한으로 사용하고 왠만하면 무상태를 사용하는 것이 좋습니다.

 

---

4. HTTP 특징3 - 비 연결성 (connectionless)

 

4-1. 연결을 유지하는 모델

1. 클라이언트1과 서버가 우선 요청 응답(TCP/IP 연결) 합니다.

 

 

2. 클라이언트1과 서버가 연결된 상태에서 클라이언트2와 서버가 요청 응답해도 클라이언트1과 서버는 계속 연결되어 있습니다.

 

 

3. 클라이언트3과 서버가 연결해도 클라이언트1과 서버, 클라이언트2와 서버는 계속 연결되어 있습니다.

 

계속 연결되고 있을 때의 단점

클라이언트1과 클라이언트2가 요청 응답하지 않고 놀고 있어도 쓸데없이 연결을 계속 유지해야 합니다.
즉, 서버 자원은 연결되어 있는 동안 계속 소모가 됩니다.

 

4-2. 연결을 유지하지 않는 모델 (비 연결성)

1. 클라이언트1과 서버가 우선 요청 응답(TCP/IP 연결) 합니다.

 

 

2. 그러고 작업이 끝나면 즉시 연결을 끊어냅니다.

 

 

3. 클라이언트2와 서버를 연결합니다.

그러고 클라이언트1 때 처럼 작업이 끝나면 즉시 연결을 끊어냅니다.

 

 

4. 클라이언트3도 클라이언트1, 클라이언트2 때처럼 합니다.

 

 

작업이 끝나고 즉시 연결을 끊어냈을 때의 장점

연결할 때만 자원을 쓰고 바로 연결을 끊어버리니까 최소한의 자원 소모를 유지할 수 있습니다.
클라이언트가 위의 그림처럼 3개가 아닌 수 만 개가 되어버린다면 사용되는 자원의 양이 엄청 줄어들 것입니다.

 

 

4-2(1). 비 연결성 정의

• HTTP는 기본적으로 연결을 유지하지 않는 비 연결성 모델입니다.
• HTTP는 일반적으로 초 단위 이하의 빠른 속도로 응답합니다.
• 1시간 동안 수 천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수 십 개 이하로 매우 작습니다.
  • ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않습니다.
• 서버 자원을 매우 효율적으로 사용할 수 있습니다. (이유는 위에서 확인)

 

4-3. 비 연결성 한계와 극복

<한계>

• 연결할 때마다 TCP/IP 연결을 새로 맺어야 합니다.
  • 3 way handshake 시간이 추가 됩니다. (사용자 입장에서 매우 단점)
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드가 됩니다.
  • 즉, 검색 하나만 해도 수 많은 자원이 우루루 다운로드가 됩니다.

<극복>

• 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결했습니다.
  • HTTP 지속 연결과 관련된 얘기는 밑에서 하도록 하겠습니다.
• HTTP/2, HTTP/3에서 더 많이 최적화 하였습니다.

 

4-3(1). HTTP 초기 - 연결, 종료 낭비

0.1초 시간은 임의로 적어놓은 것입니다.

필요한 것이 생길 때마다 연결을 하고 끝나면 바로 끊고.. 시간 낭비가 됩니다.

 

 

4-3(2). HTTP 지속 연결(Persistent Connections)

짧은 시간 동안만 연결을 유지하다가 연결을 종료시켜버립니다.

그 짧은 시간 동안 작업을 다 하는 것입니다.

http/3는 UDP 연결을 해서 지속 연결을 하면서 연결하는 속도 마저 줄여버렸습니다.

 

---

5. HTTP 특징4 - HTTP 메시지

젤루 중요한 HTTP 메시지에 관해서 설명해보도록 하겠습니다.

우선 HTTP 요청 메시지와 HTTP 응답 메시지의 예시를 보여드리도록 하겠습니다.

 

예시는 위의 사진처럼 이렇고 HTTP 요청 메시지와 HTTP 응답 메시지 구조 차이를 그림으로 설명하도록 하겠습니다.

HTTP 요청 메시지와 HTTP 응답 메시지는 시작 라인이 다릅니다!! 

또한, HTTP 요청 메시지와 HTTP 응답 메시지 둘 다 무조건 공백라인(CRLF)가 있어야 합니다.

 

5-1. 요청 메시지 시작 라인

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

• start-line = request-line(요청 메시지) / status-line(응답 메시지)
• request-line = method SP(공백 - 한 칸 띄는 space키) request-target SP(공백 - space키) HTTP-version CRLF(엔터)
  • method: GET = 조회
  • request-target: path = /search?q=hello&hl=ko
  • HTTP-version: HTTP 버전

 

5-1(1). 요청 메시지 시작 라인 - HTTP 메서드

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

• 종류: GET, POST, PUT, DELETE
• 서버가 수행해야 할 동작을 지정합니다.
  • GET: 리소스 조회
  • POST: 요청 내역 처리
• HTTP 메서드의 더 자세한 내용은 뒤에서 하도록 하겠습니다.

 

5-1(2). 요청 메시지 시작 라인 - 요청 대상

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

• absoulte-path[?query] => (절대경로[?쿼리])
  • 절대 경로에 쿼리 합쳐서!
  • 절대 경로 = "/"로 시작하는 경로

 

5-1(3). 요청 메시지 시작 라인 - HTTP 버전

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

• HTTP Version

 

5-2. 응답 메시지 시작 라인

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 버전
  • status-code: HTTP 상태 코드, 요청 성공 혹은 요청 실패를 나타냅니다.
    • 200: 성공
    • 400: 클라이언트 요청 오류
    • 500: 서버 내부 오류
  • reason-phrase: 이유 문구 = 사람이 이해할 수 있는 짧은 상태 코드 설명 글

 

5-3. HTTP 헤더

위에가 요청 메시지 / 아래가 응답 메시지

노란색 배경에 밑줄 쳐진 부분이 헤더 부분 입니다.

요청 메시지와 응답 메시지 둘 다 헤더 구조가 비슷합니다.

• header-field = field-name ":" OWS field-value OWS    (OWS: 띄어쓰기 허용)
• field-name은 대소문자 구분이 없습니다.

 

5-3(1). HTTP 헤더 - 용도

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

 

5-4. HTTP 메시지 바디

파란색 배경에 노란 글씨가 메시지 바디 부분 입니다.

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

 

6. HTTP 특징5 - 단순함 확장 가능

• HTTP는 단순합니다. 또한, HTTP 메시지도 매우 단순합니다.
• 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술입니다.
• 지금은 HTTP 시대!!