HTTP의 특징(서버/ 클라이언트 구조, Stateless, Connectionless)

HTTP의 특징

http의 특징인 서버/클라이언트 구조, Stateless, Connectionless, http message 중

서버/클라이언트 구조와 Stateless, Connectionless에 대해서 정리해놓은 게시물입니다.

서버/ 클라이언트 구조

• 클라이언트: 요청을 보내(고 응답 대기하는) 쪽
• 서버: 요청에 대한 (결과를 만들어내서) 응답하는 쪽
• 무조건 클라이언트가 먼저 요청을 해야 서버에서 응답하는 구조
• 데이터의 전송이 필요 → 이때 TCP 프로토콜을 사용함

서버/ 클라이언트 구조의 의의 및 장점

• 클라이언트와 서버의 분리
  • 리소스가 존재하는 곳(서버)와 리소스를 사용하는 곳(클라이언트)로 분리
  • 서버: 데이터와 비즈니스 로직
  • 클라이언트: UI 사용성
• 독립적인 관리 가능
  • 사용성 향상이 필요할 때? 클라이언트 관리
  • 트래픽 증가에 대한 대응? 서버 관리
  •  

무상태성(Stateless)

우선 무상태성을 설명하기 전에 Stateless한 상태는 무엇일까?

Stateful

• 서버가 클라이언트 상태를 보존하는지에 따라 나뉨
• 특정 서버가 특정 클라이언트를 대응하면 Stateful, 자유자재로 확장 및 변경 할 수 있으면 Stateless

그림과 같이 위에 2개를 담당하고 있는 첫번째 서버가 다운이 될 경우 클라이언트 2개를 다른 서버들이 담당해주지 못한다.

그럼 반대로 Stateless는 어떤 것인지 느낌이 대충 올것이다.

Stateless

• 상태를 보존하지 않음
• 장점: 서버 확장성이 좋다 = 스케일 아웃이 용이하다
• 서버 확장성이란? 한개의 클라이언트를 상대하기 위해 한개의 서버만을 이용하는 것이 아니라 여러개 서버를 번갈아 가면서 사용 가능하다는 의미
• 단점: 클라이언트에서 추가로 데이터를 전송해야한다

Stateless 단점

- 고객 : 이 노트북은 얼마인가요?
- 점원A : 100만원 입니다.
- 고객 : 2개 주문할게요
- 점원B : 어떤 거 말씀이세요?
- 고객 : 신용카드로 하겠습니다.
- 점원C : 무슨 제품을 몇개 구매하시겠어요?

Stateless 장점

- 고객 : 이 노트북은 얼마인가요?
- 점원A : 100만원 입니다.
- 고객 : 노트북 2개 주문할게요
- 점원B : 200만원입니다. 신용카드, 현금 중에 어떻게 구매하시겠어요?
- 고객 : 노트북 2개를 신용카드로 하겠습니다.
- 점원C : 200만원 결제 완료되었습니다.

• 즉 점원이 바뀌어도 괜찮다
• 트래픽이 갑자기 늘어도(고객이 갑자기 많아져도) 점원만 충분히 고용하면 늘어난 고객에 대해 대응이 가능하다(응답서버를 마음대로 바꿀 수 있다)
• 갑자기 점원 하나가 쓰러져도(서버가 뻗어도) 대응 가능하다

한계와 극복

• 모든 것이 무상태일 수는 없다(ex. login 여부) → 데이터 유지가 필요할 때가 있음
• 서버에서 관리해줘야 한다
• 단순한 요청에 대한 데이터가 너무 많이 왔다갔다 한다.
• 이를 해결하기 위해 쿠키(브라우저 : 클라이언트)와 세션(서버) 사용해서 stateful인 것 처럼 사용함.

해결 방안

• 쿠키(브라우저 : 클라이언트)와 세션(서버) 사용

쿠키와 세션에 대해서도 자세히 다룰 예정이나 대략적인 느낌을 갖자면 다음과 같다.

 

쿠키와 세션)

