CH02 HTTP 기본

클라이언트 - 서버 구조

이건 그냥 말 그대로 클라이언트는 http를 통해서 요청을 하고 서버의 응답을 기다리며, 서버는 http를 통해서 답을 클라이언트에게 준다는 개념이다. 이 구조가 사실 굉장히 당연스럽고 ‘원래 그런거 아니야?’ 라고 할 수 있지만 강의에서는 http가 나오면서 이런 구조로 서비스가 운영되게 되었다고 말해주고 있었다.

그럼 더 중요한 것은 클라이언트 - 서버 구조가 의도하는 바라고 할 수 있는데, 클라이언트는 가져와서 보여주는 것에 집중하고 서버는 필요한 저장 및 연산을 하는 것에 집중하는 것으로 역할을 나눠 가져서 독립적으로 발전하면서도 사용자 경험을 증대(서비스의 향상)시킬 수 있도록 하는 것이 클라이언트 - 서버 구조가 의도하는 바라고 할 수 있겠다.

Stateful vs Stateless

상태가 없다는 말이 곧 클라이언트의 상태를 보존하지 않는다 는 이야기이고 이것이 Stateless의 핵심이다. 강의에서 정말 예시를 멋지게 들고 있어서 여기 옮긴다.

상태 유지 - Stateful

고객: 이 노트북 얼마인가요? 점원: 100만원 입니다. 고객: 2개 구매하겠습니다. 점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? 고객: 신용카드로 구매하겠습니다. 점원: 200만원 결제 완료되었습니다.

무상태 - Stateless

고객: 이 노트북 얼마인가요? 점원: 100만원 입니다. 고객: 노트북 2개 구매하겠습니다. 점원: 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? 고객: 노트북 2개를 신용카드로 구매하겠습니다. 점원: 200만원 결제 완료되었습니다.

핵심은 Stateless에서는 매 요청마다 점원이 바뀌어도 처리에 아무 상관이 없다는 것이다. 왜냐하면 각각의 독립된 처리에 필요한 데이터를 클라이언트가 모두 보내주기 때문이다. 이를 통해서 의도하는 바는 결국 상태유지할 필요가 전혀 없기 때문에 어느 시점이든 시점에 상관없이 원하는 시점에 서버 증설을 무한대로 늘릴 수 있다는 것이다.

다시 말해서, 각각의 (통신중인 서버)서버는 클라이언트의 상태를 보존할 의무가 없기 때문에(대화중인 고객의 대화 내용을 트랙킹할 필요가 없기 때문에) 모두 현재 시점에서 진행중인 프로세스를 처리하고 밀려있는 프로세스가 없다면 항상 자유의 몸이고, 이를 도와줄 여러 다른 서버를 중간에 대거 투입해도 전체 서비스 운영에 아무런 문제가 없다.

더 쉽게 말해서 Stateless한 덕분에 스케일아웃이 용이한 구조 가 된다.

메세지

start-line은 요청이냐 응답이냐에 따라서 request-line, status-line으로 구분된다

• start-line : 해당 요청 및 응답에 대한 method type, http version, url, status code

• header : 해당 요청 및 응답에 대한 모든 메타 데이터

• empty-line : 공백 라인

• body : 해당 요청 및 응답의 데이터