Study/정보통신공학

[Week 3-1] Web - HTTP, Cookie, Cache, E-mail

ansui 2023. 4. 10. 21:05

Chap 2. Protocol Architecture, TCP/IP, and Internet-Based Application

 


< Web >

: 네트워크 상의 디바이스 간 상호작용을 위한 소프트웨어 시스템

: object로 구성 - HTML file(markup language), JPG, audio file...

: 기본적으로 HTML file을 가지고 있고, 이 HTML file이 JPG, audio file을 포함

: 각 object는 URL로 식별 가능

 

 


< HTTP >

: HyperText Transfer Protocol

: Web application layer protocol ( 서비스를 제공하는 프로토콜)

: TCP 사용

: client(request, receive) - 브라우저 / server(send, response) model

: stateless → 과거의 정보(상태)를 저장 x

: port # = 80

 

 

**stateless**

multi-step exchange 상태 추적 x
: 모든 HTTP 요청은 서로 독립적
: 클라이언트/서버가 부분적으로 완료되었을 때

완료되지 않은 트랜잭션에서 제거하지 않아도 됨

: 만약 state를 유지한다면 (stateful) 매우 복잡

(과거 기록 유지보수, server/client 충돌 해결, 불일치성 해결해야 함)

 

 

< HTTP 과정 >

1. client가 server와 TCP 연결을 시작

: server의 port # 80으로 대기 client는 url로 TCP connection을 열고 socket 생성

2. server가 TCP 연결을 수락

3. client(brower)와 server(web server)간에 HTTP 메시지 교환

4. TCP 연결이 닫힘

 


< HTTP Request Message >

 

1) Request line

> GET: 서버에 resource 전송 요청 (URL field)

> POST: 서버에 form data 전송 (entity body) - user input을 타이핑하여 넣음

> HEAD: GET method를 사용하여 지정된 URL을 요청한 경우 반환되는 헤더만 요청

> PUT

: 서버에 새 파일 업로드

: 지정된 URL에 있는 파일을 entity body에 있는 내용으로 완전히 바꿈

 

2) Header lines

> Host: Host name

> User-Agent: browser의 종류

→ 브라우저의 종류는 동일한 object의 다른 버전을 다른 유형의 브라우저로 보내려는 서버에게 필요하기 때문에 명시

> Accept-language: 원하는 언어

> Connection: persistent connection의 유무

 

3) Header line의 끝

> \ r: carriage return

> \ n: line-feed character

 


< HTTP Response Message >

 

1) Status line

: Protocol(HTTP) + Status code + Status phrase

 

2) Header lines

- Date: 이 메세지(요청)가 만들어진 시각 (request generation time)

- Server: Server 종류

- Last-modified: 마지막 수정 시각

- Content-length: Header line 후에 나오는 요청된 HTML 파일의 길이 (bytes)

- Connection: persistent connection의 유무

- Content-Type: html, css...

 

3) Header line의 끝

- \ r: carriage return

- \ n: line-feed character

 

 

< HTTP Response Status Code >

- 200 OK

: 요청이 성공, object가 body에 담겨 있음

 

​- 301 Moved Permanetly

: 요청한 object의 위치 변경

 

​- 400 Bad Request

: request message가 잘못되어서 서버에서 이해 x

 

- 404 Not Found

: request document를 해당 서버에서 찾을 수 x

 

- 505 HTTP Version Not Supported

: 서버가 지원하지 않는 HTTP Version의 메시지를 요청했을 때

 


< User-Server state: Cookies >

: 유저의 상태 정보 저장

: HTTP는 stateless 쿠기를 사용하여 데이터를 저장 같은 요청이 들어오면 데이터를 기반으로 더 나은 서비스 제공

: HTTP response/request message에 쿠키 헤더 라인이 존재

: 쿠키 정보들은 user의 host, 웹 서버의 backend database에 저장되어 관리

 

 

< Cookie에 필요한 4가지 Components >

1. cookie header line of HTTP response message

