1. Network Application
사용자가 작성할 프로그램이 가지는 특징
- 다른 end system에서 실행됨
(ex. 하나는 사용자 PC, 다른 하나는 웹 서버) - 네트워크를 통해 통신
(ex. 웹 서버 소프트웨어 ↔ 브라우저 소프트웨어 간의 통신)
프로그래머들은 라우터, 스위치 등 네트워크 핵심 장비의 소프트웨어를 작성할 필요 x
(핵심 장비에는 사용자 애플리케이션 실행 x)
2. Architecture (응용 구조)
Client-Server paradigm
server
- 항상 켜져 있는 호스트 (ex. Naver, 24시간 운영)
- 고정 IP 주소 (permanent IP address)
- 데이터 센터에 위치
Client
- 서버에 접속하고 통신
- 간헐적으로 연결됨 (항상 접속X)
- 동적 IP 주소 사용 가능
(접속할 때마다 IP가 바뀔 수 있음) - 클라이언트끼리는 직접 통신하지 않음
(client 간에는 직접적인 연결 X)
Protocol Example : HTTP, IMAP, FTP
P2P
Client, Server와는 다른 개념으로 user들이 대등한 관계에 있는 구조 (Peer-to-peer architecture)
- 항상 켜진 서버 없음
(중앙 서버 없이, 동등한 peer들끼리 직접 통신함) - 모든 단말기(end system)가 직접 통신 가능
- 서로 서비스 주고 받음
(요청도 하고, 다른 peer에게는 서비스를 제공하는 구조)
(ex. 파일을 받고, 동시에 다른 사람에게도 제공) - Self-scalability (자체 확장성)
새로운 peer가 네트워크에 들어오면, 새로운 자원과 수요를 동시에 가져옴 → 확장성 뛰어남
한계점
- Peers는 간헐적으로 연결됨 (항상 연결 x)
- IP 주소 자주 바뀜
(동적 IP 사용, 연결 유지 어려움) - 복잡한 관리 필요 (Complex management)
(중앙 관리자가 없으므로 운영 복잡)
Example : P2P file sharing
3. Processes communicating
Process란, 하나의 호스트 내에서 실행 중인 프로그램
(호스트 내부에서 작동하는 단위)
- 같은 호스트 내 통신
: OS내에 정의된 Inter-process communication (IPC)를 사용하여 통신 - 다른 호스트 간 통신
: 메시지를 주고받으며 통신하며, 주로 Socket 사용
Process 내 역할 구분
Client Process : 통신을 시작하는 프로세스
(ex. 웹 브라우저가 요청 보냄)
Server Process : 연결을 기다리는 프로세스
(ex. 웹 서버가 요청을 수신하고 응답)
(프로세스와 아키텍쳐 구분하기, 역할에 따라 client, server의 process는 언제든지 바뀔 수 있음)
Sockets(소켓)
Process가 메시지를 주고받을 때 사용하는 소프트웨어 인터페이스
- 네트워크 통신을 위한 문 역할
(보낸 쪽 Process는 메시지를 소켓 밖으로 밀어냄)
(받는 쪽 Process는 메시지를 해당 프로세스에 전달) - 메시지를 전달하는 것은 transport infrastructure (전송 계층)의 역할
(ex. TCP, UDP 등이 메시지를 정확한 위치로 전달) - 두 개의 소켓 필요
(송신 측 소켓 + 수신 측 소켓)
Socket 구성
- 응용 계층 (application): 개발자가 제어
- 전송(transport) 이하 계층: 운영체제(OS)가 제어
Addressing Processes
프로세스가 메시지를 받기 위해서는 identifier(식별자)가 필요 (프로세스 주소 지정)
- identifier 구성 : IP Address + Port number
(둘 다 있어야 정확히 지정 가능)
4. Application layer protocol
응용 계층 프로토콜의 요소
-
메시지 유형 (Types of messages)
(ex. request, response) -
메시지 구문 (Message syntax)
메시지 안에 어떤 필드가 있는지 확인 (문법적으로 정의)
(ex. binary/ASCII) -
메시지 의미 (Message semantics)
각 필드의 정보 의미
(ex. 사용자 ID / 요청 데이터) -
규칙 (Rules)
송신 / 수신 프로세스 간 상호작용의 흐름
Open protocols vs Proprietary protocols
- Open protocols (공개 프로토콜)
RFCs에 정의되어, 모든 사람들에게 접근 가능
다양한 시스템 간 호환성을 보장
(ex. HTTP, SMTP) - Proprietary protocols (독점 프로토콜)
특정 회사나 제품에 종속
(ex. Skype)
5. Transport service (전송 계층 서비스의 종류)
Data Integrity (데이터 신뢰성)
데이터가 손실되지 않고 잘 올 수 있느냐의 여부
- Data Integrity 필요한 경우
100% 정확한 데이터 전송이 아니면 치명적
(ex. 파일 전송, 웹 거래) - Data Integrity 필요 없는 경우
일부 데이터 손실 허용 가능
(ex. 전화 통화)
Timing (타이밍 / 지연)
데이터가 전송될 때의 시간이 중요하냐의 여부
- Timing 중요한 경우
데이터가 빨리 도착해야 사용자 경험 유지
(ex. 인터넷 전화) - Timing 중요하지 않은 경우
데이터가 늦게 도착해도 지장 x
(ex. mail)
Throughput (처리량, 수신율)
데이터 처리량이 중요하냐의 여부
- Throughput이 중요한 경우
일정 수준 이상의 처리량이 있어야 효과적
(ex. 월드컵 경기 → 처리량 부족하면 답답함) - Throughput이 중요하지 않은 경우
가능한 대역폭을 최대한 활용(속도 중요 x)
(ex. elastic apps)
Security (보안)
암호화, 데이터 무결성 등이 필요
(민감한 data 주고받는 애플리케이션 중요)
Transport service 응용
6. Internet Transport protocols services
TCP (Transmission Control Protocol)
- 신뢰성 있는 전송 제공
송신 프로세스 ↔ 수신 프로세스 간에 데이터가 정확하게 도달 - Flow control (흐름 제어)
수신자가 감당할 수 있는 만큼만 송신자가 전송
(과부하 방지) - Congestion control (혼잡 제어)
네트워크 과부하 시 송신 속도 조절 - Connection-oriented (연결 지향)
송신자와 수신자 간 연결 설정이 먼저 필요함
(데이터를 보내기 전 수월하도록 사전 작업)
제공하지 않는 기능
: 타이밍 보장, 최소 처리량 보장, 보안
(이거까지 보장하면 Process 복잡해짐)
UDP (User Datagram Protocol)
- 신뢰없는 전송
제공하지 않는 기능
: 신뢰성, 흐름 제어, 혼잡 제어 (TCP에서 보장하는)
타이밍 보장, 처리량 보장, 보안 등 (TCP에서도 안 하는)
UDP가 필요한 경우
단순하고 빠르기 때문에 사용
일부 애플리케이션(ex. 실시간 스트리밍, DNS)은 빠른 전송이 상대적으로 중요 (약간의 손실 허용 가능)
TCP vs UDP 응용
7. Transport Layer Security (TLS)
Vanilla TCP & UDP sockets 의 문제점
- 기본 TCP/UDP 소켓은 암호화 X
- 평문으로 비밀번호 전송
(인터넷을 통해 그대로 노출될 위험 존재)
Transport Layer Security (TLS)
TCP 보안으로서, TCP를 안전하게 만드는 방법
- 암호화된 TCP 연결 제공
- 데이터 신뢰성 (data integrity) 제공
- 종단 간 인증(end-point authentication) 지원
(신뢰할 수 있는 상대인지 확인)
TLS 구현 방식 (특징)
-
응용 계층(application layer)에 구현
(앱에서 TLS 라이브러리 사용) -
TLS socket API
사용자는 평문으로 보내지만, 소켓 내부에서 암호화
