티스토리 뷰

Web & Networks

HTTP Protocol / Cookie 정리

Voyager Woo 2014. 6. 28. 00:01
반응형

저는 5월 달 중순부터 인턴사원에서 정직원이 되었습니다. 그리고 이건 제가 인턴 시절에 정리해본 자료입니다. joinc.co.kr의 많은 도움을 받아 작성했습니다. 거의 따라 치면서 이해를 했다고 해야할까요...


마지막에는 웹 서비스의 흐름에 대해서도 그림으로 표현해 보았습니다. 조금 이상하다 싶으시면 댓글을 달아주세요. 감사합니다. 




[참조]  

http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Network_Programing/AdvancedComm/HTTP

http://www.joinc.co.kr/modules/moniwiki/wiki.php/man/12/cookie


  HTTP 정리


1.     HTTP

HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다. 애플리케이션 레벨의 프로토콜로 TCP/IP위에서 작동한다.

HTTP는 어떤 종류의 데이터든지 전송할 수 있도록 설계되어 있다. HTML문서 뿐만 아니라 이미지, 동영상, 오디오, 텍스트 문서 등 종류를 가리지 않고 전송 가능하다. 왜냐하면 하이퍼텍스트 기반으로 즉 링크를 기반으로 데이터에 접속하기 때문이다.

 

2.     작동방식

HTTP는 서버/클라이언트 모델을 따른다. 클라이언트에서 요청(Request)을 보내면 서버는 요청을 처리해서 응답(Response)한다.

 

3.     Connectless & Stateless

HTTP는 일반적으로 Connectless방식으로 작동한다. 서버에 연결하고, 요청해서 응답을 받으면 연결을 끊어버린다. 기본적으로는 자원 하나에 대해서 하나의 연결을 만든다. 이런 작동방식은 각각 아래의 장점과 단점을 가진다.

 

Ÿ   장점 : 불특정 다수를 대상으로 하는 서비스에 적합한 방식이다. 수십 만 명이 웹 서비스를 사용하더라도 접속유지는 최소한으로 할 수 있기 때문에, 더 많은 유저의 요청을 처리할 수 있다.

Ÿ   단점 : 연결을 끊어버리기 때문에, 클라이언트의 이전 상태를 알 수 없다. 이러한 특징을 Stateless라고 하는데, Connectless로부터 파생되는 특징이라고 할 수 있다. 클라이언트 이전 상태 정보를 알 수 없게 되면, 웹 서비스를 하는데 당장 문제가 생긴다. 예를 들어, 클라이언트가 과거에 로그인을 성공했더라도 로그정보를 유지할 수 없다. HTTP Cookie를 이용해 문제를 해결하고 있다.

 

4.     URI

클라이언트 프로그램(웹 브라우저) URI를 이용해서 자원의 위치를 찾는다. URI HTTP와는 독립된 다른 체계이다. HTTP는 전송 프로토콜이고, URI는 자원의 위치를 알려주기 위한 프로토콜이다. Uniform Resource Identifiers의 줄임말로, World Wide Web 상에서 접근하고자 하는 자원의 위치를 나타내기 위해 사용한다. 자원은 “문서”, “이미지”, “동영상”, “프로그램”, “이메일”등 모든 것이 될 수 있다.

URI Subset으로 URN URL이 있다. URN은 이름으로 자원을 찾고, URL은 네트워크 상에서의 위치로 자원을 찾는다.

 

5.     Method 

메소드는요청의 종류를 서버에게 알려주기 위해서 사용한다.

Ÿ   GET : 정보를 요청하기 위해서 사용한다. (SELECT)

Ÿ   POST : 정보를 밀어넣기 위해서 사용한다. (INSERT)

Ÿ   PUT : 정보를 업데이트하기 위해서 사용한다. (UPDATE)

Ÿ   DELETE : 정보를 삭제하기 위해서 사용한다. (DELETE)

