HTTP 프로토콜 개요, 특징

HTTP 프로토콜 개요

HyperText Transfer Protocol

분산환경 및 공동작업 환경에 이용할 하이퍼미디어 정보시스템의 개발을 목적으로 설계된 응용 계층의 프로토콜

요청/응답 (request/response, i.e., stateless) 동작에 기반하여 서비스를 제공

1989년 팀 버너스 리(Tim Berners Lee)에 의하여 처음 설계

http의 첫번째 버전은 인터넷을 통하여 가공되지 않은 단순 데이터를 전송하기 위한 단순한 프로토콜로 시작

1. 브라우저는 서버 호스트에 접속
   q URL에 명시된 서버(인터네트 주소:포트번호)에 연결
   q default 포트 번호 : 80
   
2. 브라우저는 요청 메시지(request message)를 생성하여 전송
   
3. 서버는 브라우저의 요청 메시지에 대한 응답메시지(response message)를 전송
   q 응답헤더에는 성공/실패여부, 전송될 데이타타입(텍스트, 이미지, 동영상 등)으로 구성
   q 응답헤더에 이어 실제 데이타를 전송
   
4. 서버는 응답을 보낸 직후 강제로 접속 종료

단, HTTP 1.1의 경우에는 문서에 이미지가 존재할 경우 텍스트를 받고나서 연결을 종료하지 않고 연결을 유지한 상태에서 이미지 요청패킷을 전송하므로 HTTP 1.0과 같이 8 Step에 걸쳐서 작업완료를 하는게 아니라 6 Step으로 작업을 완료하게 됩니다. 또한, 처음의 로딩은 딜레이가 크지만 문서 내에 이미지나 오브젝트가 많이 존재할수록 그 수행성능은 더욱 더 향상 됩니다.

HTTP 트랜잭션의 특징

연결 당 하나의 트랜잭션을 수행한다.

q 하나의 URL을 이용하여 접속할 때 하나의 트랜잭션을 수행한다.

q 이미지 당 하나의 트랜잭션을 수행한다. 10개의 <img>태그를 가진 html 문서를 출력하기 위해 11번의 트랜잭션을 수행

각 트랜잭션들은 상호 무관(independent)하다.

q 트랜잭션은 stateless의 특징을 가진다. 즉 이전 트랜잭션의 상황을 기억하지 않는다.

스타트라인(Start Line)

q HTTP 메시지의 기본적 기능을 포함

q 요청 메시지 : 요구사항에 대한 정보

q 응답 메시지 : 응답할 내용의 상태

메시지헤더(Message Header)

q HTTP 메시지의 부가적인 정보를 포함

q 날짜, 프로그램 이름과 버전정보, 쿠키와 캐시에 대한 정보

q 헤더의 구성 : "[헤더이름:헤더정보]+CRLF" 형태

헤더의 종류

q 일반 헤더 (General Header) : 클라이언트 서버 HTTP 관련된 정보

q 요청 헤더 (Request Header) : 선호하는 문서 형식과 서버 파라미터들

q 응답 헤더 (Response Header) : 응답을 보내는 서버에 관한 정보

q 객체헤더 (Entity Header) : 클라이언트와 서버간에 전달되는 데이터에 관한 정보

메시지바디(Message Body)

q 요청이나 응답에 필요한 데이터 내용 기술

q 요청메시지의 CGI, Servlet 요청 데이터

q 응답메시지의 HTML문서

클라이언트 요청 과정

1. 클라이언트는 지정된 포트(웹서버 기본 포트: 80)로 서버와 접촉
   [예] telnet://192.168.0.88:80
   
2. METHOD라는 HTTP 명령어를 지정함으로써 문서요청(request)을 요청메소드, URI, 프로토콜 형식의 순서로 전송
   [예] GET /test.html HTTP/1.0
   
3. 클라이언트는 서버에게 옵션 헤더 정보를 보내 자신의 구성과 받아들일 수 있는 문서 형식을 알린다.
   [예] Connection : Keep_Alive
   Use_Agent : Mozilla/4.03
   Accept : */* (모든 미디어 타입과 서브타입을 명시)
   If-Modified-Since : Tue, 15 Nov 1998 12:45 GMT
   
4. 요청에서 헤더를 보내기 전에 클라이언트는 부가적인 데이터를 보낼 수도 있다.
   [예] GET /servlet/DefaultServlet?name=Exam&version=1 HTTP/1.0
   
5. 헤더 정보 다음에 빈칸(CR LF)으로 요청을 마치는 표시를 보낸다.

서버의 응답 과정

1. 서버는 필드 3개(HTTP 버전,상태코드,설명)로 구성된 스타트 라인으로 응답한다.
   [예] HTTP/1.0 200 OK
   서버가 응답할 때 HTTP버전 1.0을 사용한다는 의미이고 상태코드 200은 클라이언트 요청이 성공적으로 받아들여 졌다는 의미이다.
   
2. 스타트라인 뒤에 서버 자체와 요청문서에 대한 헤더 정보를 클라이언트에게 보낸다.
   [예] Date : Tue, 15 Nov 1998 15:45 GMT
   Server : Microsoft IIS/2.0
   Last-modified : Tue, 15 Nov 1998 12:45 GMT
   Content-type : text/html
   Content-length : 1200
   
3. 클라이언트 요청이 성공적이었으면 요청된 데이터가 전송
   
<span style='font-family: "나눔고딕",NanumGothic,Sans-serif;'> < /span>
4. 거절된 경우 왜 거절되었는지를 클라이언트가 읽을 수 있는 형태의 메시지를 응답
   
5. 서버가 요청된 데이터를 전송 후 연결을 종료
   
6. Connection:Keep-Alive 헤더가 기술된 경우에는 연결을 계속 유지

메소드

q 메소드는 서버에게 클라이언트 요청의 목적을 알린다.

q HTTP에서 정의된 주요 메소드
GET, POST, HEAD, PUT, DELETE, LINK, UNLINK

GET 메소드

q GET은 서버의 지정한 URI에 위치한 정보를 요청

• 요청 URI에서 어떤 실행 프로그램(CGI,Servlet)을 명시할 경우 실행 결과가 응답 메시지로 전달

• 서버가 에러나 승인 결함으로 요청을 처리할 수 없는 경우엔 일반적으로 응답 메시지에 에러 원인 표시

q 클라이언트 요청
GET /default.html HTTP/1.0
Connection : Keep_Alive
Use_Agent : Mozilla/4.03
Accept : */* (모든 미디어 타입과 서브타입을 명시)
If-Modified-Since : Tue, 15 Nov 1998 12:45 GMT

