HTTP 완벽가이드 1장 - HTTP개관

김명성·2022년 7월 3일

HTTP 이해하기

목록 보기

1/2

전 세계의 웹브라우저,서버, 웹에플리이션은 모두 HTTP를 통해 서로 대화한다.
HTTP는 현대 인터넷의 공용어이다.

HTTP는 웹 서버로부터 사람들의 PC에 설치된 웹 브라우저로 데이터를 옮겨준다.

웹 서버

웹 서버는 HTTP 프로포콜로 의사소통하기 때문에 보통 HTTP 서버라고 불린다.

웹 서버는 인터넷의 데이터를 저장하고, HTTP클라이언트가 요청한 데이터를 제공한다.

클라이언트는 서버에 HTTP REQUEST를, 서버는 클라이언트에 HTTP RESPONSE를 주고받는다.

웹 클라이언트

HTTP 클라이언트의 가장 보편적인 모습은 크롬과 같은 웹 브라우저다.
웹브라우저는 서버에게 HTTP 객체를 요청하고 사용자의 화면에 보여준다.

웹브라우저가 https://www.google.com/index.html 사이트를 접속했을 때를 가정해보자.

웹브라우저는 먼저 HTTP 요청을 https://www.google.com으로 HTTP요청을 서버로 보내고, 서버는 요청 받은 객체/index/html를 찾고 성공했다면 객체의 타입,길이등 정보와 함께 HTTP 응답에 실어서 클라이언트에게 보낸다.

리소스

웹서버(HTTP 서버)는 리소스를 관리하고 제공한다.

가장 기본적인 형태의 웹 리소스는 웹 서버 파일 시스템의 정적 파일이다.

리소스는 꼭 정적 파일일 필요는 없으며, 요청에 따라 콘텐츠를 생산할 수도 있고 이런 동적 콘텐츠 리소스는 사용자가 누구인지, 어떤 정보를 요청했는지, 몇 시인지에 따라 다른 콘텐츠를 생성한다.

또 카메라에서 라이브 영상을 가져오거나, 주식 거래, 부동산 DB 검색, 온라인쇼핑등을 가능하게도 만들어준다.

요악하자면 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.

미디어 타입

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

즉 웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙인다.
웹브라우저가 서버로부터 요청한 HTTP 객체를 응답받을 때, 다룰 수 있는 객체인지 MIME타입을 통해 확인하며 대부분 웹 브라우저는 잘 알려진 객체 타입 수백 가지를 다룰 수 있다.

MIME 타입

MIME타입은 사선 /으로 구분된 주 타입과 부 타입으로 이루어진 문자열 라벨이다.

MIME type
Content-type: image/jpeg
Content-type: image/gif
Content-type: video/quicktime

URI

웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다.
서버 리소스 이름은 URI로 불린다.
URI는 인터넷의 우편물 주소 같은 것으로, 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다.

URI는 URL과 URN이라는 두 종류의 리소스 식별자로 나뉜다.

URL

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

scheme이라고 불리는 리소스에 접근하기 위해 사용되는 프로토콜을 서술한다.
http:// , https://
서버의 인터넷 주소를 서술한다.
www.google.com
마지막은 웹 서버의 리소스를 가리킨다.
/specials/something.gif

오늘날의 대부분 URI는 URL이다.

URN

URN은 콘텐츠를 이루는 한 리소스에 대해 그 리소스의 위치에 영향을 받지 않는 유일무이한 이름 역할을 한다.

리소스 자체의 이름이 변경되지 않는 한, 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제 없다.
urn:ietf:rfc:2141

인프라의 부재로 URN 채택은 늦춰지고 있다.

트랜잭션

HTTP 트랜잭션은 요청과 응답으로 구성되어 있다.
이 상호작용은 HTTP 메세지라고 불리는 정형화된 데이터 덩어리를 이용해 이루어 진다.

메서드

