-Request Handling
-URL에 대한 동적 binding -> 편하게 사용할 수 있지만 request path와 혼동될 우려가 있다
-Query String을 이용한 방식
Query String은 특별한 형식의 문자열
쿼리스트링은 무조건 물음표로 시작하고 키와밸류의 쌍이 나옴 또다른키와밸류쌍연결은 & 로 연결
?name=홍길동&age=20&address=서울 // URL뒤에 붙여서 사용
- Cookie, Session, File Upload, ec.
- Database Handling (MySQL)
-> 기본적인 Web Application 작성
Cookie : 문자열 ( 길이에 제한이 있어요! ) e.g. 시스템마다 다르다. 예를 들어, 맥과 pc 에서 사용되는 cookie 의 길이제한은 서로 다르다.
key 와 value 의 쌍으로 데이터를 저장
Client 쪽에 저장된다 (좀 더 엄밀히 말하자면, 브라우저 쪽 어느 공간에 저장된다)
내 컴퓨터에 저장된 cookie 를 열어볼 수 있을까? 물론이다. 따라서 보안성이라고는 찾아볼 수가 없다 라고도 볼 수 있다.
서버가 특정목적을 가지고 클라이언트쪽에 저장하는 문자열
**signed cookie - 사용자가 편하게 cookie를 열어볼 수 있는 대신, 보안을 위해 서버쪽에서 RSA 방식으로 cookie 내용을 128 bit 로 암호화한다
- 다시 말해, 내 컴퓨터에 있는 쿠키를 맘대로 열고, 지울 순 있지만, 열어봐도 알아볼 수 없다. 암호화 되어 있기 때문에.
동작방법 예
- 클라이언트가 서버쪽으로 request 를 보낼 때 해당 cookie가 request 에 딸려가요!!
- 그래서 서버가 cookie 를 받고, "아 어제 접속했던 '홍길동' 이구나 라고 인지하고
- 목적: 사용자 tracking
쿠키가 나온 이유
수많은 사람들이 접속하는 클라이언트-서버 모델 상 이 부하를 감당해내기 위한 방법으로서 HTTP 는 client 가 request 를 보내면 소켓을 열고, client 에게 response 를 보내고
그 다음에 session 을 끊고 소켓을 끊는 방식을 사용했다. 그런데 이렇게 하기 시작하자 금방 접속했던 친구가 A 인지 B 인지 확인하는 것이 너무 번거로워진 것이다.
그래서 사용자 tracking 을 위해 쿠키가 필요하게 되어 쿠키라는 개념이 생기게 된 것.
요즘은 session을 더 많이 쓰지만, session 자체가 cookie 에 기반하고 있기 때문에 cookie 개념을 잘 이해해야 한다.
browser 별로 따로 관리. cookie 는 내가 컴퓨터를 새로 포맷할 때까지 계속 남아있나요? cookie 유지기간을 정할 수 있다.
어떤 사이트에 접속한다. 그럼 그 사이트가 내 컴퓨터에 cookie 를 남긴다. 그리고 내가 나중에 다시 그 사이트에 접속할 때, 즉, request 를 보낼 때
그 해당 cookie 가 함께 보내진다. 물론 내 컴퓨터에 쌓여있는 모든 쿠키가 보내지는게 아니라, 그 domain 과 매칭되는 쿠키만 보내진다.
쿠키는 도메인 단위로 관리되요.
서버가 특정목적을 가지고 클라이언트쪽에 저장하는 문자열
signed cookie
Session
=> 쿠키의 단점 때문에 등장
Cookie가 문자열기반이기 때문에 사용상에 불편함이 있고,
보안성 없고, 대역폭 낙비
저장길이에 제한있다..
Session : 데이터를 저장하기 위한 객체
Key 와 value 의 쌍으로 데이터를 저장
이 저장객체는 서버쪽에 위치...
1. 클라이언트가 서버에 접속을 해요
2. 서버쪽에서는 session이라는 객체를 하나 만들어요.
그리고 이 객체에 꼬리표를 하나 달아요 (숫자값)
3. 응답을 돌려줄 때 signed cookie를 이용해서
해당 숫자값을 클라이언트에게 전송
4. 이 클라이언트가 다시 서버에 request 를 보내요.
당연히 아까 설정된 cookie 값(꼬리표 숫자값)이 서버로 전송되요
5. 서버는 이 숫자값을 가지고 아까 있던 객체를 찾아서 이용.
6. 이 객체는 언제까지 유지되나요
session 만료의 의미 - 서버 쪽에 있는 session 객체가 날라가서 존재하지 않는다는 의미
장점 : 서버쪽에 존재 (안전)
프로그램하기도 편해요 (객체)
크기에 제한이 있나요
(크기에 제한은 없어요)
대역폭 낭비도 훨씬 적어요!!
Session 의 단점 : cookie 가 동작하지 않으면 session 자체를 사용할 수 없어요!!
=> 따라서, 브라우저 상에서 '쿠키 사용 안 함' 을 클릭하면 session 을 사용하지 못하게 되는 것이다
=> 그럼 어떻게 해? => 이를 해결하기 위해 쿠키를 사용하지 않고 URL 을 이용하는 방식으로 session 을 이용
=> e.g. 은행권 사이트 들어가서 로그인 하면 그 뒤에 URL 이 엄~~청 길어진다. 서버측에서 클라이언트 쪽에 쿠키를 심지 못하다 보니
URL 내에 키 값을 심는 방식으로 문제를 우회한 것이고, 그렇기 때문에 URL 이 길어진 것이다.
session <- 서버 쪽에 있는 객체
e..g
쇼핑사이트에서 장바구니에 넣는 순간 쿠키가 우리 컴퓨터에 저장된다.
나중에 결제할때 전체결제 들어가면 확인할 수 있다.
다시 한번 말해, HTTP 가 가지고 있는 약점! 즉, 사용자 구분이 불가능하다는 단점을 쿠키를 통해 해결!
사용자 구분을 위해 쿠키는 무조건 필요하다.
Web Application 에 쿠키 개념이 안 들어가는 경우가 없다.
http://localhost:5000/?name=홍길동&age=20&address=서울
express안 쓰면!!! 헤더 짜르고 거기서 또 스트링 짤라서 쿼리스트링 아주 복잡하게 처리해야되지만
express쓰면 그냥 req.query.key값 으로 간단하게 꺼낼수있음 당길수잇음~
client 에서 보내는 데이터는
query string 혹은 form tag 이다.
서버와 클라이언트가 데이터를 주고 받는다.
그리고
서버와 데이터베이스가 데이터를 주고 받는다.
데이터를 주고 받을 때 (많은 양의 데이터를 주고 받을 때)
홍길동,20,서울,김길동,30,인천,김구,40,제주도
CSV (Comma Separated Value)
-> 문제점
데이터를 구조화 할 수 없어요!
파싱 프로그램을 짜야되요! (더군다나, 1회성이다. 앞으로 들어오는 데이터들이 '이름,나이,주소' 인 패턴을 가지고 있을리가 없다.)
장점
부가적인 데이터가 상대적으로 크지 않아요
대용량의 데이터를 보내기에 적합해요
XML
<name> 홍길동 </name> <age> 20 </age> <addr> 서울 </addr> ...
장점
구조화된 데이터를 만들기 쉬워요
파싱프로그램을 쉽게 만들 수 있어요
단점
부가적인 데이터가 많아요 (왜? e.g. <name> </name> <age> </age> ... 식으로 태그를 다 붙여야 하니까)
그러다 결국 다음 언어를 사용하게 되었다
JSON (JavaScript Object Notation)
->표준, 데이터를 표현하는 형식
특정언어에 종속되지 않아요!
{ name : "홍길동", age : 20, addr : "서울" } <- 마치 자바스크립트 객체와 같이 생겼다. 실제로 JSON 을 만들 때 자바스크립트를 참조해서 만들었기 때문이라 볼 수 있다.
WRITTEN BY