Ÿ   HEAD : (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지 확인하기 위해서 사용한다.

Ÿ   OPTION : 웹 서버가 지원하는 메소드의 종류를 요청한다.

Ÿ   TRACE : 클라이언트의 요청을 그대로 반환한다. 예컨데 echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용한다.

 

보통 웹 서비스들은 GET POST만을 이용해서 개발한다. DELETE PUT등이 필요한 요청에도 GET  POST를 사용하는데, 예를 들어, 게시판에서 특정 레코드를 삭제할 때도 GET으로 표현한다.

각 용도에 맞는 매소드가 준비되어 있음에도 이렇게 사용하는 이유는


     GET POST만으로도 모든 종류의 요청을 표현할 수 있다.

     편하게 개발하고 싶다.

     웹 브라우저로 DELETE, HEAD 등을 보내는 FORM이 없다.

 

그러나 가능하면 CRUD를 명시하는게 좋다. RESTful API 서버의 경우에는 GET, POST, DELETE, PUT을 명시적으로 구분한다. 자원의 위치 뿐만 아니라 자원에 할 일까지 명시할 수 있기 때문에, Open API 서버를 만들기 위해서 널리 사용한다.


)

GET api.joinc.co.kr/user/list : 유저 목록을 가져온다.

POST api.joinc.co.kr/user/create : 유저를 생성한다. 생성에 필요한 유저 정보는 POST 데이터 형식으로 전달할 수 있다.

PUT api.joinc.co.kr/usr/123 : 유저 ID 123인 유저의 정보를 업데이트 한다.

DELETE api.joinc.co.kr/user/123 : 유저 ID 123인 유저를 삭제한다.

 

6.     요청 데이터 포멧

웹 브라우저는 웹 서버에 데이터를 ‘요청’하는 클라이언트 프로그램이다. 요청은 서버가 인식할 수 있는 약속된 형식(HTTP형식)을 따라야 한다.

요청 데이터는 HEADER BODY로 구성된다.

 

① GET /cgi-bin/http_trace.pl HTTP/1.1\r\n

② ACCEPT_ENCODING: gzip,deflate,sdch\r\n

③ CONNECTION: keep-alive\r\n

④ ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n

⑤ ACCEPT_CHARSET: windows-949,utf-8;q=0.7,*;q=0.3\r\n

⑥ USER_AGENT: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.24\r\n

⑦ ACCEPT_LANGUAGE: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4\rn

⑧ HOST: www.joinc.co.kr\r\n

⑨ \r\n

 

HTTP헤더는 라인피드(LF, \n)와 캐리지리턴(CR, \r)을 함께 사용한다. HTTP헤더를 파싱할 때 주의해야 한다.

 

l  필수 요소로 요청의 제일 처음에 위치한다. 3개의 필드로 이루어져 있다.

A.     요청 매서드

B.      요청 URI

C.      HTTP 프로토콜 버전: 웹 브라우저가 사용하는 프로토콜 버전이다. (2013 6)현재 HTTP 최신 버전은 1.1이다. 웹 브라우저의 프로토콜 버전에 따라서 서버의 지원이 달라진다. 대부분의 웹 서버가 1.1만 사용한다고 봐도 무리는 없다. 1.1 1.0DPTJ keep-alive, 데이터 압축 등의 기능을 추가 지원한다.

l  자원인코딩

l  연결 방식

l  클라이언트가 지원하는 미디어타입

l  클라이언트가 지원하는 문자셋

l  클라이언트의 버전, 운영체제등을 명시

l  언어

l  정보를 요청하는 서버의 주소 : 하나의 서버가 여러 도메인을 가지고 서비스 할 수 있기 때문에 HTTP 1.1에서 반드시 필요하다. 웹 서버에 따라서는 HOST가 없을 경우 기본 도메인 서버를 연결해 주기도 한다.

l  헤더 종료 : 줄 처음에 \r\n을 명시해서, 헤더가 끝났다는 것을 서버에게 알린다. 이후에 BODY가 들어간다.

 

7.     응답 헤더 포멧

응답헤더는 서버의 여러 상태 정보를 포함하기 때문에 꽤 복잡해질 수 있다. wget을 이용하면 헤더 정보를 가져올 수 있다.

 

① # wget -S http://www.test.co.kr

② HTTP/1.1 200 OK\r\n

③ Date: Fri, 08 Jul 2011 00:59:41 GMT\r\n

