2.1 principles of network applications

application layer : 레이어 중 가장 위의 레이어
-> network application : 네트워크를 이용한 프로그램들
-> 이메일, 웹, 메세지 등
-> 두 가지의 application architecture가 있다. -> client-server, peer-ro-peer

client-server architecture

대부분의 앱들이 이 구조를 따른다.
client 와 server가 존재하여 둘 사이에 데이터가 이동한다.
보통 client가 데이터를 요청하여 받고, server가 데이터 요청을 받아서 보내준다.

• server
  -> 항상 켜져있는 호스트
  -> 영구적인 ip 주소(고정적 ip주소) -> 클라이언트가 접속하기 위해
  -> 데이터 센터를 통해 운용되는 경우도 있음(크기가 크면 컴퓨터 여러대로 연결해가며 확장)
• client
  -> 서버와 커뮤니케이션 한다.
  -> 껐다 켰다 할 수 있다. (간헐적 연결)
  -> ip 주소가 달라진다.(동적 ip 주소)
  -> 클라이언트끼리 직접 통신하지 않는다.(통신하는 것은 p2p) -> 서버를 통해서 통신한다.

P2P architecture

동등한 peer(end system) 끼리 직접 통신한다. 새로운 peer가 나타나면 규모가 늘어난다.

-> 항상 켜져있는 서버가 없다.(보통 작은 서버가 있긴 한데, 이 서버는 데이터 통신을 위한 서버가 아니라 peer에 대한 정보를 저장하는 서버이다. 데이터 통신은 peer끼리 한다.)
-> end system 끼리 직접 통신한다.(서로 간 서버 클라이언트 관계가 달라진다. 예를들어 내가 상대 컴퓨터에서 정보를 받아올 때 내가 클라이언트, 상대가 서버의 역할을 한다.)
-> peer 끼리 서비스를 요구, 제공한다.(self-scalability : peer가 서버 역할과 클라이언트 역할 모두 수행하기 때문에 service demands 뿐만 아니라 service capacity 까지 가져오게 된다.-> peer가 늘어나면 서버 용량이(원래 있던 peer들 + 추가된 peer들)로 자동(스스로) 확장 된다.)
-> peere들이 있었다 없어졌다 하니까 ip주소가 바뀌는 것을 고려하여 프로그램을 구성해야 한다.(관리가 복잡)

processes communicating

메세지를 주고받는 것은 호스트라기 보단 프로세스라고 보면 된다.
프로세스 : 호스트 내부에서 동작하는 프로그램
-> inter process communication : 같은 호스트 내부에서 다른 프로세스 끼리 소통(OS에 의해 정의됨)
-> 서로 다른 호스트의 프로세스들은 메세지를 통해 소통한다.

• client-server architecture
  -> 클라이언트 프로세스 : 소통 시작(서버 쪽으로 메세지 보냄)
  -> 서버 프로세스 : 연결되기를 기다림
• p2p architecture
  -> 프로세스가 클라이언트가 될수도 있고 서버가 될수도 있다.
  -> peer A가 peer B로부터 파일을 다운로드 하면 A는 클라이언트, B는 서버 역할을 한다.

Sockets

소켓 : 프로세스 간 메세지를 주고받는 인터페이스
-> 프로세스들은 소켓을 통해 메세지를 주고 받는다.
-> 어플리케이션 레이어와 트랜스포트 레이어 사이의 인터페이스라고 볼 수 있다.
-> 전체적으로 봤을 때 어플리케이션 사이의 메세지를 보내는 인터페이스 라고 볼 수도 있다.

Addressing processes

• 메세지를 받기 위해서는 프로세스들은 identifier를 가지고 있어야 한다.
• 서버의 호스트 디바이스는 32비트 짜리 ip주소를 가지고 있다.
• 포트넘버(16비트)를 통해 같은 호스트에서 돌아가는 많은 프로세스들을 구별할 수 있다.
• 포트넘버는 주로 well known port number이다.
  -> 이런 서비스는 항상 이런 포트넘버를 갖는다(디폴트 값으로 보는거) : http server 80, mail server 25 등
• ip주소와 포트넘버를 알아야 웹서비스로 접근이 가능하다.

App-layer protocol defines...

메세지를 주고 받기 위해서는 프로토콜이 필요하다.

• 무슨 메세지가 전달 되는가(request, response 등) -> 메세지의 타입
• 메세지 신택스(필드에 대한 내용 - 앞에 몇비트는 뭘 나타내고 등)
• 메세지 semantics(필드가 의미하는 바가 무엇인지)
• 프로세스들이 언제 메세지를 보내고 받으면 어떻게 처리할지 등
• 스카이프를 만들었다? -> 프로토콜들을 디자인하거나 오픈 프로토콜 사용(http, smtp 등) -> 어떤 웹을 만들어도 웹서버들과 통신할 수 있도록 하기 위해 오픈프로토콜을 사용함

what transport service does an app need?

