모든 것이 HTTP

HTTP ( HyperText Transfer Protocol)

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

---

HTTP 역사

• HTTP/0.9 : GET 메서드만 지원, HTTP 헤더 없음
• HTTP/1.0 : 메서드, 헤더 추가
• HTTP/1.1 : 가장 많이 사용
  • RFC2068(1997) -> RFC2616(1999) -> RFC7230~7235(2014)
• HTTP/2 : 성능 개선
• HTTP/3 : TCP 대신에 UDP 사용, 성능 개선

---

기반 프로토콜

• TCP : HTTP/1.1. HTTP/2
• UDP : HTTP/3
  • 느린 TCP 대신 UDP 프로토콜 위에 애플리케이션 레벨에서 성능을 최적화하도록 나온 버전

---

HTTP 특징

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

---

클라이언트 서버 구조

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고, 응답 대기
• 서버가 요청에 대한 결과를 만들어서 응답
  • 서버 : 비즈니스 로직이랑 데이터
  • 클라이언트 : UI, UX그리기, 사용성에 집중
    
    • 양쪽이 독립적으로 진화할 수 있다는 것이 중요하다.

---

Stateful,Stateless

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

---

Stateful, Stateless 차이 (상태 유지 여부)

• Stateful (서버가 클라이언트의 상태를 보존한다.) - Server가 바뀌면 Context가 사라진다.
  • 중간에 다른 서버로 바뀌면 안된다.
    • 중간에 다른 서버로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다. 
  • Client : 이 노트북 얼마인가요?
  • Server : 100만원 입니다. (노트북 상태 유지)
  • Client : 2개 구매하겠습니다.
  • Server : 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매 하시겠어요? (노트북, 2개 상태 유지)
  • Client : 신용카드로 구매하겠습니다.
  • Server : 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지)

• Stateless
  • 중간에 다른 서버로 바뀌어도 된다.
    • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다. 
    • 무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능
  • Client : 이 노트북 얼마인가요?
  • ServerA : 100만원 입니다.
  • Client : 노트북 2개를 구매하겠습니다.
  • ServerB : 노트북 2개는 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매하시겠어요?
  • Client : 노트북 2개를 신용카드로 구매하겠습니다.
  • ServerC : 200만원 결제 완료되었습니다.

 

---

Stateless (실무 한계)

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

---

비연결성 (connectionless)

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

• 단점
  • TCP/IP 연결을 새로 맺어야 함.
    
    • 3 way handshack 시간이 추가됨. -> client 입장에서 짜증
  • 웹 브라우저로 사이트를 요청하면
    • HTML 뿐만 아니라 javascript, css, 추가 이미지 등 수 많은 자원이 함께 다운로드
  • 지금은 HTTP 지속 연결 (Persistent Connections)로 문제 해결
  • HTTP/2, HTTP/3 에서 더 많은 최적화

---

Stateless를 기억하자

서버 개발자들이 어려워하는 업무

• 같은 시간에 맞춰 발생하는 대용량 트래픽
  • 예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
  • 예) 저녁 6시 1000명 치킨 할인 이벤트 -> 수만명이 동시에 요청.
• 어떻게든 머리를 쥐어짜서 최대한 stateless하게 설계한다.