05-02 Http 프로토콜

Q. 당신이 개발한 웹 서비스에서는 클라이언트와 서버 간에 데이터는 어떻게 주고 받나요?

일단 웹 서비스는 애플리케이션 계층에서 HTTP를 사용하여 데이터를 주고받습니다. 클라이언트의 웹 브라우저에서 버튼 클릭이나 페이지 이동같은 사용자 액션이 발생하면, HTTP 요청이 생성됩니다. 이 요청에는 HTTP 메서드가 포함되어 어떤 작업을 수행할지 서버에 알리고, 필요한 데이터가 함께 실려 전송됩니다. 서버는 이 요청을 받아 처리한 후, 응답을 다시 클라이언트에게 보냅니다. 이 응답에는 요청 처리의 결과와 데이터, 그리고 캐싱이나 리디렉션과 같은 추가 정보가 담길 수 있습니다.

제가 만든 서비스는 SPA(Single Page Application) 형태로 개발되어, 초기 로딩 시에는 HTML, CSS, JavaScript 같은 정적 파일들을 HTTP를 통해 받고, 이후 데이터는 주로 RESTful API 형태로 서버와 JSON 데이터를 주고받습니다. 사용자 로그인, 데이터 조회, 게시물 작성 등 대부분의 상호작용은 비동기적으로 HTTP 요청을 보내고 JSON 응답을 받아 웹 페이지를 동적으로 업데이트하는 방식으로 이루어집니다.

Q. HTTP 웹 프로토콜에 대해서 더 자세히 설명해주세요.

HTTP는 하이퍼 텍스트 전송 프로토콜(HyperText Transfer Protocol)의 약자로 웹에서 클라이언트와 서버 간에 하이퍼텍스트를 주고받기 위한 프로토콜입니다. 이름에서 알 수 있듯이 HTTP가 설계될 때는 웹의 주된 콘텐츠가 하이퍼텍스트 문서(HTML)였기 때문에 하이퍼텍스트 전송 프로토콜이란 이름이 붙었습니다만, 요즘은 주로 JSON 형태로 데이터를 주고 받죠.

HTTP는 상태를 유지하지 않는 stateless 프로토콜로, 클라이언트가 서버에 요청을 보내면 서버는 이에 대한 응답을 보내고 연결을 종료합니다. 이를 통해 HTML 문서, 이미지, JSON 등 다양한 리소스를 주고받을 수 있습니다.

주요 메서드로는 데이터를 조회하는 GET, 데이터을 생성하는 POST, 데이터를 수정하는 PUT, 데이터를 삭제하는 DELETE 등이 있으며, 각 메서드는 특정한 목적에 맞게 사용됩니다. HTTP는 기본적으로 텍스트 기반이지만, 보안이 필요한 경우 SSL/TLS와 결합하여 HTTPS로 암호화된 통신을 할 수 있습니다.

Q. HTTP가 stateless 프로토콜이라고 설명해주셨는데, 그렇다면 웹 서비스에서 사용자 로그인 상태 유지나 장바구니 기능처럼 '상태'를 관리해야 할 때는 어떤 방식으로 이 stateless 한계를 극복하고 있나요?

HTTP가 stateless 프로토콜이여서 보통 로그인 상태 유지는 쿠키나 세션등을 이용합니다.

먼저 쿠키(Cookie)는 서버가 클라이언트에게 특정 정보를 담은 쿠키를 HTTP 응답 헤더에 담아 보내면, 클라이언트는 그 쿠키를 저장해둡니다. 그리고 이후 동일한 서버로 요청을 보낼 때 마다 해당 쿠키를 HTTP 요청 헤더에 자동으로 포함시켜 서버로 전송합니다. 그럼 서버는 이 쿠키를 통해 클라이언트의 상태를 식별하고 필요한 정보를 얻을 수 있습니다.

