새로운 Chapter로 들어왔다 !
Chapter 1 에서 다루었던 컴퓨터 네트워크와 인터넷에서 배운 5계층을 각 계층별로 자세히 배운다.
Chapter2에서는 Layer에 대해서 application에 관한 내용을 자세히 다룬다. network application의 원리에 대해 설명하고 웹과 HTTP, FTP, 메일에서 사용되는 프로토콜, DNS, P2P applications, 비디오 스트리밍, socket프로그래밍 ,UDP, TCP에 관한 내용을 배울 예정이다.
5 layer에 대해서는 지난 포스팅에서 자세히 다루어보았다.
[ 컴퓨터 네트워크 ] 1.5 - 1.7 Protocol Layer개요 및 보안
1.5 Protocol layers, service models 네트워크는 복잡하다. 매우! 네트워크는 복잡하며 수많은 'pieces'가 존재한다. - host, routers, links of various media, applications, protocols, hardware, software등등 이러한 수많은 네트
0lrlokr.tistory.com
이번 포스팅에서는 application architectures, process, socket등에 대해서 작성해보겠다.
1. Application architecture
Application 아키텍쳐 : 애플리케이션 개발자에 의해 설계되고 애플리케이션이 다양한 end-system에서 조직되는 방식을 지시
client-server 방식과 peer-to-peer(P2P)방식이 있음
1. 1 Client-server architecture
서버 :
- 항상 켜져있는 Host
- 고정 IP주소를 갖는다.
클라이언트라는 다른 Host의 요청을 받는다. - 데이터 센터를 통해 운용(확장)되는 경우가 있다
* 클라이언트 - 서버 application에서 하나의 서버 호스트가 자신의 클라이언트로부터 오는 모든 요청에 응답이 불가능 한 경우가 있다.
(ex. 구글같은 세계적인 사이트에서 하나의 서버만을 사용하는 경우 서버가 정상적으로 작동하기 어려운 경우가 있다)
이러한 경우에 대비하여 수 많은 호스트를 갇춘 데이터 센터가 사용된다.
클라이언트 :
- 항상 켜져있지 않다. (간헐적 연결)
- 서버와 통신(communication)한다.
- 동적인 IP주소를 가지고 있다.
- 클라이언트끼리 직접 통신하지 않는다.
(직접 통신하는 것은 P2P방식)
**Pros : 서버가 집중적으로 서비스 관리를 하기에 시스템의 설계 유지가 편하고 업데이트 관리가 쉽다.
**Cons : 앞서 데이터 센터가 운용되는 이유를 설명했듯 서버 장애 등 문제가 발생하면 전체가 중단된다.
1.2 P2P architecture
동등한 계층끼리 직접 통신한다. 즉, 컴퓨터끼리의 양방향 파일 전송 시스템
- 항상 켜져있는 서버가 없다.
데이터 통신은 peer끼리 한다 - 자율적으로 end-system과 직접통신한다.
서버 - 클라이언트 관계가 달라진다.
**컴퓨터에서 정보를 받아올 때 - 클라이언트
컴퓨터에 정보를 전달할 때 - 서버
- peer끼리 서비스를 요구하고 제공한다.
** self scalabilty : peer가 늘어나면 서버 용량이 자동으로 확장된다. peer가 서버 역할과 클라이언트 역할을 함께 수행하기에 service demands뿐만 아니라 service capacity까지 가져오게 된다.
- peer들이 간헐적으로 연결되고 IP주소가 바뀐다. → 프로그램 구성과 관리가 복잡해진다.
Pros :
서버가 없고 peer들이 트래픽과 자원을 할당해 부하를 분산시킴
높은 확장성을 가진다.
Cons :
새로운 기능 추가나 업데이트 관리가 어렵다.
네트워크 전송 시간으로 인해 노드 간 정보 불일치 → 성능 저하가 발생한다.
2. Process communicating
2.1 Process
프로세스(process) : 호스트 내부에서 동작하는 프로그램
- 같은 호스트 내부에서 통신 → OS에서 정의된 inter-process communication을 통해 통신
- 다른 호스트끼리 통신 → 메세지를 교환함으로써 통신함
* Client process : 소통을 시작하는 프로세스 ( 서버쪽으로 메세지를 보냄 )
* Server process : 연결되기를 기다리는 프로세스
** P2P 방식에서는 프로세스가 클라이언트가 될 수도 있고 서버가 될 수도 있다.
2.2 sockets
어떻게 data를 보낼 것인가?
socket : process가 message를 주고 받는 경로
* 소켓의 정의는 '네트워크 상에서 돌아가는 두 개의 프로그램 간 양방향 통신의 하나의 엔드 포인트'라고 명시되어있다.
하지만 이렇게 보면 다소 어렵게 다가온다. 그래서 보통 소켓을 비유적으로 '문(door)'이라고 표현하곤 한다.
프로세스들은 소켓을 통해 메세지를 주고 받는다.
소켓은 아래 transport를 통해서 메세지를 전달시켜준다. application의 입장에서는 프로세스가 메세지를 내놓는다고 본다. 그 다음 아래에 있던 transport가 받아와 다음 과정으로 전달시킨다.
소켓을 인덱싱하는 것 : IP주소 + 포트 번호
2.3 Addressing processes
메세지를 주고받기 위해서는 process는 identifier(id, port number)를 가져야한다.
교수님이 알려주신 예시를 들어보겠다. 한 집에 4개의 방이 있고 각 방을 구별하고 싶다. 이 때 집 주소는 하나고 그 안에서 4개의 방에 대한 주소를 각각 붙이면 된다. 이때 집 주소(host 비유)는 IP주소이고 4개의 방(process 비유)에 각각 붙은 주소는 port number이다 !
- 네트워크에서도 마찬가지로 메세지를 방(process)에 전송하기 위해 process id, 즉 포트넘버가 필요하다.
- 포트넘버는 16비트로 구성되어있다. (c.f. 서버의 호스트 디바이스는 32비트의 ip주소를 가지고 있다.)
- 포트넘버를 통해 같은 호스트 내에서 실행되고 있는 많은 프로세스들을 구별할 수 있다.
- e.g ) 포트 넘버 :
- HTTP 서버 : 80
- mail 서버 : 25
- IP 주소와 포트 넘버를 알아야 웹 서비스로 접근이 가능하.
3. App - layer protocol
3.1 App-layer protocol
메세지를 주고 받기 위한 protocol
- 메세지의 타입 → 어떤 메세지가 전달되는가 ( request, response )
- 메세지 문법(syntax) → 필드에 관한 내용(ex. 이전 n 비트는 어떤 내용을 나타내는지)
- 메세지 의미(semantics) → 필드가 의미하는 정보가 무엇인지
- 프로세스들이 언제 메세지를 주고 받는지에 대한 규칙 (rules)
open protocols:
- RFC에 정의
- 상호운영성 허용 (allows for interoperability)
- e.g ) HTTP, SMTP
proprietary protocols:
- e.g ) Skype
3.2 What transport service does an app need?
application 은 transport layer의 서비스를 받는다.
(app에서 tcp와 udp 중 어떤 프로토콜을 선택할 지 정한다)
Data integrity(데이터 진실성)
: 메세지를 보내면 수신받는 application에서 완벽한 수신(reliable data transfer)을 transport layer에서 보장받음
→ realiability : tcp는 reliable 서비스를 지원한다. udp는 unreliable한 서비스
→ 파일 전송에는 100% reliable data transfer가 필요하지만 오디오 같은 경우는 100%보장할 필요는 없음 (loss 관용적)
Timing (딜레이 보장)
:데이터를 전달하면 바로 전달되는 데 걸리는 시간
→효율적이기 위해 낮은 delay 요구
→ 패킷을 보내면 수신 서버까지 반드시 몇초 내에 도착받는 것을 보장(tcp, udp 의 보장은 X)
→ 인터넷 전화, 게임 등 앱에서 딜레이 보장을 필요로 함 (실시간)
Throughput(처리량)
: 1초에 몇비트 전송되는가 (효율적이기 위해 최소한의 throughput을 요구)
→ Throughput 보장이 필요할 수 있음 : 영상 재생 앱 등
→ elastic app에서는 보장할 필요 X
→ TCP, UDP 둘 다 보장 안함
security(보안)
: 데이터를 전달하면 암호화(encryption), 데이터 진실성(data integrity)를 보장
→ TCP, UCP 둘 다 보장 안함
3.3 Internet transport protocols services
실제로 transport layer에 있는 서비스는 크게 TCP, UDP로 나뉜다.
TCP (Transmission Control Protocol) service
:인터넷 상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜
- reliable transport : 높은 신뢰성 보장
sending - receiving 프로세스 간 신뢰할 수 있는 전송을 보장함 - flow control : 흐름제어
송신자는 수신자에게 데이터를 밀어넣지 않음 → 수신자를 보며 속도를 잘 모니터링 하며 조절함 ! - congestion control : 혼잡 제어
네트워크가 과부하되면 조절함 → (네트워크 상황에 따른 속도 조절) - connection - oriented : 연결지향 방식
클라이언트와 서버가 통신하기 전 connection을 셋업 해주는 과정이 필요함 - does not provide : 타이밍, Throughput, 보안 제공하지 않음
연속성보다 신뢰성 있는 전송이 중요할 때에 사용하는 프로토콜 (ex. 파일 전송)
UDP (User Datagram Protocol) service
: 데이터를 데이터그램 단위로 처리하는 프로토콜
- unreliable data transfer : 낮은 신뢰성
정보를 주고 받을 때 정보를 보내거나 받는다는 신호 절차를 거치지 않는다. → 프로세스 간 데이터를 보내기만 함 - does not provide : TCP에서 제공하는 내용 제공 X
→ 비연결형 서비스
3.4 Securing TCP
timing, Throughput은 transport layer에서의 보장이 어렵지만 보안은 어느정도 보장이 된다 !
* TCP & UDP : encryption(암호화)없음, 일반 텍스트로 소켓을 통과하고 인터넷으로 전송된 일반 텍스트 암호를 가짐
SSL
TCP 커넥션에 대해 data integrity(데이터 진실성, 무결성)
encryption(암호화),
end point authentication(상대방인지, 상대방으로 위조한 것인지 구별)
이 세가지 기능(보안에서의 기본 사항)을 제공 !
SSL is at app layer :
application layer에 라이브러리로 존재함
SSL socket API :
일반 텍스트 암호를 인터넷 암호화된 소켓 traverse로 전송
[참고 및 출처]
https://post.naver.com/viewer/postView.nhn?volumeNo=14678102&memberNo=19185109
https://inyongs.tistory.com/56
https://mangkyu.tistory.com/15
한국항공대학교 컴퓨터 네트워크 강의자료
'[지식창고] > 네트워크' 카테고리의 다른 글
| [ 컴퓨터 네트워크 ] 2.2 Web and HTTP(2) (0) | 2023.03.27 |
|---|---|
| [ 컴퓨터 네트워크 ] 2.2 Web and HTTP (1) (0) | 2023.03.20 |
| [ 컴퓨터 네트워크 ] 1.5 - 1.7 Protocol Layer개요 및 보안 (0) | 2023.03.19 |
| [ 컴퓨터 네트워크 ] 1.4 Delay, Loss, Throughput (1) | 2023.03.18 |
| [ 컴퓨터 네트워크 ] 1.3 Network core (0) | 2023.03.11 |