I. HTTP: 웹의 기초 | 1. HTTP 개관, 2. URL과 리소스

번역가의 다음 글을 참고해서 앞으로 며칠 간 HTTP 완벽 가이드를 읽으며 내용을 정리하려고 합니다.

 

 

웹 프로그래머를 위한 HTTP 완벽 가이드 읽는 법

 

웹 프로그래머에게는 필독서로 정평이 난 HTTP 완벽 가이드

I. HTTP: 웹의 기초

01 HTTP 개관

 

•   HTTP

  HTTP는 일종의 배달부이다. 음악, 영상, HTML 코드 등을 전송하는 프로토콜이다. HTTP는 신뢰할 수 있는 데이터 전송 프로토콜이기 때문에 데이터가 지구 반대편에 오더라도 전송 중 손상되거나 꼬이지 않는다.

  사용자가 보고자 하는 웹 컨텐츠는 서버가 보유하고 있다. 클라이언트가 서버에게 요청(req)를 보내면 서버는 응답(res)을 통해 데이터를 제공한다.

  웹 서버는 웹 리소스를 관리하고 제공한다. 웹 리소스는 HTML 파일, mp4 동영상과 같은 정적 파일 뿐만 아니라 DB에서 추출한 정보나 이용자의 정보에 따라 동적으로 생성되는 파일 등도 포함한다.

 

•   MIME 타입

  이렇게 여러가지 형태를 가진 웹 리소스를 전달할 때 HTTP는 MIME 타입이라는 데이터 포맷 라벨을 붙인다. 예컨대 jpeg는 image/jpeg, gif는 image/gif, HTML은 text/html과 같이. MIME 타입은 수백 가지 이상이 존재한다.

 

• URI(URN)

  URI는 일종의 주소라서 리소스를 고유하게 식별하고 위치를 지정할 수 있다. URI는 URL과 URN이라는 두 가지 종류가 존재한다. (오늘날의 URI는 대부분 URL이기에 URL과 URI를 같은 의미로 사용한다.) URL은 평소 인터넷을 사용하는 사람이라면 흔히 알고 있는 그것이다. 다만 좀 더 자세히 설명하자면, URL은 스킴, 인터넷 주소, 리소스라는 세 부분으로 구별할 수 있다. http://www.shopping.com/food?search=kimchi라는 가상의 URL을 예시로 설명하자면 스킴(http), 인터넷 주소(www.shopping.com), 리소스 /food?search=kimchi로 구별된다.   

 

• 트랜잭션

  HTTP 트랙잭션은 요청(req), 응답(res)로 구성되어 있다. 즉, 트랙잭션이란 클라이언트와 서버의 소통 방식이라고 할 수 있다. 각 리소스에 대해서 별개로 HTTP 트랙잭션이 이루어지기 때문에 시각적으로 풍부한 웹페이지를 가져오기 위해서는 대량의 트랜잭션이 이루어진다. 

  트랜잭션을 분석하기 위해서는 요청, 응답 메세지를 살펴 보아야 한다. 두 메세지다 시작줄, 헤더, 본문(body)로 구분되어 있다. 시작줄과 헤더는 통신에 관한 정보와 명령이 포함되어 있고 실제로 전송되는 데이터는 body에 포함되어 있으며 헤더와 본문은 빈 줄로 구분되어 있다.

 

왼쪽이 요청, 오른쪽이 응답

 

  - 요청(req) 메세지

    클라이언트가 서버에게 보내는 요청의 방법(메서드)에는 GET, POST, PUT, DELETE, HEAD가 빈번히 사용된다. 요청을 보낵 측의 브라우저 등 정보가 헤더가 담여 있다.

 

  - 응답(res) 메세지

    응답 메세지는 상태 코드와 함께 반환된다. 매우 많은 상태 코드가 있으나 200(정상), 404(리소스 찾을 수 없음)이 유명하다. 헤더를 살펴보면 응답 본문의 길이는 Content-Length, MIME type은 content-Type에 적혀 있다. 이 외에도 다양한 내용이 적혀 있다.

 

 

