1. HTTP(Hypertext Transfer Protocol) 란?
전 세계의 웹브라우저, 서버, 웹어플리케이션은 모두 HTTP를 통해 서로 대화한다. 즉 HTTP는 현대 인터넷의 공용어라고 생각하자!
1-1 HTTP : 인터넷의 멀티미디어 배달부
•
HTTP는 수십억개의 JPEG 이미지 , HTML 페이지, 텍스트 파일 MPEG 동영상, WAV 음성파일, 자바 애플릿 등이 하루도 쉬지 않고 인터넷을 향해 배달을 해준다.
•
배달을 하면서 HTTP는 대량의 정보를 빠르고, 간편, 정확하게 사람들의 PC에 설치된 웹브라우저로 연결시켜준다!
•
HTTP는 신뢰성있는 데이터 전송 프로토콜을 사용한다. 어느정도냐면 데이터가 지구의 반대편에 오더라도 전송 중 손상되거나 꼬이지 않음을 보장시켜준다.
•
HTTP덕분에 개발자는 애플리케이션 고유의 기능을 구현하는데 집중 할 수 있다.
1-2 웹 클라이언트와 서버
•
웹 콘텐츠는 웹서버에 존재
•
웹 서버는 HTTP 프로토콜로 의사소통하기 때문에 보통 HTTP 서버라고한다.
•
아래의 이미지로 클라이언트와 서버 흐름을 간단하게 살펴보자
1-3 리소스
웹서버는 웹 리소스를 관리 / 제공한다.
•
웹 리소스는 웹 콘텐츠의 원천이다.
•
가장 단순한 웹 리소스는 웹 서버 파일 시스템의 정적 파일이다.
정적 파일 : 텍스트파일, HTML 파일, 마이크로 소프트 워드파일, 어도비 아크로벳 파일, JPEG 이미지 파일, AVI 동영상 파일, 그 외 모든 종류 파일을 말한다.
•
리소스는 또한 요청에 따라 콘텐츠를 생산하는 프로그램이 될 수 있다.
동적콘텐츠 리소스 예시 : 주식거래, 부동산 데이터베이스 검색, 온라인 쇼핑몰에서 선물 구입, 카메라에서 라이브 영상을 가져와 보여준다.
1-3-1 미디어 타입
•
HTTP는 웹에서 전송되는 객체 각각에 신중하게 MIME 타입이라는 데이터 포맷라벨을 붙인다.
•
웹서버는 모든 HTTP 객체 데이터에 MIME타입을 붙인다.
•
MIME 타입은 사선(/)으로 구분된 주 타입과 부타입으로 이루어진 문자열 라벨이다.
1-3-2 URI
1. URI란 ?
웹 서버 리소스는 각자 이름을 갖고있기 때문에 클라이언트는 관심리소스를 지목할 수 있다. 이 때 서버 리소스 이름은 통합 자원 식별 (Uniform Resource Identifier) 혹은 URI 라고 불린다.
•
URI는 쉽게 인터넷의 우편물 주소라고 생각하면 된다.
•
정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다.
•
URI에는 두가지 종류가 있다 1. URL 과 2. URN이 있다.
1-3-3 URL
•
URI에 한 종류이며 통합 자원 지시자( Uniform Resource Locator)라고 하며 리소스 식별자의 가장 흔한형태이다
•
특정서버의 한 리소스에 대해 구체적인 위치를 서술한다.
대부분 URL은 세 부분으로 이루어진 표준 포맷을 따른다
1.
첫 번째 부분은 스킴(Scheme)이라고 불리며 리소스에 접근하기위해 사용되는 프로토콜이다. 보통 HTTP 프로토콜이다 (http://)
2.
두 번째 부분은 서버의 인터넷 주소를 제공한다
3.
세 번째 부분은 웹서버의 리소스를 가르킨다.
1-3-4 URN
유니폼 리소스 이름 (Uniform Resource Name)이며 콘텐츠를 이루는 한 리소스에 대해 그 리소의 위치에 영향 받지 않는 유일무이한 이름 역할을 한다.
1-4 트랜잭션
클라이언트가 웹 서버와 리소스를 주고 받기위해 HTTP 트랜잭션은 요청명령과 응답결과로 구성되어있다.
1-4-1 메서드
HTTP는 HTTP메서드라고 불리는 여러가지 종류의 요청 명령을 지원한다.
HTTP 요청 메시지는 한 개의 메서드를 갖는다, 메서드는 서버에게 어떤동작이 취해져야하는지 말해준다(웹페이지 가져오기, 게이트위에 프로그램 실행하기, 파일 삭제하기등)
1-4-2 상태코드
모든 HTTP 응답 메시지는 상태코드와 함께 반환된다. 상태코드는 클라이언트에 요청이 성공했는지 아니면 추가 조치가 필요한지 알려주는 세자리 숫자이다.
1-4-3 웹페이지는 여러 객체로 이루어 질 수 있다.
•
웹브라우저는 시각적으로 풍부한 웹페이즈를 가져 올때 대량의 HTTP 트랜잭션을 수행한다.
1.
페이지 레이아웃을 서술하는 HTML ‘뼈대’를 한번의 트랜잭션으로 가져온 뒤
2.
첨부된 이미지, 그래픽 조각 ,자바 애플릿등을 가져오기 위해 추가로 HTTP 트랜잭션들을 수행한다
웹 페이지는 리소스의 모음이다!
1-5 메시지
HTTP 메시지는 단순한 줄 단위의 문자열이다. 이진 형식이 아닌 일반 텍스트이기 때문에 사람이 읽고 쓰기 쉽다. 아래 그림은 간단한 트랜잭션에 대한 HTTP 메시지를 보여주고 있다.
웹 클라이언트에서 웹 서버로 보낸 HTTP 메시지를 요청 메시지라 부른다. 서버에서 클라이언트로 가는 메시지는 응답 메시지라고 부른다. 그 외에 다른 종류의 HTTP 메시지는 없으며, HTTP 요청과 응답 메시지의 형식은 굉장히 비슷하다.
HTTP 메시지는 다음의 세 부분으로 이루어진다.
•
시작줄
메시지의 첫 줄은 시작줄로, 요청이라면 무엇을 해야하는지 응답이라면 무슨 일이 일어났는지 나타낸다.
•
헤더
시작줄 다음에는 0개 이상의 헤더 필드가 이어진다. 각 헤더 필드는 쉬운 구문분석을 위해 쌍점(:)으로 구분되어 있는 하나의 이름과 하나의 값으로 구성된다. 헤더 필드를 추가하려면 그저 한 줄을 더하기만 하면 된다. 헤더는 빈 줄로 끝난다.
•
본문
빈 줄 다음에는 어떤 종류의 데이터든 들어갈 수 있는 메시지 본문이 필요에 따라 올 수 있다. 요청의 본문은 웹 서버로 데이터를 실어 보내며, 응답의 본문은 클라이언트로 데이터를 반환한다.
1-6 TCP 커넥션
TCP 란? Transmisson Control Protocol, 전송제어 프로토콜 이다.
1-6-1 TCP/IP
•
HTTP는 애플리케이션 계층프로토콜이다. HTTP는 네트워크 통신의 핵심적인 세부사항에 대해서 신경 쓰지 않는다.
•
대중적이고 신뢰성 있는 인터넷 전송 프로토콜은 TCP/IP가 해준다.
ㅁ TCP는 다음을 제공한다
1.
오류없는 데이터 전송
2.
순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착한다)
3.
조각나지 않는 데이터 스트림(언제든 어떤 크기로든 보낼 수 있다)
TCP/IP는 TCP와 IP가 층을 이루는 ,패킷 교환 네트워크 프로토콜의 집합
TCP/IP의 특징
•
네트워크아 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨너타 네트워크든 서로 신뢰성 있는 의사소통을 하게 해준다
TCP 커넥션이 맺어진다면?
•
클라이언트와 서버 컴퓨터 간의 교환되는 메시지가 없어지거나, 손상되거나, 순서가 뒤바뀌어 수신되는 일은 결코없다.
추가적으로
네트워크 개념상, HTTP 프로토콜은 TCP 위의 계층이다. HTTP는 자신의 메시지 데이터를 전송하기 위해 TCP를 사용한다. 이와 유사하게 TCP는 IP 위의 계층이다.
1-6-2 접속, IP주소 그리고 포트번호
•
HTTP 클라이언트가 서버에 메시지를 전송할 수 있게 되기 전에, 인터넷 프로토콜(Internet Protocol, IP) 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.
•
TCP 커넥션을 맺는 것은 다른 회사 사무실에 있는 누군가에게 전화를 거는 것과 다소 비슷하다.
1.
먼저 회사의 전화번호를 누른다. 이렇게 하면 그 회사로 연결된다.
2.
그 다음엔 전화를 걸고자 하는 상대방이 쓰는 번호를 누른다.
•
TCP에서는 서버 컴퓨터에 대한 IP 주소와 그 서버에서 실행 중인 프로그램이 사용 중인 포트번호가 필요하다.
HTTP 서버의 IP 주소와 포트번호는 어떻게 알아낼 수 있을까?
URL을 사용하면 된다. URL이란 리소스에 대한 주소이고, URL은 그 리소스를 가지고 있는 장비에 대한 IP 주소를 알려줄 수 있다. 몇 가지 URL을 살펴보자.
1.
첫 번째 URL은 IP 주소 '207.200.83.29'와 포트번호 '80'을 갖고 있다.
2.
두 번째 URL에는 숫자로 된 IP 주소가 없다. 대신 글자로 된 도메인 이름 혹은 호스트 명을 갖고 있다. 호스트 명은 IP 주소에 대한 이해하기 쉬운 형태의 별명이다. 호스트 명은 도메인 이름 서비스(Domain Name Service, DNS)라 불리는 장치를 통해 쉽게 IP로 변환될 수 있으므로 모든 준비는 끝난 것이다.
3.
마지막 URL은 포트번호가 없다. HTTP URL에 포트번호가 빠진 경우에는 기본값 80이라고 가정하면 된다.
IP주소와 포트번호를 이용해 클라이언트는 TCP/IP로 쉽게 통신할 수 있다. 다음 그림은 웹 브라우저가 어떻게 HTTP를 이용해서 멀리 떨어진 곳에 있는 서버의 단순한 HTML 리소스를 사용자에게 보여주는지 묘사하고 있다.
순서는 다음과 같다.
(a) 웹 브라우저는 서버의 URL에서 호스트 명을 추출한다.
(b) 웹 브라우저는 서버의 호스트 명을 IP로 변환한다.
(c) 웹 브라우저는 URL에서 포트번호(있다면)를 추출한다.
(d) 웹 브라우저는 웹 서버와 TCP 커넥션을 맺는다.
(e) 웹 브라우저는 서버에 HTTP 요청을 보낸다.
(f) 서버는 웹 브라우저에 HTTP 응답을 돌려준다.
(g) 커넥션이 닫히면, 웹 브라우저는 문서를 보여준다.
1.7 프로토콜 버전
•
HTTP/0.9
1991년의 HTTP 프로토타입은 HTTP/0.9로 알려져 있다. 이 프로토콜은 심각한 디자인 결함이 다수 있고 구식 클라이언트하고만 같이 사용할 수 있다. HTTP/0.9는 오직 GET 메서드만 지원하고, 멀티미디어 콘텐츠에 대한 MIME 타입이나, HTTP 헤더, 버전 번호는 지원하지 않는다. HTTP/0.9는 원래 간단한 HTML 객체를 받아오기 위해 만들어진 것이다.
•
HTTP/1.0
1.0은 처음으로 널리 쓰이기 시작한 HTTP 버전이다. HTTP/1.0은 버전 번호, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리를 추가했따. HTTP/1.0은 시각적으로 매력적인 웹페이지와 상호작용하는 폼을 실현했고 이는 월드 와이드 웹을 대세로 만들었다. HTTP/1.0은 결코 잘 정의된 명세가 아니다. HTTP가 상업적, 학술적으로 급성장하던 시기에 만들어진, 잘 동작하는 용례들의 모음에 가깝다.
•
HTTP/1.0+
1990년대 중반, 월드 와이드 웹이 급격히 팽창하고 상업적으로도 성공하면서 여러 유명 웹 클라이언트와 서버 들은 그에 따른 요구를 만족시키기 위해 발 빠르게 HTTP에 기능을 추가해갔다. 오래 지속되는 "keep-alive" 커넥션, 가상 호스팅 지원, 프락시 연결 지원을 포함해 많은 기능이 공식적이진 않지만 사실상의 표준으로 HTTP에 추가되었다.
•
HTTP/1.1
HTTP/1.1은 HTTP 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중했다. 뿐만 아니라 HTTP/1.1은 더 복잡해진 웹 애플리케이션과 배포를 지원한다. HTTP/1.1은 현재의 HTTP 버전이다.
•
HTTP/2.0
HTTP/2.0은 HTTP/1.1 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계가 진행 중인 프로토콜이다.
1-8 웹의 구성요소
◦
프락시
클라이언트와 서버 사이에 위치한 HTTP 중개자
◦
캐시
많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
◦
게이트웨이
다른 애플리케이션과 연결된 특별한 웹 서버
◦
터널
단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
◦
에이전트
자동화된 HTTP 요청을 만드는 준지능적(semi-intelligent) 웹클라이언트
1-8-1 프락시
◦
웹 보안, 애플리케이션 통합, 성능 최적화를 위한 중요한 구성요소인 HTTP 프락시 서버에 대해 살펴보자.
◦
아래 그림에서 보다시피, 프락시는 클라이언트와 서버 사이에 위치하여, 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다. 이 애플리케이션은 사용자를 위한 프락시로 동작하며 사용자를 대신해서 서버에 접근한다.
◦
프락시는 주로 보안을 위해 사용된다. 즉, 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 한다. 또는 프락시는 요청과 응답을 필터링한다. 예를 들어, 회사에서 무엇인가를 다운 받을 때 애플리케이션 바이러스를 검출하거나 초등학교 학생들에게서 성인 콘텐츠를 차단한다.
1-8-2 캐시
•
웹 캐시와 캐시 프락시는 자신을 거쳐 가는 문서들 중 자주 찾는 것의 사본을 저장해 두는, 특별한 종류의 HTTP 프락시 서버다. 다음번에 클라이언트가 같은 문서를 요청하면 그 캐시가 갖고 있는 사본을 받을 수 있다.
•
클라이언트는 멀리 떨어진 웹 서버보다 근처의 캐시에서 훨씬 더 빨리 문서를 다운 받을 수 있다. HTTP는, 캐시를 효율적으로 동작하게 하고 캐시된 콘텐츠를 최신 버전으로 유지하면서 동시에 프라이버시도 보호하기 위한 많은 기능을 정의한다.
1-8-3 게이트웨이
•
게이트웨이는 다른 서버들의 중개자로 동작하는 특별한 서버다. 게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다. 게이트웨이는 언제나 스스로가 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다룬다. 클라이언트는 자신이 게이트웨이와 통신하고 있음을 알아채지 못할 것이다.
•
HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP 요청을 받아들인 뒤, FTP 프로토콜을 이용해 문서를 가져온다. 받아온 문서는 HTTP 메시지에 담겨 클라이언트에게 보낸다.
1-8-4 터널
•
터널은 두 커넥션 사이에서 날(raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션이다. HTTP 터널은 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용된다.
•
HTTP 터널을 활용하는 대표적인 예로, 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송함으로써 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 것이 있다.
1-8-5 에이전트
•
사용자 에이전트는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램이다.0
•
웹 요청을 만드는 애플리케이션은 뭐든 HTTP 에이전트다. 지금까지 우리는 한 가지 종류의 HTTP 에이전트, 웹 브라우저에 대해서만 이야기했다. 그러나 사용자 에이전트에는 여러 가지 종류가 더 있다.
•
예를 들어, 사람의 통제 없이 스스로 웹을 돌아다니며 HTTP 트랜잭션을 일으키고 콘텐츠를 받아오는 자동화된 사용자 에이전트가 있다. 이들 자동화된 에이전트는 보통 '스파이더'나 '웹로봇'과 같이 다채로운 이름을 가지고 있다.
