사내 세미나 - HTTP 발표자료 (2011. 06. 03)

1. HTTP 스터디
2011-06-08
발표자 : 김연수
1

2. Contents Table
Ⅰ. HTTP
1. 등장배경
2. 특징
3. 메시지
4. 헤더필드
5. 상태코드
6. 메소드
7. MIME과 Multipart
8. 캐시
9. 보안
10. 활용방법
2

3. Ⅰ. HTTP
1. 등장배경
2. 특징
3. 메시지
4. 헤더필드
5. 상태코드
6. 메소드
7. MIME 과 Multipart
8. 캐시
9. 보안
10. 활용방법
3

4. 1. 등장배경
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가 있다.
명령어를 직접 입력해야 하는 유닉스 기반의 서
비스여서, 일반 사용자가 사용하기 불편했다
4

5. 2. 특징
I. HTTP
HTTP의 특징
요청 및 응답의 구조
• 동작형태가 클라이언트/서버 모델로 동작(즉, 요청/응답)한다.
비 연결/무 상태의 프로토콜
• 비 연결성이며, 상태를 유지하지 않는 프로토콜이다.(Connectionless,
Stateless)
메시지 교환 형태의 프로토콜
• 클라이언트와 서버 간에 HTTP 메시지를 주고 받으며 통신을 한다.
수송계층 프로토콜 및 사용 포트
• 하위 수송계층 프로토콜로는 TCP를 사용하고, 사용 포트 번호는 80이다.
5

6. 3. 메시지
I. HTTP
HTTP 메시지
요청
Client
응답
Server
HTTP 메시지는 클라이언트로 부터 서버로의 요청 및 서버로부터 클라이
언트로의 응답으로 구성되어 있다.
필요하지 않은 경우 생략 가능
• 본문 메시지를 제외한 헤더라인의 구분은 연속된 CR(Carriage Return) 과 LF(Line Feed)로 한다.
• 본문 메시지엔 보통 HTML이 들어간다.
6

7. 3. 메시지
I. HTTP
HTTP 메시지
<요청/응답 메시지의 구조 및 예제>
7

8. 4. 헤더 필드
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
중계서버(프록시,게이트웨이등)의 지원프로토이름·버전·호스트명
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
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-URL
ex)Content-Base: http://www.isoft.co.kr/
Content-Language
[entity-body]언어정보
ex)Content-Language: da
Content-Location
[entity-body]의 URL
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"
Entity-Header
명
생략여부
X
X
8

9. 4. 헤더 필드
I. HTTP
분류
Massages
Header
Request
Requst-Line
Method
설
명
생략여부
GET,POST,HEAD
OPTIONS,PUT,DELETE,TRACE
Request-URI
요청 데이터의 절대 주소나 상대주소.
ex)http://www.isoft.co.kt/
index.html or /test/helloworld.html
HTTP-Version
HTTP" + 0.9∼1.1
(해당 프로토콜)
Authorization
사용자 인증정보 - 사용자 ID와 암호가 함께
Base64로 인코딩
ex)Authorization: Basic QWxhZGRpbjpvcGVuIHN
lc2FtZQ==
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 Agenter
browser 정보
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
Request-Header
9

10. 4. 헤더 필드
분류
Massages
I. HTTP
Header
설
명
생략여부
Accept-Language
클라이언트가 인식할 수 있는 언어
(우선순위가능)
ex)Accept-Language:
da, en-gb;
q=0.8,
en;q=0.7(독일어,
영국영어, 영어)
Host
서버의 기본URL (하나의 IP주소에 여러개의 이름을 가진 멀티 서버를 지원)
ex)www.w3.org
If-Match
ETag값 비교-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를
얻고자 할 때.
10
X

11. 4. 헤더 필드
I. HTTP
분류
Massages
Header
설
Response
Status-Line
HTTP-Version
HTTP" + 0.9∼1.1(해당 프로토콜)
Status-Code
수신상태코드-(4Page의 표참조.)
Respon-Phrase
수신 상태코드에 대한 간략한 설명-(4Page의 표참조.)
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-After
503 에러시 -몇초(시간)후에 다시 요구 메시지를 보내라는 정보
ex)Retry-After: Fri, 31 Dec 1999 GMT(Time)
Retry-After: 120 (Second)
Warning
상태코드와 응답 구문에 추가적인 경고
Response-Header
명
생략여부
11

