[HTTP 완벽 가이드 - ch.1] - HTTP 개관

늘보·2022년 1월 17일
0

HTTP 완벽 가이드

목록 보기
1/2

전 세계의 웹브라우저, 서버, 웹 애플리케이션은 모두 HTTP(Hypertext Transfer Protocol)를 통해 서로 대화한다.

HTTP는 현대 인터넷의 공용어이다.

이 책에서는 HTTP에 대해 설명, HTTP가 어떻게 통신하는지, 얼마나 많은 웹 앱이 HTTP를 이용해 통신하는지 소개한다. 특히 다음에 대해 더 이야기할 것이다.

  • 얼마나 많은 클라이언트와 서버가 통신하는지

  • 리소스(웹 콘텐츠)가 어디서 오는지

  • 웹 트랜잭션이 어떻게 동작하는지

  • HTTP 통신을 위해 사용하는 메시지의 형식

  • HTTP 기저의 TCP 네트워크 전송

  • 여러 종류의 HTTP 프로토콜

  • 인터넷 곳곳에 설치된 다양한 HTTP 구성요소

HTTP: 인터넷의 멀티미디어 배달부

수많은 이미지, 페이지, 동영상 등이 인터넷을 항해하는데, HTTP는 전 세계의 웹 서버로부터 이 대량의 정보를 빠르고, 정확하게 사람들의 개인 PC의 웹 브라우저로 옮겨준다.

HTTP는 신뢰성 있는 데이터 전송 프로토콜을 사용하기 때문에 , 데이터가 전송 중 손상되거나 꼬이지 않음을 보장한다.

그럼 HTTP가 웹 트래픽을 어떻게 전송하는지 더 자세히 알아보자.

웹 클라이언트와 서버

웹 콘텐츠는 웹 서버에 존재한다. 웹 서버는 인터넷의 데이터를 저장하고, HTTP 클라이언트가 요청한 데이터를 제공한다. 아래 그림을 보면 알 수 있듯이

  • 클라이언트는 서버에게 HTTP 요청을 보내고

  • 서버는 요청된 데이터를 HTTP 응답으로 돌려준다.

ex) http://www.oreily.com/index.html 페이지를 열어볼 경우

  1. 웹 브라우저는 HTTP 요청을 www.oreily.com 서버로 보낸다.

  2. 서버는 요청 받은 객체(index.html)을 찾고

  3. 성공했다면 그것의 타입, 길이 등의 정보와 함께 HTTP 응답에 실어서 클라이언트로 보낸다.

리소스

웹 리소스는 웹 콘텐츠의 원천이다. 리소스는 일반적으로 '정적 파일'을 의미하지만(이미지, 텍스트, 동영상 파일 등) 반드시 정적 파일이어야 할 필요는 없다.

동적 리소스: 사용자가 누구인지, 어떤 정보를 요청하는지 등에 따라 다른 콘텐츠 생성 가능(e.g. 주식거래 gateway, 전자상거래 gateway etc)

미디어 타입

인터넷은 수천 가지 데이터 타입을 다루기 때문에, HTTP는 웹에서 전송되는 객체 각각에 신중하게 MIME 타입이라는 데이터 포맷 라벨을 붙인다.

MIME(Multipurpose Internet Mail Extensions): 원래 메일을 주고 받을 때 이용하기 위한 포맷이었으나 유용성이 입증되어 HTTP 통신에도 채택됨.

MIME 타입은 사선(/)으로 구분된 주 타입과 부타입으로 이루어진 문자열 라벨이다. 예를 들면 다음과 같다.

  • HTML로 작성된 텍스트 문서는 text/html 라벨이 붙는다.

  • JPEG 이미지는 image/jpeg가 붙는다.

Axios를 통해 서버로 HTTP 요청을 보내기 위해 설정을 할 때, content-type과 같은 속성을 볼 수 있었을 것이다. 그것이 바로 미디어 타입이다.

content-type: image/jpeg
content-length: 12984

URI

웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다.

서버 리소스 이름은 통합 자원 식별자(uniform resoure identifier), 혹은 URI로 불린다.

이는 인터넷의 우편물 주소 같은 것으로 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다.

예를 들어, '죠의 컴퓨터 가게'의 웹 서버에 있는 이미지 리소스에 대한 URI라면 이런 식이다.

http://www.joes-harware.com/specials/saw-blade.gif

URI에는 두 가지가 있는데, URL과 URN이라는 자원 식별자다. 둘을 지금 살펴보자.

URL

통합 자원 지시자(uniform resource locator, URL)는 리소스 식별자의 가장 흔한 형태다. URL은 특정 서버의 한 리소스에 대한 구체적인 위치를 알려준다.

ex) http://www.oreily.com/index.html --> 오라일리 출판사 홈페이지의 URL

