[Http&Network Basic] 2장 간단한 프로토콜 HTTP

1. HTTP는 클라이언트와 서버 간에 통신을 한다.

HTTP 프로토콜에서는 반드시 한 쪽은 클라이언트, 다른 한 쪽은 서버의 역할을 담당한다.

TCP/IP에 있는 다른 많은 프로토콜과 마찬가지로 HTTP도 클라이언트와 서버 간에 통신을 한다. 텍스트와 이미지 등의 리소스를 필요하다고 요구하는 쪽이 클라이언트가 되고, 이러한 리소스를 제공하는 쪽이 서버가 된다. HTTP를 사용하여 2대의 컴퓨터 간에 통신을 하는 경우, 한 번 통신을 할 때마다 반드시 어느 한쪽은 클라이언트가 되고 다른 한쪽은 서버가 된다. 경우에 따라서는 2대의 컴퓨터 간에 클라이언트와 서버가 바뀌는 일도 있을 수 있다. 

 

위의 그림과 같이 HTTP는 클라이언트로부터 리퀘스트가 송신되며, 그 결과가 서버로부터 리스폰스로 돌아오게 된다. 즉, 통신은 반드시 클라이언트로부터 시작이 된다. 서버 측에서는 리퀘스트가 없는 경우 리스폰스를 발생시키는 일은 없다. 

 

2. HTTP는 상태를 유지하지 않는 프로토콜이다.

상태를 유지하지 않는 프로토콜이 의미하는 것은 클라이언트와 서버가 자신들이 보내거나 받았던 리퀘스트나 리스폰스에 대해 기억하지 않는 다는 것을 의미한다. 이렇게 설계된 이유는 많은 데이터를 매우 빠르고 확실하게 처리하기 위한 범위성을 확보하기 위해서이다. 하지만, 로그인이 유지되어야 하는 경우를 예로 들어보자면 화면 전환이 이루어질 때마다 로그인을 계속해주어야 하는 불편함이 생긴다. 이것을 해결하기 위해 HTTP/1.1에서 쿠키라는 기술이 도입되었다. 쿠키에 대한 내용은 다음에 자세히 정리할 것이다.

 

3. 서버에 임무를 부여하는 HTTP 메소드

www.msmk530.tistory.com은 tistory 서버로부터 나의 블로그를 불러낼 수 있는 URI이다. 내가 이 블로그를 띄우기 위해서는 리퀘스트에 URI를 포함하여야 하는데, 이 리소스에 대하여 어떠한 작업을 할 것인지를 지정해주는 것이 HTTP 메소드라고 할 수 있다. 

 

리퀘스트 메세지에 포함되어 전송될 HTTP 메서드의 종류는 위와 같다. 이 밖에도 TRACE와 CONNECT 등이 있지만 자세한 내용은 따로 공부를 해야 할 것 같다. 중요한 것은 이러한 메소드를 이용해서 서버에게 지시를 내린다는 것이다. 리퀘스트 URI로 지정한 리소스에 어떠한 작업을 하고 싶은지를 명시한다고 보면 되겠다.

 

리퀘스트 메세지의 예시를 하나 가져와 보았는데, 위와 같이 HTTP메소드와 URI를 볼 수 있다. 위와 같은 경우엔 localhost:3000에게 /create-user라는 리소스를 POST 해달라는 의미이다. 즉, /create-user에 해당하는 리소스를 달라는 request 메세지라고 해석하면 되겠다. 서버에서 해당 리소스를 가지고 있을 경우 내어주고, 없을 경우 없다는 응답을 해줄 것이다.

 

4. 지속 연결

HTTP  초기 버전에서는 HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료를 할 필요가 있었다. 이 당시에는 작은 사이즈의 텍스트를 보내는 정도였기 때문에, 이렇게 기능을 구현하여도 문제가 없었다. 하지만, HTTP가 널리 보급되면서 다량의 이미지를 포함한 문서 등이 늘어났다. 이러한 문서를 리퀘스트하게 되면 리소스 하나하나에 대한 통신이 발생하기 때문에, 매우 비효율적이게 된다.

HTTP/1.1과 일부 HTTP/1.0에서는 이러한 TCP 연결 문제를 해결하기 위해 지속 연결이라는 방법을 고안하였다. 이 방법에서는 누군가 명시적으로 종료를 할  때까지 연결을 유지하는 방법이다. 이렇게 하면 여러 번 연결과 종료를 반복하는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 감소하게 된다. 또한 지속 연결은 파이프라인화를 가능하게 한다. 파이프라인화에 의해서, 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 후 다음 리퀘스트를 보낼 수 있었는데, 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있게 되어 속도 측면에서 매우 빠른 통신이 가능해졌다. 

 

5. 쿠키

HTTP는 stateless 하기 때문에, 기존에 주고받았던 정보들에 대해 기억하지 않는다. 결국 과거 상태를 근거로 하여 현재의 리퀘스트를 처리하는 것이 불가능하다는 의미이다. 이러한 stateless 함의 장점은 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있다는 것이다. 하지만, 인증이 필요한 웹 페이지에서 상태관리를 하지 않는다면 새로운 페이지로 넘어갈 때마다 계속해서 로그인을 해주어야 하는 문제가 발생한다. 이러한 문제를 해결하기 위해 HTTP는 stateless 프로토콜이라는 특징은 남겨둔 채, 쿠키라는 시스템을 도입하였다.

쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다. 이후 클라이언트의 리퀘스트에는 이 쿠키 값을 함께 넣어 전송하게 되고, 서버는 클라이언트가 보내온 쿠키를 확인하여 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인하여 이전 상태를 알게 되는 것이다.