HTTP 기본

1. 모든 것이 HTTP

📌 HTTP(HyperText Transfer Protocol)
하이퍼텍스트를 교환하기 위한 프로토콜이다. HTTP에 HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML (API) 등 거의 모든 형태의 데이터 담아 전송할 수 있다. 서버 간에 데이터를 주고받을 때도 대부분 HTTP를 사용한다.

📌 HTTP 역사

• HTTP/0.9 (1991년): GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 (1996년): 메서드, 헤더 추가
• HTTP/1.1 (1997년): 가장 많이 사용, 우리에게 가장 중요한 버전
  👉 RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
• HTTP/2 (2015년): 성능 개선
• HTTP/3 (진행 중): TCP 대신에 UDP 사용, 성능 개선

📌 HTTP의 기반 프로토콜
HTTP/1.1, HTTP/2는 TCP 프로토콜 위에서 동작한다. HTTP/3는 UDP 프로토콜 기반으로 개발되어 있다. TCP는 3 way handshake를 수행하고 데이터양이 많고 메커니즘 자체가 속도가 느린 편이다.

이 때문에 UDP 프로토콜 위에 애플리케이션 단계에서 성능을 최적화하도록 새로 설계한다. 현재 HTTP/1.1 주로 사용하지만, HTTP/2, HTTP/3의 사용도 점점 증가하고 있다.

👉 웹 사이트 개발자 도구에서 현재 웹 사이트의 프로토콜을 확인할 수 있다. 인프런 강의 사이트는 HTTP/2 버전이 사용되고 있다.

📌 HTTP 특징
HTTP는 클라이언트 서버 구조로 동작한다. 무상태 프로토콜(stateless)이고 비연결성이라는 특징이 있다. 또한, HTTP 메시지를 통해서 통신하고 단순하고 확장 가능하다.

---

2. 클라이언트 서버 구조

📌 Request Response 구조

HTTP는 클라이언트가 HTTP 메시지를 통해 서버에 요청을 보내고 서버에서 클라이언트로 응답이 올 때까지 기다린다. 서버가 요청에 대한 결과를 만들어서 응답이 오면, 그 응답 결과를 열어 클라이언트가 동작한다.

💡 클라이언트와 서버를 분리하는 이유

클라이언트와 서버를 분리해서 클라이언트는 UI와 사용성에 집중하고, 서버는 비지니스 로직과 데이터에 집중하게 했다.

이슈가 발생해도 서로의 역할이 다르기 때문에 영향을 미치지 않고 독립적으로 이슈에 대응하면서 진화할 수 있다.

---

3. Stateful, Stateless

🙍‍♂️ 고객은 노트북 2개를 신용카드로 구매할 예정이다.
🙍‍♀️ Stateful, Stateless에 따른 고객과 점원의 상태 변화를 알아보자.

📌 상태 유지(Stateful)

서버가 클라이언트의 상태를 유지한다. 클라이언트의 요청 정보를 매칭된 서버에 계속 유지해야 하므로 서버를 늘릴 수가 없다. 중간에 유지해야 하는 서버에 장애가 발생하여 서버가 변경된다면, 클라이언트가 정보를 다시 요청해야 한다.

점원(서버)이 '고객이 노트북 2개를 신용카드로 구매할 것이다.'라는 내용을 기억하고 있는다.

📌 무상태(Stateless)

서버가 클라이언트의 상태를 유지하지 않는다. 클라이언트의 모든 요청 정보를 서버에 요청하면 서버는 상태를 보존하지 않고 응답만 한다. 중간에 서버에 장애가 발생해도 클라이언트 요청에 필요한 정보가 모두 담겨있기 때문에 다른 서버에 요청하고 서버가 응답할 수 있다.
👉 무한 서버 증설 가능.

고객이 직원에게 결제를 요청할 때 '노트북 2개를 신용카드로 구매할 것이다.' 와 같이 모든 요청 내용을 같이 말한다.

📌 무상태 스케일 아웃

무상태는 수평 확장에 유리하다. 만약 로그인 없이 검색만 할 경우, 검색 서버에 트래픽이 많이 올라가더라도 검색 서버에 클라이언트의 상태가 유지되지 않아서 서버를 많이 늘릴 수 있다. 또한, 상태를 유지할 필요가 없어 설계가 용이하다.