④ Server: Apache/2.2.4 (Unix) PHP/5.2.0\r\n

⑤ X-Powered-By: PHP/5.2.0\r\n

⑥ Expires: Mon, 26 Jul 1997 05:00:00 GMT\r\n

⑦ Last-Modified: Fri, 08 Jul 2011 00:59:41 GMT\r\n

⑧ Cache-Control: no-store, no-cache, must-revalidate\r\n

⑨ Content-Length: 102\r\n

⑩ Keep-Alive: timeout=15, max=100\r\n

⑪ Connection: Keep-Alive\r\n

⑫ Content-Type: text/html\r\n

⑬ \r\n

     wget으로 헤더 정보를 출력했다.

     프로토콜과 응답코드: 3개의 필드로 구성되었으며, 첫출에 위치한다.

A.     응답 프로토콜과 버전

B.     응답 코드

C.     응답 메시지

     날짜

     서버 프로그램 및 스크립트 정보

     웹 애플리케이션을 지원하는 기술 명세 (필요없이 트레픽을 증가시켜 제거하기도 한다.)

     데이터 보관일시

     컨텐츠의 마지막 수정일

     캐시 제어 방식

     컨텐츠 길이

     Keep Alive 기능 설정

     Keep Alive 기능 설정

     컨텐츠 타입


8.     응답 코드

서버는 세자리 숫자로 이루어진 응답코드로 서버의 상태를 알려준다.

l  1XX 조건부 응답

요청을 받았으며 현재 처리중임을 의미한다. 클라이언트에서 첨부문서(attached document)를 보내기 전에 요청을 보낼 때 Expect헤더에 설정해서 보낸다. 잠정적인 응답을 표시하며Status-Line과 선택적인 헤더로 구성되어 있다. 이 클래스는 빈 라인으로 종료되고 HTTP/1.0은 어떠한 1XX 상태코드도 정의하지 않기 때문에 실험적인 상황 이외에 서버는 1XX 응답을HTTP/1.0 클라이언트에 발송하지 말아야 한다.

코드번호

설명

비고

100

계속

요청자는 요청을 계속해야 합니다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타냅니다.

101

프로토콜 전환

요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중입니다.

 

l  2XX 성공

서버가 요청을 성공적으로 처리했음을 의미한다.

코드번호

설명

비고

200

성공

서버가 요청을 제대로 처리했다.

201

생성됨

요청이 성공했으며, 새로운 리소스를 만들었다.

202

허용됨

요청을 받았으나, 아직 처리하지는 못했다.

204

컨텐츠 없음

요청을 처리했지만, 컨텐츠를 제공하지 않는다.

205

컨텐츠 재 설정

요청을 처리했지만, 컨텐츠를 표시하지 않는다. 그리고 문서를 재 설정할 것을 요구한다.

206

일부 성공

요청의 일부만 성공적으로 처리

207

다중상태

 

l  3XX 리다이렉션

때때로 요청을 완료하기 위해서 다른 페이지로 보내야 할 때가 있다. 예를 들어, 로그인에 성공하고 나서 메인 페이지로 보내거나, 로그인 직전 머무르던 페이지로 보내는 등의 용도로 사용할 수 있다.

 

코드번호

설명

비고

300

여러 선택 항목

301

영구이동

요청한 페이지가 다른 위치로 영구이동 했다.

302

임시이동

요청한 페이지가 다른 위치로 임시이동 했다. 요청자는 여전히 현재 페이지를 요청해야 한다.

303

기타위치 보기

요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우

304

수정되지 않음

마지막 요청 이후 요청한 페이지가 수정되지 않았다. if-Modified-Sine 헤더에 지정된 날짜/시간 이래로 지정된 문서가 변경된 사실이 없는 경우 이 code로 응답한다.

305

프록시 사용

요청자는 프록시를 사용하여 요청한 페이지만 접근할 수 있다.

          

l  4XX

클라이언트 요청에 오류가 있음을 의미한다.

코드번호

설명

비고

400

잘못된 요청

주로 헤더 포멧이 HTTP 규약에 맞지 않을 경우

401

권한 없음

