2.1 principles of network application
L5 레이어의 두 가지 구조
- 클라-서버(HTTP,SMTP,DNS)
- p2p
client-server 아키텍쳐
서버: 항상 켜져 있고 ip 주소 영구적.
클라: 대화를 엶. 서로와 직접 소통 x. ip 주소 다이나믹.
p2p 아키텍쳐
항상 켜져 있지 않음. 일시적으로 연결되고 ip 바꾸기 가능.
self scalability- 새로운 peer의 join은 곧 더 많은 서버.
Soket
L5와 L4 사이의 문짝.
Addressing processes
host device는 L2의 NIC(Network Interface Card), identifier은 ip addr와 port num 있어야.
※ DNS가 공식 url을 ip addr로 바꿔줌.
유명 포트 넘버
HTTP: 80
mail 서버: 25
L5프로토콜
RFC(표준.http)
skype(비표준)
L4가 L5에게 제공하는 서비스
- data integrity(loss)
- timing(delay): loss 있어도 되니까 빨리오렴~
- throughtput (최소 bw 필요)
tcp는 1만 제공, udp는 1-3 전부 제공 안함. L5가 알아서 만들어 쓰기.
tcp 서비스
reliable transport.
connection-oriented(set up)
flow control
congestion control
udp 서비스
unreliable data transfer
프로세스 찾기+ e2e error checksum
2.2 Web and HTTP
HTTP overview
http가 web을 서비스
web page는 base HTML 파일과 referenced obj(url로 addressed되는..)으로 구성
obj url은 자기 서버에 있을 수도 있고 남의 서버에 있을 수도 있음. 아무튼 어딘가에서 가져와 넣어준다.
HTTP: hypertext (transfer protocol)
client: browser that request,receive,display
server: http 프로토콜 이용, 리퀘에 맞는 obj 보내는 웹서버
→ HTTP 써서 메세지 주고 받음. HTTP는 TCP 사용!
(오랫 동안 주고 받을 땐 한번 연 통로 계속 쓰는 tcp가 좋다.)
Overall HTTP Operation
http는 stateless. 각각의 리퀘는 별개임!
→ 장점: dynamically load balance request accross multiple servers!
만약 state 였다면?
과거 히스토리 유지, 충돌시 조정 필요 → 복잡...
HTTP Connections
- non-persistent HTTP: multiple obj →multi connection.
- persistent HTTP: 한 번 열고 계속 씀. 서버는 부담일 수 있다.
✔ non-persistent HTTP의 경우 10개 obj있는 html 서비스 위해..
(tcp 열기 + base html 가져오기)+ 10개 obj (tcp 열기 + obj 가져오기)=(1+1)+10(1+1)=22RTT time 소요.
✔ persistent HTTP의 경우 10개 obj있는 html 서비스 위해..
(tcp 열기 + base html 가져오기+ 10개 obj 한번에 가져오기)=(1+1+1)=3RTT time
pipelining
리퀘에 대한 반응 받기도 전에 다음 리퀘 연달아 보내는 것. ordering 있는 tcp만 가능!
HTTP request message
host 항상 명시하는 이유는 proxy 서버 때문!
User-server state: cookies
HTTP 프로토콜은 stateless지만, 쿠키가 있으면 stateful 서포트 가능 (stateful HTTP)
첫번째 연결에 서버가 unique id 할당- 두번째 연결부터는 리퀘에 쿠키 헤더가 포함됨.
※ pc의 하드 디스크에 쿠키 ID 저장됨. (즉 pc 바뀌면 못알아봄...)
cookie can be used for..
authorization
쇼핑카트
추천
user session state(웹 이메일)
Web caches (Proxy Server)
hit: LAN(아니면 access network ISP)안에서 끝남.
miss: external link 타고 나가야...
※ proxy가 origin server에서 가져와야 하는 상황이라면 프록시가 클라.
※ 보통 access network ISP 안에 캐시 둔다. (대학, 회사, 지역..)
장점: 반응 시간을 줄임. traffic 줄임. p2p같은 허접한 서버가 잘 동작할 수 있게 도움.
2.3 Electronic mail
3 major component
보내는 애: Mail User Agent(MUA)
받는 애: Mail Transfer Agent(MTA)
메일 전송 프로토콜: SMTP
Electronic mail: mail servers
mail box: incoming msg 저장
message queue: outgoing msg 저장
SMTP 프로토콜:
- SMTP 클라이언트: sending mail server
- SMTP 서버: receiving mail server
※ SMTP입장에서 클라/서버 관계는 유동적임!
※ 두 SMTP 사이에 다른 SMTP 서버 x. 다이렉트로 연결!
Electronic mail: SMTP
mail은 reliable해야 돼서 tcp 사용.. 그러므로 절차는
1. handshaking
2. SMTP msg 전송
3. closure
※msg는 7bit ASCII여야 함!
SMTP v.s. HTTP
push 프로토콜-SMTP
receving mail 서버에 mail push
persistent connection 사용
port #25
7-bit ASCII로 인코딩 방법 통일!
모든 obj를 싱글 메세지로.
pull 프로토콜-HTTP
persistent랑 non persistent 둘 다 사용
port #80
7-bit ASCII 외 다른 인코딩 써도 됨
obj마다 각자의 http msg 가짐
pull 프로토콜 예시: POP, IMAP
Mail access protocols
POP: Post Office Protocol
'download and delete' → 내가 다운받으면 서버는 삭제 → 장소 이동시 메일 증발 → 🤨해결책 없어? → 'download and keep' → 근데 얘도 읽었는지 여부는 알 수 없어...
✔POP는 stateless!
IMAP: Internet Mail Access Protocol
http-gmail등...이런 애들은 메일 설치 필요 없이 웹만 잇으면 가능! 서버에서 메일을 keep하고 있다.
✔IMAP은 statefull!
