HTTP의 중요성
HTTP는 RFC 2616에서 규정된 프로토콜이다.
현시점에서 최신 버전은 1.1이다.
HTTP(HyperText Transfer Protocol, 문화어: 초본문전송규약, 하이퍼본문전송규약)는 WWW 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로
HTML 문서를 주고받는 데에 쓰인다. TCP와 UDP를 사용하며, 80번 포트를 사용한다. 1996년 버전 1.0, 그리고 1999년 1.1이 각각 발표되었다.
HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 나타나는 것이다.
HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있다.
[출처 - 위키백과]
원래의 HTTP의 이름대로라면 하이퍼텍스트 전송용 프토콜이다. 하지만 실제로는 HTML, XML과 같은 하이퍼텍스트뿐만 아니라 이미지, 음성, 영상등의 컴퓨터에서 다룰 수 있는 데이터라면 무엇이든 전송 가능하다.
특히, HTTP는 REST의 중요한 특징인 유니폼 인터페이스, 스테이트리스 서버, 캐시 등을 구현하고 있는 웹의 기반이 되는 프로토콜이다.
TCP/IP란 ?
HTTP는 TCP/IP를 기반으로 하고 있다. 그러므로 HTTP를 이해하기 위해서 최소한의 TCP/IP 지식이 필요하다.
계층형 프로토콜
Application |
|
Application |
Presentation |
|
|
Session |
|
|
Transport |
|
Transport |
Network |
|
Internet |
Data Link |
|
Network Interface |
Physical |
|
각 계층별로 추상화하여 구현하면 물리적으로 케이블이 동선인지 광케이블인지 하는 하위 계층의 구체적인 사항에 좌우되지 않고, 상위 계층을 구현할 수 있다.
- 네트워크 인터페이스 계층
* 물리적인 케이블이나 네트워크 어댑터에 해당하는 부분이다
- 인터넷 계층
* 네트워크에서 데이터를 실제로 주고받는 부분. TCP/IP에서 IP가 해당된다.
* 기본적인 통신단위를 패킷이라고 부른다.
* 지정한 IP 주소와 패킷 단위로 데이터를 주고 받으면서 통신한다.
- 트랜스포트 계층
* IP가 하지 않았던 데이터의 무결성을 보증하는 역할. TCP/IP에서 TCP가 해당된다.
* TCP는 목적지의 상대에 대해서 커넥션을 연결한다.
* 커넥션을 사용해서 데이터의 누락을 체크하고, 데이터의 도달을 보증한다.
* 접속된 커넥션에서 전송하는 데이터가 어느 어플리케이션으로 전달될지 결정하는 것이 포트번호. (포트 번호는 1~ 65535)
* HTTP의 디폴트는 80번 포트를 사용한다.
[왜 TCP IP가 그런지 구조를 그림으로 보여줘야 될 듯]
- 애플리케이션 계층
* 구체적인 인터넷 애플리케이션 (예를 들어 메일, DNS, HTTP를 실현하는 계층)
* TCP로 프로그램을 만들 때는 소켓이라는 라이브러리르 사용하는 것이 일반적이다.
( 소켓은 네트워크에서의 데이터 교환을 추상화한 API로 접속, 송신, 수신, 절단 등의 기본적인 기능을 갖추고 있다. )
* HTTP의 서버와 브라우저는 소켓을 이용하여 구현한다.
* 대부분의 프로그래밍 언어에는 HTTP를 구현한 라이브러리가 있기 때문에 독자적으로 구현할 필요는 없다.
* 웹 서비스와 웹 API를 개발함에 있어서는 프레임워크의 세세한 동작과 설정, 파라미터 등이 프로토콜 수준에서 어떻게 동작하는지 파악해 둘 필요는 있다.
HTTP의 버전
HTTP의 버전은 크게 3개로 나눌 수 있다.
HTTP 0.9 - HTTP의 탄생
- HTTP 0.9라는 버전의 스펙시트는 존재하지 않는다.
- 버너스리가 1990년에 웹을 발명했을 때 사용하던 프로토콜을 HTTP 0.9 라고 부른다.
요청
GET /index.html
응답
<html>
...
</html>
- HTTP 0.9에는 현재의 HTTP와는 다르게 헤더가 없다.
- HTTP 메서드는 GET만 존재한다.
- HTTP 0.9는 현재 거의 쓰이지 않는다.
HTTP 1.0 - HTTP 최초의 표준화
- 스펙 책정작업이 완료되기 전에 각 회사에서 연달아 기능을 구현했다. (때문에 스펙과 구현의 괴리가 발생한다.)
- 결국, 인터넷 표준이 아니라 Informational(인터넷 전체에 주지가 필요한 정보)로서 공개되었음.
- HTTP 1.0은 헤더의 도입, GET 이외의 메서드를 추가했다.
HTTP 1.1 - HTTP의 완성
- HTTP 1.0의 기능에 더해 채널 전송, Accept 헤더에 의한 콘텐트 네고시에이션, 복잡한 캐시 컨트롤, 지속적 연결 등의 기능이 추가되었다.
그 후의 HTTP
- HTTP 자체의 가치를 REST 아키텍처 스타일에서 찾아낸 결과, HTTP 1.1을 효과적으로 활용하자는 것이 현대적인 개발 스타일이 되었다.
- 10년이 지난 HTTP 1.1 스펙에 관한 오류수정, 참고문헌 개정, 모호함의 배제, 구현 경험에서 나온 어드바이스 추가 등이 예정되어 있다.
클라이언트와 서버
- 웹은 아키텍처 스타일로 클라이언트/서버를 이용함. (즉, 클라이언트가 정보를 제공하는 서버에 접속하여 각종 요청을 보내고 응답을 받는 구조이다.
- RFC 2616에는 클라이언트와 유사한 용어로 유저 에이전트도 등장했다.
- RFC 정의로는 요청을 송신할 목적으로 서버와의 커넥션을 확립하는 프로그램이 클라이언트이고, 서버에 대해 구체적인 요청을 발행하는 것은 유저 에이전트라고 구별하고 있지만, 거의 대부분 큰 차이가 없다.
요청와 응답
- HTTP는 클라이언트와 내보낸 요청을 서버에서 처리하고 응답을 돌려주는 방시긍로 요청/응답형 프로토콜이라고 한다.
- HTTP = 동기형 프로토콜 ( 서버에서의 처리에 시간이 많이 걸리는 경우라도 요청을 보낸 클라이언트는 응답이 돌아올 때까지 대기한다. )
클라이언트에서 일어나는 일들
1. 요청 메시지 구축한다.
2. 요청 메시지 수신한다.
3. (응답이 돌아올 때까지 대기한다.)
4. 응답 메시지 수신한다.
5. 응답 메시지 해석한다.
6. 클라이언트의 목적을 달성하기 위해 필요한 처리한다.
서버에서 일어나는 일들
1. (요청을 대기한다.)
2. 요청 메시지 수신한다.
3. 요청 메시지 해석한다.
4. 적절한 애플리케이션 프로그램으로 처리를 위임한다.
5. 애플리케이션 프로그램으로부터 결과를 취득한다.
6. 응답 메시지 구축한다.
7. 응답 메시지 송신한다.
HTTP 메시지
- HTTP 메시지 = 요청 메시지 + 응답 메시지
요청 메시지
GET /test HTTP/1.1 <-- 요청 라인 (메서드 GET, 요청 URI /test, 프로토콜 버전 HTTP/1.1)
Host: example.com
- 쿼리 파라미터 + URI 프래그먼트가 포함되는 복잡한 URI인 경우
ex) http://example.com:8080/search?q=test&debug=true#n10을 GET하는 경우의 요청 메시지
GET /search?q=test&debug=true#n10 HTTP/1.1
Host:example.com:8080
헤더
- 요청 메시지의 둘째 줄부터는 헤더가 이어진다.
- 헤더는 메시지의 메타 데이터이다.
- 하나의 메시지는 복수의 헤더를 가질 수 있다.
- 각 헤더는 '이름:값'의 구성을 하고 있다.
앞의 예에서는 'Host'라는 이름에 'example.com'라는 값이 연결되어 있는 것을 확인할 수 있다.
바디
- 헤더 뒤에 바디가 오는 경우가 있다.
- 바디에는 그 메시지를 나타내는 본질적인 정보가 들어간다.
- ex) 리소스를 새로 작성하거나 갱신할 때는 요청의 바디부분에 리소스의 표현자체가 들어간다.
응답 메시지
HTTP/1.1 200 OK
Content-Type: application/xhtml+xml: charset=utf-8
<html xmlns="http://www.w3.org/1999/xhtml">
....
</html>
스테이터스 라인
- 응답 메시지의 첫째 줄은 스테이터스 라인이라고 한다.
- 프로토콜 버전(HTTP/1.1), 스테이터스 코드(200), 텍스트 구문(OK)로 구성된다.
헤더
- 응답 메시지의 둘째 줄부터는 요청 메시지와 마찬가지로 헤더이다.
- 이 예에서는 Content-Type 헤더에서 HTML의 MIME 미디어 타입(applcation.xhtml+xml)과 문자 인코딩 방식(utf-8)을 지정하고 있다.
바디
- 응답 메시지에는 바디도 포함되어 있다.
- 헤더와 바디는 빈 줄로 구분한다.
HTTP 메시지의 구성요소
스타트 라인 |
헤더 |
빈 줄 |
바디 |
- 스타트 라인 : 요청 메시지의 경우는 요청 라인, 응답 메시지의 경우는 스테이터스 라인이 된다.
- 헤더 : 헤더 각행의 줄 바꿈은 CRLF이다. 헤더의 종료는 빈 줄로 식별하고, 생략 가능하다.
- 바디 : 텍스트뿐만 아니라, 바이너리 데이터도 들어갈 수 있다. 생략 가능하다.
HTTP 스테이트리스성
- HTTP는 스테이트리스한 프로토콜로 설계되어 있다.
스테이트풀한 대화는 간결하다.
스테이트리스한 대화는 장황하다.
스테이트풀한 대화에서 서버는 클라이언트의 주문 내역을 기억한다.
스테이트리스한 대화에서 클라이언트는 매번 모든 주문을 반복한다.
대표적인 스테이트풀한 프로토콜 - FTP
[ FTP는 클라이언트가 FTP 서버에 로그인해서 로그아웃할 때까지 그 클라이언트가 어느 디렉터리에 있는지와 같은 애플리케이션 상태를 서버가 관리한다.]
스테이트풀의 결점
- 서버가 클라이언트의 애플리케이션 상태를 기억하는 것은 클라이언트의 수가 증가함에 따라 어려워진다.
- 여러 대로 증가할 때, 데이터를 동기화시키는 오버헤드를 무시할 수 없을만큼 커진다.
스테이트리스의 이점
- 위의 결점을 보완했다.
- 요청을 처리하는 데 필요한 정보가 모두 포함되어 있는 메시지를 가리켜 '자기 기술적 메시지'라고 한다.
- 스테이트리스한 아키텍처에서는 서버가 클라이언트의 애플리케이션 상태를 기억하는 대신에 클라이언트가 자신의 애플리케이션 상태를 기억하고 모든 요청을 자기 기술적 메시지로 송신한다.
- 스테이트리스한 서버는 애플리케이션 상태를 기억할 필요가 없기 때문에 서버 시스템이 단순해진다.
- 서버는 새로 오는 요청을 처리하는 데 집중하면 된다.
스테이트리스의 결점
- 퍼포먼스의 저하
- 서버를 스테이트리스로 만들기 위해서는 클라이언트는 매번 필요한 정보를 모두 송신하지 않으면 안된다.
- 따라서 송신할 데이터의 양이 많아지고, 인증 등 서버에 부하가 걸리는 처리를 반복한다.
- 통신 에러에 대한 대처
- 스테이트풀에서 통신의 문제가 생긴다면 계속해서 반복 요청이 가능하다.
- 스테이트리스한 통신에서는 문제가 발생했을 때, 그 요청이 처리되었는지 알 수 없다.
심플한 프로토콜의 이점
- HTTP의 가장 큰 특징은 심플하다.
- HTTP 1.1이 되면서 HTTP 0.9만큼의 심플함은 사라졌지만, 프로토콜을 심플하게 유지하려는 노력은 지속되고있다.
'프로그래밍' 카테고리의 다른 글
| [STL] Vector 정리 (0) | 2017.04.14 |
|---|---|
| STL vector sort(벡터 정렬) (2) (0) | 2017.04.08 |
| STL vector sort(벡터 정렬) (1) (1) | 2017.04.08 |
| STL Vector정리(1) (0) | 2017.04.08 |
| mutable 키워드 (0) | 2017.03.25 |
댓글