3:56

서적  'HTTP 완벽 가이드 - 웹은 어떻게 동작하는가'를 요약 정리한 내용입니다.

2장 URL과 리소스

2.1 인터넷의 리소스 탐색하기

대부분의 URL은 ‘스킴://서버위치/경로’ 구조로 이루어져 있다. 스킴은 웹 클라이언트가 리소스에 어떻게 접근하는지 알려준다. 서버 위치는 웹 클라이언트가 리소스가 어디에 호스팅 되어 있는지 알려준다. 경로는 서버에 존재하는 로컬 리소스들 중에서 요청받은 리소스가 무엇인지 알려준다.

2.1.1 URL이 있기 전 암흑의 시대

2.2 URL 문법

URL의 형태는 일반적으로 다음과 같이 구성된다.

<스킴>://<사용자 이름>:<비밀번호>@호스트:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>

꼭 이 모든 컴포넌트를 다 가지는 것은 아니며 가장 중요한 세 가지 컴포넌트는 스킴, 호스트, 경로이다.

2.2.1 스킴 : 사용할 프로토콜

스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 정보이며 이는 URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지 알려준다. ‘http’도 여기에 속한다.

2.2.2 호스트와 포트

호스트는 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킨다. 호스트 명으로 나타내기도 하며 IP주소로 나타내기도 한다. 포트는 서버가 열어놓은 네트워크 포트를 가리키는데, TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80을 사용한다.

2.2.3 사용자 이름과 프로토콜

많은 서버가 자신이 가지고 있는 데이터에 접근을 허용하기 전 사용자 이름과 비밀번호를 요구한다. 그 값들이 삽입되어 있지 않을 경우 기본 사용자 이름과 비밀번호 값을 넣어둔다.

2.2.4 경로

경로는 리소스가 서버의 어디에 있는지 알려준다. HTTP URL에서 경로 컴포넌트는 ‘/’ 문자를 기준으로 경로 조각으로 나뉘며, 각 경로 조각은 자체만의 파라미터 컴포넌트를 가질 수 있다.

2.2.5 파라미터

파라미터 컴포넌트는 프로토콜이 요구하는 더 많은 정보를 처리한다. 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미털르 받으며, 이름/값 쌍의 리스트로 URL 나머지 부분들로부터 ‘;’ 문자로 구분하여 URL에 기술한다.

2.2.6 질의 문자열

데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있다. 많은 게이트웨이가 ‘&’으로 나뉜 ‘이름=값’ 쌍 형식의 질의 문자열을 원한다.

예시) http;;//www.abcdefgh.com/inventory-check.cgi?item=12345&color=blue

2.2.7 프래그먼트

URL은 텍스트 문서 전체를 가리키겠지만, 이상적으로는 리소스 안에 있는 특정 절을 가리킬 수 있어야 한다. 리소스의 특정 부분을 가리킬 수 있도록, URL은 리소스 내의 조각을 가리킬 수 있는 프래그먼트 컴포넌트를 제공한다. 일반적으로 클라이언트는 서버에 프래그먼트를 전달하지 않으며, 브라우저가 서버로부터 전체 리소스를 내려받은 후 프래그먼틑를 사용하여 사용자가 보고자 하는 리소스의 일부를 보여준다.

2.3 단축 URL

2.3.1 상대 URL

2.3.2 URL 확장

어떤 브라우저들은 URL을 입력하는 동안 자동으로 URL을 확장하여 사용자가 URL을 빠르게 입력하게 도와준다. 확장에는 호스트명 확장과 히스토리 확장이 있다. 호스트명 확장은 휴리스틱을 사용하여 입력한 호스트명을 전체 호스트명으로 확장한다. 히스토리 확장은 과거에 사용자가 방문했던 URL의 기록을 저장해 놓는 방법이다. URL을 입력하면 입력된 앞 글자들을 포함하는 완결된 형태의 URL을 선택하게 해준다.

2.4 안전하지 않은 문자

서로 다른 장치에서 어떤 인터넷 프로토콜을 통해서든 안전하게 데이터가 전송될 수 있도록 URL을 설계해야 한다. 정보가 유실되지 않도록 URL은 상대적으로 작고 일반적으로 안전한 알파벳 문자만 포함하도록 허락하였다. 그러나 URL 설게자들이 알파벳 이외의 문자로 URL을 만드는 것을 수요하자 이스케이프라는 기능을 추가하여 안전하지 않은 문자를 안전한 문자로 인코딩 할 수 있게 하였다.