대부분의 URL은 세 부분으로 이루어진 표준 포맷을 따른다.

  • http:// : 첫 번째 부분은 스킴(scheme)이라고 불리는데, 리소스에 접근하기 위해 사용되는 프로토콜을 서술한다. 보통 HTTP 프로토콜이다.

  • www.oreily.com : 두 번째 부분은 서버의 인터넷 주소를 제공한다.

  • /index.html : 마지막은 웹 서버의 리소스를 가리킨다.

URN

URN(uniform resource name)은 리소스의 위치에 영향을 받지 않는 유일무이한 이름 역할을 한다. URN은 리소스를 여기저기로 옮기더라도 문제없이 동작한다.

그러나 URN은 여전히 실험 중인 상태고 아직 인프라가 부재하기에 채택이 늦어지고 있다. 따라서 대부분은 URN이 아닌 URL(=URI)에 지면을 할애할 것이다.

트랜잭션

HTTP 트랜잭션은 요청(클라이언트 -> 서버) / 응답(서버 -> 클라이언트)으로 구성되어 있다.

메서드

HTTP는 HTTP 메서드라고 불리는 여러 가지 종류의 요청 명령을 지원한다.

모든 HTTP 요청 메시지는 한 개의 메서드를 가진다.

일반적으로 프로젝트에서 사용하던 GET, POST, PUT, DELETE 요청 등이 있다.

상태 코드

모든 HTTP 응답 메시지는 상태 코드와 함께 반환된다. 프로젝트에서 백엔드 서버로 요청을 보내다 보면 404, 400, 500등 수많은 에러를 본 적이 있지 않는가? 그게 상태코드다.

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

애플리케이션은 보통 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행한다. 예를 들어, 웹 브라우저는 시각적으로 풍부한 웹페이지를 가져올 때 대량의 HTTP 트랜잭션을 수행한다.

  • 페이지 레이아웃을 서술하는 HTML '뼈대'를 한 번의 트랜잭션으로 가져온 뒤

  • 첨부된 이미지, 그랲기 조각, 자바 애플릿 등을 가져오는 등

추가로 HTTP 트랜잭션을 수행한다.

메시지

HTTP 요청/응답 메시지에 대해 알아보자. 요청, 응답 메시지의 구성은 아래 이미지와 같이 이루어진다. 아마 크롬 개발자 도구의 Network 탭에서 자주 보던 것들일 것이다.

HTTP 메시지는 다음과 같이 세 부분으로 나뉜다.

  • 시작줄: 메시지의 첫 줄이다. 요청이라면 무엇을 해야 하는지, 응답이라면 무슨 일이 일어났는지 나타낸다. 위의 이미지에서는 요청 메시지에서 GET / seasonal ..., 응답 메시지에서는 HTTP/1.1 200 OK을 의미한다.

  • 헤더: 시작줄 다음에는 0개 이상의 헤더 필드가 이어진다. 헤더는 빈 줄로 끝난다. 위의 이미지에서는 요청 메시지에서는 Accept: *, 응답 메시지에서는 Content-Type: text/html, Content-Length: 617을 의미한다.

  • 본문: 요청의 본문에는 웹 서버로 데이터를 실어보내며, 응답의 본문은 클라이언트로 데이터를 반환한다. 본문에는 단순 문자열 뿐만 아니라 임의의 이진 데이터(이미지, 비디오, 응용 소프트웨어 등)를 포함할 수 있다.

TCP 커넥션

지금까지 HTTP 메시지가 어떻게 구성되는지 대략 알아보았으니, 어떻게 메시지가 TCP(Transmission Control Protocol, 전송 제어 프로토콜) 커넥션을 통해 한 곳에서 다른 곳으로 옮겨가는지 살펴보자.

TCP/IP

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

TCP는 다음과 같은 기능을 제공한다. (중요!)

  • 오류 없는 데이터 전송

  • 순서에 맞는 데이터 전달 (데이터는 언제나 보낸 순서대로 도착한다)

  • 조각나지 않는 데이터 스트림 (언제든 어떤 크기로든 보낼 수 있다)

TCP/IP는 TCP와 IP가 층을 이루는, 패킷 교환 네트워크 프로토콜의 집합이다. TCP/IP는 각 네트워크와 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해준다.

일단 TCP 커넥션이 맺어지면, 클라이언트-서버 간 교환되는 메시지가 없어지거나, 손상되는 일은 없다.

접속, IP 주소 그리고 포트번호

HTTP 클라이언트가 서버에 메시지를 전송할 수 있게 되기 전에, IP 주소와 포트번호를 이용해 클라이언트-서버 간에 TCP/IP 커넥션을 맺어야 한다.

