[Network] 2.1 네트워크 어플리케이션의 원리

*2장 Application Layer

# transport layer 와 연계된 application layer이다.

이장의 목적

• Network application의 개념과 구현
• Transport layer 서비스 모델
• 클라이언트_서버 모델의 예

# 지금 쓰이는건 100% 클라이언트_서버 모델

# 2T, 3T이다.

• Peer-Peer 모델

# 지금 이거 안쓴다. 인터넷사업자나 국가가 싫어한다.

# 법률적 제한이 매우 심하다.

# 관리하는 곳이 없기 떄문에 요금을 지불할 곳이 없다.

# 좋은 기술이라도 트래픽이 심하기에 안쓴다.

# ex) 당나귀, 토렌트 - 바이러스의 집합체

많이 사용되는 application 관련 protocol에 대해서 학습한다.

• HTTP
• FTP
• SMTP/POP3/IMAP
• DNS

# 인터넷에서 오래된 서비스들이다. 인터넷 초창기부터 사용되던 네가지 종류

# 가장 오래된것은 전자우편과 FTP이며 DNS가 없어도 사용이 가능했다.

#? 그럼 ip로 쓴건가?

Network application 프로그래밍 방법

• Socket API

# 아파치의 모든서버가 80번 포트라면? 어떻게 구분하느냐를 소켓이 해결해준다.

# TCP와 UDP의 방식의 차이는 소켓을 통해 나타난다.

*Some network app

• E-mail
• Web
• Instanct messaging
• Remote login
• P2P file sharing
• Multi-user network game
• Streaming stored video clips
• Internet TEL.
• Real-time video conference
• Massive parallel computing

# 최근 각광받는 기술이다. 논문쓰기 좋은 ..

*Creating a network app

프로그램의 실행

• 서로 다른 종단시스템 간에 실행

# 1대1로 연결되는 형태

• 네트워크 위에서 실행
• 예. Web: Web 서버와 browser간에 통신

Network core는 Network 프로그램에 대해서 투명하다.

• Network core의 장치와 application 개발과는 무관하다.

# 코어가 어떻게 작동하든 상관이없다.

• 종단시스템으로 소프트웨어를 제한한다는 기본설계는 인터넷 application의 빠른 개발과 전개를 쉽게 해준다.

# 사용자 인터페이스만 신경써서 만드는게 어플리케이션이다.

Network application의 구조

• Client-Server
• Peer-to-peer (P2P)
• Hybrid of client-server and P2P

# 요즘은 하이브리드 모델이 거의 없다.

# ex) 네이트온 - 서버에 로그인, 채팅은 컴퓨터가 각자 데이터를 주고받는다.

# 그래서 서버가 내용이 안남는다.

# 카톡은 클라이언트 서버방식이다. 대부분이 이렇게 서비스하고 있다.

# 허밍버드사의 콜럼버스 - p2p

# 기술적 측면에선 아주 중요한 기술이다. 논문쓰는 사람에게 매우 좋다. 인증, 책임 등

*Client-server 구조

Server

• 항상 켜져 있다.
• 고정 IP를 갖는다.
• 다량의 client로부터 요청을 처리하기 위해 server farm를 구성하기도 한다. (가상 서버)

# 서버는 프로세스를 이야기하는 것이다.

# 컴퓨터자체를 이야기하는게 아니다. 보통은 프로그램을 이야기한다.

# 서버용은 사양이 좋고 안정적이여야한다. - 그래서 비싸다.

# ddns 서비스를 구지사용할 필요없다. - ip가 바뀌면 그대로 도메인을 바꿔 등록

# 서버 팜 : 여러 컴퓨터가 동시에 서비스를 한다. - 무결성이 침해당할수 있다.

# 클러스터링 서버 : 동기화 문제 해결하여 무결성을 지킨다.

Client(ex : 사파리, 크롬)

• Server에 서비스를 요청한다.
• 필요에 따라 서버에 접속한다.
• 동적인 IP를 사용하는 경우도 있다.
• Client간에 직접 통신하지 않는다.

# 직접 통신한다면 이것이 P2P이다.

 # SSH 같은경우는 세션키를 꼭 클라이언트가 보낼 필요는 없다.

*순수 P2P 구조(1:N)

• 항상 켜있는 서버가 존재하지 않는다.
• 임의의 호스트 쌍이 직접 통신한다.
• Peer는 필요에 따라 간헐적으로 접속하며 IP또한 바뀔 수 있다.
• 예:그누텔라(Gnutella)
• 높은 분배와 분산 특성
• 관리가 어렵다. -> 통제가 어렵다.

# 책임소재에 대한 파악이 어렵기 떄문에 사업적으로 사용되기 어렵다.

*Client-server와 P2P의 통합구조

Napster