• TCP/IP 커넥션

  인터넷은 TCP/IP에 기초하고 있다. TCP/IP는 TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합이다. TCP 커넥션이 맺어지면 클라이언트와 서버 간에 교환되는 메세지가 도중에 유실되거나 순서가 뒤바뀌어 전송되는 일이 없어진다.

  이해하기 어렵다면 OSI 7 Layer와 연계해서 이해하면 쉽습니다. TCP는 transport Layer(4L)이며 IP는 Network Layer(3L) HTTP는 Application layer (7L)에 속합니다. 즉, TCP는 IP에 의존하며 HTTP는 TCP와 IP에 의존합니다.

 

 

  클라이언트가 서버에 req 요청을 보내기 위해서는 IP와 포트 번호를 통해 TCP/IP 커넥션을 맺어야 합니다. 정확히는 TCPIP 커넥션을 위해서 서버 컴퓨터의 IP와 PORT 번호가 필요합니다. http://172.217.27.78:80 이라는 URL 주소에서 google 웹페이지의 IP(   172.217.27.78)와 PORT 번호(80)를 확인할 수 있습니다. 여기서 도메인 이름과 포트 번호 생략을 통해 http://gogoole.com으로도 접속할 수 있게 됩니다.

 

  TCP/IP 커넥션이 작동하는 순서는 다음과 같습니다. 

 

  (1) 웹 브라우저는 URL에서 호스트 명을 추출한 다음 DNS를 거쳐 IP로 변환하고, 포트 번호도 추출합니다(생략시 80)

  (2) 웹 브라우저는 이 IP와 PORT 번호를 가지고 웹 서버와 TCP 커넥션을 맺습니다.

  (3) 그 후에는 서버에 req를 날리고 서버는 웹 브라우저에게 res를 돌려줍니다.

  (4) 커넥션이 닫히면 브라우저는 res에서 받은 내용을 해석하여 사용자에게 보여줍니다.

• HTTP 버전

  현재 2020년 3월 HTTP/3.0을 크롬에서 지원하겠다고 위키피디아에 나와있습니다. 물론 이 전에 0.9부터 시작하는 HTTP의 역사가 존재합니다. 간단히, 2.0은 1.1을 개선하기 위해 구글의 spdy 프로토콜을 기반으로 설계되었다고만 알아둡시다.

 

• 앞으로 공부할 웹 구성 요소의 소개

  - 프록시 : 클라이언트와 서버 사이에 위치한 HTTP 중개자. 주로 모든 웹 트래픽 흐름 속에서 보안을 위한 중간책으로 사용됩니다. 예를 들어 무언가를 다운로드 받을 때 바이러스를 검출하거나 성인 콘텐츠를 차단하는 등 필터링 작업을 한다고 보면 됩니다.

  - 캐시 : 자주 찾는 페이지는 클라이언트 가까이에 보관하는 창고 (AWS의 CloudFront는 이를 활용합니다)

  - 게이트웨이 : 다른 애플리케이션과 연결된 특별한 웹 서버입니다. 주로 HTTP 트래픽을 다른 트래픽(FTP와 같은)으로 변환하기 위해 사용됩니다. 

  터널 : 두 커넥션 사이에서 날 데이터를 열어보지 않고 전달하기만 하는 특별한 종류의 프록시. 주로 비 HTTP 데이터를 HTTP 연결을 통해 그대로 전송하기 위해 사용됩니다.

  에이전트 : 자동화된 HTTP 요청을 만드는 웹 클라이언트. 사람의 통제 없이 트랙잭션을 일으켜서 콘텐츠를 크롤링하는 봇이 그 예이다.

 

 

 

02 URL과 리소스

 

  사람에게 주민번호, 건물에게 건물번호가 있듯이 리소스를 가치키는 URL이 존재한다. 또, URL은 http에만 국한된 것이 아니라 ftp등 다른 프로토콜에서도 적용하는 개념이다. 이 URL을 통해 리소스를 찾고 공유하는 것이 가능해진다. 앞서 URL을 "스킴://서버 위치(IP, 도메인)/리소스 경로"라는 세 부분으로 구성되어 있다고 하였다. 좀 더 정확하게는 다음과 같다.

 

 

  물론 모든 URL에서 저 컴포넌트를 다 보여주지는 않는다. 보안의 문제와 간결성의 문제가 있기 때문이다.

 

 

