1

HTTP 스터디2011-06-08

발표자 : 김연수

HTTP 스터디2011-06-08

발표자 : 김연수

2

Contents Table

Ⅰ. HTTP

1. 등장배경

2. 특징

3. 메시지

4. 헤더필드

5. 상태코드

6. 메소드

7. MIME 과 Multipart

8. 캐시

9. 보안

10. 활용방법

3

Ⅰ. HTTP

1. 등장배경2. 특징3. 메시지4. 헤더필드5. 상태코드6. 메소드7. MIME 과 Multipart

8. 캐시9. 보안10.활용방법

4

1. 등장배경1. 등장배경 I. HTTP I. HTTP

HTTP 란 ?

HTTP(HyperText Transfer Protocol) 는 WWW 상에서 서버와 클라이언트 ( 웹 서버 및 브라우저 ) 간 상호간의 통신을 위한 응용계층 프로토콜이다 . 주로 HTML 문서를 주고 받는 데에 쓰인다 . HTTP 를 통해 전달되는 자료는 http: 로 시작하는 URL( 인터넷 주소 ) 로 조회할 수 있다 .(1996 년 버전 1.0, 1999 년 버전 1.1 등장 )

HTTP 등장 전 HTTP 등장 후

HTTP 등장 전에는 Telnet 을 이용하여 외부 사용자들과 통신을 위해 PC 통신이라는 것을 통해 외부 사용자들과 통신을 했다 .

월드 와이드 웹의 기능인 , 웹 자원의 위치 지정 방법인 URL( 인터넷 주소 ), 웹의 자원에 접근하는 프로토콜 HTTP, 웹 자원들 사이를 쉽게 항해 할 수 있는 언어 HTML 을 통해 많은 사용자는 인터넷을 통해 웹 브라우저로 간단히 세계 각지의 웹사이트에 접속이 가능해졌고 , 이 모든 통신의 핵심엔 프로토콜 HTTP가 있다 .

명령어를 직접 입력해야 하는 유닉스 기반의 서비스여서 , 일반 사용자가 사용하기 불편했다

5

HTTP 의 특징

2. 특징2. 특징 I. HTTP I. HTTP

• 동작형태가 클라이언트 / 서버 모델로 동작 ( 즉 , 요청 / 응답 ) 한다 .

요청 및 응답의 구조

• 비 연결성이며 , 상태를 유지하지 않는 프로토콜이다 .(Connectionless, Stateless)

비 연결 / 무 상태의 프로토콜

• 클라이언트와 서버 간에 HTTP 메시지를 주고 받으며 통신을 한다 .

메시지 교환 형태의 프로토콜

• 하위 수송계층 프로토콜로는 TCP 를 사용하고 , 사용 포트 번호는 80 이다 .

수송계층 프로토콜 및 사용 포트

6

HTTP 메시지

3. 메시지3. 메시지 I. HTTP I. HTTP

Client Server

요청

응답 HTTP 메시지는 클라이언트로 부터 서버로의 요청 및 서버로부터 클라이언트로의 응답으로 구성되어 있다 .

필요하지 않은 경우 생략 가능

• 본문 메시지를 제외한 헤더라인의 구분은 연속된 CR(Carriage Return) 과 LF(Line Feed) 로 한다 .• 본문 메시지엔 보통 HTML 이 들어간다 .

<Request Message> <Response Message>

7

HTTP 메시지

3. 메시지3. 메시지 I. HTTP I. HTTP

<Request Message> <Response Message>

< 요청 / 응답 메시지의 구조 및 예제 >

8

4. 헤더 필드4. 헤더 필드 I. HTTP I. HTTP

HTTP 에서 가장 중요한 것은 Header 에 사용되는 각 필드의 의미와 사용법을 익히는 것이다 . 헤더는 크게 일반 (General) 헤더 , 요청 (Request) 헤더 , 응답 (Response) 헤더 , 엔티티 (Entity) 네가지로 나눌 수 있다 .

Massages Header 설 명 생략여부

General-Header Date현재시간ex)Date: Tue, 15 Nov 1994 GMT

 

  Pragma케시제어ex)Pragma: no-cache

 

  Cache-Control 케시 여부 · 업데이트시간 · 내용 · 지움등  

  Connection연결끊기 -http1.1 은 연결을 지속ex)Connection: close

 

  Transfer-Encoding [entity-body] 의 압축방식  

  Upgrade프로토콜 변경시ex)Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

 

  Via 중계서버 ( 프록시 , 게이트웨이등 ) 의 지원프로토이름 · 버전 · 호스트명  

