Ch2-1) Principles of internet network

 

• 우선, Network Application을 만들 때 고려해야할 사항들을 생각해보자.
• 우리는, “end system”에서 동작할 수 있는 프로그램을 만들어야한다.
  • 또한, 이러한 프로그램들은 서로 통신을 할 수 있어야 한다.
    • ex) 웹 서버 소프트웨어는, 웹 브라우저 소프트웨어와 통신한다. (클라이언트-서버)
• 또한, 소프트웨어 app은 네트워크 코어에 대해서는 고려하지 않아도 된다.
  • 네트워크 Application을 만들 때엔, 라우터 및 스위치 등 Network Core에 대한 소프트웨어를 작성할 필요가 없다.
  • Network Core 장치들은 단지 데이터를 전달하는 역할만 수행하기 때문이고, Application은 주로 end-system에서 작동하기 때문이다.
  → end-system에서 Network core에 대한 고려를 하지 않아도 개발자는 App자체에 집중할 수 있다.
• ⇒ Application developer는 Network core을 고려해 App을 만들어야한다? (맞춰보세요~)

Network application architecture

• 잘 알려진 application architecture에는 크게 2가지 종류가 있다.

1. Clien-server paradigm

• 항상 동작하고 있는 서버가 존재하고, 클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다.

 

• Server
  • 항상 동작중이다.
  • 영구적인 IP주소를 갖는다.
  • 보통 데이터 센터에 존재한다.
• Client
  • 서버에 요청하고, 소통하는 호스트이다.
  • Client들은 서로 직접적으로 통신하지 않는다.
  • 동적인 Ip 주소를 가질 수 있다.
  • Clinet는 서버와 intermittently (간헐적으로) 연결된다.
    • 즉,항상 서버와 연결되어 있지 않을 수 있다. (연결이 불안정할 때)
• 이러한 예시로, HTTP, SMTP, FTP 등이 있다.

 

 

2. Peer-Peer paradigm (P2P)

• always-on server가 존재하지 않는다.
• 대신에 애플리케이션은 peer라는 간헐적으로 연결된 호스트 쌍( end-system)이 서로 직접 통신하게 한다.
  • 여기서 peer은 흔히 알려진 client라고 생각하면 될 듯 하다.
  • IP 주소를 동적으로 바꾼다.
• Self-scalability가 존재한다.
  • 새로운 Peer가 네트워크에 참여할 때마다, 네트워크의 규모도 함께 확장된다.
  • 규모가 확장되면 당연히 수요도 커진다.

⇒ P2P에서, Scalability가 증가하면 전체 Delay도 커진다? (맞춰보세요~)

 

 

 

 

Process communicating

• Program은 여러개의 Process로 이루어 지는데, 이 End-system을 구성하는 process간의 communication을 통해 데이터를 주고받는다.
• Inter-Process Communicating
  • 동일한 호스트에서 실행되는 여러가지 프로세스들은, OS에 의해 관리받는다.
• 이때, Client Process를

process that initiates communication : communication을 시작하는 Process

라고 정의하고,

• Server process를

process that waits to be contacted : 연결되기를 기다리는 process

라고 정의한다.

참고로, P2P 구조에서 봤듯이 클라이언트도 서버 프로세스가 될 수 있고, 서버도 클라이언트 프로세스가 될 수 있다.

→ 그렇다면, 이 프로세스들은 어떻게 메시지를 주고받을까?

Socket

• 프로세스들은 socket을 통해 네트워크로 메시지를 주고받는다.
• 네트워크에서 Process를 집이라고 한다면, Socket은 Application layer과 Transport layer을 연결해주는 문 같은 존재이다.

 

 

위 그림에서 알 수 있듯이, Socket은 Application layer과 Transport를 연결해주는 Interface이므로,

Application과 네트워크 사이의 API라고도 부른다.

• Socket을 통해서 Network를 송수신할 수 있다.
  • 이때 송수신하기 위해서, Transport layer의 TCP, UDP와 같은 프로토콜에 의존하게 된다.

→ 그렇다면, 이렇게 Process끼리 메시지를 주고받기 위해서는, 상대방의 주소를 알아야 하는데, 어떻게 알 수 있을까?

• 바로 IP Address의 존재로 상대방의 위치를 인식할 수 있다.
• 하지만, 상대 Application의 IP 주소를 알아냈다고 하더라도, 하나의 Application에서 여러 process들이 동시에 동작하고 있을 수 있기에, 어느 process에 메시지를 전달할 지도 결정되어야 한다.
  • 즉, 수신 프로세스를 명시하는 식별자인 “Port” 번호가 필요하다.

Application protocol role

• 그렇다면, Application layer의 protocol은 무엇을 define하는 것일까?
• 다음과 같은 것들을 정의한다.
  • Types of message exchanged
    • Request, Response와 같은 주고받을 메시지의 종류를 규정한다.
  • Message syntax
    • 또한, 이러한 메시지들이 어떠한 구조와 field를 가질 지도 규정해야한다.
    • Ex) Request의 GET, POST method
  • Message semantics
    • Syntax까지 설정했으면, 각 필드가 무엇을 의미하는지도 정의해야한다.
    • Ex) 이메일 프로토콜에서 수신자, 발신자 Field가 무엇을 의미하는지
  • Rules for message exchange
    • 또한 어떠한 규칙을 가지고 메시지를 주고받을 것인지 규정한다.
    • 언제 응답을 보내고, 답장을 받을것인가?