인증을 필요로 하는 요청이다. Basic access authentication에 사용한다.

403

금지

서버가 요청을 거부하고 있다.

404

찾을 수 없음

요청한 자원이 서버에 존재하지 않는다.

405

허용하지 않는 방법

요청에 지정한 방법을 사용할 수 없다.

406

허용되지 않음

요청한 페이지를 콘텐츠 특성 때문에 응답할 수 없다.

408

요청시간 초과

서버의 요청대기가 시간을 초과

410

사라짐

요청한 자원이 삭제되었음. 404와 비슷하지만, 410은 과거에 있었으나 지금 없는 자원이다. 예컨데, 게시판에서 삭제한 포스트에 접근하는 경우

411

길이필요

유효한 컨텐츠 길이를 명시해야 한다.

 

l  5XX 서버 오류

서버에 문제 발생. 보통 서버사이드 스크립트가 잘못 작동할 때 발생한다.

코드번호

설명

비고

500

내부 서버 오류

서버에 오류 발생

501

구현되지 않음

서버에 요청을 수행할 기능이 없다.

503

서비스를 사용할 수 없다.

관리 목적 등으로 서버를 다운했다.

505

HTTP 버전 지원이 안됨

서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.

 

9.     Keep Alive

HTTP 1.1 부터는 keep-alive 기능을 지원한다.

HTTP는 하나의 연결에 하나의 요청을 하는 것을 기준으로 설계되었다. 요즘 웹 서비스의 경우 간단한 페이지라고 해도 수십 개의 데이터 (이미지, 문서, CSS, JavaScript) 등이 있기 마련인데, HTTP의 원래 규격대로라면 웹 페이지를 하나 표시하기 위해서 연결을 맺고 끊는 과정을 수십 번 반복해야 한다.

keep-alive 설정을 하면, 지정된 시간 동안 연결을 끊지 않고 요청을 계속 보낼 수 있다.

 

l  keep-alive 설정

keep-alive HTTP 1.1부터 사용할 수 있다. 아래와 같은 과정을 거쳐서 keep-alive를 설정한다.

     웹 브라우저는 요청 헤더에 keep-alive 방식의 연결을 할 것을 명시한다. chrome 브라우저로 www.joinc.co.kr로 연결 요청을 캡춰했다.

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

Accept-Charset:windows-949,utf-8;q=0.7,*;q=0.3

Accept-Encoding:gzip,deflate,sdch

Accept-Language:ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4

Connection:keep-alive

Host:www.joinc.co.kr

Referer:http://www.joinc.co.kr/

User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31

          

     웹 서버의 설정이 keep-alive 방식을 지원하도록 설정되어 있다면, 응답 헤더에 keep-alive 정보를 실어 보낸다. www.joinc.co.kr 서버의 응답 헤더의 일부분이다.

Connection:Keep-Alive

Keep-Alive:timeout=5, max=100

Content-Encoding:gzip

Content-Length:5933

Content-Type:text/html

Vary:Accept-Encoding

Ÿ  Connection : Keep-Alive – 연결을 keep-alive 상태로 유지한다.

Ÿ  Keep-Alive:timeout=5, max=100 – 하나의 연결당 5초 동안 유지한다. Keep-alive 연결은 최대 100개까지 허용된다. keep-alive는 하나의 연결로 여러 요청을 처리하기 때문에 효율적이지만, 연결이 그만큼 길어지기 때문에 동시간대 연결이 늘어난다. 운영체제에 있어서 연결은 “유한한 자원”이다. 연결을 다 써버리면 더 이상 연결을 받을 수 없게 된다. Max 값을 이용해서 keep-alive 연결을 제한하는 이유이다.

 

 

l  keep-alive 설정을 안 할 경우

대게 keep-alive 설정을 하면 서비스 효율이 좋아진다. 하지만 항상 그런건 아니다. 엄청나게 많은 요청을 처리하는 서비스의 경우에는 keep-alive를 설정하지 않는 것이 더 나을 수 있다.포털 같은 경우에는 keep-alive를 끄는 경우가 많다. 어차피 이미지의 많은 부분은 클라이언트에서 캐시로 유지할 테니 굳이 keep-alive를 설정할 필요가 없다.

 

  Cookie