Entity-Header Allow사용이 허용되는 메소드열거ex)Allow: GET ,HEAD ,OPTIONS ,TRACE

 

  Content-Encoding[entity-body] 의 리소스 압축방식 (gzip, compress, deflate..)ex)Content-Encoding: gzip

 

  Content-Length[entity-body] 의 리소스 크기 ( 바이트 단위 )ex)Content-Length: 3495

X

  Content-Type[entity-body] 의 미디어 타입ex)Content-Type: text/html

 

  expires자원의 만기 날짜 ( 케시데이터 업데이트요구 )ex)Expires: Thu, 01 Dec 1994 GMT

 

  Last-Modified가장 최근에 수정된 날짜ex)Last-Modified: Thu, 01 Dec 1994 GMT

 

  Content-Base[entity-body] 리소스 base-URLex)Content-Base: http://www.isoft.co.kr/

 

  Content-Language[entity-body] 언어정보ex)Content-Language: da

 

  Content-Location [entity-body] 의 URL  X

  Content-MD5 전송시 [entity-body] 의 오류발생검사 -[entity-body] 일부를 요약※ 1(MD5 RFC1864)  

  Content-Range[entity-body] 일부분 전송시의 해당부분 ( 이어받기등에 사용 )ex)Content-Range: bytes 4150-5140/5140

 

  ETag케시 업데이트 정보를 위한 임의의 식별숫자ex)ETag: "0-556-343b9e36"

 

9

4. 헤더 필드4. 헤더 필드 I. HTTP I. HTTP

분 류 Massages Header 설 명 생략여부

Request Requst-Line MethodGET,POST,HEAD  

OPTIONS,PUT,DELETE,TRACE  

    Request-URI요청 데이터의 절대 주소나 상대주소 .ex)http://www.isoft.co.kt/index.html or /test/helloworld.html

 

    HTTP-VersionHTTP" + 0.9∼1.1( 해당 프로토콜 )  

  Request-Header Authorization

사용자 인증정보 - 사용자 ID 와 암호가 함께 Base64 로 인코딩ex)Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

 

    From자원의 생성자나 웹마스터의 전자우편 주소ex)From: psycho@isoft.co.kr

 

    If-Modified-Since

GET 사용시 - 헤더 필드에 지정된 날짜보다 나중 자원만 전달 ( 케시일자검색 )ex)If-Modified-Since: Tue, 15 Nov 1994 GMT

 

    Refer

한페이지에서 다른페이지를 요청할 때 ( 링크시 ) 이전 페이지 주소제공ex)Referer: http://www.w3.org/hypertext/ DataSources/Overview.html

 

    User Agenterbrowser 정보ex)User-Agent: MyWebBroswer/0.5

 

    Accept클라이언트의 사용가능 미디어타입ex)Accept: text/*, text/html, text/html;level=1, */*

 

 (Content Neogotation)

Accept-Charset클라이언트에서 사용할수 있는 문자 집합( 생략시 모두인식 )ex)Accepr: iso-8859-1, unicode-1-1

 

 (Content Neogotation)

Accept-Encoding클라이언트에서 제공되는 인코딩 방법 ( 압축 )ex)Accept-Encoding: compress, gzip

 

10

4. 헤더 필드4. 헤더 필드 I. HTTP I. HTTP

분 류 Massages Header 설 명 생략여부

    Accept-Language

클라이언트가 인식할 수 있는 언어( 우선순위가능 )ex)Accept-Language: da, en-gb;q=0.8, en;q=0.7( 독일어 , 영국영어 , 영어 )

 

    Host서버의 기본 URL ( 하나의 IP 주소에 여러개의 이름을 가진 멀티 서버를 지원 )ex)www.w3.org

X

    If-MatchETag 값 비교 -Method 수행 - (PUT 메소드 : 해당 header 무시 ),다르면 402 에러발생ex)If-Match: "0-556-343b9e36"

 

    If-None-Match

ETag 값 비교 , 다를때 -Method 수행 - (If-Match 와 반대 ),같을 때 에러ex)If-None-Match: "0-556-343b9e36","0-1e4-34367116"

 

    If-Range클라이언트 캐시 정보를 업데이트 정보 (ETag or Date 비교 )

 

    If-Unmodified-Since

