성장, 그리고 노력

부족하더라도 어제보다 더 잘해지자. 노력은 절대 배신하지 않는다.

네트워크

[HTTP] Hypertext Transfer Protocol 기초

제이콥(JACOB) 2019. 12. 14. 17:28

HTTP는 웹 트래픽을 어떻게 전송할까?

하루에도 수십억 개의 이미지, HTML 페이지, 텍스트 파일, 동영상 파일 등이 인터넷을 통해 전 세계 사람들의 웹브라우저로 전달된다. 모두 HTTP를 사용해서 통신하여 인터넷의 공용어라고도 할 수 있다. 그렇다면 HTTP는 웹 트래픽을 어떻게 전송하는 것일까?

 

우선 항상 정보를 요청하는 웹 클라이언트와 내가 원하는 정보를 가지고 있는 웹 서버가 있다. 클라이언트는 서버에게 HTTP 요청을 보내고 서버는 요청된 데이터를 HTTP 응답으로 돌려준다. 이게 월드 와이드 웹(www)의 기본 요소이다. 

여기서 말하는 클라이언트는 웹브라우저를 의미하며, 우리가 흔히 사용하고 있는 크롬(Chrome)이나 인터넷 익스플로러다.  그리고 웹브라우저는 HTTP 객체를 요청하고 사용자의 화면에 보여준다. 

 

웹 서버

웹서버는 웹 리소스를 관리하고 제공한다. 여기서 웹 리소스란 웹에 제공하는 콘텐츠를 제공하는 모든 것을 의미한다. 단순히 그림 파일, 텍스트 파일 등 정적 파일뿐만 아니라, 요청에 따라 콘텐츠를 생성하는 동적 파일도 될 수 있다. 많은 리소스를 다루다 보니, 수천 가지의 데이터 타입을 다루게 된다. 그래서 HTTP는 웹에서 전송되는 객체 각각에 MIME(Multipuerpose Internet Mail Extenstions) 타입이라는 데이터 포맷 라벨을 붙인다. MIME 타입은 지금 바로 브라우저의 개발자 도구를 열어 확인할 수도 있다.

MIME 타입은 그림과 같이 사선(/)으로 구분되며, 주 타입(primary object type)과 부 타입(specific subtype)으로 이루어진 문자열 라벨이다. 수많은 타입이 존재하기 때문에 직접 브라우저의 개발자 도구를 이용하여 네트워크 탭을 보면서 확인해 보는 걸 추천한다.

 

URI & URL

웹 서버 리소스는 각자 이름을 가지고 있다. 클라이언트는 관심 있는 리소스를 지목할 수 있으며 우리가 주소창에서 항상 볼 수 있는 URI(uniform resource identifier)이다. 리소스를 고유하게 식별하고 위치를 지정할 수 있다.

위 URI를 해석해 보면 아래와 같다. 

  • https:// -> HTTPS 프로토콜을 사용해라
  • github.com -> github.com으로 이동해라
  • /JungKyuHyun/TypeScript/blob/master/README.md -> /JungKyuHyun/TypeScript/blob/master/README.md 라는 리소스를 가져와라

URI가 HTTP 프로토콜에서 어떻게 해석하는지를 보여주는 것이다. 그리고 URI는 URL과 URN이 있다.

 

URL

URL(uniform resource locator)로 URI의 가장 흔한 형태이다. 특정 서버의 한 리소스에 대한 구체적인 위치를 알려주며, 오늘날 대부분의 URI는 URL이다. URL은 대부분 표준 포맷을 따르며, 위에서 설명한 URI를 URL 포맷으로 설명하자면 아래와 같다. 

 

  • https:// -> 스킴(scheme)이라고 부르는 부분으로 리소스에 접근하기 위해 사용하는 프로토콜을 말한다.
  • github.com -> 서버의 인터넷 주소를 제공한다.
  • /JungKyuHyun/TypeScript/blob/master/README.md -> 웹 서버의 리소스를 가르킨다.

 우리가 본 대부분의 URL은 http 프로토콜이지만, 다른 프로토콜을 사용할 수도 있다. 이메일 주소를 예를 들자면, mailto:exam@exam.com 등도 가능하다.

(통상적으로 URI와 URL을 같은 의미로 사용한다.)

URN

 URI의 또 다른 종류인 URN(uniform resource name)은 콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 위치에 영향을 받지 않는 고유한 이름 역할을 한다(문서에서는 위치 독립적인 자원 식별자라고 표현한다). 리소스가 이름이 변하지 않는 한, 여러 종류의 네트워크 접속 프로토콜로 접근해도 되며, 리소스를 여기저기 옮기더라도 문제없이 작동한다. 

// NOTE: Syntax (Backus-Naur form 표기법)
<URN> ::= "urn:" <NID> ":" <NSS> 

cf) 베커스 나우르 표기법 - https://ko.wikipedia.org/wiki/%EB%B0%B0%EC%BB%A4%EC%8A%A4-%EB%82%98%EC%9A%B0%EB%A5%B4_%ED%91%9C%EA%B8%B0%EB%B2%95

매우 유용한 URN이지만, URN 리소스 위치를 찾기 위한 인프라 부족으로 아직 널리 채택하지는 못했다. 

 

HTTP 트랜잭션

HTTP 트랜잭션은 클라이언트에서 서버로 보내는 요청 명령과 서버가 클라이언트에게 돌려주는 응답 결과로 구성되어 있다.

 

HTTP 메서드