1.     Cookie

Cookie Web cookie, HTTP cookie 혹은 browser cookie등의 이름으로 불린다. 쿠키는 유저의 웹 브라우저가 웹 사이트를 방문했을 때, 웹 서버로부터 받아 저장하는 작은 데이터 조각이다.유저가 해당 웹 사이트를 다시 방문하면 저장했던 쿠키를 웹 사이트로 전송해서, 이전에 웹 사이트에서 어떤 행동을 했다는 것을 알려준다.

쿠키로는 바이러스를 옮기거나 호스트 컴퓨터에 악성코드를 설치할 수 없지만, 쿠키에 담겨진 데이터는 추적할 수 있다. 특히 persistent cookie는 로컬 디스크에 쿠키를 남기는데, 쿠키에 개인정보가 있다면 타인에게 그대로 노출될 수 있다. 어떤 웹 사이트는 유저의 접근 편의성을 위해서 자동 접속 기능을 제공하기도 하는데 모두 쿠키를 이용해서 구현한다. 당연히 쿠키에는 웹 사이트에 접근하기 위한 정보를 가지고 있으며, 노출될 경우 웹 사이트에 저장ㅎ난 유저의 개인정보가 고스란히 노출될 수 있다.

 

2.     쿠키관련 용어

     Session Cookie

유저 세션 쿠키라고 불린다. 이들 쿠키는 메모리 상에만 위치한다. 보통 만료시간을 가지고 있으며, 시간이 지난 쿠키는 무효화 되어 더 이상 사용할 수 없게 된다. 메모리 상에만 존재하기 때문에 유저가 브라우저를 닫을 경우 지워진다.

     Persistent Cookie

Persistent 쿠키는 오랜 기간 유지되는 쿠키이다. 만약 쿠키의, Max-Age 1년으로 했다면, 이 기간 동안 쿠키는 유효하며 (쿠키를 발행한) 웹 사이트를 방문할 때마다 사용할 수 있다. 로컬 디스크에 보관하기 때문에, 브라우저나 PC의 종료/시작과 관계없이 유지된다. 주로 유저의 이전 방문 상태를 추적하기 위해서 사용하기 때문에 Tracking Cookie라고 부르기도 한다.

     Secure Cookie

Secure 쿠키는 HTTPS 상에서만 사용 가능하다. 클라이언트에서 서버로 전송되는 쿠키는 항상 암호화된다. 따라서 쿠키가 노출될 가능성을 줄여준다.

     HttpOnly Cookie

HttpOnly 쿠키는 모든 브라우저가 지원하는 기능이다. HttpOnly 쿠키는 오로지 HTTP(혹은 HTTPS)요청이 있을 때에만 전송된다. 예를 들어 JavaScript 등에서 non-HTTP API로 호출할 경우에는 쿠키를 사용할 수 없다. 이 기능은 세션 쿠키를 관리하기 위한 목적으로 사용된다.

     Third-Party Cookie

First-Party 쿠키는 브라우저의 주소에 보이는 도메인과 같은 도메인에 속한 쿠키이다. Third-Party 쿠키는 주소 표시줄에 표시된 것과 다른 도메인에 속한 쿠키이다. 광고 배너 등을 관리할 때, 유저가 어느 사이트를 통해서 유입되었는지 등을 추적하기 위한 용도로 사용할 수 있다. 유저의 행동을 추적하는 것은 개인 프라이버시를 침해할 수 있기 때문에 브라우저는 유저에게Third-Party 쿠키를 막도록 옵션을 제공한다.

 

3.     쿠키의 구성요소

     쿠키의 이름

     쿠키의 값

     쿠키의 만료시간

     쿠키를 전송할 도메인 이름

     쿠키를 전송할 패스

     쿠키를 이용하기 위해서 보안연결이 필요한가

     HttpOnly 쿠키를 사용할 것인가

 

처음 두 개는 필수이며 나머지는 옵션이다.

 

4.     쿠키의 사용

     세션 관리