헤더값에 지정된 날자로부터 수정이 없는경우 Method 를 수행ex) If-Unmodified-Since: Sat, 29 Oct 1994 GMT

 

    Max-Forwards이 메시지가 거쳐 갈수 있는 최대 Proxy 의 개수를 지정ex)Max-Forwards: 7

 

    Proxy-Authorization비공개 프록시 서버 유저인증을 위한 코드

 

    Range자원의 일부분만 받을때 ( 이어받기기능 ) 받을범위 지정ex)bytes=0-499            : <- 0~499byte 를 얻고자 할 때 .

 

11

4. 헤더 필드4. 헤더 필드 I. HTTP I. HTTP

분 류 Massages Header 설 명 생략여부

Response Status-Line HTTP-Version HTTP" + 0.9∼1.1( 해당 프로토콜 )  

    Status-Code 수신상태코드 -(4Page 의 표참조 .)  

    Respon-Phrase 수신 상태코드에 대한 간략한 설명 -(4Page 의 표참조 .)  

  Response-Header Location 요구한 정보 실제 위치 . 옮겨지거나 다를경우 - 정보주소가 실제 위치 정보 .(redirection,forwording 단 , 절대주소만 가능 .)

 

    Server 서버 프로그램의 이름과 버전 정보ex)Server: Apache/1.3a1

 

    WWW-Authenticate   사용자 인증이 필요한 자원을 요구시 , 필요데이터와 서버가 제공하는 인증 방식ex)WWW-Authenticate: Basic realm=" 아이 소프트 "

 

    Age 요구후 원 서버 (origin Server) 에서 응답생성하지까지의 시간 ( 초단위 )  

    Proxy-Authenticate 서버가 프록시 서버일 경우 유저 인증을 요구하기 위한 헤더이다 .  

    Public서버에서 지원 가능한 Method 의 리스트 ( 제한의 의미는없음 )ex)Public: OPTIONS, MGET, MHEAD, GET, HEAD

 

    Retry-After503 에러시 - 몇초 ( 시간 ) 후에 다시 요구 메시지를 보내라는 정보ex)Retry-After: Fri, 31 Dec 1999 GMT(Time)   Retry-After: 120   (Second)

 

    Warning 상태코드와 응답 구문에 추가적인 경고

12

5. 상태코드5. 상태코드 I. HTTP I. HTTP

1xx: Informational - 요구메시지를 받은 후 연결 중 작업할 때 .

2xx: Success - 요구메시지를 제대로 받았을 때 .

3xx: Redirection - 요구메시지를 수행하기 위해 다른 작업이 필요할 때 .

4xx: Client Error - 요구 메시지의 형식이 틀리거나 빠진 부분이 있을 때 .

5xx: Server Error - 서버에 문제가 있을 때 .

100 Continue200 OK 성공처리

300 Multiple Choices ( 실제 발생하지 않음 )

400 Bad Request 요구가 올바르지 않음

500 Internal Server Error 예기치 못한 서버처리오류

101 Switching Protocols201 Created 요구에따라 새로운자원생성 (PUT)

301 Moved Permanently URL 이 확정적으로 옮겨짐

401 Unauthorized 사용자 인증이 필요

501 Not Implemented 요구에 대한 지원불가 (transfer-Encoding)

 202 Accepted 요구를 이해하였으며 진행중

302 Moved Temporarily URL 이 임시적으로 옮겨짐 402 Payment Require

502 Bad Gateway 게이트웨이 · 프락시의 응답오류

  203 Non-Authoritative Information 303 See Other403 Forbidden 요구는 이해하나 수행거절 (PUT)

503 Service Unavailable 서버부하로 응답불가

 204 No Content 요구자료에 정보가 없음 (empty)

304 Not Modified(If-Modified-Since) 수정날짜에 수정되지 않음

404 Not Found 요구한 파일이 없음 504 Gateway Time-out

  205 Reser Content 305 Use Proxy405 Method Not Allowed 허락된 메소드가 아님

505 HTTP Version not supported ( 요구를 무시할 수 있음 ..??)

  206 Partial Content   406 Not Acceptable  

      407 Proxy Authentication Required  

      408 Request Time-out  

      409 Conflict  

      410 Gone  

      411 Length Required  

      412 Precondition Failed  

      413 Request Entity Too Large  

      414 Request-URI Too Large  

      415 Unsupported Media Type  

HTTP 의 응답헤더의 상태코드에는 다음과 같은 값들이 있다 .

13

6. 메소드6. 메소드 I. HTTP I. HTTP

메소드 설명

HEAD GET 과 같은 요청이지만 , 응답메시지는 [Entity-body] 없이 헤더만 받는다 .- URI 가 유효한지 확인시 사용

GET 요청한 URL 자료를 전송

POST [Entity-body] 를 해당 서버에 전송