다음으로 세션(Sesstion)은 서버 측에서 사용자 상태 정보를 저장하는 방식입니다. 클라이언트가 로그인하면 서버는 고유한 세션 ID를 생성하고, 이 ID와 연결된 사용자 정보를 서버 메모리나 데이터베이스에 저장합니다. 쿠키가 클라이언트 측에 데이터를 저장하는 반면, 세션은 서버 측에 테이터를 저장하므로 보안상 더 유리할 수 있습니다.

마지막으로 토큰(Token) 기반 인증이 있습니다. 특히 JWT(JSON Web Token)와 같은 토큰이 많이 사용되는데, 클라이언트가 로그인 요청을 보내 인증에 성공하면, 서버는 사용자 정보를 담고 암호화된 토큰을 생성하여 클라이언트에게 응답을 보냅니다. 클라이언트는 이 토큰을 저장하고 있다가, 이후 서버에 요청 시 HTTP 요청 헤더의 Authorization 필드에 토큰을 포함시켜 전송합니다. 서버는 요청이 올 때마다 이 토큰의 유효성을 검증하고, 토큰에 담긴 정보를 통해 사용자 상태를 식별하여 권한을 부여합니다. 토큰은 서버가 별도의 세션 저장소를 유지할 필요가 없어 서버 확장에 용이하다는 장점이 있습니다.

Q. HTTP 메소드에서 PUT과 PETCH의 쓰임이 비슷한거 같은데 어떠한 차이점이 있나요?

PUT과 PATCH는 모두 리소스를 수정하는 데 사용되지만, 그 목적에 차이가 있습니다.

먼저 PUT 메소드는 리소스의 전체를 교체하거나 수정할 때 사용됩니다. 클라이언트가 서버에 전달한 데이터로 리소스 전체를 덮어쓰므로, 누락된 필드는 기본값이나 null로 설정될 수 있습니다. 즉, 리소스의 완전한 대체를 의미합니다.

반면 PATCH 메소드는 리소스의 일부를 수정할 때 사용됩니다. 클라이언트가 특정 필드만 수정하고 싶을 때, 해당 필드만 보내면 서버가 나머지 필드를 유지한 채로 변경사항만 반영합니다. 부분 업데이트에 더 적합한 방식입니다.

따라서 PUT은 전체 데이터를, PATCH는 부분 데이터를 수정하는 데 사용된다고 이해하면 됩니다.

Q. HTTP 1.1과 2, 3등 뒤에 숫자가 붙어있는 것을 볼 수 있는데 무엇을 의미하나요?

HTTP 뒤에 붙는 숫자는 프로토콜의 버전을 나타냅니다. 각 버전마다 성능 개선과 기능 추가가 이루어졌습니다.

HTTP/1.1은 오랫동안 사용된 버전으로, 한 번 맺은 연결을 계속 사용하는 지속적인 연결을 도입해 효율을 높였습니다. 또한 청크 전송 인코딩을 통해 동적 콘텐츠 전송을 유연하게 만들었죠. 하지만 요청과 응답을 순서대로 처리해야 하는 한계로 병목 현상이 발생할 수 있었습니다. Spring Boot로 개발한 서비스는 기본적으로 이 버전을 사용합니다.

HTTP/2는 HTTP/1.1의 병목 현상을 해결하고자 등장했습니다. 가장 큰 특징은 멀티플렉싱으로, 하나의 연결 안에서 여러 요청과 응답을 동시에 주고받을 수 있게 합니다. 이로 인해 웹 페이지 로딩 속도가 빨라졌고, 헤더 압축과 서버 푸시 기능으로 네트워크 자원 사용을 더욱 효율화했습니다.

HTTP/3는 최신 버전으로, HTTP/2에서 한 단계 더 나아가 전송 계층 프로토콜을 TCP 대신 UDP 기반의 QUIC으로 변경했습니다. QUIC는 연결 설정 시간을 단축시키고, 패킷 손실 시 해당 스트림만 재전송하여 전체 성능 저하를 줄입니다. 특히 모바일 환경처럼 네트워크 변동이 잦은 곳에서 연결 안정성과 속도 개선에 큰 이점이 있습니다.