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로 식별 가능
: 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를 참고하였고, 자료는 이화여자대학교 이형준 교수님의 정보통신공학 강의에서 가져온 것입니다.
'Study > 정보통신공학' 카테고리의 다른 글
[Week 4-1] Data Transmission (2) | 2023.04.12 |
---|---|
[Week 3-2] Socket programming for TCP and UDP (0) | 2023.04.11 |
[Week 2-2] Principles of Network Applications (0) | 2023.04.09 |
[Week 2-2] Protocol Architecture, TCP/IP (0) | 2023.04.09 |
[Week 2-1] Network Core - Packet/Circuit switching, Internet structure (0) | 2023.04.08 |