- 본 글은 이전에 사용하던 영상 강의 필기 앱인 'Slid'에서 필기 했던 내용을 Velog로 옮긴 내용입니다.
- 본 글은 이화여대 이미정교수님 2014학년도 1학기 컴퓨터 네트워크 강의를 기반으로 작성되었습니다.
- 강의 링크 : http://www.kocw.net/home/search/kemView.do?kemId=1046412
쿠키 : Cookie
Http는 상태정보를 저장할 수 없어!
- 카톡 메세지 하나 보낼 때마다 카톡 로그인을 다시 해야한다고 생각해보자.
- 즉 자신의 로그인 상태가 저장이 안된다면(Stateless) 많이 곤란하다.
- HTTP 프로토콜 자체는 Stateless 한 프로토콜이다!
- 즉 State 정보 저장은 유저가 해야한다.
- HTTP를 stateful하게 설계한다면 물리적으로 항상 같은 서버와 통신해야 하기 때문에 서버 측에서 확장하기 어렵다.
쿠키: Cookie
- 쿠키는 Unique한 ID이다!
- Unique한 ID로 상태정보를 저장할 수 있다.
작동원리
- 클라이언트가 서버에게 요청을 보낸다.
- 서버는 클라이언트에게 Unique한 ID를 HTTP헤더에 실어서 보내고
- 누구에게 어떤 ID를 할당했는지 서버 데이터베이스에 저장한다.
- 클라이언트는 그 사이트의 쿠키를 다른 쿠키들이 모여있는 쿠키파일에 저장하고
- 다음 요청부터는 헤더에 쿠키를 같이 적어서 보낸다!
- 서버는 쿠키가 담긴 http 메세지를 보고 Cookie Specific Action을 취할 수 있다.
쿠키의 사용 예
User session state(Web e-mail) - 세션이 유지된다.(로그인 한번 하면 안 사라지잖아? 쿠키를 사용하기 때문)
결국, HTTP 자체는 stateless하지만, 쿠키를 통해서 stateful하게 유지할 수 있다.
웹 캐시 (Web caches)
다른말로 Proxy Server이라고도 한다.
웹 캐시는 왜 필요할까?
- 클라이언트와 서버가 매우 멀리 있고
- 몇몇 페이지만 자주 사용된다고 생각해보자.
- 그러면 매번 저 멀리있는 서버까지 왔다갔다 해야할까....?
그럼 중간에 서버를 하나 더 두자!
- 그럼 중간에 서버를 하나 더 두자!
- 자주 사용하는 파일은 중간 서버에 두고
- 덜 사용하는 파일은 중간 서버에 없으면 그때만 서버에 갔다오면 되지!
- 중간에 있는 서버가 Original 서버를 대신한다. == Proxy!!!
- 응답시간이 줄어들기 때문에 사용자 입장에서 매우 좋다.
- 대학생, 회사 입장에서는 불필요한 traffic을 줄일 수 있다.
- "poor content providers", "P2P 파일 공유 사이트" 등에서 Web Cache를 매우 유용하게 사용할 수 있다.
작동과정
- 1. 클라이언트가 프록시 서버에게 요청한다.
- 2. 프록시 서버는 원 서버에게 Conditional Get메소드를 이용해서 물어본다.
- + 프록시 서버는 자신의 파일에 최근 수정일 를 보고Condtional Get 메소드로 원 서버에게 이후로 수정되었는지 물어본다.
- + 원 서버는 수정되었지 않다면 304 not Modified를, 수정되었다면 200 OK [New Data]를 응답으로 보낸다.
- + 매번 크기가 큰 데이터를 받을 필요없이 크키가 작은 http 헤더 메세지만 주고 받으면 돼서 ISP 비용이 저렴하다.
- + 수정일 대신 버전을 사용할 수도 있다.
- 3. 클라이언트에게 응답 메세지를 보낸다.
- Hit Rate만큼 트래픽이 감소한다.
Caching example (뚱뚱한 access link를 쓸 경우)
- traffic intensity = link utilization = 99% (이 부분이 문제라는거다.)
- 이를 개선할 수 있는 방법은?
- access link를 뚱뚱한 걸로 바꾼다. (화면 상 속도가 10배 증가)
- access link는 정기적으로 ISP에게 돈을 내야 함. 따라서 뚱뚱한 access link를 쓴다면 비용이 많이 들 것임.
Caching example (local cache를 설치할 경우)
- access link의 utilizatino이 낮으니까 access link가 뚱뚱하지 않더라도 충분히 빠를 수 있다.
Conditional GET
만약 기존의 웹 서버가 업데이트 된 경우, 웹 캐시는 그걸 모르고 예전의 웹 페이지를 지속적으로 서비스할 수 있다. 이를 방지하기 위해 Conditional GET이 필요하다.
이를 통해 update된 data를 client에게 제공할 수 있다.
- 이를 client에게 웹 서버가 업데이트 될 때마다 HTTP request를 보낸다면?
- 사용자는 최신의 정보를 얻을 수 있지만, delay가 많이 발생하게 된다.
- 이를 방지하기 위해 몇 분에 한번씩 Conditional GET을 시도한다면, 구식 정보를 client에게 제공할 수도 있다.
- ex) 새로고침 안하면 그 전의 정보를 제공하는 웹 페이지 등
Electronic mail (전자 메일)
인터넷 상에서 URL로 연결된 웹문서로 정보를 교류하는 서비스가 웹이었고, 웹을 위한 프로토콜이 http였다.
이번에는 이메일 서비스와 이를 위한 프로토콜인 SMTP, POP, IMAP을 알아보자.
먼저 Non-Electronic Mail을 생각해보자.
- 집의 우편함과 우체국을 생각해보자.
- 각 집마다 편지를 받는 공간인 우편함이 있다.
- 발송될 편지는 우체국에 모아놨다가 한꺼번에 차에 실어 보낸다.
- Electronim Mail도 이와 비슷하지 않을까?
메일서버의 구조
- Mail box : 사용자마다 따로 가지고 있는 수신메일을 담는 자료구조다.
- Message Queue : 송신될 메세지를 담는 자료구조다.
- Message Queue는 일정시간 주기로 SMTP 프로토콜로 받는 측 서버에게 보낸다.
- 받는 측 서버는 받은 메세지를 수신자 별로 알맞게 분리해서 Mail box에 넣는다.
- 절대 Off되지 않는다.
SMTP
- 이메일 전송을 위한 프로토콜이다.
- Http와 마찬가지로 Data Integrity가 중요하므로 TCP 위에서 작동한다.
- 커맨드 라인으로 메세지를 송수신하며
- 송신자를 지정하는 MAIL, 수신자를 지정하는 RCPT, 데이터의 시작을 알려주는 DATA 명령어등으로 구성된다.
- port번호는 25번
- client message: command가 있고, server message는 response가 있다.
- command: ASCII 코드로 구성, response: status code와 phrase로 구성
- messages는 반드시 7-bit ASCII code가 되어야 한다.
HTTP vs SMTP
- HTTP는 요청을 보내서 정보를 가져오는(PULL) 프로토콜이다.
- SMTP는 정보를 보내는(PUSH) 프로토콜이다.
- 그러면 수신 측 서버와 수신 측 클라이언트 간 통신은 PUSH 성격을 가지는 SMTP는 적절하지 않다.
수신측 서버 - 클라이언트 간 프로토콜
- Mail Access Protocol이라고 한다.
- POP, IMAP, HTTP가 사용된다.
POP
- 인증 단계와 트랜잭션 단계로 구성된다.
- 다운로드-삭제 모드와 다운로드 - 유지 모드가 있다.
- 어쨋든 Stateless하다.
IMAP
- 모든 메세지를 서버측에 저장해서 State를 유지한다.
- 대신 서버 부담이 커진다.