• 스킴 ://

  스킴은 리소스에 어떻게 접근하는지를 표시한다. URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용해야 하는지 알려주는 것이다. 주로 http, https가 사용된다. 대소문자가 구별되지 않기 때문에 HTTP는 http와 동일한 것으로 취급된다.

 

• 사용자 이름과 비밀번호 @

  ftp와 같은 특정 프로토콜은 리소스에 접근하기 위해 사용자 이름과 비밀번호를 요구하기도 한다. 이 컴포넌트의 마지막에 위치한 @는 URL과 사용자 이름, 비밀번호를 구분하는 기준이다.

 

•   호스트와 포트 :

  원하는 리소스를 호스팅하고 있는 장비의 주소와 해당 주소의 서버가 열어놓은 네트워크 포트를 알아야 리소스에 접근할 수 있습니다. 내부적으로 TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80, HTTPS는 443 포트를 사용합니다.

 

• 경로(route) /

  경로 컴포넌트는 호스트에서 명시한 주소로 접속한 후에는 해당 서버 내에 원하는 리소스가 어디에 있는지 알려줍니다. node.js로 백엔드 작업을 할 때 route 설정을 위해 app.get("/about", (req, res) => res.send(...))라고 설정한 기억이 있을 겁니다.

  각 경로는 /로 구분됩니다. /auth/login, /company/recruit/recent와 같이 말이죠.

 

• 파라미터 ;

  많은 스킴은 객체에 대한 호스트나 경로만으로는 리소스를 찾지 못한다. 추가적인 파라미터를 통해 리소스에 접근하는데 필요한 추가 정보를 줄 수 있다. 파라미터는 키=값으로 적히며 앞에 세미 콜론(;)이 붙는다. 각 경로마다 파라미터 값을 줄 수 있다.

  http://www.shopping.com/hammers;sale=false/index.html;graphics=true 같은 URL이 존재한다면 /hammers와 /index.html이라는 경로에 각각 sale=false, praphics=true라는 파라미터가 있는 것이다.

 

• 쿼리(질의) ?

  검색과 같은 쿼리를 달리면 ? 뒤에 붙습니다. 쇼핑 웹에서 cake를 검색한다면 ?search=cake와 같이 붙는다. 쿼리가 여러개 일 경우 &가 붙곤한다. ?item=1363&color=blue와 같이.

 

• 프래그먼트 #

  나무위키나 위키피디아에서 특정 절로 이동하기 위해 #을 붙이는 것을 확인할 수 있을 것이다. 이와 같이 서버로 부터 전달받은 리소스 중 특정 리소스로 이동하기 위해서 프래그먼트를 사용한다.

  페이지 내에서 프래그먼트를 사용하는 방법은 다음 포스트에 정리해두었습니다.

https://darrengwon.tistory.com/227

 

 

  한편, URL은 상대 URL과 절대 URL로 나뉩니다. 지금까지 살펴본 URL은 절대 URL로 리소스에 접근하기 위한 모든 정보를 표시합니다. 상대 URL은 URL을 짧게 표시하는 방법입니다. URL에 스킴이나 호스트 같은 다른 컴포넌트를 모두 입력할 필요가 없어 간편합니다. HTML에서 anchor 태그의 href를 작성할 때 내부를 이동할 때나 node.js나 React에너 라우팅 처리를 할 때 URL주소를 모두 입력하지 않은 것은 상대 URL의 방식으로 URL을 작성한 것입니다.

 

  또한, 주소창에 URL을 전부 입력하지 않아도 자동 완성을 통해 URL을 완성하는 경우가 있습니다. 크롬에서 google만 검색해도 google 웹페이지로 이동할 수 있는 것은 이러한 URL 확장 덕분입니다. 

 

  그런데, URL을 작성할 때 모든 프로토콜에서 URL이 전송되어야 하기 때문에 생기는 제약이 있습니다. {}, [] 등을 사용할 수 없는 문자 제한이 그것입니다. 안전하지 않은 문자를 URL에서 사용하기 위한 방법도 존재하지만  URL은 안전한 문자열을 사용하는 것을 권장합니다.