쿠키는 유저가 사이트의 탐색과 방문정보를 남기는데 사용할 수 있다. 예를 들어, 사용자의 웹 서버 로그인 정보를 유지하기 위한 목적으로 사용한다. 사용자가 로그인에 성공하면, 웹 서버는 유일한 세션아이디를 포함하는 쿠키를 전송한다. 이후 유저는 세션아이디를 제출하는 것으로 로그인 했다는 것을 증명할 수 있다.

이처럼 쿠키는 클라이언트/서버의 상호작용을 위한 편리한 수단을 제공한다. 간단하게 사용할 수 있다는 것이 가장 큰 장점이다. 또한 정보를 클라이언트에 분산함으로써 서버 측의 부하를 줄일 수 있다는 장점도 가지고 있다.

     개인화

쿠키는 웹 사이트를 방문한 사용자에 대한 정보를 저장했다가 재방문 시 사용자에 적합한 정보를 제공하는데 사용할 수 있다.

     추적

 

5.     구현

쿠키라는 데이터 조각을 주고 받는 것으로 HTTP stateless 문제를 해결한다. 만약 쿠키가 없다면 웹 페이지는 모두 서로 분리되며 아무런 연결점을 가지지 못할 것이다.

 

l  쿠키 설정

쿠키가 설정되는 과정은 HTTP의 흐름을 쫓아가면서 살펴봐야 한다.

     클라이언트가 웹 서버에 요청한다. (HTTP Request)

     요청 받은 웹 서버는 응답(HTTP Response)를 서버 측으로 전송한다. 이때 쿠키설정 정보를 전송한다.

     서버는 Set-Cookie를 이용해서 클라이언트에 쿠키를 전송한다. 쿠키는 key=value 형식을 따르며, 브라우저에 저장된다. 브라우저는 쿠키를 받은 웹 서버에 방문할 때, 저장되어있던 쿠키 값을 서버에 전송한다.

     서버는 브라우저로부터 쿠키 값을 읽는 것으로 브라우저의 이전 상태를 확인할 수 있게 된다. 서버는 쿠키의 값으로 데이터베이스를 조회할 수 있는 key를 보내는 식으로 유저의 여러 정보를 데이터베이스에 저장할 수 있다.

l  쿠키 속성

쿠키의 메인 속성은 name=key이다. 이 외에도 몇 가지 중요한 속성을 가지고 있는데 cookie domain, path, expiration time 혹은 maxium age이다. 브라우저는 이들 속성 정보를 서버에 전달하지 않는다. 서버에는 name=key만 전송한다. 나머지 속성들은 쿠키를 서버로 전송할지 말지, 언제 쿠키를 삭제할지 결정하기 위해서 사용한다.

     Domain Path

도메인과 패스는 쿠키를 어느 도메인의 어느 패스에서 전송할지를 브라우저에게 알려주기 위해서 사용한다. 서버는 쿠키를 보낼 때 이 쿠키를 사용할 도메인과 패스 정보까지 함께 브라우저로 전송한다. 브라우저는 도메인과 패스가 일치할 때만 쿠키를 전송한다.

Set-Cookie: LSID=DQAAAK…Eaem_vYg; Domain=docs.foo.com; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly

Set-Cookie: HSID=AYQEVn….DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly

Set-Cookie: SSID=Ap4P….GTEq; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly

-       LSID docs.foo.com/accounts 페이지를 방문할 때만 서버로 전송한다.

-       HSID docs.foo.com/ 페이지를 방문할 때만 서버로 전송한다.

-       SSID *.foo.com/ 페이지를 방문할 때 서버로 전송한다.

 

     Expire Max-Age

Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Jan 2013 21:47:38 GMT; Path=/; Domain=.example.com; HttpOnly

Set-Cookie: made_write_conn=1295214458; Path=/; Domain=.example.com

Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly

-        lu 쿠키의 만료일은 Tue, 15 Jan 2013 21:47:38이다. 이 시간이 지나면 브라우저는 쿠키를 삭제하고 더 이상 서버로 쿠키를 전송하지 않는다.

-        made_write_conn 쿠키는 만료일을 정하지 않았다. 이 경우 session cookie가 된다. 즉 브라우저를 종료하는 시점에서 삭제된다.