• Application Protocol의 종류에는 크게 2가지가 존재한다.
  • Open Protocol
    • RFC ( requests for comments)에 의해 규정되어, 누구나 그 포로토콜의 정의에 접근할 수 있다.
    • 이를 통해 Interoperabillity ( 상호 운용성 : 다양한 기기에서 호환 가능) 를 보장한다.
    • HTTP, SMTP와 같은 프로토콜이 있다.
  • Proprietary Protocol
    • 특정 회사나 기업이 소유하고 있는 프로토콜이다.
    • SKYPE와 같은 프로토콜이 있다.

⇒ Open protocol은 standardized protocol의 일종이다? (맞춰보세요 ~)

What transport service does an app need?

• 앞서, Application들은 Socket을 통해서 Transport layer에게 메시지를 전달할 수 있다고 했다.

→ 그럼 Transport protocol이 application에 제공할 수 있는 service의 종류엔 무엇이 있을까? 크게 4가지가 존재한다.

1. Data integrity (신뢰성 있는 Data 전송)

• Ch1.에서 보았듯이 몇몇 Packet들이 사라질 수 있다.
• 몇몇 앱은 100% reliable한 data를 transfer해야 하기에, Data를 socket으로 보내고 그 data가 오류없이 destination process에 도착할거 라는 믿음이 필요하다.
• 실시간 vedio/audio application처럼 loss를 허용하는 앱도 있다.

1. Throughput (대역폭 = 처리율)

• 다른 세션들이 네트워크에 따라서 대역폭을 공유하기에, throughput은 시간에 따라서 변한다
• 이때 Transport Protocol은 어느정도 명시된 throughput을 보장한다.
• 몇몇 app들(Multimedia)은 효과적으로 service를 제공하기 위해 필요한 “최소한의 throughput”이 존재할 수 있다.
  • Elastic apps(탄력적 어플리케이션)은 요구사항이 없다.

1. Timing

• 실시간 Application에서는, 송신자가 socket으로 내보내는 모든 비트가 수신자의 socket에 일정 시간 안에 도달해야 하기 때문에, Transport protocol은 도착 시간을 보장해준다.

1. Security

• 송신할 때는 암호화, 수신할 때는 해독하는 과정을 지원해준다.

아래 사진은, 대표적인 app들에서 요구하는 transport layer service의 표이다.

 

→ 그렇다면, 각자가 요구하는 서비스에 따라서 Protocol의 기능을 달리하여 세분화하는 과정이 필요하다.

이를 대표하는 2가지 Transport protocol이 바로 TCP, UDP이다.

 

 

TCP, UDP

• TCP protocol은 다음과 같은 기능들을 제공한다.
  • Reliable transport
    • 송수신 과정에서, hand-shaking 과정을 통해 안정적으로 송수신할 수 있도록 한다.
  • Flow control
    • Receiver가 처리할 수 있는 데이터 양만큼만 sender가 보낼 수 있도록 Flow를 control할 수 있다.
  • Congestion control (혼잡 제어)
    • 네트워크가 과부하 상태일 때 송신 속도를 줄여 네트워크 혼잡을 방지할 수 있다.
• 하지만, 다음과 같은 기능들은 제공하지 않는다.
  • 전송 도착 시간(Timing), 최소 대역폭 (minimum Throughput) , Security
• 또한, TCP는 sender와 receiver 간의 connection이 성립되어야 data 전송을 시작한다.
• UDP protocol은 다음과 같은 기능들을 제공한다.
  • Unreliable data transfer
    • 데이터를 보낼 때, 수신자가 잘 받았는지 확인하지 않고, 데이터 손실이 발생해도 재전송하지 않는다
• UDP protocol은 다음과 같은 기능들은 제공하지 않는다
  • reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup.

→ 그럼 UDP 요 새끼 왜써요??

UDP는 TCP에 비해 간단하고 빠르기 때문에, 빠른 데이터 전송이 필요한 실시간 서비스에서 유용하다.

ex) Streaming , Game 등 에서는 데이터의 손실이 발생하더라도 빨리 데이터를 전송하는 것이 중요하다.

Security for TCP

• Vanilla TCP&UDP socket들은,
  • encryption이 보장되지 않았다.
    • 그렇기 때문에 password를 qwer1234로 입력하면, 그대로 qwer1234로 전송됐다. ㅋㅋㅋ

→ 그래서, 이러한 단점을 보완하기 위해 나온 Secure Protocol이 바로 TLS이다.

• TCP connection의 encryption을 제공한다.
• Data integrity를 보장한다. (송수신 사이에 데이터손실 x)
• End-point Authentication 을 제공해 신뢰할 수 있는 대상 사이에 통신이 이루어짐을 보장한다.

⇒ TLS가 보완하는 TCP의 단점 3가지를 쓰시오.( 혼자 생각해보세요~ )

• TLS는 Application layer에서 구현되는데, Application들이 TLS라는 Library를 이용해 통신 내용을 암호화한다.
  • 기본적으로 TCP 위에서 동작한다.
  • TLS 소켓 API를 사용하면, 애플리케이션이 소켓에 입력한 평문 데이터가 암호화되어 인터넷을 통해 전송된다. 사용자는 TLS를 사용함으로써 평문 데이터를 안전하게 전송할 수 있다.