2.4.1 URL 문자 집합

역사적으로 많은 컴퓨터 애플리케이션들이 US-ASCII문자 집합을 사용해왔다. 이는 7비트를 사용하여 영문 자판의 키 대부분과 몇몇 제어 문자들을 표현한다. 그러나 URL에 다른 언어들과 특정 이진 데이터를 포함해야 하는 경우가 생기면서 URL 설게자들은 이스케이프 문자열을 쓸 수 있게 설계하였다.

2.4.2 인코딩 체계

인코딩은 안전하지 않은 문자를 퍼센티지 기호로 시작해 ASCII 코드로 표현되는 두 개의 16진수 문자로 이루어진 이스케이프 문자로 바꾼다.

2.4.3 문자 제한

US-ASCII에서 출력이 불가능한 문자, 몇몇 인터넷 게이트웨이와 프로토콜에서 혼동되는 문자들은 사용이 제한되며 반드시 사용하기 전 인코딩을 필요로 한다.

2.4.4 좀 더 알아보기

입력받은 URL에서 어떤 문자를 인코딩해야 하는지 결정하는 데는 브라우저와 같이 사용자로부터 최초로 URL을 입력받는 애플리케이션에서 하는 것이 가장 적절하다.

2.5 스킴의 바다

2.6 미래

URL은 리소스의 주소를 가리키지 실제 이름은 아니다. 따라서 리소스가 옮겨지면 URL을 더는 사용할 수 없다. 이러한 문제를 예방하기 위해서는 그 객체를 가리키는 실제 객체의 이름을 사용해야 하는데, 이러한 방식을 URN이라 한다.

서적  'HTTP 완벽 가이드 - 웹은 어떻게 동작하는가'를 요약 정리한 내용입니다.

1장 HTTP 개관

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

1.2 웹 클라이언트와 서버

클라이언트(웹 브라우저)는 서버에게 HTTP 요청을 보내고 서버는 요청된 데이터를 HTTP 응답으로 돌려준다.

1.3 리소스

리소스는 웹에 콘텐츠를 제공하는 모든 것들을 말한다.

예시) 텍스트 파일, HTML 파일, 워드 파일, 이미지 파일 등 정적 파일과 웹 캠, 주식 거래, 전자상거래 게이트웨이 등 동적 파일

1.3.1 미디어 타입

웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙인다. 웹 브라우저는 서버로부터 객체를 돌려받을 때, 다룰 수 있는 객체인지 MIME 타입을 통해 확인한다. MIME 타입은 주 타입과 부 타입으로 이루어진 문자열 라벨이다.

예시) HTML – text/html, plain ASCII-text/plain, JPEG-image/jpeg 등

1.3.2 URI

웹 서버 리소스는 각자 이름을 갖고 있는데 이를 통합 자원 식별자, URI(unifrm resource identifier)라 한다. URI의 종류에는 URN과 URL이 있다.

1.3.3 URL

통합 자원 지시자(Uniform resource locator, URL)는 리소스 식별자의 가장 흔한 형태로, 특정 서버의 한 리소스에 대한 구체적인 위치를 서술하며 어떻게 접근할 수 있는지도 나타낸다.

예시) (https://) + (postfiles.pstatic.net) + (/MjAyMjAxMjJfMjAw)

첫 번째 부분은 스킴이라고 하는데, 리소스에 접근하기 위해 사용되는 프로토콜을 서술한다.

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

마지막은 웹 서버의 리소스를 가리킨다.

1.3.4 URN

유니폼 리소스 이름(Uniform Resource Name, URN)은 콘텐츠를 이루는 한 리소스에 대해 그 리소스의 위치에 영향 받지 않는 이름 역할을 한다. URN은 위치 독립적이어서 이름을 변하지 않게 유지하는 한, 리소스를 여기저기로 옮기더라도 문제없이 동작하며 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제없다.

1.4 트랜잭션

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

1.4.1 메서드 (요청 명령)

HTTP는 HTTP 메서드라고 불리는 여러 가지 종류의 요청 명령을 지원한다. 모든 HTTP 요청 메시지는 한 개의 메서드를 갖는다. 메서드는 서버에게 어떤 동작이 취해져야 하는지 말해준다.

예시)