모든 HTTP REQUEST는 한 개의 메서드만을 갖는다.
메서드는 서버에게 어떤 동작이 취해져야 하는지 말해준다.

REST API : GET / PUT / DELETE / PETCH / POST / HEAD / OPTIONS ...

상태 코드

모든 HTTP RESPONSE는 상태 코드와 함께 반환된다.
상태 코드는 HTTP REQUEST의 요청에 대한 상태를 의미한다.
또한 상태 코드에 reason phrase도 함께 보낸다.

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

어플리케이션은 보통 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행한다.

예를 들어, 웹브라우저는 시각적으로 풍부한 웹페이지를 가져올 때 대량의 HTTP 트랜잭션을 수행한다.

페이지 레이아웃을 서술하는 HTML '뼈대'를 한 번의 트랜잭션으로 가져온 뒤
이후 첨부된 이미지, 그래픽 조각, 자바 애플릿 등을 가져오기 위해 추가적으로 HTTP 트랜잭션들을 수행한다.

이때 수행되는 HTTP REQUEST는 여러 곳에서 리소스를 가져올 수 있으며 웹 페이지는 하나의 리소스가 아닌 리소스들의 모음이다.

HTTP 메세지

HTTP 메세지는 binary 형식이 아닌 단순 text 타입으로 사람들이 읽고 쓰기 쉽다.

응답 메시지, 요청 메시지 모두 세 부분으로 나누어진다.

HTTP 메세지의 시작 줄

요청메세지 GET /special/something.gif HTTP/1.0
응답메세지 HTTP/1.0 200 OK

