클라이언트는 화면에 보이고 사용자와 상호작용을 하는 브라우저(애플리케이션도 될 수 있다.)를 말하며, 서버는 클라이언트에서 필요한 데이터를 요청하면 최종적으로 도달하는 추상적인 공간이다.
사용자가 브라우저를 통해 상호작용 하는 것이 클라이언트와 서버가 서로 통신하는 것으로 볼 수 있는 셈이다.
브라우저는 서버로 요청을 하고, 서버로 부터 응답 받은 데이터를 사용자에게 보여준다.
(꼭 요청해서 응답 받은 데이터를 보여주는 것 뿐 아니라, 새로운 데이터를 저장하거나 기본 데이터를 수정 또는 삭제 할 때도 서버로 요청하고 응답을 받는다.)
그렇다면 브라우저는 서버로 어떻게 요청을 하는걸까?
브라우저는 HTTP(Hyper Text Transfer Protocal)라는 전 세계적으로 약속된 인터페이스를 통해 서버와 통신을 주고 받는다.
브라우저에서 서버로 요청을 보내게 되면 서버의 루트 도메인으로 가서 추가적인 정보에 따라 작업을 진행할것이다.
서버로 요청을 보낼 때 클라이언트와 서버는 서로 통신을 할 준비가 되어있는지 테스트를 하는데 이는 TCP라는 프로토콜을 기반으로해서 작동하는 HTTP의 특징이다.
통신을 할 준비가 되어있는지 테스트를 하는 것을 핸드 쉐이크라고 부르며, 준비가 됬다면 그때서야 실질적인 통신을 한다.
왜? 서로 통신을 할 준비가 되어있는지 테스트를 하는 핸드 쉐이크를 하는것일까?
TCP는 패킷 전송 방식을 사용하기 때문에 보내려고 하는 데이터를 여러 개의 패킷으로 쪼갠 후 일정 단위로 묶어서 스트림처럼 전송한다.
전송을 위처럼 한다면 받는 측은 어떨까?
쪼개서 보내주니까 어떻게 조립을 해야할지? 어떤 데이터끼리 연관이 있는지? 누가 보낸건지? 알아야 한다.
그래서 핸드 쉐이크라는 특별한 과정을 통해 연결을 생성하고, 시퀀스 번호를 주고 받는 등 신뢰성을 위한 작업들을 진행한다.
TCP는 신뢰성 있는 연결을 추구하는데 통신하기 위해 연결을 생성하고 종료하는 순간에도 신뢰성을 확보하기 위함이다.(연속적인 데이터 전송의 신뢰성)
브라우저가 응답을 받으면 HTTP 상태코드를 받는데, 상태코드는 100번대~ 200번대~ 300번대~ 400번대~ 500번대~ 가 있다.
통신을 할 준비가 되었는지 테스트를 할 때 정상적으로 준비가 된 상태면 응답코드가 200번대로 들어온다.
상태코드를 간단하게 요약하자면 클라이언트가 요청한 것에 대한 결과를 숫자로 표현한 것이다.
프론트엔드 개발자가 주로 마주치는 상태코드는 200번대~ 와 400번대~ 그리고 500번대~ 이다.
200 : 상태코드 메시지는 OK.
클라이언트가 요청한 작업이 성공했음을 의미한다.
201 : 상태코드 메시지는 Created.
클라이언트가 요청한 작업이 성공했고, 결과로 리소스가 새롭게 생성되었다는 것을 의미한다.
400 : 상태코드 메시지는 Bad Request.
클라이언트가 요청을 잘못 했다는 것을 의미한다.
403 : 상태코드 메시지는 Forbidden.
접근이 안되는 리소스를 요청했음을 의미한다.
404 : 상태코드 메시지는 Not Found.
요청한 리소스를 찾을 수 없음을 의미한다.
500 : 상태코드 메시지는 Internal Server Error.
서버에서 무슨 문제가 일어났다는것을 의미한다.
502 : 상태코드 메시지는 Bad Gateway.
서버 또는 백엔드 애플리케이션과 서버 간의 연결된 통로에 문제가 일어났다는것을 의미한다.
503 : 상태코드 메시지는 Service Unavailable.
서버가 요청을 처리할 준비가 되어있지 않다는것을 의미한다.
504 : 상태코드 메시지는 Gateway Timeout.
클라이언트에서 보낸 요청이 타임아웃 된게 아니라, 백엔드 아키텍처 내부에서 서버끼리 주고받는 요청에서 타임아웃이 발생한것을 의미한다.
실질적인 통신을 할 때 서버에서 응답을 해주는데, 응답의 헤더에는 http 프로토콜의 버전 / 요청의 성공 여부를 나타내는 상태코드 / 상태코드의 설명을 나타내는 메시지 / 리소스가 포함되는 본문 등이 들어있다.
프론트엔드 개발자는 상태코드를 가지고 핸들링 할 수 있으며, 리소스를 받아 사용 할 수 있다.