Transport service로 뭘 사용할 것인가?
애플리케이션은 트랜스포트 레이어의 서비스를 받는다.
-> 애플리케이션에서 tcp 랑 udp 중 어떤걸 선택할지 정함
-> 일반화 시켜서 애플리케이션 만들어서 반대쪽 애플리케이션이랑 소통하는데 어떤 트랜스포트 서비스들이 있을 수 있는가?

• Data integrity : 메세지를 보내면 반대쪽 애플리케이션에서 완벽하게 수신이 될 것(reliable data transfer)을 애플리케이션이 아닌 트랜스포트 레이어가 보장해준다.
  -> reliability : tcp는 reliable 서비스 지원 / udp는 미지원(메세지를 보내도 못받을 수도 있음)(unreliable)
  -> 파일전송의 경우 100프로 reliability가 필요하지만 오디오 같은 경우는 100프로 보장할 필요가 없음
  -> 경우에 따라 tcp, udp 선택 가능
  -> tcp의 단점(중간에 날아가면 재전송(느려짐))때문에 tcp 무조건 쓰는게 이득은 아님
  -> 둘중 하나를 애플리케이션에서 고르는거
• Timing : 딜레이 보장(효율적이기 위해 낮은 딜레이가 요구되는 상황)
  -> 패킷을 보내면 반대편 서버까지 몇 초 내에 반드시 도착하는 것을 보장(tcp, udp 둘 다 이거 보장 안함)
  -> 전화, 게임 등의 경우 딜레이 보장이 필요함
• Throughput : 1초에 몇비트 전송 되는가(효율적이기 위해 최소한의 throughput을 요구하는 상황)
  -> 쓰루풋 보장이 필요할 수 있음(넷플릭스 등) / elastic app 들은 보장할 필요 없음
  -> tcp, udp 둘다 보장 안함
• 보안 : 데이터 전달하면 알아서 encryption(암호화), data integrity(전달 한 내용이 변화 없이 잘 전달 되는가)
  -> tcp, udp 둘 다 지원 안함
  (참고 타이밍 - 데이터 전달하면 바로 전달되는데 걸리는 시간 / 쓰루풋 - 단위 시간당 얼마나 많이 전달 되는가)

대표적인 애플리케이션들이 reliable, 쓰루풋, 타이밍 측면에서 필요로 하는가 아닌가 나타낸 표
(데이터 손실 면에서 loss-tolerant -> 어느정도 손실이 있어도 된다 / no loss -> 손실 없어야함)
-> 위에 세개는 쓰루풋, 타이밍 모두 크게 필요 없음
-> Real-time audio/video(실시간) 는 쓰루풋, 타이밍 필요함
-> Stored audio/video(녹방) 쓰루풋은 중요한데 타이밍은 그닥
-> Game 쓰루풋은 적당히, 타이밍은 케바케(fps 등 게임 종류에 따라)
-> 문자메세지 쓰루풋은 그닥, 타이밍은 케바케

internet transport protocols services

실제로 트랜스포트 레이어에 있는 서비스 -> 크게 tcp, udp

• TCP service
  -> sending 프로세스와 receiving 프로세스 사이의 reliable한 transport(데이터의 손실 X)
  -> Flow, congestion control(중요) : 전송 속도 조절 -> 송신자 쪽에서 데이터를 밀어 넣으면 라우터나 수신자 쪽에서 데이터를 빨리 못받을 수 있음 -> 속도 잘 모니터링하면서 속도 조절함 -> 속도 조절을 통한 reliable 보장(두 기능 차이는 나중에 다룰 예정 대충 보면 flow control은 수신자를 보고 속도 조절, congestion control은 네트워크 상황에 따라 속도 조절)
  -> 타이밍, 쓰루풋, 보안 제공 안함
  -> connection-oriented : 클라이언트와 서버가 통신하기 전에 커넥션을 셋업해 주는 과정 필요. -> 위의 것들을 하려면 서로 간 컨트롤 메세지를 주고 받을 수 있는 것들이 필요하기 때문에 커넥션을 셋업해줌
• UDP service
  ->프로세스간 데이터를 보내기만 함(unreliable data transfer)
  ->위의 내용들 다 제공 안함

애플리케이션이 사용하는 애플리케이션 프로토콜과 어떤 트랜스포트 레이어를 쓰는지에 대한 표

securing TCP

타이밍, 쓰루풋은 트랜스포트 레이어에서 보장해 주기 어렵다.
보안은 해줄만 하다.

• SSL : TCP 커넥션에 대해 데이터 무결성, encryption, end point authentication(상대편이 진짜 상대편인지 위조된 것인지 구별) 등을 제공해 주는 서비스
  -> 이 세 기능이 보안에서 가장 기본적인 기능들
• SSL은 트랜스포트 레이어에 있는것이 아니라 애플리케이션 레이어에 존재
  -> 애플리케이션 레이어에 라이브러리로 존재
• SSL 소켓 API를 통해 함

출처 및 참고
https://inyongs.tistory.com/57?category=761968
Computer Networking A Top-Down Approach 7-th Edition / Kurose, Ross / Pearson
서강대학교 기초컴퓨터네트워크 강의자료