- 라우터들은 end-to-end 아님 - transport layer까지 필요 X
- 패킷이 목적지까지 도착하면 network 계층에서의 역할 끝 -> transport layer로 올려줌 (NL, AL은 end-to-end)
- HTTP
- IMAP - 파일
- FTP - 이메일
- inter-process communication : same host 내 process끼리의 통신, OS에서 제공
- socket에서 process를 addressing할 때 필요한 정보 : IP, port, TL(TCP or UDP)
- well-known port : HTTP(web) server - 80 / mail server - 25
Application Layer protocol이 정의하는 것들
- 메시지 타입 (request or response)
- message syntax (메시지에 어떤 필드들이 있고 어떻게 구분되는가)
- message semantics (각 필드의 의미)
- 프로세스들이 언제/어떻게 메시지를 주고받을지에 대한 규칙과 절차
Application에 따른 필요한 transport service
- data integrity
- 보장 필요 : file transfer, web transaction, e-mail
- loss-tolerant : audio, streaming video, interactive games
- timing
- low delay 요구 : interacive games
- throughput
- security
| application | AL protocol | transport protocol |
|---|
| file transfer/download | FTP | TCP |
| e-mail | SMTP | TCP |
| web documents | HTTP 1.1 | TCP |
| streaming audio/video | HTTP, DASH | TCP |
| Internet telephony | | TCP or UDP |
| interactive games | | TCP or UDP |
Transport Layer Security (TLS)
security TCP
1. 암호화 (provides encrypted TCP connections)
제 3자로부터 전송되는 데이터를 숨김
2. 인증 (end-point authentication)
정보를 교환하는 당사자가 요청된 당사자임을 보장
3. 무결성 (data integrity)
데이터가 위조되거나 변조되지 않았는지 확인
HTTP (hypertext transfer protocol) 특징
- client / server model
- TCP 사용
- stateless : 서버는 클라이언트의 과거 request에 대한 정보 유지 X
HTTP 종류
- Non-persistent HTTP
- TCP connection이 맺어지면 해당 connection을 통해 최대 하나의 object만 전송
- Non-persistent HTTP response time = 2RTT + file transmission time
- 문제점(1) : object당 2RTT가 필요하다. (TCP connection 시작 + HTTP request)
- 문제점(2) : 각 TCP connection마다 OS overhead가 추가된다.
- 문제점(3) : multiple objects들을 다운로드 하려면 multiple connections이 필요하다.
- Persistent HTTP
- 특정 서버에서 TCP connection을 1번만 만들어놓고 유지한다.
- multiple objects들도 single TCP connection으로 전송 가능
※ RTT (Round Trip Time) : 송신측에서 패킷을 목적지에 보낼 때 패킷이 목적지에 도달하고 나서 해당 패킷에 대한 응답이 출발지로 다시 돌아오기까지의 시간
HTTP 버전
E-mail
The Domail Name System (DNS)
- 도메인 이름에 해당하는 IP주소로 변환해주는 서비스 제공, AL protocol
- 변환한 IP 주소는 패킷의 헤더 부분에 들어감
- 많은 name server들의 계층 구조(tree)로 구현된 분산 database
- 계층 구조
- Root DNS Server : 최상위 서버
- Top Level Domain (TLD) Server : .com, .org, .net 같은 top level의 country domain을 담당
- Authoritative server : 조직이나 서비스 제공자가 관리
- Local DNS Server : host가 DNS 쿼리를 날리면, 그 쿼리는 일단 local DNS Server에 보내진다 -> local cache에 있으면 그걸 반환해주고, 없으면 계층적 DNS 구조에 쿼리를 보낸다.
- 각 ISP들은 local DNS server를 가지고 있다
- 쿼리 방식
- iterated query : 연결된 서버가 새로 연결할 서버의 이름을 알려준다.
- recursive query : 연결된 name server로 name resolution 책임을 넘긴다.
- root server에 너무 큰 부담을 준다는 단점
Peer-to-peer (P2P)
- always-on-server 없이, 임의의 end system끼리 직접 통신
- peers들은 서로에게 서비스를 요청하고 제공
- 장점 : one-point failure를 피해갈 수 있다
cf) server-client는 서버가 터지면 서비스 중지
- 구현 방법(1) : 서버 컨셉을 가지고 있는 P2P (어떤 파일을 누가 가지고 있는지에 대한 정보 올림)
- 구현 방법(2) : 서버 컨셉 없는 P2P (P2P망 형성, Logical network)
- spatial redundancy (공간적으로 동일한 정보) 제거
- temporal - 바뀌는 부분의 정보만 전달
-> 데이터 전송량 줄임
- CBR(constant bit rate) : MPEG 사용 X -> 항상 일정한 rate로 전송
- VBR(variable bit rate) : MPEG 사용 O
DASH (Dynamic, Adaptive Streaming over HTTP)
- client가 bandwidth를 측정하고 chunk 파일을 요구하는 방식 (client에게 부담이 감)
- 서버
- 동일한 콘텐츠의 비디오를 chunk로 잘라서 각 chunk를 다양한 인코딩 rate로 저장해놓음
- manifest file에 파일 각각의 encoding rate와 각 chunk를 어디에 요청할지 기록되어 있음
- 클라이언트
- 지속적으로 server-to-client bandwidth 측정 (server에서 측정하면 모든 클라이언트 고려 필요하므로 오버헤드가 큼)
- manifest 파일을 보고 해당 url로 chunk 요청
- 현재 주어진 bandwidth를 보고 지속가능한 최대의 coding rate 선택
- 각 시간에 따른 적절한 bandwidth로 시간마다 다른 coding rate의 chunk 파일을 받을 수 있다.
Content distribution networks (CDNs)
- 지역적으로 분산된 장소에 여러 개의 video 복사본을 저장하고 제공
- enter deep : client와 가깝게 수많은 작은 서버를 연결시키는 방식
- bring home : 적은 수의 핵심 지점(PoP, Point of Presence)에 큰 규모의 서버 클러스터 구축
CDN service와 DASH protocol
: user가 content를 선택하면 manifest file을 통해 CDN server를 하나 선택하고, 그 후에 DASH protocol을 통해 실질적으로 데이터를 받아온다.