📌 상태 유지(Stateful)와 무상태(Stateless)의 한계

💡상태 유지(Stateful)의 한계

• 로그인해야 하는 경우, 로그인한 사용자가 로그인했다는 상태를 서버에 유지해야 한다.
• 브라우저에서 쿠키와 세션을 같이 조합해서 상태를 유지하는 기능을 사용한다.
  👉 서버에 세션이 날아가거나 세션 서버가 죽어버리면 로그인이 풀린다.
• 상태 유지는 최소한만 사용한다.

💡무상태(Stateless)의 한계

• 클라이언트 요청 정보를 담아야 하기 때문에 데이터양이 많다.

---

4. 비연결성(connectionless)

📌 연결을 유지하는 모델

여러 클라이언트에서 서버로 응답을 요청하면 서버는 요청이 들어온 클라이언트마다 연결을 유지해서 상태를 저장한다. 클라이언트가 많아질수록 연결을 유지하는 서버 자원이 계속 소모된다는 단점이 있다.

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

클라이언트가 요청할 때마다 서버는 응답만 보내주고 연결을 종료하기 때문에 최소한의 자원을 사용한다.

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

📌 비연결성의 한계

• TCP/IP 연결을 새로 맺을 때마다 3 way handshake 시간이 추가돼서 클라이언트 입장에서는 느리다.

• 웹 브라우저로 사이트를 요청하면 HTML뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드된다.
  👉 이때마다 연결하고 끊고를 반복하면 비효율적이다.
  
  

📌 비연결성의 한계 극복
HTTP 지속 연결(Persistent Connections)로 비연결성의 한계를 극복할 수 있다. HTTP/2, HTTP/3에서 지속 연결이 더욱 최적화 되어있다.

💡 HTTP 초기

👉 '연결하고 요청/응답하고 종료'를 반복하므로 속도가 느리다.

💡 HTTP 지속 연결(Persistent Connections)

👉 연결을 유지하면서 내부 메커니즘으로 요청/응답을 완료한 후 종료하므로 속도가 빠르다.

➕➕
Stateless를 기억하자
서버 개발자들이 어려워하는 업무는 선착순 이벤트, 명절 KTX 예약과 같이 같은 시간에 딱 맞춰서 발생하는 대용량 트래픽 관리이다. 이와 같은 상황에서는 Stateless 하게 설계하는 게 가장 중요하다.

---

5. HTTP 메시지

📌 HTTP 메시지 구조

HTTP 메시지는 start-line, header, empty line(CRLF), message body 4개의 구조로 나뉜다.

📌 HTTP 요청 메시지

⚡ start-line = request-line

GET/search?q=hello&hl=ko HTTP/1.1
method SP(공백) request-target SP(공백) HTTP-version CRLF(엔터)

Host: www.google.com
field-name":" OWS field-value OWS        (OWS:띄어쓰기 허용)

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

• request-target

  /absolute-path[?query]
  /절대경로[?쿼리]

절대경로는 "/"로 시작하고 뒤에 쿼리를 합친다.
(*http://...?x=y와 같이 다른 유형의 경로지정 방법도 있다.)

📌 HTTP 응답 메시지

⚡ start-line = status-line

HTTP/1.1 200 OK
HTTP-version SP status-code SP reason-phrase CRLF

• status-code (HTTP 상태 코드)
  클라이언트 요청이 성공했는지 실패했는지를 나타낸다.
  ✔️ 200: 성공, 400: 클라이언트 요청 오류, 500: 서버 내부 오류
  
  

• reason-phrase(이유 문구)
  사람이 이해할 수 있는 짧은 상태 코드 설명이다.

⚡ HTTP header

위 사진에서
field-name은 Content-Type, Content-Length
field-value는 'text/html;charset=UTF-8', ': 3423'

• field-name: 대소문자 구분 ❌
• field-value: 대소문자 구분 ⭕

HTTP 헤더는 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등 HTTP 전송에 필요한 모든 부가 정보를 담고 있다.

표준 헤더가 매우 많고 필요시 임의의 헤더를 추가할 수 있다.

⚡ HTTP 메시지 바디

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