12. 5. 상태코드
I. HTTP
HTTP의 응답헤더의 상태코드에는 다음과 같은 값들이 있다.
1xx: Informational 요구메시지를 받은 후
연결 중 작업할 때.
2xx: Success 요구메시지를 제대로 받았을 때.
3xx: Redirection 요구메시지를 수행하기 위해
다른 작업이 필요할 때.
4xx: Client Error 요구 메시지의 형식이 틀리거나
빠진 부분이 있을 때.
5xx: Server Error 서버에 문제가 있을 때.
100 Continue
200 OK
성공처리
300 Multiple Choices
(실제 발생하지 않음)
400 Bad Request
요구가 올바르지 않음
500 Internal Server Error
예기치 못한 서버처리오류
101 Switching Protocols
201 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 Other
403 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 Proxy
405 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
12

13. 6. 메소드
I. HTTP
HTTP의 요청헤더의 메소드에는 다음과 같은 값들이 존재한다.
메소드
설명
HEAD
GET과 같은 요청이지만, 응답메시지는 [Entity-body]없이 헤더만 받는다.
- URI가 유효한지 확인시 사용
GET
요청한 URL 자료를 전송
POST
[Entity-body]를 해당 서버에 전송
PUT
메시지 바디 부분의 데이터를 지정한 요구 URI이름으로 저장한다.(FTP의 PUT과
동일)
보안 문제로 대부분
지원하지 않음
DELETE
서버에서 요구 URI에 지정된 자원을 지울 수 있다.
TRACE
요구 메시지가 최종 수신처에 도달 경로를 기록하는 루프백(loop back) 검사용 (클
라이언트 의 요구 메시지가 거쳐가는 프록시나 게이트웨이의 중간 경로부터 최종
수신 서버까지의 경로를 알아낼 때 사용, Max-Forwards 헤드 필드에는 중간에 거쳐
갈 프록시나 게이트웨이 경로의 최대수를 지정)
OPTIONS
어떠한 옵션이 있는지 묻는다.
13

14. 6. 메소드
•
•
•
헤더의 Allow 필드에 나오는 항목들이 지원되는
Method를 의미한다.
모든 Web Server가 정의된 Method를 모두 지원하는
것은 아니다.
확장 Method를 만들어 사용할 수도 있다.
I. HTTP
•
•
14
HEAD Method를 사용하면 Web Server는 GET Method의
응답 중에 Header만을 보낸다.
요청하는 URI의 자원이 실제로 있는지를 확인하는데 주
로 사용한다.

15. 6. 메소드
•
•
Request URI의 자원을 웹서버에게 보내달라고 요청
URI에 파라메터를 전달할 수있고 파라메터가 노출됨
(URI에 파라메터 표시됨)
I. HTTP
•
15
Request URI에 파라메터를 보내, 서버가 파라메터를 처
리해 응답하게 한다. 파라메터가 노출되지 않는다.(URI에
파라메터 표시되지 않음)

16. 6. 메소드
•
I. HTTP
요청한 자원이 수신되는 경로를 확인한다
16

17. 7. MIME 과 Multipart
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' 으로 정의 되어 있습니다.
- 예외) 모든 형식을 포함할 경우에는 '*/*' 과 같은 방식으로 해야 합니다.
17

18. 7. MIME 과 Multipart
I. HTTP
3. 주요 MIME type(Header에서는 Content-type)
18

19. 7. MIME 과 Multipart
I. HTTP
4. Multipart
- MIME은 많은 “multipart” 형식을 제공하고 있는데 이는 하나 또는 그 이상의 엔티티를 단일 메시지 본
문 내에 포함시킬수 있도록 하는 것이다.
BodyPart
BodyPart
BodyPart
…
일반적으로 파일 업로드 시 많이 사용하고 이를 이용하게 되면, POST 방식으로 폼 데이터(여러 파라메터
를 담고 있는)와 함께 여러 개의 파일도 같이 업로드 할 수 있다.
* 여러 개의 파일을 업로드 하기 위해 요청 메시지를 여러 번 보낼 필요 없이 한번의 요청 메시지에 여러
파일들을 Multipart로 보내면 된다.
19