-        reg_fb_gate는 쿠키의 만료일이 과거다. 일반적으로 쿠키는 직접 삭제할 수 없다. 그러나 만료일을 과거로 설정하는 식으로 브라우저가 쿠키를 삭제하도록 유도할 수는 있다

 

     보안과 HttpOnly

HttpOnly 속성이 붙은 쿠키는 HTTP HTTPS이외의 방법으로는 사용할 수가 없다. 예컨데 javascript document.cookie메서드를 이용해서 쿠키정보를 획득할 수가 없다.

 

 

n  session

쿠키가 웹 브라우저에 사용자의 상태를 유지하기 위한 정보를 저장했다면, 세션은 웹 서버 쪽의 웹 컨테이너에 상태를 유지하기 위한 정보를 저장한다.

자바 웹 개발에서 세션은 사용자의 정보를 유지하기 위해 javax.servlet.http 패키지의 HttpSession 인터페이스를 구현해서 사용한다. 웹 서버는 사용자의 상태 유지를 위한 정보를 쿠키로 만들어 웹 브라우저에 저장해서 웹 서버가 쿠키 정보를 읽어서 사용한다. 이것은 웹 브라우저에 저장된 쿠키는 웹 서버에서 열어볼 수 있다는 점에서 보안상의 문제가 발생할 수 있다.

따라서 사용자의 정보를 유지하기 위해서는 쿠키를 사용하는 것보다 세션을 사용하여 웹 브라우저와 웹 서버를 안정적으로 상태 유지할 수 있다.

 

 

 

n 웹 서비스의 전체적인 흐름도

    유저가 링크를 클릭하거나 주소를 입력하여 브라우저에 정보를 요청한다.

    브라우저는 주소를 DNS 서버에 보낸다.

    DNS에서 받은 주소를 IP로 변환한다.

    HTTP 요청를 서버에 보낸다.

    웹 서버는 HTTP 요청를 받아서 컨테이너에 전달한다.

    만약 요청이 데이터베이스에 접근해서 정보를 가져오는 것이라면 접근하여 가져온다.

    컨테이너에서 요청 받은 웹 프로그램을 메모리에 적재하고 실행한다. 그리고 그 결과를 HTTP 응답과 함께 웹 서버로 전달한다.

    웹 서버는 결과를 웹 브라우저로 전달한다.

    웹 브라우저는 HTML Javascript를 분석하여 화면을 구성한다.

 

 

n  서블릿 컨테이너 흐름도

    HTTP 요청를 받는다.

    서블릿 컨테이너는 HttpServletRequest, HttpServletResponse 두 객체를 생성한다.

    사용자가 요청한 URI를 분석하여 어느 서블릿에 대한 요청인지 찾는다.

    해당 서블릿이 요청을 분석하고 Service() 메소드를 호출한다.

    Service()가 요청을 분석하여 doGet() 또는 doPost 등이 호출된다.

    doGet(), doPost() 메소드가 동적인 페이지를 생성한 후 HttpServletResponse 객체에 응답을 보낸다.

    페이지와 함께 응답을 보낸다. 그리고 HttpServletRequest, HttpServletResponse 두 객체를 소멸시킨다.

 

 

n  JSP 컨테이너 흐름도

    웹 서버에서 HTTP 요청를 받는다.

    Servlet Container jsp 파일을 jsp 컨테이너로 넘긴다. Jsp 컨테이너는 jsp 파일에 대한 서블릿 코드가 존재하는가 확인하고 없거나 최근에 수정된 시간보다 이전이라면 새로운 서블릿 코드를 생성한다.

    생성된 서블릿 코드를 컴파일 한다.

    그리고 실행한다. 
(jsp 
파일에 대한 서블릿 코드가 존재하고, 수정되지 않았다면 해당 서블릿의 인스턴스가 메모리에 있는지 확인하고, 있다면 해당 인스턴스를 샐행하고 그렇지 않은 경우 새로운 인스턴스를 생성하여 실행한다.

    실행 결과를 서블릿 컨테이너로 전송한다.

    HTTP 응답과 함께 웹 서버로 결과를 전송한다.





반응형
댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함