2.1 네트워크 애플리케이션의 원리

Creating a network app

• software 개발자 관점에서는 네트워크 구조가 고정되어 있다. 하지만, application 구조는 개발자가 설계하며, 여러 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.
• 이러한 application 구조는 크게 2가지로 나뉜다.
  • Client - server 구조
  • P2P 구조

Client-server paradigm

• Server
  • 항상 동작하고 있는 서버가 존재하고, Client라는 다른 호스트들로부터 서비스 요청을 받는다.
  • 서버는 잘 알려진 고정 IP 주소를 갖는다. (permanent IP address - not change)
  • 서버가 클라이언트로부터 오는 모든 요청에 더 응답하는 것이 불가능할 때
    • 많은 수의 호스트를 갖춘 data center가 강력한 가상의 서버를 생성하는 역할로 사용된다.
    • 보통 10만개 정도의 서버를 갖추고 있다.
• Clients
  • 필요할 때 connect 한다.
  • may be intermittently connected (간접적으로, 가끔식 연결된다)
  • dynamic IP address를 갖는다.
  • Client끼리는 직접 통신하지 않는다.

P2P 구조

• Client와 server 둘 다의 responsibility를 갖는다.
• 항상 켜져있는 서버에 의존하지 않는다.
• 임의의(arbitrary) end system들은 직접 소통한다.
  • 즉, peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다.
• peer는 우리가 흔히 알고 있는 Client(laptop 같은 것들)
• **Self scalability(자가확장성)**를 갖는다.
  • 즉, 사용자가 많아질수록 네트워크에 부담이 커지는 것이 아니라, 오히려 서로 도와서 네트워크의 효율성이 높아진다.
  • 예를 들어, 파일 공유 application에서는 각 peer들이 파일을 요구하여 작업 부하가 생기지만, 각 Peer들은 파일을 다른 Peer들에게 분배하여 시스템에 서비스 능력을 갖춘다.
• data center 등이 필요 없으므로 비용이 효율적이다.

👩🏻‍💻 2.1.2 프로세스 간 통신

실제 통신하는 것은 프로그램이 아니라, 실행되고 있는 프로그램인 process이다.

• 같은 host 범위 내에서, 두개의 process들은 IPC를 사용해 communication 한다.
  • Inter-process-communication : 두 개 이상의 프로세스가 데이터를 주고받는 방법
• 다른 host 범위 내에서는 exchanging messages를 통해 소통한다.
• 2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.
• P2P 구조에서처럼 Client도 서버 프로세스가 될 수 있고, 서버도 client process가 될 수 있다.
• 송신 프로세스 : 메시지를 만들어서 보냄
• 수신 프로세스 : 메시지를 받고 역으로 메시지를 보냄으로써 응답

Client, Server process

• client process : process that initiates communication
  • 요청을 보내는 쪽의 프로세스
• server process : process that waits to be contacted
  • 요청을 받는 쪽의 프로세스

Socket

process는 socket을 통해 네트워크로 메시지를 보내고 받는다. (문 같은 개념)

• 호스트의 application 계층과 transport 계층간의 인터페이스이다.
• 애플리케이션 개발자는 소켓의 application 계층에 대한 모든 통제권을 갖지만, 소켓의 transport 계층에 대한 통제권은 거의 갖지 못한다.
  • transport protocol을 선택
  • 최대 버퍼와 최대 세그먼트 크기 같은 약간의 매개변수 설정
• sending process shoves message out door - 전송 프로세스는 메시지를 밖으로 밀어낸다.
• Application과 network 사이의 API라고도 한다.

Addressing processes

프로세스가 수행되고 있는 다른 패킷으로 프로세스를 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다. 수신 프로세스를 식별하기 위해서는 두 가지 정보가 필요하다.

Identifier는 IP주소와 port number를 갖는다.

1. 호스트의 주소 즉, IP 주소가 필요하다.
   1. IP 주소가 identifier가 된다.
2. 호스트 내의 수신 프로세스를 명시하는 식별자. 즉 port 번호가 필요하다.
   1. 이 port 번호로 내 process를 특정할 수 있다.
   2. 같은 IP 주소를 가진 여러 application이나 process가 동시에 수행될 수 있기 때문에 port 번호로 구분한다.

• IP를 통해 적절한 computer를 찾는다.

👩🏻‍💻 2.1.3 An Application-layer protocol defines

application 개발자는 소켓의 application 계층에 대한 모든 통제권을 갖지만, 소켓의 transport 계층에 대한 통제권은 거의 갖지 못한다. 즉, 여기에서는 그 중 애플리케이션이 어떤 transport service를 이용할 수 있는지에 대한 내용이다.

1. Data integrity
   1. 손실되지 않는 data를 전송
2. throughput
   1. 다른 session들이 network 경로를 따라 대역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가능한 처리율은 시간에 따라 변한다. 이는 어느 명시된 속도에서 보장된 가용 처리율을 제공한다.
   2. 이러한 처리율 요구사항 여부를 기준으로 두 가지로 나뉜다.
      1. effective app : 처리율 요구사항이 있는 민감 application
      2. elastic app : 탄력적 application. 처리율 요구사항이 없다.
3. timing
   1. 예를 들어, 송신기가 socket으로 내보내는 모든 bit가 수신자의 socket에 100ms 내에 도착하게 할 수 있다. 주로 실시간 application에서 사용한다.
4. security
   1. data를 암호화 할 수 있다.

Internet transport protocols services

인터넷 전송 프로토콜이 제공하는 서비스

1. TCP 서비스
2. UDP 서비스

TCP service

• reliable transport
• 서로 전송 제어 정보를 교환하게 한다.

UDP service

• unreliable data transefer
• hand shaking 과정이 없고, 데이터가 전달되는 것을 보장하지 않는다.

TCP vs. UDP

• TCP가 UDP보다 더 유용하지만, UDP는 더 빠르다.
• 둘 다 처리율 혹은 시간 보장 서비스를 제공하지 않는다.
  • 그래서 시간 민감 애플리케이션 같은 경우, 이러한 처리율 및 시간 지연에 잘 대처할 수 있도록 설계되어 있다.

👩🏻‍💻 2.1.5 Application layer: Protocol

다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지 보내는 방법을 정의한다.

• 교환 메시지의 타입
• 여러 메시지 타입의 문법(syntax)
• 필드의 의미, 즉 필드에 있는 정보의 의미(semantics)
• 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답 하는지를 결정하는 규칙