그러면 HTTP 서버의 IP 주소와 포트번호를 어떻게 알아낼 수 있을까? URL을 이용한다. 예시를 보자.

  1. http://207.200.83.29:80/index.html
  2. http://www.netxcape.com:80/index.html
  3. http://www.netscape.com/index.html
  • 첫 번째 URL은 IP 주소 207.200.83.29와 포트번호 80을 갖고 있다.

  • 두 번째 URL에는 숫자로 된 IP 주소가 없다. 대신 글자로 된 도메인 이름 혹은 호스트명(www.netscape.com)을 갖고 있다. 호스트명은 DNS라 불리는 장치를 통해 쉽게 IP로 변환될 수 있다.

  • 마지막 URL에는 포트번호가 없다. HTTP URL에 포트번호가 빠진 경우에는 기본값 80이라고 가정하면 된다.

웹 브라우저가 HTTP 통신을 통해 서버의 리소스를 보여주는 사용자에게 보여주는 방법

  1. 웹브라우저는 서버의 URL에서 호스트명을 추출한다.

  2. 웹브라우저는 서버의 호스트명을 IP로 변환한다.

  3. 웹브라우저는 URL에서 포트번호를 추출한다.

  4. 웹브라우저는 웹서버와 TCP 커넥션을 맺는다.

  5. 웹 브라우저는 서버에 HTTP 요청을 보낸다.

  6. 서버는 웹브라우저에 HTTP 응답을 돌려준다.

  7. 커넥션이 닫히면, 웹브라우저는 문서를 보여준다.

프로토콜 버전

오늘날 쓰이고 있는 HTTP 프로토콜은 버전이 여러 가지다. 대표적인 버전 두가지를 살펴보자.

HTTP/1.1

HTTP/1.1은 HTTP 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중했다. 이는 현재의 HTTP 버전이다.

HTTP/2.0

HTTP/2.0은 HTTP/1.1의 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계가 진행 중인 프로토콜이다.

웹의 구성요소

이 장에서, 우리는 웹 애플리케이션(웹브라우저와 웹서버)이 기본적인 트랜잭션을 구현하기 위해 어떻게 메시지를 주고받는지에 중점을 두었다. 인터넷과 상호작용을 할 수 있는 웹 애플리케이션은 많은데, 다음에서 나오는 것들은 프로젝트를 진행하며 자주 봤던 것들일 것이다.

프록시

클라이언트와 서버 사이에 위치한 HTTP 중개자. 프록시는 웹 보안, 애플리케이션 통합, 성능 최적화를 위한 중요한 구성요소다.

위의 그림과 같이, 프록시는 클라이언트-서버 사이에 위치하여, 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다(대개 요청을 수정한 뒤에). 이 애플리케이션은 사용자를 위한 프록시로 동작하며 사용자를 대신해서 서버에 접근한다.

프록시는 주로 보안을 위해 사용된다.(신뢰할 만한 중개자 역할) 또한 프록시는 요청과 응답을 필터링한다. 프록시를 통해 해결할 수 있는 보안 이슈 중에 대표적으로 CORS 이슈가 있다.

캐시

많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고

그림을 보면 쉽게 이해할 수 있을 것이다. 클라이언트는 멀리 떨어진 웹 서버보다 근처의 캐시에서 훨씬 더 빨리 문서를 다운 받을 수 있다.

'캐싱을 통한 성능 향상' 이런 말을 자주 들어봤을 것이다(물론 웹 캐시와는 살짝 다르긴 하지만). 이는 7장에서 더 자세히 다룰 것이다.

게이트웨이

게이트웨이는 다른 서버들의 중개자로 동작하는 특별한 서버다. 게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다. 게이트웨이는 언제나 스스로가 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다룬다. 클라이언트는 자신이 게이트웨이와 통신하고 있음을 알아채지 못할 것이다.

HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP 요청을 받아들인 뒤, FTP 프로토콜을 이용해 문서를 가져온다. 받아온 문서는 HTTP 메시지에 담겨 클라이언트에게 보낸다. (8장에서 게이트웨이에 대해 다룸)

터널

단순히 HTTP 통신을 전달하기만 하는 특별한 프록시다. 터널은 두 커넥션 사이에서 날(raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션이다. HTTP 터널은 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용된다.

HTTP 터널을 활용하는 대표적인 예로, 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송함으로써 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 것이 있다.

에이전트

사용자 에이전트(혹은 그냥 에이전트)는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램이다. 웹 요청을 만드는 애플리케이션은 뭐든 HTTP 에이전트다.

예를 들면, 검색 엔진에 사용되는 '스파이더'나 '웹로봇'과 같이 자동화된 에이전트도 있다.

이 글은 'HTTP 완벽 가이드 - 웹은 어떻게 동작하는가(데이빗 고울리 저)'를 정리한 글입니다.

0개의 댓글