keyword
HTTP, SMTP, IMAP, DNS, CDNs
client-server architecture
- server: ip 항상 고정, 항상 켜져 있음
- client: 필요할 때만 연결, dynamic ip address (by DHCP)
클라이언트들끼리 직접 통신 x, HTTP, IMAP, FTP ...
peer-peer architecture (p2p)
동등한 peer끼리 직접 통신, 새로운 peer가 나타나면 규모가 늘어남
peer들이 있었다 없어졌다 하면서 ip주소 바뀌는 것까지 고려해야함(뽁잡)
prcoess communicating
prcoess: 호스트 내부에서 동작하는 프로그램
같은 호스트 내부에서 두 프로세스는 inter-process-communication으로 소통(IPC)
다른 호스트에 있는 프로세스들은 메시지를 교환하여 소통
Sockets
소켓: 프로세스 간 메시지를 주고받는 인터페이스 (문이라고 생각하자)
문 밖으로 내놓기만 허면 알아서 보내줌 (블랙 박스)
AL, PL 사이에 있음
What transport service does an app need?
* data reliability (신뢰성) <- tcp만
* timing (딜레이 보장, 데이터 전달하는데 걸리는 시간) <- tcp, udp 모두 x
* throughput (처리율, 단위 시간 당 얼마나 많이 전달?) <- tcp, udp 모두 x
* security(보안) <- tcp, udp 모두 x
Internet transport protocol service (tcp, udp)
* tcp
- reliable transport (no loss, ordering 보장)
- flow control (흐름 제어, 라우터의 버퍼 가능한만큼만 보내)
- congestion control (혼잡 제어, 모든 sender 보내는 비율 줄여)
- connection oriented (통신 전에 커넥션 설정 필요)
- 지원 안해 (timing, minimum throughput guarantee, security)
* udp
- unreliable data transfer (best effort, 노력은 하지만 보장은 못해줘)
- 지원 안해 (reliability, flow control, congestion control, /timing,
throughput guarantee, security/, connection setup)
* 그럼 udp는 왜 있어? tcp의 연결 설정이 부담(오버헤드)되면 udp 쓸려고
Securing TCP
처음 제안된 tcp/udp는 암호화 없었음 (평문)
* Transport Layer Security(TLS)
- SSL (Secure Sockets Layer)을 뒤이어 나옴
- tcp 커넥션에 대해 암호화, 데이터 무결성, end point authentication 제공
- application 레이어에 라이브러리 형태로 존재
- 평문이 소켓으로 보내지면 TLS에서 암호화되서 목적지까지 전달됨
Web and HTTP
HTTP (hypertext transfer protocol): 브라우저 서버간 통신할 때 사용
- 웹에서 사용되는 어플리케이션 레이어 프로토콜
- 클라이언트-서버 모델을 따름
* 특징
1) TCP 사용
- 클라이언트는 소켓을 만들고 TCP connection을 요청 (포트번호 80)
- 서버가 TCP connection을 클라이언트로부터 받으면 http message가 전달
- TCP connection closed
2) stateless (상대방 상태를 기억못함)
- 필요하다면 쿠키를 사용해서 관리
- 기본적으로 stateless (stateful이면 inconsistent가 발생할 수 있어서 관리 복잡)
* connection 2type: Non-persistent, Persistent
Non-persistent HTTP (~1.0 버전)
object 하나 보내고 연결 닫음, object가 여러개라면 여러개의 connection 필요
-> 비효율적
* 과정
1a) http 클라이언트가 http 서버에게 포트번호 80번으로 tcp 커넥션 요청
1b) http 서버는 기다리고 있다가 커넥션 받아들이고 클라이언트에게 알려줌
2) 클라이언트는 클라이언트가 원하는 object를 포함하는 request message를 소켓을 통해 보냄
3) 서버는 req msg를 받고 원하는 내용을 포함하는 response msg를 만들어서 소켓으 통해 보냄
4) 서버가 tcp 커넥션을 끊음
5) 클라이언트는 response msg 받고 화면에 표시함
html을 파싱하는 과정에서 10개의 참조된 이미지 발견
6) 이 과정을 10번 반복
* RTT: 작은 패킷이 클라이언트를 떠나 서버에 갔다가 다시 돌아오는 시간
(for "propagation-delay" 잴려고, 패킷이 크면 transmission delay 커서 작은 패킷 사용)
* HTTP response time (per object)
- tcp connection 맺는데 1RTT
- request 보내고 response의 첫 바이트 들어오는데 1RTT
- 오브젝트 파일이 크면 transmission time 커짐
-> Non-persistent Http Response time = 2RTT + file transmission time (object마다)
Persistent HTTP (1.1 버전 ~ 현재 3.0까지 출시됨)
하나의 TCP connection을 통해 여러개의 object 전달 가능
* Non-persistent Http의 문제
- object마다 2RTT 요구
- 커넥션을 만드는데 오버헤드 발생
- parallel TCP connection이 생길 수도 있음
* persistent HTTP
- 서버가 response를 보내고 나서도 커넥션 계속 열어놓음 (유지)
- 같은 클라이언트와 서버는 열려있는 커넥션을 계속 사용
- 요청에 대한 응답을 기다리지 않고 한 커넥션으로 한번에 연속하여 요청 가능
- 모든 referenced object 보내는데 1RTT정도 걸림
HTTP request msg
http req msg는 ASCII 형태로 구성 (사람이 읽을 수 있음)
header + body로 구성 (엔터, 엔터로 둘 사이 구분)
cr = carriage return, lf = line feed로 둘 다 enter키
* 종류
- POST: entitiy body에 사용자 input을 담아서 전달 ex) 폼
- GET: 클라이언트가 서버로 url을 통해 값을 전달
- HEAD: 헤더 부분만 요청 (for 개발자가 test)
- PUT: upload, replace
HTTP response msg
status line
status code: 200 OK, 301 Moved Permanently, 400 Bad Request
404 Not Found, 505 HTTP Version Not Suuported
-> status code는 resonse msg 첫번째 줄에 나타남
브라우저 이외의 방식으로 web에 접근하기
1. netcat to your favorite Web server
2. type in a GET HTTP request (사용자가 직접입력)
3. look at response msg by HTTP server
Maintaining user/sever state: cookies
http는 stateless -> 이 한계 극복하기 위해 쿠키 도입 (사용자 식별용 데이터)
쿠키는 서버가 만든다!!
* 과정
1) 클라이언트가 서버로 req 메시지 보냄
2) 서버에서는 id를 하나 새로 만들어서 쿠키로 세팅하고 클라이언트로 response함
(필드에 값으르 지정하는 방식), 동시에 관련 정보들을 db에 저장
3) 다시 접속할 때 쿠키 번호를 req msg에 담아서 함께 보냄 (쿠키가 자동으로 붙음)
4) 서버에서는 해당 쿠키에 맞는 것을 db에서 찾아서 response
=> 클라이언트에 쿠키 파일 없으면 서버에서 id 생성해서 response msg에 담아서 보냄
서버는 id를 db에 저장
만약 클라이언트에 쿠키가 있으면 req msg에 쿠키가 자동으로 붙어서 보내지고
서버는 db에서 쿠키에 맞는 것을 찾아서 response msg에 함께 보내줌
쿠키가 state를 저장하고 있고 http는 쿠키를 전달만 해주는 것임
* third party cookies: 대부분 광고 목적
Web Cache (proxy server)
자주 가져오는 object들을 cache에 저장해두고 원래 서버까지 갈 필요 없이 cache에서 받아옴
- 캐시는 클라이언트/서버 역할 둘다 함
- resonse header에 object's allowable 서술
Cache-Control: max-age=<seconds> : seconds동안은 최신임을 보증
(나한테 second동안은 물어보지마)
Cache-Control: no-cache (캐시를 저장하되 캐시가 유효한지 서버에게 매번 확인해)
Cache-Control: no-stroage (캐시 저장하지마)
- client 입장에서 response time 줄일 수 있음
- 기관의 access link의 트래픽 줄일 수 있음
conditional GET (내가 갖고있는 object이 최신이냐)
Get method의 옵션에 "If-modified-since <date>" 추가
<date>에는 response msg의 last-modified 필드의 값이 들어옴
- 데이터 안 바꼈으면 서버에서 캐시로 304 Not Modfied 응답
- 데이터 바꼈으면 서버에서 캐시로 200 메세지랑 새 데이터 응답
캐시 업데이트하고 클라이언트에 데이터 전송
HTTP/2, HTTP/3
1.0: Non-persistent
1.1: multiple, pipelined GETs over single connection 도입 (persistent)
* 1.1의 한계
- 서버는 순서대로 응답 (FCFS)
- FCFS 때문에 head-of-blocking (HOL blocking) 발생
- loss 발생하면 받을 때까지 재전송하는 것 때문에 stall 발생 (tcp 사용해서 그럼)
* 2.0: flexibility at server 증가
- 우선 순위 지정 가능 (not necessarily FCFS, 숫자 클수록 우선순위 높음)
- client가 요청하지 않은 object도 함께 제공 가능 ex) 연속된 페이지
- object를 프레임으로 쪼개서 HOL blocking 해결, 쪼개진 프레임은 round-robin
- 하지만 여전히 packet loss 발생하면 그 뒤로 모두가 멈춤
* 3.0: tcp 버리고 udp 쓰자!!!! 대신 error control을 위해 QUIC 추가
* 요약
HTTP 1.0: non-persistent
HTTP 1.1: persistent, HOL Blocking 해결 못함
HTTP 2.0: HOL Blocking 해결, but loss 일어나면 모두 stall
HTTP 3.0: 이거 해결하려고 udp 쓰고 quic 추가하자
E-mail (SMTP, IMAP)
* components
- user agents, mail servers, SMTP(simple mail transfer protocol)
1) user agents (mail reader)
- 메일 구성, 수정, 읽기 ex) outlook, iphone mail client
- 메일 서버를 통해 메일 보내거나 받음
2) mail server
- 받은 메일을 mailbox에 저장
- 보낼 메일들을 message queue에 넣음
- 메일 서버들 간에 SMTP 프로토콜을 이용하여 메세지 주고받음
3) SMTP
- 신뢰성 위해 TCP 사용, 25번 포트 사용
- Direct transfer: sending 서버가 receiving 서버로 직접 전달
- 전달 과정: STMP handshaking(연결 설정), 실제 전송, 연결 종료
- 메시지는 7비트의 ASCII 코드
- HTTP처럼 클라이언트가 command 보내면 서버가 status code, pharse로 응답
* STMP 정리
- persistent connection 사용
- SMTP req 메시지는 7비트 ASCII
- CRLF.CRLF로 메시지의 끝을 알림
HTTP는 각각의 오브젝트들이 자기 자신의 response 메시지로 캡슐화되어 전달
SMTP는 여러 오브젝트들이 메세지의 여러 파트에 담겨서 한번에 전달
- SMTP는 ASCII만 지원하기 때문에 사진, 음악 등은 MIME
(Multipurpose Internet Mail Extension) 포맷으로 변환되어 전달
* IMAP(Internet Mail Access Protocol): 메일 서버에서 도착한 메일 받아올 때 사용
(검색, 삭제, 폴더 기능 제공)
- 최근에는 web-based interface 써서 SMTP, IMAP의 역할을 HTTP가 대체
