HTTP 프로토콜

● HTTP란?
. html 문서의 송수신 위해서 사용하는 프로토콜
. 웹 URL 공간의 자원들을 지원하기 위해서 TCP/IP 위에서 실행되는 프로토콜
. HTTP는 C/S 시스템의 일종이지만 Stateless
. TCP/IP상의 RPC의 일종
. 클라이언트는 URL을 이용하여 서버에 요청하고, 서버는 요청을 처리한후에 연걸을 잊어버림

● HTTP 메세지 기본
. 클라이언트가 서버에 접속해서 Request를 보내고 Response를 받음
. 동기형 프로토콜: 서버에서 응답올때까지 대기함



● HTTP Request 메시지

• 요청 라인 : Request 메시지의 첫번째 줄

- http://example.com/test 에 대한 최소한의 요청은 아래와 같다.

- 복잡한 URI에도 요청라인은 동일

- 절대 URI 요청의 경우 Host 헤더 생략가능

• 두번째줄 부터는 복수개의 Header 가 이어짐

- “이름: 값” 형태의 구성 → Host: example.com , User-Agent: Mozilla/5.0

• 요청메시지에도 헤더뒤에 Body 가 오는 경우가 있음

- POST,PUT 같은 메소드를 통해 리소스를 작성하거나 갱신할 때

● HTTP Response 메시지

• Status Line : 응답메시지의 첫줄

- 스테이터스 코드로 결과의 상태를 표현

- 프로그램에서 이 코드를 통해 상태 파악

• Request 와 같이 두번째줄 부터는 복수개의 Header 가 이어짐

- Content-Type 헤더를 통해 MIME 미디어 타입 (text/html)과 문자인코딩 타입(utf-8)을 전송

- Content-Length 헤더를 통해 이어지는 Body 의 크기를 알려줌

• Body 에 실제 문서데이터가 포함

- 헤더와 바디는 빈줄 ( CRLF ) 로 구분- HTML 또는 다양한 문서형식 가능

● HTTP 메시지의 구성

4. HTTP Method

● Method별 용도와 의미

• HTTP 1.1 에 정의된 메쏘드는 단 8개, 그중에서도 5~6개만 사용

Method	용도	의미
GET	Read	리소스 취득
POST	Create	서브 리소스의 작성, 리소스 데이터의 추가, 그 밖의 처리
PUT	Update	리소스 갱신, 리소스 작성
DELETE	Delete	리소스 삭제
HEAD		리소스의 헤더(메타 데이터) 취득
OPTIONS		리소스가 서포트하는 메소드의 취득
TRACE		자기 앞으로 요청 메시지를 반환(루프 백) 시험
CONNECT		프록시 동작의 터널 접속으로 변경

● GET (Read)

• 지정한 URI 정보 가져오기.
• 브라우저의 기본 동작. 가장 이용 빈도가 높음

● POST (Create)

• 리소스의 작성 : 새로 생성된 리소스의 URI가 Location 에 리턴

• 다른 메소드로는 대응할 수 없는 처리

▶ 요청하는 URI 가 매우 길어서 처리가 불가능할 경우 ( URI가 2000자가 넘거나.. )

▶ http://example.com/search?q={엄청엄청긴 검색 문자열}

● PUT (Update)

• 리소스의 갱신

• PUT을 POST 와 마찬가지로 자료의 생성에 쓸수도 있지만, 가능하면 POST/PUT을 분리하여 Create / Update 로 쓰는것이 바람직 하다.

● DELETE (Delete)

• 리소스 삭제

● HEAD

• 리소스의 헤더만 취득

• 바디가 포함되지 않아 네트워크 대역을 절약하면서 리소스의 크기 조사 및 갱신일자 취득이 가능

● OPTIONS

• 리소스가 지원하는 메서드의 취득

● GET/POST

• 현실적으로 가장 많이 이용되는 것은 GET/POST