GET-서버에서 클라이언트로 지정한 리소스를 보내라

PUT-클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하라

DELETE-지정한 리소스를 서버에서 삭제하라

POST-클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라

HEAD-지정한 리소스에 대한 응답에서 HTTP 헤더 부분만 보내라

1.4.2 상태 코드 (응답 결과)

모든 HTTP 응답 메시지는 상태 코드와 함께 반환된다. 상태 코드는 클라리언트에게 요청이 성공했는지 추가 조치가 필요한지 알려주며, 숫자 상태 코드에 더해 텍스트로 된 사유 구절도 함께 보낸다.

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

하나의 작업을 수행하기 위해서는 여러 HTTP 트랜잭션을 수행한다. 예를 들어 페이지 레이아웃을 서술하는 HTML 뼈대를 한 번의 트랜잭션으로 가져온 뒤 이미지, 그래픽 등을 가져오는 HTTP 트랜잭션을 추가로 수행한다.

1.5 메시지

HTTP 요청 및 응답 메시지는 시작줄, 헤더, 본문으로 이루어진다.

시작줄 – 요청은 무엇을 해야 하는지, 응답은 무슨 일이 일어났는지 나타낸다. 상태코드와 사유 구절, HTTP 버전 등이 여기에 포함된다.

헤더 – 요청의 경우 호스트 정보와 무엇을 받아올 것인지, 응답의 경우 서버 정보와 내용의 길이와 타입 등이 해당된다.

본문 –데이터를 실어 보내거나 반환한다.

1.6 TCP 커넥션

TCP란 전송 제어 프로토콜 (Transmissoin Control Protocol)을 의미한다.

1.6.1 TCP/IP

HTTP는 애플리케이션 계층 프로토콜로, 네트워크 통신의 핵심적인 세부사항은 신경 쓰지 않으며 이를 TCP/IP에게 맡긴다. TCP/IP는 TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합이다. 이는 각 네트워크와 하드웨어의 특성을 숨기고 어떤 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해준다. TCP 커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간 교환되는 메시지가 없어지거나, 손상 되거나, 순서가 뒤바뀌어 수신되는 일은 결코 없다.

1.6.2 접속, IP주소, 포트번호

TCP/IP 커넥션을 맺기 위해서는 IP 주소와 포트번호를 이용해 클라이언트와 서버 사이에 커넥션을 맺어야 한다. IP주소와 포트번호는 URL을 이용하여 알 수 있다. URL에는 IP주소와 포트번호가 있으며, IP 주소는 문자로 된 도메인 이름으로 대체하여 사용하기도 한다. (일종의 별명)

1.7 프로토콜 버전

HTTP 0.9, HTTP 1.0, HTTP 1.1, HTTP 2.0

1.8 웹의 구성요소

인터넷과 상호작용 할 수 있는 웹 애플리케이션은 많다.

(예시) 프락시, 캐시, 게이트웨이, 터널

1.8.1 프락시

프락시는 클라이언트와 서버 사이에 위치한 HTTP 중개자이다. 클라이언트의 HTTP 요청을 수정하고 서버에 전달하며, 바이러스를 검출하거나 성인 콘텐츠를 차단하는 등 요청과 응답을 필터링한다.

1.8.2 캐시

캐시는 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고이다. 웹캐시와 캐시 프락시는 자신을 거쳐가는 문서들 중 자주 찾는 것의 사본을 저장하는 HTTP 프락시 서버이다. 클라이언트는 웹 서버보다 근처의 캐시에서 훨신 더 빨리 문서를 다운 받을 수 있다.

1.8.3. 게이트웨이

게이트웨이는 다른 애플리케이션과 연결된 특별한 웹서버이다. 게이트웨이는 다른 서버들의 중개자로 동작하는데, 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다. 예컨대 HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP 요청을 받아들인 뒤, FRP 프로토콜을 이용해 문서를 가져온다.

1.8.4. 터널

터널은 단순히 HTTP 통신을 전달하기만 하는 프락시이다. 터널은 두 커넥션 사이에서 날 데이터를 열어보지 않고 그대로 전달한다. HTTP 터널은 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해줄 때 사용한다.

1.8.5 에이전트

사용자 에이전트는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램이다. HTTP 요청을 만들어주는 클라이언트 프로그램은 모두 HTTP 에이전트이며 웹 브라우저도 여기에 속한다.