요청메세지 : Accept: text/* , Accept-Language: en, kr
응답메세지 : Content-type: text/plain , Content-length: 19

HTTP 메세지의 Body

본문에는 어떤 종류의 데이터든 들어갈 수 있는 메세지 본문(Body)이 필요에 따라 올 수 있다.

요청의 Body에는 웹 서버로 데이터를 실어 보내며, 응답의 본문은 클라이언트로 데이터를 반환한다.
문자열이며 구조적인 시작줄,Header와는 달리 본문은 binary데이터를 포함할 수 있다.
image,video,Autio 등은 text타입으로 올 수 없기에 binary 데이터로 보낼 수 있다.

응답 Body의 길이는 Header의 Content-Length에, 문서의 MIME Type은 Header의 Content-type 에 적혀 있다.

TCP 커넥션

HTTP 메세지가 어떻게 생겼는지는 대략 위에 서술한 바와 같다.

이제 어떻게 메세지가 TCP 커넥션을 통해 한 곳에서 다른 곳으로 옮겨가는지 이야기해보자.

TCP/IP

HTTP는 어플리케이션 계층 프로토콜이다.

어플리케이션 계층?
어플리케이션 계층은 네트워크 4계층의 4단계를 의미한다.(최상위)
어플리케이션 계층을 네트워크 7계층으로 구분질 때에는 7단계: 응용, 6단계: 표현,5단계: 세션이 이에 해당한다.

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

TCP/IP에게 맡긴다?
네트워크의 구조를 4계층 또는 7계층으로 나누었을때 TCP/IP가
어플리케이션 계층 프로토콜의 하위 계층임을 의미한다.
TCP는 7계층에서 4단계 전송 계층을 의미하며, 4계층에서는 3단계 Transport이다.
IP는 7계층의 3단계 네트워크 계층을 의미하며 4계층에서는 2단계 Internet이다.

TCP가 제공하는 것

오류 없는 데이터 전송

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

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

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

일단 클라이언트와 서버간의 TCP 커낵션이 맺어지면, 교환되는 메세지가 없어지거나, 손상되거나, 순서가 뒤바뀌어 수신되는 일은 결코 없다.

네트워크 개념상, HTTP 프로토콜은 TCP위의 계층이다.
HTTP는 자신의 메세지 데이터를 전송하기 위해 TCP를 사용한다.
(요청과 응답 모두 TCP를 사용하여 통신한다는 뜻)
이와 유사하게 TCP는 IP의 상위 계층이다.

IP가 제공하는 것

HTTP 클라이언트가 서버에 메세지를 전송할 수 있게 되기 전에, 인터넷 프로토콜(IP) 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.

TCP 커넥션을 맺는 것은 콜센터에 전화를 거는 것과 다소 비슷하다.

전화번호를 누른다. 콜센터에 연결된다. 그 다음 자신의 민원에 맞는 버튼을 눌러 상대방과 연결된다.

TCP에서는 서버 컴퓨터에 대한 IP주소와 그 서버에서 실행 중인 프로그램이 사용 중인 포트번호가 필요하다.

IP주소와 포트번호는 URL을 통해 알 수 있다.

URL의 예시

http://255.255.255.255:80/index.html
http://www.google.com:80/index.html
http://www.google.com/index.html

첫번째 URL은 IP주소와 포트번호 80을 갖고 있다.
두번째 URL은 IP주소 대신 글자로 된 도메인 혹은 호스트 명을 갖고 있다.
호스트 명은 도메인 이름 서비스(DNS)라 불리는 장치를 통해 쉽게 IP로 변환될 수 있다.
세번째 URL은 포트번호가 없다. HTTP URL에 포트번호가 빠진 경우에 Default는 80이다.

IP주소와 포트번호를 이용해 클라이언트는 TCP/IP로 쉽게 통신할 수 있다.

HTTP의 TCP/IP 커넥션 순서

클라이언트는 서버의 URL에서 호스트 명을 추출
클라이언트는 서버의 호스트 명을 IP로 변환
클라이언트는 포트번호가 있다면 추출.
클라이언트는 웹 서버와 TCP 커낵션을 맺는다.
클라이언트는 서버에 HTTP 요청을 보낸다.
서버는 클라이언트에 HTTP 응답을 돌려준다.
커넥션이 닫히면, 클라이언트는 사용자에게 문서를 보여준다.

웹의 구성 요소

웹 어플리케이션이 기본적인 트랜잭션을 구현하기 위해 어떻게 메세지를 주고 받는지에 대해 알아보았다.

인터넷과 상호작용할 수 있는 웹 어플리케이션은 다수이며, 간략히 알아보자.

프락시

클라이언트와 서버 사이에 위치한 HTTP 중개자

웹 보안, 어플리케이션 통합, 성능 최적화를 위해 중요한 구성요소이다.

프락시는 클라이언트와 서버 사이에 위치하여 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다. (대개 요청을 수정한 뒤에 전달)

프락시는 사용자를 위해 동작하며 사용자를 대신해서 서버에 접근한다.
프락시는 주로 보안을 위해 사용되며 요청과 응답을 필터링한다.
예를 들어 어떤 프로그램을 다운로드 받을 때 바이러스를 검출하거나, 성인 콘텐츠를 차단한다.

캐시

많이 찾는 웹페이지를 클라이언트 가까이 보관하는 HTTP 창고
자주 거쳐 가는 문서들의 사본을 저장해 두는 특별한 HTTP 프락시 서버다.

게이트웨이

다른 어플리케이션과 연결된 특별한 웹 서버

게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용한다.

게이트웨이는 스스로 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다룬다.

터널

단순히 HTTP 통신을 전달하기만 하는 프락시

터널은 데이터를 열어보지 않으며 그대로 전달한다.

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

에이전트

자동화 된 HTTP 요청을 만드는 준 지능적 웹클라이언트

사람의 통제 없이 스스로 웹을 돌아다니며 HTTP 트랜잭션을 일으키고 콘텐츠를 받아오는 자동화된 사용자 에이전트를 스파이더, 웹로봇과 같이 다채로운 이름으로 부르고 있다.

검색 엔진의 데이터베이스나 가격 비교 카탈로그와 같은 유용한 웹 컨텐츠 보관소를 만드는 것이 에이전트이다.

김명성

다음 포스트