- HTML의 Form 에서 지정할수 있는 메서드가 오직 GET/POST 이기 때문

- AJAX 에서는 XMLHTTPRequest 를 이용하여 임의의 메서드 사용가능

• POST 로 PUT/DELETE 를 대신하는 방법

- _method 파라미터 활용

- X-HTTP-Method-Override

● 멱등성과 안정성

• 통신 에러에 대처하기 위한 HTTP 의 대안

- 멱등성 ( Idempotence ) : 어떤 조작을 몇번 반복해도 결과가 동일한 것

- 안전 ( Safe ) : 조작 대상의 리소스의 상태를 변화시키지 않는것

Method	성질
GET, HEAD	멱등이고 안전하다
PUT, DELETE	멱등이지만 안전하지 않다
POST	멱등이지도 안전하지도 않다

1. GET의 경우 리소스는 안전하지만, 서버의 로그파일에 기록되고, 히트카운터가 변경이 된다.
2. 쇼핑몰에서 “뒤로” 버튼 눌렀을대 “다시 전송하시겠습니까?” 를 묻는것은 POST 재전송 때문
3. GET 의 URI 에 action=delete 와 같은 방식으로 쓰거나 하는 방식의 오용은 금물

5. HTTP Status Code

• 웹을 사용하면서 이미 404, 500 과 같은 HTTP 상태코드를 많이 보아 왔다.

-https://github.com/404 , http://huml.org/404 , http://ifolderlinks.ru/404

• 상태코드의 분류와 의미

코드	분류	의미
1xx	처리중	처리가 계속되고 있음. 클라이언트는 요청을 계속하거나, 서버의 지시에 따라 프로토콜 업데이트 후 재전송
2xx	성공	요청이 성공했음을 나타냄
3xx	리다이렉트	다른 리소스로의 리다이렉트. 클라이언트는 이 코드를 받았을 때 응답메시지의 Location 헤더를 보고 새 리소스에 접근
4xx	클라이언트 에러	클라이언트의 요청이 에러의 원인. 클라이언트쪽에서 요청을 수정해서 재 전송해야 한다.
5xx	서버 에러	서버가 에러의 원인. 서버측에서 원인이 해결되면, 동일한 요청을 보내어 정상적인 결과를 얻을 가능성이 있다.

• 자주 사용되는 상태코드

상태코드 및 텍스트	의미	비고
200 OK	요청성공
201 Created	리소스 작성 성공	Location 헤더에 새 URI
301 Moved Permanently	리소스가 새 URI로 이동했음	Location 헤더에 새 URI
303 See Other	다른 URI 참조	-
400 Bad Request	요청 구문이나 파라미터에 오류	-
401 Unauthorized	접근 권한 없음, 인증실패	WWW-Authenticate 헤더
404 Not Found	리소스 없음	-
500 Internal Server Error	서버 내부 에러	-
503 Service Unavailable	서버가 점검등으로 일시적 정지	Retry-After 헤더에 재개시간

• 하지만, 전체적으로 상태코드를 알고 정확하게 사용할 것

6. HTTP Header

• HTTP 0.9에는 헤더가 없었고,1.0때 메일스펙(RFC822)에서 형식빌려옴

● 날짜와 시간

● MIME 미디어 타입( Multipurpose Internet Mail Extensions )

• Content-Type : type/subtype 형태로 미디어타입을 지정하는 헤더

- application/xhtml+xml;charset=utf-8 : type = application , subtype = xhtml+xml

- charset 파라미터로 문자 인코딩 지정가능

타입	의미	예
text	사람이 읽고 직접 이해할수 있는 텍스트	text/plain
image	image 그림 데이터	image/jpeg
audio	음성 데이터	audio/mpeg
video	동영상 데이터	video/mp4
application	그 밖의 데이터	application/pdf
multipart	복수개의 데이터로 이루어진 복합 데이터	multipart/related
message	전자메일 메시지	message/rfc822
model	복수 차원으로 구성하는 모델 데이터	model/vrml
example	예시용	example/foo-bar

