[Web] Web Request, Response(웹의 요청과 응답)

[Web] Web Request, Response(웹의 요청과 응답)

 

웹이라는 단어는 인터넷을 사용하는 우리에게는 참 친숙한 단어이다.

웹 사이트, 웹 서버.... 그렇지만, 정확하게 웹이라는 단어의 의미와 뜻을 알고 있는가에 대해 반성을 해볼 필요가 있다.

 

웹(World Wide Web, WWW)은 인터넷을 지칭하는 개념이 아니다. 하위 개념이라고 할 수 있다.

컴퓨터와 컴퓨터를 연결하는 기술이 인터넷 기술이고, 웹은 그 인터넷 위에서 동작하는 서비스 중에 하나이다.

 

인터넷이라는 네트워크 인프라 위에서 동작하는 것이 웹

 

 

1. 웹의 존재 이유

 

그럼 웹은 왜 존재하는 것일까? 무엇을 위해 있는 기술일까?

팀 버너스 리 경

팀 버너스리는 WWW의 창시자이다. 이 사람은 컴퓨터로 어떤 정보를 공유하고 싶은 마음이 있었다.

그렇지만, 서로 다른 컴퓨터에 서로 다른 정보들이 저장되어 있는데, 컴퓨터마다 다른 프로그램을 사용하기 때문에, 처음 보는 프로그램이라면 그 프로그램에 대해 학습을 하고 정보를 공유받을 수밖에 없었다고 한다. 그냥 직접 대면해서 정보를 공유하는 것이 더 빨랐던 것이다.

 

더 쉽게 이야기하자면, 다른 사람의 컴퓨터에 저장되어 있는 에스파 윈터의 사진이 jpeg로 저장이 되어 있는데, 내 컴퓨터는 jpg만 볼 수 있는 컴퓨터라서 jpeg에 맞는 설정을 공부한 후에 그 사진을 같이 공유받아 볼 수 있었던 것이다.

 

그래서 통합된 하나의 기준 방식이 필요함을 느낀 버너스리 기사님은 하나의 프로토콜을 생각해낸다.

인터넷과 하이퍼텍스트라는 그 때 당시의 핫한 기술들을 이용하고, URI 등의 개념을 생각해내서 웹을 만들어낸 것이다.

 

---

cf. URI

URI는 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier)를 의미한다. 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스다.

URL은 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약이다. URI의 서브셋이다.
웹은 '정보의 공유'를 위해서 탄생된 것이고, 그것을 위해 존재하는 기술인 것이다.

---

 

공유를 위해서는 누군가가 '요청'을 해주어야 하고, 누군가가 '응답'을 해주어야 한다. 그래서 웹은 요청과 응답의 사이클이 무한히 반복된다.

 

공유과정에 참여하는 주체: 서버와 클라이언트

서버 : 정보, 자원, 서비스를 제공하는 측. 요청을 받고 응답하는 측이다. 아파치, NginX, IIS 등이 있다.

클라이언트 : 정보, 자원, 서비스를 사용하는 측. 요청을 보내는 측이다. 인터넷 브라우저(크롬, 웨일, 파이어폭스, 사파리 등)이 있다.

 

 

2. 웹이 존재하기 위해 필요한 통신규약, HTTP

 

HTTP(HyperText Transfer Protocol)는 웹 요청과 응답에 관한 클라이언트의 서버 사이의 규약(약속)이다. 클라이언트와 서버 사이에 어떤 기준을 마련해서 그 사이에 주고받는 정보들을 일정하게 가공을 해서 요청을 주고, 응답을 해주어서 서로 정보를 교환할 수 있게 하는 것이다.

 

1) HTTP의 특성1, 비연결성

 

클라이언트의 요청에 대해 서버가 응답을 마치면 연결을 끊는다. 다음 요청은 새로운 연결을 통해서 이루어진다. 이에 따르는 단점이 있다. 매번 모든 요청에 대해 새로운 연결/해제 과정을 거치므로 네트워크 비용 측면에서 비효율적이다. 네트워크 오버헤드가 단점이다. 이를 보완하기 위해 HTTP/1.1 Keep-Alive. 서버와 클라이언트 사이에서 통신이 없어도 지정된 시간 동안 연결을 유지하는 기능을 사용한다.

 

2) HTTP의 특성2, 무상태성

 

서버와 클라이언트는 하나의 요청이 진행되는 동안만 서로를 인지한다. 이로 인한 단점으로 클라이언트 인증(로그인)이 필요한 서비스에서 불편하다. 매번 새로운 페이지로 넘어갈 때마다 로그인했던 기록이 사라질 수 있는 것이다. 그래서 보완책으로 쿠키, 세션, 토큰(OAuth, JWT) 등 상태를 기억하기 위한 기능들을 활용한다.

 

