[컴퓨터 네트워크] 17. 웹과 HTTP (2)
■ HTTP Message
HTTP 메시지(Message)는 클라이언트 request와 서버 response 2가지로 이루어지는데 구성되는 형태는 위 그림과 같다.
처음에 위치한 method는 특정한 명령어에 해당한다. 가령 GET이라는 method는 클라이언트가 어떤 데이터를 가지고 싶을 때 사용한다. 다른 method들에 대해서는 뒤에서 다시 알아보자. method 다음에는 URL을 작성해서 어떤 오브젝트에 대한 요청인지 적게 되어있다. 그 뒤에는 HTTP 버전을 작성하는데 1.1버전인지 2버전인지 등 어떤 버전의 HTTP를 사용하고 있는지 적는 곳이다.
다음 줄의 header lines에서는 어떤 host에게서 데이터를 가져오고 싶은가를 적는다. header field name에는 어떤 정보의 종류를 나열하고 value에는 그 정보의 값을 적고 그것들이 여러 개 나열되는 형태이다. 실제 데이터나 파일을 전달해야 한다면 하단의 entity body를 통해 전달할 수 있다.
■ HTTP Request Message
HTTP request message는 위의 그림과 같다. 앞의 method에 해당하는 곳에는 GET이나 POST, HEAD, PUT, DELETE 같은 명령어들을 담을 수 있다. 간단하게 정리하면 GET은 method 뒤에 적히는 오브젝트를 가져올 때 사용한다. POST는 데이터를 보내는 역할을 한다. 가령 검색창에서 검색하고 싶은 단어를 넣고 검색 버튼을 누르면 해당 검색어 데이터가 서버로 넘어가는데 그런 경우에 사용한다. HEAD는 전체 데이터가 아닌 필요로 하는 오브젝트의 헤더 정보만을 보내준다. PUT이나 DELETE는 서버에 파일을 넣거나 지울 때 사용한다. method에 대한 구체적인 정보는 별도의 검색을 통해서 찾아보길 바란다.
■ HTTP Response Message
클라이언트로부터 HTTP request message를 받았다면 서버는 HTTP response message를 보내 응답한다. 클라이언트의 요청을 어떻게 처리했는지 할당된 Response code를 통해 알 수 있다. 위의 그림에는 HTTP 버전 뒤에 200이 적혀있는데 이것은 요청이 잘 처리되었다는 의미이다. 301은 클라이언트가 요청한 오브젝트가 다른 경로로 이동했기 때문에 해당 경로로 이동하겠다는 의미이다. 400은 클라이언트가 요청한 정보를 이해하지 못했다는 의미, 404는 클라이언트가 요청한 정보를 찾지 못했거나 없다는 의미다. 마지막으로 505는 HTTP 버전이 달라서 클라이언트와 통신을 할 수 없다는 내용이다.
■ REST
● REpresentational State Transfer
최근에 IoT와 관련된 이야기에서 REST라는 단어를 들어본 적이 있을 것이다. REST는 Representational State Transfer의 약자이다. 간단히 말하면 서버가 클라이언트의 상태를 유지하지 않겠다는 것이다. 2000년도에 Roy Fielding 박사가 논문을 통해 제안한 개념인데 HTTP/1.1버전에 포함되었다.
사용자가 작업을 처리하는 데 현재 상태가 중요할 때가 있다. 가령 사용자가 장기나 체스 게임을 한다고 할 경우 장기 알이나 체스 말을 이동시키고 난 후 다음 턴이 돌아올 때까지 이동시킨 상태가 유지되어야만 게임을 진행할 수 있다. 그런데 HTTP를 통한 클라이언트 서버 모델에서는 클라이언트의 위치, 현재 상태를 유지하는 정보를 담으면 서버에게 너무 큰 오버헤드를 유발한다. 특히 클라이언트의 수가 많아진 최근에 이르러서는 서버가 이 오버헤드를 전부 처리할 수 없다. 그래서 서버는 클라이언트 state(상태)를 저장하고 있지 않다. 그 대신에 클라이언트와 서버가 주고 받는 HTTP 메시지 안에 클라이언트에 대한 모든 정보가 들어있고, 해석할 수 있는 정보까지 들어있는 것이다.
그래서 서버는 굳이 특정 클라이언트에 대한 상태를 저장하고 있지 않아도 HTTP request message를 받으면 어떻게 처리해야 할지, 반대로 클라이언트로 서버의 response message를 받으면 어떤 방식으로 데이터를 가져와야 할지 모두 HTTP 코드 안에 담겨져 있다. 이런 아키텍처(architecture)를 따르는 서비스를 RESTful이라고 이야기한다.
● REST 구조의 6가지 요구사항
REST의 구조가 가져야하는 요구사항들이 크게 6가지로 정리되어 있다.
첫 번째는 클라이언트 서버 구조여야하고, 이것은 실제 데이터와 유저에 대한 정보가 분리되어 있어야 한다는 것이다. 어떤 사용자의 요구를 처리하기 위해서 특정 데이터 스토리지에 접근하지 않아도 되게끔 HTTP 메시지 안에 다 들어있어야 한다.
두 번째는 무상태(statelessness)로, 클라이언트의 현재 상황을 서버에 저장하지 않는다는 것이 특징이다.
세 번째는 캐시 처리 가능(Cacheable)으로, 서버의 response를 클라이언트 또는 중간의 웹 캐시 같은 곳에 저장할 수 있어야 한다.
네 번째는 계층화(Layered System)으로, 클라이언트가 접속할 때 서버에 접속한 것인지 중간의 웹 프록시 서버에 접속한 것인지 구별할 수 없어야 한다. 클라이언트 입장에서 서비스를 받을 때 실제 원(Origin) 서버에 접속할 때와 프록시 서버의 접속할 때의 경험이 차이가 없어야 한다는 것이다.
다섯 번째는 code on demand라는 선택적(optional)인 특징인데, 자바 애플릿이나 자바 스크립트 같은 코드가 클라이언트 쪽에 전달되어서 실행될 때 해당 코드를 해석하고 실행할 수 있는 응용 프로그램까지 전달해주는 개념이다.
마지막 여섯 번째는 일관된 인터페이스(uniform interface)로, 특정한 컴퓨터 아키텍처(Architecture)에 제약받지 않아야 한다. 모든 인터페이스가 독립적으로서 HTML이나 XML, JSON 같은 표준화된 언어를 사용해서 특정한 컴퓨터 아키텍처에 제약받지 않는 서비스를 해야한다는 의미이다.
※ 본 정리 내용은 부산대학교 유영환 교수님의 컴퓨터 네트워킹 수업을 정리한 것입니다.
※※ 강의에 사용된 교재 : [Computer Networking A Top-Down Approach 7th edition / Jim Kurose, Keith Ross]