20. 8. 캐시
I. HTTP
HTTP는 전형적으로 응답 캐시를 사용하여 성능을 향상시킨다.
캐시의 목적은 많은 경우에 요구를 발송할 필요를 제거하고 또 다른 많은 경우엔 완전한 응답을 발송할 필요를 제거하는 것이다.
캐시의 목적
요구발송감소
• 많은 운영에서 네트워크의 왕복 여행 숫자를 줄여준다
응답발송감소
• 네트워크 대역폭 요구를 감소시켜 준다
• 만기일(expiration) 메커니즘을 사용한다.
• 검증(validation) 매커니즘을 사용한다.
서버에서 expires 헤더 또는 Cache-Control 헤더의
max-age 지시자를 사용하여 만기시간을 지정한다.
보통 만기일이 될때까지 서버에 요구를 하지 않고
캐시된 문서를 브라우저에 보내게 된다.
지정하지 않을 경우 last-modified 시간과 같은 값
을 통해 자동설정 만기시간을 할당한다.
계속되는 요구로 캐시가 낡은 경우(서버로 부터 응
답 경과시간이 오래됐을때), 캐시된 엔트리를 아직
도 사용할 수 있는지 알아보기 위해 클라이언트는
캐시엔트리를 서버에 검증한다.
이 중 하나의 방식으로는 last-modified 시간이 캐시
값 이후 변경 되지 않았으면 유효한 것으로 간주한
다.
<만기일 메커니즘>
<검증 메커니즘>
20

21. 9. 보안
I. HTTP
일반적인 HTTP의 경우 아래 그림에서와 같이, 패킷이 모두 암호화되지 않고 그대로 전송되므로 중간에서 메시지를 가로챌 경우 모든 정보
가 무방비로 노출 될 수 있다.
그러나 HTTPS를 이용하면 서버와 브라우져가 데이터를 내보내기 전에 모든 트래픽을 암호화하여 통신하게 된다.
SSL은 네트웍 내에서 메시지 전송의 안전을 관리하기 위해 넷스케이프에 의해 만들어진 프로그램 계층이다. 비밀이 보장되어야 하는 메
시지를 맡은 프로그램은 웹 브라우저 또는 HTTP와 같은 응용프로그램과, 인터넷의 TCP/IP 계층 사이에 들어간다.
HTTP 뿐만 아니라 FTP 등에도 사용할 수 있다.
IETF(Internet Enginierring Task Force)에서는 웹 브라우저와 서버를 위한 표준 보안 접근방법으로 제시하였다.
* IETF : TCP/IP와 같은 인터넷 운영 프로토콜의 표준을 정의하는 주체
21

22. 9. 보안
I. HTTP
<인증서 예제>
22

23. 10. 활용방법
I. HTTP
• 일반적으로 HTTP는 웹 서버와 클라이언트(웹 브라우져) 간에 웹 페이지 및 이미지나 각종 미디어를 전송하는 역할을 한다.
Web
Server
HTTP
• 그러나 HTTP 프로토콜을 그대로 이용하며, XML 또는 SOAP으로 통신하는 연동방식의 웹 서비스도 제공할 수 있다.
• 서로 원격의 객체(데이터)를 XML로 변환하여 주고 받는다.
• Open API 의 서비스의 경우도 모두 HTTP 프로토콜을 이용한다.(Open API : 서비스의 API를 개방, 공유함으로써 사용자 참여를 유도함)
위 처럼 HTTP의 [Entity-body] 영역에 XML을 주고 받아 통신하거나 또는 좌측처럼 구성된
SOAP 메시지를 클라이언트와 서버가 주고 받는 통신을 하게 웹 서비스 환경을 구축할 수 있다.
•
•
•
HTTP 프로토콜의 모든 장점을 그대로 이용하면서, 확장이 뛰어난 XML 메시지를 주고 받는
다.
RPC 통신을 한다.
플랫폼 독립적이다.
RPC(Remote Procedure Call) – 원격의 프로시져(서브 프로그램) 호출(URI 또는 파라메터로 구
분 할 수 있다)
23

24. 감사합니다.
24