● MIME 주요 서브 타입

타입/서브타입	의미
text/plain	플레인 텍스트
text/csv CSV	형식 텍스트 ( Comma Separated Values )
text/css CSS	형식의 스타일시트
text/html	HTML 문서
text/xml	XML 문서(비추천)
image/jpeg	JPEG 이미지
image/png PNG	이미지
application/xml	XML 문서
application/xhtml+xml	XHTML 문서
application/javascript	Javascript 파일
application/json	JSON 문서 ( Javascript Object Notation )
application/msword	Word
application/vnc.ms-excel	Excel
application/pdf	PDF
application/zip	ZIP
application/x-shockwave-flash	Flash 오브젝트
application/x-www-form-urlencoded	HTML 폼 형식

● Content Negotiation : 내용 교섭

• Accept - 클라이언트가 자신이 처리할수 있는 미디어 타입을 전달

- Accept: text/html, application/xhtml+xml, application/xml;q=0.9,*/*;q=0.8

- qvalue 는 0~1 의 값을 가지며, 디폴트 값은 1
- 서버가 해당 포맷들중에 대응가능한게 없다면 406 Not Acceptable 코드를 리턴

• Accept-Charset - 클라이언트가 자신이 처리할수 있는 문자 인코딩을 전달

- Accept-Charset: EUC-KR;utf-8;q=0.7,*/*;q=0.7

• Accept-Language - 처리할수 있는 언어를 전달

- Accept-Language: ko, en-us;q=0.7, en;q=0.3

● Content-Length 와 Chunk 전송

• Content-Length : 메시지에 바디가 있을경우 사이즈를 10진수 바이트로 나타냄

- Content-Length: 5538

• 청크전송 : 사이즈를 모르는 경우 바디를 분할하여 전송가능하게 함

- Transfer-Encoding: chunked

- 각 청크의 시작에는 청크사이즈가 16진수로 들어감, 마지막에는 반드시 길이가 0인 청크와 빈줄

● 인증 ( Authentication ) : Basic 과 Digest

• Basic 인증 : 사용자 이름과 패스워드에 의한 인증방식.

- 매 요청마다 Authorization 헤더에 넣어 전송
- ID:PWD 형태로 연결하고 Base64 인코딩한 문자열 ( 간단히 디코딩 가능 )
- 누구나 쉽게 볼수 있으므로 HTTPS 통신을 통해 암호화 필요

• Digest 인증 : 해시값을 이용한 인증방식

- Digest 값 생성 : 서버가 보낸 nonce ( number used once ) , qop ( quality of protection ) 값을 사용

1. 유저이름,realm,패스워드를 : 로 연결하여 MD5 해시값을 구한다.
2. 메서드와 URI 패스를 : 로 연결하고 MD5 해시값을 구한다.
3. 1과 서버로 부터 얻은 nonce , 클라이언트가 nonce 보낸 횟수, 클라이언트가 생성한 nonce, qop , 2의값을 : 로 연결하여 MD5 해시값을 구하여 보낸다.

● 그 외 정보

• 캐시 - 서버로부터 가져온 리소스를 로컬 스토리지에 저장하여 재사용 하는것

(1) Pragma - 현재 리소스는 캐시 하지 않도록 한다.

* Pragma: no-cache

(2) Expires - 캐시의 유효기한을 지정한다.
* Expires: Thu, 11 Sep 2012 16:00:00 GMT

(3) Cache-Control - Pragma/Expires 보다 상세한 캐시방법을 지정한다. ( Pragma/Expires대체가능 )
* max-age:86400 - 상대적 표현으로 캐시저장기간 지정. 24시간동안 캐시 유지

• 조건부 GET

- If-Modified-Since - 리소스가 갱신되었다면 가져온다. 변경되지 않았다면 304 Not Modified