• File의 전송은 P2P를 이용한다.
• File 검색은 서버를 이용한다.
• Peer들은 중앙 서버에 자신이 가진 파일의 목록을 등록한다.
• 원하는 file의 위치를 찾기 위해서는 중앙 서버에 질의한다.

Instant messaging

• 두 사용자간에 채팅은 전형적인 P2P이다.
• 사용자의 접속여부와 위치는 중앙 서버를 이용한다.
• 채팅에 참여하기 위해서는 중앙 서버에 IP와 자신의 정보를 등록한다.
• 대화를 위해서 온라인에 대기중인 사용자를 찾기 위해서는 중앙서버에 연결한다.

# 소개팅 앱 - 정보는 서버에 화상채팅은 P2P

*프로세스간 통신

Process : 호스트에서 실행중인 프로그램

• 동일 시스템의 프로세스는 그들은 서로 프로세스간 통신을 하게 된다. inter-process communication 이라 불리는 이 통신의 규칙은 종단 시스템의 운영체제에 의해서 좌우된다. ( 네트워크 없이 접속 할수도있음 )

# oracle의 sqlplus - 로컬

# inter-process communication 메모리 내에서 프로세스끼리 통신

# tnsora 는 네트워크를 통해서 접속하는 것

# inter-process communication 는 로컬호스트로 접속한것.

# ip를 치고 접속하면 네트워크를 통해 접속한것

• 서로 다른 시스템간의 process간에는 message 교환으로 통신한다.
• Note : P2P application 은 client process 와 server process 두가지 기능을 모두 가지고 있다

Client process : Process간에 통신 세션에서 통신을 초기화 한다. (능동적)

Server process : 세션을 시작하기 위해서 접속을 기다린다.(수동적) - listen

# 직접 리스닝을 하여야 네트워크를 통해 오라클에 접속(감시도 해주고)

# 서버가 네트워크를 감시하지않는것 - 리스닝을 다른놈이 대신 해주는 슈퍼데몬xined

*Socket(OS의 메모리 구조)

두개의 process는 네트워크를 통해서 message를 주고 받는다. 이때 process는 socket을 통해 네트워크에 message를 보내고 받는다.

# 따로 있는게 아니라 TCP에 있는거고 어플리케이션과 트랜스포트 사이에 있다.

Socket은 문(door)에 비유 될 수 있다.

# 네트워크에서 문이라고 비유한다는 것을 특별한 의미가 있다.

# 투명성과 연관이 있는 것이다. 서로에게 안보인다. 서로 신경을 안쓴다.

• 송신쪽 process는 door 바깥쪽으로 message를 밀어낸다.
• 송신 process는 네트워크를 거쳐 수신 process로 message가 전달되는 구조가 문 바깥쪽에 있다고 신뢰한다.
• 전달된 message는 door을 통해 수신 process로 전달 된다.

# process와 TCP는 중간에 뜬 소켓에만 이야기하면된다. 통역사를 이용하는 것과 같다.

API : (1) Transport protocol 선택; (2) 몇가지 매개변수들

# 멀티플렉싱 :process에서 TCP로 내려가는 것

# 디멀티플렉싱 : TCP에서 process 내려가는 올라가는 것

# RDT 신뢰적인 데이터구간

# UDP는 소켓 만드는 방식이 다르다.

*Addressing processes

• process가 message를 수신하기 위해서는 반드시 자신에 대한 인식 정보가 필요하다.
• 호스트들은 32bit의 unique한 IP주소를 갖는다.

# IP를 갖는 호스트 : 식별가능한 호스트가 갖는것

# 인터넷에서의 호스트 : 노드중에서 ip를 가지면 호스트

# 노드 : mac address 장비를 가진 애들 - 이더넷통신가능

# 시리얼라인은 여러개가 동시에 연결되있음. 노드 주소 없음. 1대1 연결

• Q : 종단 시스템의 IP 주소만으로 process를 정확히 구별 할 수 있는가?
• Answer : No

동일한 host에는 많은 process가 존재함으로 구별이 불가능하다.

• 호스트의 각 process를 정확히 구별하기 위해서는 IP주소와 port number가 모두 필요 하다.
• 유명한 application protocol들은 특정 port number가 할당 되어 있다.
• HTTP server: 80
• Mail server : 25

*App-layer protocol 정의

• 교환되는 message의 타입
• Request & response message
• 여러 message type의 syntax(message 내부의 각 field를 구별하는 방법)
• Filed의 semantics (각 field의 의미, 담고 있는 정보의 내용)
• 언제 어떻게 process가 message를 전송하고 응답하는지를 결정하는 규칙
• Protocol의 3요소
• Timing(시간) - ex ) 세션 유지시간
• Syntax(구조) - 어떻게 자를것인지
• semantics(구조) - 그 안에 의미는 무엇인지

