Application Layer
- end system에 존재(transport도)
- 몇몇 네트워크 앱: web, social networking, e-mail, zoom, youtube, netflix
creating a network app
<프로그램 작성>
- 다른 end systems에서 작동
- network를 통해 통신
- 예 : 웹 서버 소프트웨어랑 브라우저 소프트웨어랑 통신
네트워크 코어 장비를 위한 또 다른 소프트웨어를 필요로 하지 않는다
- 네트워크 코어 장비는 유저 애플리케이션을 실행하지 않고, end systems의 애플리케이션을 통해 신속한 앱 개발, 전파
(결국 network core는 관여안하고 end system끼리 통신하여 개발한다는것)
Application architectures
(1) Client-server paradigm
- Server
: 항상 켜져 있는 호스트(always-on host)
: 서비스를 제공하는 주체가 되며, 모든 서버는 호스트이지만, 모든 호스트가 서버인 것은 아님 → 네트워크에 연결이 확립된 모든 장치는 호스트의 자격이 있는 반면, 다른 장치(클라이언트)로부터의 연결을 수락하는 호스트만 서버가 될 수 있다.
: 영구적(permanent)으로 고정된 IP address를 사용하며, 각 server를 IP 주소로 구분한다.
: 데이터 센터로 확장될 수 있다
(웹 개발자가 된다 == 웹 서버 개발자가 된다)- Client
: 서버와 통신한다 -> 서버에 서비스 요청
: 클라이언트 간에 직접 통신하지 않는다 -> 서버를 거쳐 통신
: 유동 IP(dynamic IP) 주소를 가진다.(고정 IP를 사용할 수도 있다.) → Internet을 사용할 시점에 받아온다.
: 항상 연결되어 있지 않고, 간헐적으로 통신할 수 있다(client의 필요에 따라)
: ex) HTTP, IMAP, FTP
(2) Peer-peer architecture
- 항상 켜져 있는 서버가 없다(no always on server)
- 임의의 end-system들이 직접적으로 통신한다
- peer가 다른 peer에게 서비스를 요청하고 및 제공함 (동등한 관계)
클라이언트 수가 많아지더라도 안정적 = 높은 self-scalability(확장성)를 갖는다.- 여러 peers가 간헐적으로 연결되고 IP 주소를 변경한다(복잡한 관리)
Processes communicating
- Process : 호스트 내에서 실행 중인 프로그램
: 같은 호스트 내에서 두 프로세스가 OS에서 정의한 IPC(Inter-process communication)를 이용해 통신한다.
: 다른 호스트 간의 프로세스들은 메세지(Message)를 교환하여 통신한다.- Client, Servers
Client process : 통신을 시작하는 process
Server process : 세션을 시작하기 위해 접속을 기다리는 process- P2P 구조의 application들은 클라이언트 프로세스와 서버 프로세스를 가진다.
Sockets
- Process는 소켓을 통해 네트워크로 메세지를 주고받는다
- Host의 application-layer와 transport-layer 간의 인터페이스
- 소켓을 문으로 비유하면, 보내는 과정(sending process)은 메세지를 문 밖으로 밀어내는 것이다.
메세지를 받기 위해, process는 반드시 식별자(identifier)가 있어야 한다. Host device는 유니크한 32-bit IP 주소를 가지고 있다.
Addressing processes
- 메시지를 받기 위해 프로세스는 반드시 식별자가 있어야한다.
- 호스트 디바이스는 유니크한 32bit IP 주소를 가진다
- Q: 프로세스를 식별하기 위해 프로세스가 실행되는 호스트의 IP 주소로 충분합니까?
- A: 아니요, 많은 프로세스들은 같은 호스트에서 실행됩니다.
- 식별자는 호스트의 프로세스들과 연관된 IP address, port numbers를 포함한다.
ex) 포트 넘버 = HTTP server : 80, mail server : 25Applications-layer protocol defines
메세지를 주고 받기 위해서는 프로토콜이 필요
.
- 어떤 타입의 메세지가 전달 되는가 ex) request, response
- 메세지 syntax(구문) : 메세지의 필드 및 필드 설명 방법
- 메세지 semantics(의미) : 필드가 의미하는 바가 무엇인지
- rules : process들이 언제 메세지를 보내고 받으면 어떻게 처리할지 등
- 오픈 프로토콜 : 누구나 프로토콜에 엑세스 가능
: 상호 운용성 허용 ex) HTTP, SMTP
: 독점 프로토콜 ex) Skype, Zoom
What transport service does an app need?
(Application은 transport layer의 service 사용)
- Data integrity(데이터 무결성) : 메세지를 보내면 반대쪽 애플리케이션에서 완전하게 수신이 될 것을 트랜스포트 레이어가 보장해준다.
: 일부 앱(파일 전송, 웹 트랜잭션)은 100% 안정적인 데이터 전송이 필요, 다른 앱(오디오)는 그럴 필요 없이 일부 손실 허용
: 경우에 따라 애플리케이션에서 TCP(reliable), UDP(unreliable) 선택 가능- Timing(시간) : 효율성을 위해 낮은 딜레이 보장
: 패킷이 반대편 서버에 몇 초 안에 무조건 도착하는 것을 보장(TCP, UDP는 보장x)
: 인터넷 전화, 대화형 게임 등의 경우 딜레이 보장이 필요- Throughput(처리율) : 시간 당 데이터 전송 처리량(효과적인 최소한의 throughput을 요구)
: 효과적인 최소 처리량 요구(넷플릭스 등 멀티미디어), 그러나 elastic app 들은 처리량 활용(TCP, UDP는 보장x)- Security : encryption(암호화), data integrity(데이터 무결성)을 확인(TCP, UDP는 보장x)
Internet transport protocols services
TCP services:
- Reliable transport(신뢰 전송) : 송신, 수신하는 process 사이 신뢰, 안정성 보장
- Flow control(흐름 제어) : sender 수 <= receiver 수
- Congestion control(혼잡 제어) : 네트워크가 과부화됐을 때 sender 조절
- Connection-oriented(연결 지향) : client, server process간의 설정 필요
제공하지 않는 항목 : security, timing, minimum throughput guaranteeUDP services:
- Unreliable transport(비신뢰 전송) : 송신, 수신하는 process 사이 신뢰, 안정성 보장 안함
제공하지 않는 항목 : reliability, flow control, congestion control, timing, throughput guarantee, security
Q : UDP가 있는 이유는?
--> UDP는 TCP에 비해 패킷 크기가 작아서 처리 속도 빠름
Transport Layer Security(TLS)
TCP, UDP는 어떤 보안도 제공하지 않아서 문제가 있음(데이터는 전송프로세스의 소켓의 일부가 되고 이것들은 목적지 프로세스를 찾기 위해 네트워크 내에서 돌아다닌다)
TLS는 암호화된 TCP 연결 제공, 데이터 무결성, 끝 지점 인증