q 서버 응답
HTTP/1.0 200 Documents follows
Date : Tue, 15 Nov 1998 15:45 GMT
Server : Microsoft IIS/2.0
Last-modified : Tue, 15 Nov 1998 12:45 GMT Content-type : text/html
Content-length : 1200
CR LF(빈칸)
문서의 본체(Entity-Body) : 응답할 문서의 내용

HEAD 메소드

q 헤더 정보만 서버에 요구하는 명령

• 기능상 GET과 동일하나 서버가 응답의 데이터 부분에 아무것도 보내지 않는다는 점이 다르다.

• 클라이언트가 서버의 정보(존재 여부, 권한, 최근 수정 정보)를 찾고 싶으나, 문서 자체를 받을 필요가 없을 때에 사용

• 클라이언트는 다음과 같은 정보를 요구할 수 있다.

• 캐시 관련 질의에 유용한 문서 수정시간

• 페이지 레이아웃이나 문서의 도착시간 측정, 문서의 크기

• 클라이언트가 특정 타입의 문서만 검색할 수 있도록 해주는 문서의 타입

• 주문형 서버 질의를 가능하게 하는 서버의 타입

POST 메소드

q 데이터를 메시지 바디에 포함하여 입출력 스트림을 통해 처리한다.

• GET 메소드와는 달리 데이터의 크기에 제한이 없다.

• GET 메소드와 같이 데이터를 인코딩하지만 인코딩한 데이터를 스트림으로 보낸다.
=> 데이터를 메시지 바디 부분에 기술

• 폼으로부터 POST 메소드를 이용한 클라이언트 요청
POST /servlet/search.class HTTP/1.0
Connection : Keep_Alive
Use_Agent : Mozilla/4.03
Accept : */*
Content-type : application / x-www-form-urlencoded Content-length : 20
CR LF(빈칸)
name=servlet&option=서버

q OPTIONS

• Request-URI에 의해 지정되는 자원에 대한 요청/응답의 관계에 있어 통신과 관련된 선택 사항들에 대한 정보를 요청할 때 사용

• 서버 기능 조사 시에도 사용

q PUT

• 메시지에 포함되어 있는 데이타를 지정한 Request-URI 의 이름으로 저장

• FTP의 PUT 명령과 동일

q DELETE

• Request-URI에 지정되어 있는 자원을 서버에서 제거

q LINK

• 헤더 정보가 서버내의 문서와 연결되도록 요청

q UNLINK

• 헤더 정보와 서버내의 문서와 이 연결을 해제하도록 요청

q TRACE

• 요구 메시지의 최종 수신처까지의 루프백 검사용으로 사용. 즉, 클라이언트가 보내는 요구 메시지가 거쳐가는 프락시나 게이트웨이의 중간 경로 및 최종 수신 서버까지 이르는 경로를 알아내는 데에 사용

• 함께 사용되는 헤더 필드는 Max-Forwards 이며, 중간에 거쳐갈 프락시나 게이트웨이 경로의 최대 숫자를 지정

서버 응답코드

q HTTP 서버 응답의 첫번째 행

• 클라이언트 요청의 성공 여부와 그에 대한 이유를 표시

• 상태는 숫자 3개로 된 서버 응답 코드와 설명 메시지 표시

인코딩/디코딩

q 인코딩(encoding)

• '바이너리 데이터' 을 '텍스트' 로 변환

• 반대는 디코딩(decoding)

q UUEncode (Unix-to-Unix Encode) 방식 예

• 임의의 바이너리 3바이트
10011100, 00110011, 11110000

• 6 비트짜리 4 개로 분할
100111 , 000011 , 001111, 110000

• 첫 두자리에 0 을 붙임
00100111 , 00000011 , 00001111 , 00110000

• 십진수 32 (이진수 100000) 더함
01100111 , 01000011 , 01001111 , 01110000
=> 첫비트가 0인 아스키문자처럼 취급

 

 

[출처] http://blog.naver.com/kentsung/140088321294

[출처] [인터넷/웹] HTTP 프로토콜 개요, 특징|작성자 주한길