# 프로토콜 규격에 벗어난 업무할떄는 그거에 맞게 세션을 유지할 방법을 생각해야한다.

Public domain protocol

• RFC에 정의되어있다.
• www.ietf.org

# hole을 메꾸는 문서가 계속 나온다.

• RFC에서 제공되는 규칙에 따른다면 상호 운영이 가능하다.
• 예 : HTTP, SMTP

# 뭔가 만든다면 RFC를 참고하여 만들어야한다.

# 어긋나게만들면 다른곳과 통신이 안된다.

Proprietary protocol

• 예 : KaZaA

*Application이 필요로 하는 전송 서비스

Data 손실

• Application에 따라서는 data의 손실을 허용한다.
• 일부 application들은 데이터 손실이 전혀 없는 신뢰적인 전송을 요구 한다. (FTP, telnet..)

# 멀티미디어 스트리밍을 받는애들은 손실을 허용한다.

# 유투브는 데이터 손실 허용안해준다.

Timming

• 인터넷 폰이나 다자간 게임 같은 application들은 효과적인 data 전송을 위해 매우 낮은 수준의 지연만을 허용한다. 엄격한 시간조건을 요구한다.

대역폭 (bandwidth)

• Bandwidth-sensitive application

효과적인 전송을 위해 최소 대역폭을 보장해야 된다

• Elastic application

가용한 대역폭을 적게 사용한다. 물론 대역폭이 많으면 좋다.

# 통계적 다중화 방식이기에 타이밍과 대역폭에 대해 보장하지않는다.

*다양한 application들의 요구사항

*인터넷 전송 protocol이 제공하는 서비스

TCP service

• 연결지향형 서비스 : message를 전송하기 전에 client와 server process간에 전송 제어정보가 전달 된다.
• 신뢰적인 전송 서비스 : 모든 데이터가 오류 없이 올바른 순서로 전달 된다.
• 혼잡제어 : 네트워크가 혼잡상태에 이르면 송신자가 전송 속도를 낮춘다. (process의 직접적인 이득보다는 인터넷 전체 성능 향상)
• 제공되지 않는 서비스
• 최소전송률을 보장하지 않는다.
• 지연보장을 하지 않는다. Application에서 담당한다.

# 응답이 2번이기도 하고 3번이기도 하다?

# 네트워크 상태가 되도록 안정적인 상태가 유지하고싶다면?

#  - 네트워크가 처리할수 있는것보다 적게 사용한다. (안정권?)

# 네트워크 상태가 안정적인것은 무엇을 이야기하는 건가?

#  - 네트워크가 처리할수있는 양보다 적은 양을 처리할때  케파 > 처리량

# stored and forward : 스위치가 버퍼에 저장되었다가 읽고나서 내보내는것

# TCP는 응답이 늦거나 안오면 네트워크가 혼잡되었다고 추론한다. -> 혼잡제어

# 혼잡제어 : 각자의 네트워크 성능을 내려서 전체 네트워크 성능을 올리는 것

# 흐름제어 : 받는쪽에서 송신자에게 버퍼상태를 보내줌으로써 버퍼의 남은 용량만큼 받는다. - 이건 거의 어느장비나 다 들어가있는 기능이다.

# 서킷망은 흐름제어를 하지않는다.

# 흐름제어, 혼잡제어는 윈도우사이즈를 늘리고 줄이므로써 조절한다.

UDP service

• 비 신뢰적인 data전송 서비스를 제공한다. (도착여부나 순서를 보장하지 않는다.)
• 통신 전에 제어 정보를 전송하는 connection setup과정이 없다.
• 신뢰성, 혼잡제어, 흐름제어, 지연, 최소 전송률 등을 보장하지 않는다.

Q : UDP를 이용하는 이유는 무엇인가?

A: 송신자가 전송속도를 네트워크 혼잡에 따라 제어하는 혼잡제어를 제공하지 않음으로, 비록 모든 data가 전달되지 못하더라도 송신 process는 원하는 속도로 data를 전송 해야 하는 실시간 application에 사용한다. 이런 application들은 최소 전송률

이 필요하지만 data의 일부 손실은 감수 할 수 있기 때문이다.

# unicast : 유닉스가 유니크한 하나에게만 보내는것

# broadcast : 누가받든 신경안쓰고 네트웤 전체에 뿌려버림

• ex) TV
• 확인이 안되는 패킷
• IP의 브로드케스트는 같은 네트워크만 받는다.

# multicast : 그룹을 묶어서 그룹에게만 준다.

• end bone : multicast 백본망을 위해 남겨둔 ip주소

# ppp가 없어지지 않는 이유는?

• 전화는 국제표준이라서 어디든 통신이 가능하다.

# 017 이 원래 전쟁나면 군대에서 사용하던 번호이다.

*인터넷 app 의 하위 전송 protocol