이 글은 이화여자대학교 이미정 교수님의 2014년 2학기 컴퓨터 네트워크 강의를 기반으로 재구성한 것입니다. 삽화는 링크를 출처로, 저작권은 J.F Kurose and K.W. Ross에게 있다는 것을 밝힙니다.
Application Layer에서는 크게 3가지를 살펴본다.
- application principle
- client-server 구조
- peer-to-peer (P2P) 구조
- transport layer service model
- internet protocol - HTTP, electronic mail(SMTP, POP3, IMAP), DNS, P2P
- network application의 작성을 위한 interface - socket, UDP, TCP
이 글에서는 application principle을 살펴보며, application layer에서 사용하는 것들을 간단히 살펴본다.
Application Principle
모든 network communication의 주체는 program(process)이다. 여러 번 언급되는 내용으로 기억하고 있어야 한다.
Application Architecture
모든 network application과 application protocol은 client-server 또는 peer-to-peer 2가지 구조 중 하나를 가진다.
Client-Server Architecture
client-server 구조인 경우, 하나의 end system은 server host이고, 다른 하나의 end system은 client host이다. 이 때 다음과 같은 특징들을 갖는다.
- server host
- 항상 on인 상태이다.
- IP address가 변하지 않는다.
- scaling을 위해 여러 대의 server를 둔다.
- client host
- server와 communication한다. (client들끼리는 통신하지 않는다.)
- 주로 intermittently하게 통신한다. (간헐적 통신)
- IP address가 변한다.
위에서 모든 network communication의 주체는 process라고 했다. 이 경우에는 client host에 있는 process와 server host에 있는 process가 서로 통신한다.
Peer-To-Peer Architecture (P2P)
P2P의 경우에는 communicating process가 user host에 있다. 이 때 user host를 peer라고 하며, peer는 service를 다른 peer에게 제공하기도 하지만, service를 제공받기도 한다.
특징은 다음과 같다.
- no always-on server : 항상 on이 아닐 수도 있다.
- end system(user host, 또는 peer)가 직접적으로 통신한다.
- self scalability : peer가 P2P에 join한 경우, [requset + scalability]를 동시에 가져오기 때문에 system이 커져도 scalinlg할 수 있다.
- peer들이 intermittently하게 연결하고, IP address가 바뀌기 때문에 관리하기 어렵다.
Process Communicating
network에서는 서로 다른 host가 message를 교환하며 통신한다. 이 때 process는 2종류로 나뉜다.
- client process: communication을 시작하는 process
- server process : communication의 시작을 기다리는 process. 시작 요청을 대기하다가 시작 요청을 받으면 응답한다.
위에서 설명한 client-server architecture에서, client host는 client process를 실행하고, server host는 server process를 실행한다. 이후 client host의 client process가 service request를 위해 server host의 server process에 contact한다.
반면 P2P는 하나의 peer에 server process와 client process가 동시에, 또는 하나만 실행될 수도 있다. (요청할 수도 있고 응답할 수도 있기 때문이다.)
Socket
application layer는 개발자가 관리하고, transport layer의 아래에 있는 layer들 (transport, network, link, physical)들은 OS가 관리한다. 때문에 application layer와 transport layer 사이에는 하나의 interface가 존재하는데, 이것이 socket이다.
다르게 표현하면 application layer에서 network로 보낼 때는 transport layer를 거치고, network에서 application layer에 도착할 때도 transport layer를 거친다. 즉, application layer와 network 사이에는 통신이 필요한데, 이 역할을 하는 것이 socket이라는 것이다.
Process 식별
IP address를 사용해 host를 식별할 수 있지만, host를 식별하는 것 만으로는 process를 식별할 수 없다. 때문에 network service나 process를 식별하는 port를 사용해 process를 식별할 수 있다.
port는 app이나 protocol에 따라 약속된 값을 사용한다. 몇 개는 이미 약속으로 정해져 있는데, 이러한 port들을 well known port number라고 한다. 가령 80은 HTTP로, 25는 mail로 사용한다는 것이 널리 알려져 있다.
IP address는 총 32bit이며, 8bit씩 쪼개어 .으로 구분한다.
비슷한 내용이 1%의 네트워크 - 1. 웹 브라우저가 하는 일 포스팅에도 있으니 필요 시 참고하면 좋다.
Application Layer Protocol이 정의하는 것
application layer는 다음 4가지를 정의한다.
- 교환하는 message의 종류 - request인지, response인지
- message syntax : message의 field, field를 어떻게 구분하는지, ...
- message semantics : message를 어떻게 해석하는지
- rule : 특정 message를 받았을 때, 언제 어떻게 처리하고 response하는지
application layer protocol은 2종류가 있다.
- open protocol : 공개된 protocol이다. 이 경우 표준인 RFC에 등록되어 있으므로 이 규칙에 따르면 되기 때문에 interoperability하다.
- proprietary protocol : 비공개 protocol이다. 어떻게 동작하는지 모른다.
Application은 어떤 transport service를 필요로 할까?
크게 아래 4가지 요소가 있다.
- data integrity : 오류가 없는 구조. file transfer나 web transaction과 같은 경우에는 내용에 오류가 없어야 할 것이다. 반면 audio와 같은 application은 조금의 오류는 받아들일 수 있다.
- timing : delay가 적은 구조. 실시간 전화나 온라인 게임 같은 경우는 delay가 적어야 할 것이다.
- throughput : multimedia application의 경우에는 minimum throughput이 guarantee되어야 한다. 최소한의 frame이 맞추어져야 재생할 수 있기 때문이다.
- security
예시
application | data loss | throughput | time sensitive |
file transfer | no loss | elastic | no |
no loss | elastic | no | |
web document | no loss | elastic | no |
text messaging | no loss | elastic | yes or no |
real time multimedia | tolerant | audio: 5Kbps ~ 1Mbps video : 10Kbps ~ 5Mbps |
yes, 100ms |
stored multimedia | tolerant | audio: 5Kbps ~ 1Mbps video : 10Kbps ~ 5Mbps |
yes, few secs |
interactive game | tolerant | few kbps | yes, 100ms |
file transfer, email, web document, text messaging의 경우에는 data loss가 없어야 한다. 반면 throughput은 거의 없어도 되고. 시간도 딱히 민감하지 않다.
반면 real time multimedia의 경우 loss는 조금 있어도 되지만 minimum throughput이 guarantee되어야 한다. 반면 stored multimedia의 경우에는 file을 다운로드 받고, 미리 buffering을 하기 때문에 조금의 여유시간이 있다.
Internet Transport Protocol Service - TCP & UDP
TCP와 UDP가 있다.
TCP, Transmission Control Protocol
- reliable transport : 전송에 오류가 없는 것이 보장된다.
- connection oriented : handshake 과정을 거쳐 connection이 생긴 후 통신한다.
- flow control : sender와 receiver에는 둘 다 buffer가 있으며, 전송 직전/application layer로 전송하기 전에 잠시 buffer에 packet을 담아둔다. 이 때 buffer가 넘쳐 loss가 발생하기도 하는데, TCP flow control은 이 현상을 막을 수 있다. (TCP windo
- congestion control : connection oriented이기 때문에 network가 혼잡하다는 것을 감지하고 congestion을 막을 수 있다.
- 제공하지 않는 것 : timing, minimum throughput guarantee, security
UDP, User Datagram Protocol
- unreliable data transfer : 전송에 오류가 있을 수 있다.
- 제공하지 않는 것 : reliability, flow control, congestion control, timing, minimum throughput guarantee, security
TCP vs UDP
이렇게만 보면 TCP가 UDP보다 훨씬 좋아보이지만 꼭 그런 것은 아니다. 아래 예시들을 보자.
1. TCP의 경우 handshake process를 거치기 때문에 process control에 overhead가 발생하므로, 더 느리다.
2. 정말 reliability가 중요한 application의 경우, application 내부에서 reliability를 검사하기도 하는데, 이 경우 TCP와 중복된다.(그러므로 사용하지 않아도 된다.)
3. flow control, 또는 congestion control이 문제가 될 수도 있다. minimum throughput이 보장되어야 하는 상황에서 UDP를 택하면 packet을 network에 보내지만 TCP를 택하면 이를 막기 위해 packet을 발송하지 않고 계속 들고 있는다.
예시
application | application layer protocol | transport protocol |
SMTP | TCP | |
remote terminal service | Telnet | TCP |
web | HTTP | TCP |
file transfer | FTP | TCP |
streaming multimedia | HTTP or RTP | TCP or UDP |
internet telephony | SIP, RTP, proprietary(skype) | TCP or UDP |
위 예시에서, application level에서는 SMTP, HTTP, FTP 등 다양한 protocol을 사용하지만 대부분 TCP나 UDP 둘 중 하나로 transport layer에서 사용한다.
TCP와 UDP에 대한 더 자세한 내용은 1%의 네트워크 - 2. OS Protocol Stack과 LAN Adapter 포스팅에서 확인할 수 있다.
잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.
'CS > Network' 카테고리의 다른 글
[Network] 하향식 접근 네트워크 - 2. Application Layer - (3) SMTP, POP3, IMAP (0) | 2023.07.27 |
---|---|
[Network] 하향식 접근 네트워크 - 2. Application Layer - (2) HTTP (0) | 2023.07.27 |
[Network] 하향식 접근 네트워크 - 1. Introduction (0) | 2023.07.26 |
[Network] 1%의 네트워크 - 6. 마무리 : Web Server Response (0) | 2023.07.24 |
[Network] 1%의 네트워크 - 5. Firewall, Proxy, Load Balance (0) | 2023.07.24 |