PUT 메시지 바디 부분의 데이터를 지정한 요구 URI 이름으로 저장한다 .(FTP 의 PUT과 동일 )

DELETE 서버에서 요구 URI 에 지정된 자원을 지울 수 있다 .

TRACE 요구 메시지가 최종 수신처에 도달 경로를 기록하는 루프백 (loop back) 검사용 ( 클라이언트 의 요구 메시지가 거쳐가는 프록시나 게이트웨이의 중간 경로부터 최종 수신 서버까지의 경로를 알아낼 때 사용 ,  Max-Forwards 헤드 필드에는 중간에 거쳐갈 프록시나 게이트웨이 경로의 최대수를 지정 )

OPTIONS 어떠한 옵션이 있는지 묻는다 .

HTTP 의 요청헤더의 메소드에는 다음과 같은 값들이 존재한다 .

보안 문제로 대부분지원하지 않음

14

6. 메소드6. 메소드 I. HTTP I. HTTP

• 헤더의 Allow 필드에 나오는 항목들이 지원되는 Method 를 의미한다 .

• 모든 Web Server 가 정의된 Method 를 모두 지원하는 것은 아니다 .

• 확장 Method 를 만들어 사용할 수도 있다 .

• HEAD Method 를 사용하면 Web Server 는 GET Method 의 응답 중에 Header 만을 보낸다 .

• 요청하는 URI 의 자원이 실제로 있는지를 확인하는데 주로 사용한다 .

15

6. 메소드6. 메소드 I. HTTP I. HTTP

• Request URI 의 자원을 웹서버에게 보내달라고 요청

• URI 에 파라메터를 전달할 수있고 파라메터가 노출됨 (URI 에 파라메터 표시됨 )

• Request URI 에 파라메터를 보내 , 서버가 파라메터를 처리해 응답하게 한다 . 파라메터가 노출되지 않는다 .(URI 에 파라메터 표시되지 않음 )

16

6. 메소드6. 메소드 I. HTTP I. HTTP

• 요청한 자원이 수신되는 경로를 확인한다

17

7. MIME 과 Multipart7. MIME 과 Multipart I. HTTP I. HTTP

1. MIME(Multipurpose Internet Mail Extension)  의 정의

  - MIME 이란 ' 인터넷 메일 교환을 위한 멀티미디어 문서 타입 ' 이라고 정의 할수 있다 .  - MIME 은 ascii data 만을 처리할 수 있는 원래의 인터넷 전자우편 프로토콜 , 즉 SMTP 를 확장하여 오디오 , 비디오 , 이미지 , 응용프로그램 등 여러가지 종류의 data file 을 주고 받을수 있도록 확장된 프로토콜입니다 .   - 서버들은 웹 전송 시작 부분에 MIME 헤더를 삽입하고 클라이언트들은 이때 파일형식으로서 메일에 추가됩니다 .  - 클라이언트들은 헤더가 나타내는 data 형식에 따라 이를 실행시키기 위한 적절한 응용 프로그램을 선택하여 실행됩니다 .

2. MIME 의 적용

  - HTTP 전송시에 서로 간의 교류 data 를 사전에 정의 해 놓지 않는다면 error page 를 보게 되거나 , ascii 문자들로 표시된 내용밖에 볼 수 없습니다 .  - 이러한 문제를 일으키지 않기위해 Mail 상에서 사용하던 MIME Type 을 Client 와 Server 간의 데이터 Type 을 정하는 것입니다 .  - MIME 의 형식은 'Type/Subtype' 으로 정의 되어 있습니다 .  - 예외 ) 모든 형식을 포함할 경우에는 '*/*' 과 같은 방식으로 해야 합니다 .

18

7. MIME 과 Multipart7. MIME 과 Multipart I. HTTP I. HTTP

3. 주요 MIME type(Header 에서는 Content-type)

19

7. MIME 과 Multipart7. MIME 과 Multipart I. HTTP I. HTTP

4. Multipart - MIME 은 많은 “multipart” 형식을 제공하고 있는데 이는 하나 또는 그 이상의 엔티티를 단일 메시지 본문 내에 포함시킬수 있도록 하는 것이다 .

BodyPart

BodyPart

BodyPart

…

일반적으로 파일 업로드 시 많이 사용하고 이를 이용하게 되면 , POST 방식으로 폼 데이터 ( 여러 파라메터를 담고 있는 ) 와 함께 여러 개의 파일도 같이 업로드 할 수 있다 .