처음 사이트에 들어갈 때  “쿠키허용을 해주시면 저희 사이트가 더 좋은 서비스를 제공할 수 있습니다.” 문구가 나옴 → 클라이언트의 웹 브라우저에 쿠키가 존재하므로 사용자에게 요청하는것

 

다른 일반 사이트에서 로그인 한 후 일정 시간 사용을 안하면 “세션이 만료되었습니다”라는 문구가 나옴 → 서버에서 일정시간 동안만 세션을 갖고 있기 때문에 서버가 사용자를 다시 확인해야함.

 

제로베이스 스쿨에 로그인 한 후 강의를 듣고 나서 일정시간 사용을 안하면

“인증 토큰이 만료되었습니다”라는 문구가 나옴 → 세션과 마찬가지로 서버가 클라이언트에게 주는 인증도구 ‘토큰’

비연결성(Connectionless)

• 한 동작에 대한 요청을 주고 받을 때만 TCP를 연결하고 응답 후엔 바로 연결 끊음
• ex. 1시간동안 수천명이 사용하는 서비스도 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작음 (그러나 인기많은 티켓판매나 한꺼번에 많은 사람들이 동시에 처리하는 요청도 있음 )
• 즉 서버 자원을 효율적으로 관리할 수 있음

한계와 극복

• 요청이 있을 때마다 TCP 연결을 열어줘야하니 3way handshake 시간이 추가된다TCP 연결시 연결되는 방식
  1. SYN(접속 요청) “서버야 나 이런 데이터가 필요해 너 지금 자리에 있니?” : [클라이언트] -> [서버]
  2. SYN+ACK “응 나있어 요청해~”: [클라이언트] <- [서버]
  3. ACK(요청 수락) “나 A이미지랑 B동영상 좀 보여줘~”: [클라이언트] -> [서버]
  4. 데이터 전송(3번과 함께 수행 가능)
  • 즉 통신하기 전에 연결 과정이 추가로 필요하다
  • TCP 해제시 해제되는 방식은 4way handshakeTCP 연결시 연결되는 방식
    1. FIN(해제 요청) “서버야 나 TCP 해제하려고 해제해도되니?(보내는 데이터 없지?)” : [클라이언트] -> [서버]
    2. ACK “응 잠시만 확인해볼게~”: [클라이언트] <- [서버]
    3. FIN “응 보낼 거 다 보냈어 종료해도 돼”: [클라이언트] <- [서버]
    4. ACK “알겠어 종료할게!”: [클라이언트] -> [서버]
    5. 연결해제(4번과 함께 수행 가능)
    • 연결을 해제할 때도 과정이 추가로 필요하다.
  • 4 way handshake란?
• 3 way handshake란?
• 한 동작에 대한 요청은 수십가지인데 매요청마다 연결을 끊으면 연결/ 종료에 대한 시간이 매번 소비된다
  • 개발자도구로 네이버 홈화면 클릭시 HTML 뿐만 아니라 javascript, css, 추가 이미지등 수많은 자원이 함께 다운로드 됨
• 이를 극복하기 위해 Persistent Connection(지속 연결, 과거 keep-alive)을 활용한다
  • http/2, http/3 표준에서 최적화가 더 많이 이루어졌고
  • http/3의 경우 UDP 프로토콜을 통해 연결 속도를 더 빠르게 개선

Persistent Connection

Persistent Connection이 없는 경우?

- 연결(0.1초)
- 요청/html 응답(0.1초)
- 종료(0.1초)
- 연결(0.1초)
- 요청/자바스크립트 응답(0.1초)
- 종료(0.1초)
- 연결(0.1초)
- 요청/이미지 응답(0.1초)
- 종료(0.1초)

• total 0.9 sec

Persistent Connection이 있는 경우?

- 연결(0.1초)
- 요청/html 응답(0.1초)
- 요청/자바스크립트 응답(0.1초)
- 요청/이미지 응답(0.1초)
- 종료(0.1초)

• total 0.5 sec
•