더 쉽게 이야기해보자면, 서버와 클라이언트는 이전의 요청과 응답은 '없다'고 전제하고 서로 통신을 하는 것이 무상태성이라고 할 수 있겠다.

 

 

3) HTTP Method와 상태 코드

 

(1) HTTP Method

 

클라이언트가 요청을 보낼 때 해당 요청의 목적이 무엇인지 HTTP Method를 통해 명시한다.

이는 URL로 특정한 리소스를 어떻게 할 것인지를 정의하는 것이다. 

 

리소스(Resource)?

URL을 검색해서 받아온 결과물이다. 텍스트, HTML, 이미지 등 서버로부터 전달받은 데이터들을 말한다.

 

--Method 대표 네 가지(CRUD)--

GET : 서버의 리소스를 조회하고자 할 때(READ)

POST : 서버의 리소스를 생성하고자 할 때(CREATE)

PUT : 서버의 리소스를 수정할 때(UPDATE)

DELETE : 서버의 리소스를 삭제할 때(DELETE)

 

HEAD : GET과 동일하지만, 서버에서 Body를 빼고 Head로만 응답(리소스 확인의 용도)

PATCH : 리소스의 일부 부분만을 수정할 때

OPTIONS : 지원 가능한 메서드 종류를 알아볼 때

TRACE : 리소스의 경로를 따라 메시지 loop-back 테스트를 실행한다.

CONNECT : 리소스로 식별되는 서버로의 터널을 맺을 때

 

 

(2) Status Code(응답 코드, 상태 코드)

 

클라이언트의 요청에 대해서 서버는 요청에 대한 처리 상태를 숫자 코드로 반환한다.

 

1xx(정보) : 요청을 받았으며 프로세스를 계속한다.

2xx(성공) : 요청을 성공적으로 받았으며 인식해서 처리했다.

3xx(리디렉션) : 요청 완료를 위해 추가 작업 조치가 필요하다.

4xx(클라이언트 에러) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없다.

5xx(서버 에러) : 서버가 명백히 유효한 요청에 대해 충족을 실패했다.

 

 

3. 웹 요청과 응답 과정의 예시

 

1) URL(Uniform Resource Locator) : 네트워크 상 자원의 위치(주소)

 

URL은 웹서버에 무엇을 요청할 것인가를 정의한 내용이라고 요약할 수 있다.

 

URL은 다음과 같은 요소로 이루어져 있다.

Path 뒤에는 쿼리 스트링이 붙을 수도 있는데, ?key=value와 같이 함께 붙어서 서버에 요청할 것을 부가해서 나타낼 수 있다.

 

 

2) 홈페이지에 대한 요청을 서버로 전송(HTTP Request)

 

URL을 입력하고 엔터를 치면 브라우저가 이 행위를 해석을 해서 Request Headers를 서버로 보내준다.

어떤 타입의 응답 컨턴츠를 수용할 수 있는지, 어떤 운영체제이며 어떤 브라우저인지, 상태 기억을 위한 정보(cookie) 등의 정보를 서버로 전송한다.

 

 

3) 서버가 클라이언트로부터 Request Headers를 받고 요청을 처리

 

요청에 대한 정보(URI, Method), 클라이언트에 대한 정보(accept, user-agent, cookie 등)를 확인한다.

그리고 이 요청에 상응하는 로직을 수행한다. 예를 들어 위의 경우, www.example.com이라는 홈페이지에 해당하는 info 디렉토리의 aboutus.html 파일을 찾은 후에 요청에 대한 응답을 생성하는 것이다. 

 

 

4) 서버가 클라이언트에게 응답(HTTP Response)

 

Response Headers와 Response Body(HTML)을 클라이언트에게 제공한다. 

 

 

5) 클라이언트(웹 브라우저)가 응답을 받은 후에 리소스들을 추가 요청하거나 응답받기

 

CSS, JavaScript 등의 파일이 추가적으로 필요하면 요청하여 파일들을 받게 된다.

 

 

6) 클라이언트(웹 브라우저)가 모든 리소스 요청에 대한 응답을 받음

 

응답을 받고 브라우저가 렌더링 과정을 통해서 화면으로 문서들을 보여준다.

 

그림은 여러 요청과 응답들이 일어나는 과정을 보여준다. 위의 글에서 5)에 해당하는 과정들이 css, js를 받아오는 과정이라고 보면 된다.