* 여러 개의 파일을 업로드 하기 위해 요청 메시지를 여러 번 보낼 필요 없이 한번의 요청 메시지에 여러 파일들을 Multipart 로 보내면 된다 .

20

8. 캐시8. 캐시 I. HTTP I. HTTP

HTTP 는 전형적으로 응답 캐시를 사용하여 성능을 향상시킨다 .캐시의 목적은 많은 경우에 요구를 발송할 필요를 제거하고 또 다른 많은 경우엔 완전한 응답을 발송할 필요를 제거하는 것이다 .

요구발송감소

응답발송감소

• 많은 운영에서 네트워크의 왕복 여행 숫자를 줄여준다• 만기일 (expiration) 메커니즘을 사용한다 .

• 네트워크 대역폭 요구를 감소시켜 준다• 검증 (validation) 매커니즘을 사용한다 .

캐시의 목적

< 만기일 메커니즘> < 검증 메커니즘>

서버에서 expires 헤더 또는 Cache-Control 헤더의 max-age 지시자를 사용하여 만기시간을 지정한다 .보통 만기일이 될때까지 서버에 요구를 하지 않고 캐시된 문서를 브라우저에 보내게 된다 .지정하지 않을 경우 last-modified 시간과 같은 값을 통해 자동설정 만기시간을 할당한다 .

계속되는 요구로 캐시가 낡은 경우 ( 서버로 부터 응답 경과시간이 오래됐을때 ), 캐시된 엔트리를 아직도 사용할 수 있는지 알아보기 위해 클라이언트는 캐시엔트리를 서버에 검증한다 .이 중 하나의 방식으로는 last-modified 시간이 캐시 값 이후 변경 되지 않았으면 유효한 것으로 간주한다 .

21

9. 보안9. 보안 I. HTTP I. HTTP

일반적인 HTTP 의 경우 아래 그림에서와 같이 , 패킷이 모두 암호화되지 않고 그대로 전송되므로 중간에서 메시지를 가로챌 경우 모든 정보가 무방비로 노출 될 수 있다 .그러나 HTTPS 를 이용하면 서버와 브라우져가 데이터를 내보내기 전에 모든 트래픽을 암호화하여 통신하게 된다 .

HTTPS = HTTP + SSL

SSL(Secure Sockets Layer)

SSL 은 네트웍 내에서 메시지 전송의 안전을 관리하기 위해 넷스케이프에 의해 만들어진 프로그램 계층이다 . 비밀이 보장되어야 하는 메시지를 맡은 프로그램은 웹 브라우저 또는 HTTP 와 같은 응용프로그램과 , 인터넷의 TCP/IP 계층 사이에 들어간다 .HTTP 뿐만 아니라 FTP 등에도 사용할 수 있다 .

IETF(Internet Enginierring Task Force) 에서는 웹 브라우저와 서버를 위한 표준 보안 접근방법으로 제시하였다 .

* IETF : TCP/IP 와 같은 인터넷 운영 프로토콜의 표준을 정의하는 주체

22

9. 보안9. 보안 I. HTTP I. HTTP

HTTPS Flow

< 인증서 예제 >

23

10. 활용방법10. 활용방법 I. HTTP I. HTTP

• 일반적으로 HTTP 는 웹 서버와 클라이언트 ( 웹 브라우져 ) 간에 웹 페이지 및 이미지나 각종 미디어를 전송하는 역할을 한다 .

WebServerHTTP

• 그러나 HTTP 프로토콜을 그대로 이용하며 , XML 또는 SOAP 으로 통신하는 연동방식의 웹 서비스도 제공할 수 있다 .• 서로 원격의 객체 ( 데이터 ) 를 XML 로 변환하여 주고 받는다 .• Open API 의 서비스의 경우도 모두 HTTP 프로토콜을 이용한다 .(Open API : 서비스의 API 를 개방 , 공유함으로써 사용자 참여를

유도함 )

위 처럼 HTTP 의 [Entity-body] 영역에 XML 을 주고 받아 통신하거나 또는 좌측처럼 구성된 SOAP 메시지를 클라이언트와 서버가 주고 받는 통신을 하게 웹 서비스 환경을 구축할 수 있다 .

• HTTP 프로토콜의 모든 장점을 그대로 이용하면서 , 확장이 뛰어난 XML 메시지를 주고 받는다 .

• RPC 통신을 한다 .• 플랫폼 독립적이다 .

RPC(Remote Procedure Call) – 원격의 프로시져 ( 서브 프로그램 ) 호출 (URI 또는 파라메터로 구분 할 수 있다 )

24

감사합니다 .