모든 HTTP 요청 메시지는 한 개의 HTTP 메서드를 가지며, 여러 종류의 요청 명령을 지원하다. 뒤에서 좀 더 자세히 다루겠다.

ex) GET, POST, PUT, DELETE, HEAD...

 

버전 정보

HTTP 요청 메시지 및 응답 메시지에는 HTTP/x.y 형식의 버전정보가 포함된다. x는 메이저 버전, y는 마이너 버전의 수이다. 

여기서 눈여겨 볼점은 버전 숫자는 별개의 숫자로 보고 판단해야 한다. 예를 들어 2.15 버전은 2.3 버전보다 상위 버전이다. 이유는 15보다 3이 작다.

 

상태 코드

모든 HTTP 응답 메시지는 상태 코드와 함께 반환된다. 상태 코드는 클라이언트에게 요청이 성공했는지 아닌지 알려주는 세 자리 숫자이다.

위에서 봤던 이 부분이 상태 코드이다. 그리고 뒤에 있는 텍스트는 "사유 메시지(reason message)"로 단순히 설명이라고 보면 된다. 실제 응답 처리에는 숫자로 된 부분이 사용된다(설명 구절이 다르지만 상태 코드가 동일하다면 같은 응답인 거다).

 

웹 페이지는 여러 객체로 이루어질 수 있다

예를 들어 네이버(www.naver.com) 홈페이지를 들 수 있다. 네이버 페이지에 접속할 때 개발자 도구의 네트워크 탭을 확인해 보자. 대량의 HTTP 트랜잭션을 수행한다. 이때 리소스들을 다른 서버에 위치한 거 일 수도 있다.

만약 한번의 트랜잭션으로 모든 리소스를 로드하면 정말 느리겠죠?

웹 페이지는 첨부된 리소스들에 대해 각각 별개의 HTTP 트랜잭션을 필요로 한다.

 

 

TCP 커넥션

HTTP는 애플리케이션 계층 프로토콜이다. HTTP는 네트워크 통신의 핵심적인 세부 사항에 대해서는 신경 쓰지 않고, 대중적이고 신뢰성 있는 프로토콜인 TCP/IP에게 위임한다. 

 

TCP

TCP(Transmission Control Protocol)의 축약어로 다른 컴퓨터와 데이터 통신을 하기 위한 프로토콜이며, OSI 모형에서 4번째 전송 계층(Transport Layer)이다. 흔히 하위 계층(네트워크 계층)에서 사용하는 IP와 엮어서 TCP/IP라고 표현한다. 기존 패킷 교환(Packet Switching) 방식에서 부족한 신뢰성을 보장할 수 있는 통신 규약을 연구하게  된 결과로 나오게 되었다. 그래서 TCP는 아래와 같은 점을 보장한다. 

  • 오류 없는 데이터 전송
  • 데이터는 언제나 보낸 순서대로 도착
  • 조각나지 않는 데이터 스트림

인터넷은 TCP/IP에 기초하고 있으며, TCP/IP는 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해 준다.

 

TCP/IP 커낵션 맺기

클라이언트가 서버에 HTTP 메시지를 전송하기 전에, 인터넷 프로토콜(Internet protocol, IP) 주소포트 번호를 통해 TCP/IP 커낵션을 맺어야 한다. 그럼 저 정보를 어디서 얻을 수 있을까? 정답은 URL을 이용하면 된다. 리소스에 대한 주소이기 때문에 내가 원하는 정보를 이미 가고 있다. 아래 URL을 보자.

https://github.com/JungKyuHyun/TypeScript/blob/master/README.md

 여기서 IP주소는 `github.com`이다. 우리가 평소에 알고 있던 0.0.0.0 ~ 255.255.255.255의 IPv4 방식의 주소는 아니지만, 이는 IP 주소에 대한 별칭이고 실제로는 DNS(Domain Name Service)를 통해 IP로 변환된다. 포트번호는 443이다. HTTPS URL에 포트번호가 빠진 경우 443이라고 가정하면 된다(http url은 80).

 이제 이 정보를 가지고 클라이언트는 TCP/IP로 쉽게 통신할 수 있는 것이다. 그래서 아래와 같은 순서로 HTML 리소스가 나에게 보이는 것이다.

  1. 웹 브라우저는 서버의 URL에서 호스트 명을 추출하고,
  2. 서버의 호스트 명을 IP로 변환한다.
  3. 그리고 URL에 포트 번호를 추출하며,
  4. 웹 브라우저는 웹 서버와 TCP 커낵션을 맺는다.
  5. 웹 브라우저는 서버에 HTTP 요청을 보내고
  6. 서버는 웹브라우저에 HTTP 응답을 돌려준다.
  7. 커낵션이 닫히면, 웹 브라우저는 HTML 문서를 보여준다.

HTTP Protocol version

여러 버전이 있지만, 현재 가장 많이 사용되는 HTTP/1.1과 성능 개선을 하기 위해 구글의 SPDY 프로토콜 기반으로 설계된 HTTP/2.0에 대한 비교를 별도의 주제로 다룰 예정이다. 

 

 

 

 

참고 자료

https://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.html

반응형

'네트워크' 카테고리의 다른 글

[HTTP] 캐시2 - 토폴로지  (0) 2020.01.04
[HTTP] 캐시1 - 기본 개념  (0) 2020.01.04
[HTTP] Proxy (프락시)  (0) 2020.01.01
[HTTP 아키텍처] 웹 서버  (0) 2019.12.22
[HTTP] HTTP 메시지  (0) 2019.12.15