HTTP

HTTP 프로토콜 

• 클라이언트가 서버에 접속하여 Request를 보내고 Response를 받는 형태, 즉 HTTP 프로토콜은 요청(Request)과 응답(Response)의 형태로 이루어짐
• 사용자가 웹페이지의 링크를 클릭했을 때 브라우저는 HTTP 프로토콜에 따른 HTTP 요청메시지를 작성하여 웹서버로 전송
• 웹서버는 수신한 HTTP 메시지가 요청(Request) 메시지임을 판단하고 그 데이터를 분석해서 HTTP 프로토콜에 따라 HTTP 응답(Response) 메시지를 작성하여 브라우저로 보내면 브라우저는 메시지를 받아서 사용자의 화면에 표시
• HTTP 메시지는 시작라인, 헤더, 본문으로 이루어져 있는데, 시작라인에는 URL, 헤더에는 버전정보, 본문에는 내용이 들어있음.

HTTP Request 메시지 

• HTTP의 Request 메시지 형식은 아주 간단
• 첫째 줄 처음에 서버의 어떤 기능을 이용하려는지 지정하며 이것이 method
• 가장 일반적으로 쓰이는 것은 GET 방식
• HTTP 요청 메시지는 기본적으로 HTTP 메소드(GET or POST), 접근할 주소(URL), 그리고 서버에 전달할 데이터인 폼 패라미터로 구성됨 
• 브라우저가 서버에게 문서를 보내달라고 요청하는 것
• 그 다음에 화일 이름과 위치하는 디렉토리 이름 등이 들어가는 URI를 지정하고 현재 쓰이고 있는 HTTP 프로토콜의 버전을 지정
• 이 다음에는 MIME 형식으로 표현되는 일련의 지정 사항들을 덧붙일 수 있음(예를 들어 브라우저의 종류 둥)
• Request chain이란 아래와 같이 여러 헤더로 구성되어 있는 요구 메시지를 말함
• 예   GET /index.html HTTP/1.0

User-Agent: Netscape 1.2

   GET/test HTTP/1.1               GET        /test          HTTP/1.1

   HOST:dopza.com               method     요청 URI      프로토콜 버전

<span style="font-family: Arial Black;"><b><span style="font-size: 10pt;"></span></b></span><span style="font-family: Arial Black;"><b><span style="font-size: 10pt;"></span></b></span><span style="font-family: Arial Black;"><b><span style="font-size: 10pt;"></span></b></span><span style="font-family: Arial Black;"><b><span style="font-size: 10pt;"></span></b></span><span style="font-family: Arial Black;"><b><span style="font-size: 10pt;"></span></b></span>

• <span style="font-family: Gulim,굴림,AppleGothic,sans-serif; font-size: 10pt;"><font face="굴림, Gulim" size="2">form 태그 안에 정의된 인자들을 파라미터라 하며, form이 전송될 때 HTTP 요청 메시지에 담겨서 <br />form 태그 내의 action에 정의된 URL로 전송됨</font></span>
• form 태그의 method가 GET으로 명시되는지 또는 POST로 명시되는지에 따라 전송 방식이 달라짐
• GET 방식은 전송할 파라미터 값들을 시작 라인의 URL 정보에 붙여서 같이 전송하며(파라미터 길이가 256바이트를 넘을 수 없음), 본문(Body)이 필요 없기 때문에 전송 속도가 POST 방식에 비해 빠름
• 따라서 전송해야 할 데이터가 적을 경우에 유용함
• POST 방식은 파라미터 값을 요청 메시지의 본문(Body)에 담아서 전송하기 때문에 길이 제약이 없음
• 보안상 더 유리한 전송 방식

• 둘째 줄 부터는 여러 개의 Header 가 이어짐

- "name: value" 형태

- Host: dopza.com,  User-Agent: Mozilla/5.0

HTTP Response 메시지 

• HTTP의 응답 메시지 형식도 아주 간단
• 서버에서 쓰이고 있는 프로토콜 버전, Request에 대한 실행 결과 코드 및 설명문이 있으며, 전달해줄 데이타의 형식, 데이타 길이 등과 같은 추가적인 정보가 MIME 형식으로 표현되어 있음
• 마지막에 헤더 정보의 끝을 나타내는 빈줄이 들어가고, 뒤이어 실제 데이타가 전달
• 데이타 전달이 끝나면 서버는 연결을 끊음
• Response chain이란 여러 가지 헤더로 구성되어 있는 응답 메시지를 일컫는 말
• 요청에 대한 서버의 처리여부를 표시하는 상태코드(HTTP 404, 500 등)와 웹서버가 응답하는 콘텐츠의 타입 정보(텍스트/HTML, 이미지 등), 콘텐츠의 내용으로 구성
• 실제적으로 서블릿 클래스가 요청을 처리해 생성하는 페이지는 웹 서버에서 응답 메시지의 형태로 작성되어 사용자의 브라우저에 전송
• 응답메시지의 첫줄 상태(Status) 코드로 결과 상태를 표현, 프로그램에서 이 코드를 통해 상태 파악
• Request 와 같이 둘째 줄부터는 여러 개의 Header 가 이어짐
• Content-Type 헤더를 통해 MIME 미디어 타입 (text/html)과 문자인코딩 타입(utf-8)을 전송
• Content-Length 헤더를 통해 이어지는 Body 의 크기를 알려줌
• Body 에 실제 문서데이터가 포함

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

HTTP/1.0 200 OK Server: MDMA/0.1
Content-type: text/html
Last-Modified: Thu Jul 7 00:25:33 1994
Content-Length: 2003

HTTP 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자가 넘거나.. )

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 를 대신하는 방법

멱등성과 안정성 

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

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

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

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

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

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 헤더에 재개시간

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

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