2. cookie header line in next HTTP request message

3. browser에서의 cookie file을 보유

4. Web-site에서의 back-end database에 저장

 

 

< Cookie example >

 

사용자가 쇼핑몰(아마존)에 접속

request msg를 server에 전송 
server가 client에게 ID 생성 및 제공 & cookie는 DB에 저장
cookie는 response msg에 넣어 client에게 전송 
client는 cookie를 포함한 request msg를 전송  
server는 cookie를 보고 그에 맞는 특정한 일을 함 
일주일 후, 서로 아는 쿠키를 이용하여 통신

 

 

< Cookie를 이용하여 할 수 있는 일 >

- authorization (허가)

- shopping carts

- recommendations

- user session state (Web e-mail)

 

*Cookie를 허용하면 DB에 사용자의 정보 저장 가능 privacy 문제 o

 


< Web Caches (Proxy server) >

: origin server의 관여 없이 client의 request를 처리

: client가 Web cache를 이용하여 server에 접속

: 만약 object가 cache에 있다면 → proxy server에서 처리

: 만약 object가 cache에 없다면 origin server에서 처리 

: Web cache는 client/server 둘 다의 역할

: 대학, 회사, residential ISP (가정용 ISP)에서 이용

 

 

< Web Cache를 사용하는 이유 >

1. access link의 traffic을 줄이기 위해

2. client의 request에 대한 "response time"을 줄이기 위해 (cache is closer to client)

3. poor 컨텐츠 provider가 컨텐츠를 보다 효과적으로 제공할 수 있도록 지원하기 위해

 


 

< E-mail의 주요 요소 >

1) user agents

: 메일을 읽고 쓰는 작업을 하는 것

: "mail reader"

: POP / IMAP

 

2) mail servers

: 사용자에게 온 메일을 저장하는 메일 박스 (받은 메일함)

: 보내는 메일을 담고 있는 메시지 큐 존재 (보낸 메일함)

 

3) protocol - SMTP

: 메일 서버 간 통신 프로토콜

: client - sending / server: receiving

 

 

< E-mail example: Alice가 Bob에게 메일을 보내는 과정 >

 

1. 앨리스가 UA(user agent)를 이용하여 메세지 작성

2. 앨리스의 UA → 앨리스의 mail server (message queue에 저장) - SMTP 사용

3. SMTP로 밥의 mail server TCP연결 open

4. TCP로 앨리스의 mail server 밥의 mail server

5. 밥의 mail server가 메일을 mailbox에 저장

6. 밥의 UA가 내용을 읽음

 


< SMTP (Simple Mail Transfer Protocol) >

: TCP 사용 (신뢰 o)

: persistent connections 사용

: port # 25

sending server와 receiving server 간 direct transfer

: 전송단계 - handshaking / transfer of messages / closure

: commands - ASCII text / response - status code, phrase

: 7-bit ASCI

 

 

< Sample SMTP interaction >

 

- 첫 줄: server의 mail server name (받는 사람)

- 두번째 줄: client의 mail server name (보내는 사람)

- server의 250번 응답으로 greeting 완료

- RCPT TO: 수신자 밝힘

 

 

< SMTP vs HTTP >

SMTP HTTP
server로 보냄 (push) server로 가져옴 (pull)
multiple object를 하나의 메세지로 전송 object를 각자의 메세지에 넣어 전송
ASCII command / response 상호작용
status code 사용
RFC 531

 


< Mail access protocols >

 

1) SMTP

: UA mail server / mail server → mail server (TCP)

 

2) mail access protocol

: IMAP

: mail server UA

 

3) HTTP

: gmail, Hotmail, Yahoo!Mail...

: mail server UA

: web 기반의 interface 사용

: SMTP(전송할 때), IMAP/POP 위에 web 기반 interface를 제공하여 e-mail 메시지를 검색

 


교재는 Data and Computer Communications를 참고하였고, 자료는 이화여자대학교 이형준 교수님의 정보통신공학 강의에서 가져온 것입니다.