[네트워크] KOCW 이석복 강의 - 컴퓨터 네트워크 기본 2

[한양대학교 이석복 교수, 2015년도 컴퓨터네트워크 강의]

를 개인이 정리한 글이며, [추가 내용 및 의역]이 포함되어 있습니다.

 

 

---

 

 

목차

 

 

Caravan analogy

100km/hs의 차(bit) 10대가 같이 다녀야만 할 때(packet of 10bit), 100km 떨어진 톨게이트에 도달하는 시간

단, 톨게이트에서 한대의 차에 서비스 하는 시간은 12sec

 

trasmission delay = (12*10)s = 2m

propagation delay = 1hour = 60m

total = 62m

 

중요한 것은, 패킷 단위의 전송에서 하나의 비트가 적재된 이후 바로 전파되는 것이 아니라, 한 패킷의 모든 비트가 적재될 때 까지 대기해야 한다는 점이다.

 

Creating a network App

프로그램(앱)을 작성한다면,

종단 시스템에서 실행되며 네트워크를 넘어(통해) 다른 종단 시스템과 통신한다.

 

이 때, 앱의 입장에서는 네트워크(네트워크 코어/라우터 등)를 거치지만, 네트워크는 앱을 실행시키지 않으며 데이터 전송의 역할만을 담당하므로 빠른 개발 및 배포가 가능하다.

 

Client-server architecture

Server

항상 켜져있다/호스팅을 제공한다.

확장을 위한 데이터 센터를 가진다.

고정적(Static) IP 주소를 가진다.

+ 일반적으로는 참이나, (주로 모놀리식 아키텍처에서)

디스커버리 서버 등과 연계하여 동적인 IP 주소를 가지는 아키텍처도 존재 (장애대처, 성능 개선의 달성을 위함)

 

Client

서버와 소통한다.

간헐적인 연결을 할 수 있다.

동적인(Dynamic) IP 주소를 가질 수 있다.

클라이언트간의 직접적인 통신은 하지 않는다. <-> P2P Network

 

Processes communicating

Process

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

코드/데이터의 집합인 실행파일(.exe)의 내용을 바탕으로, 실질적으로 메모리 공간을 할당받아 동작하는 프로그램

 

같은 호스트 내의 프로세스 통신

IPC(inter-process-communication)를 사용하여 통신한다.

IPC 자체는 프로세스간의 통신을 위한 기술이며, 실직적인 Interface는 OS가 API 형태로 제공한다.

다른 호스트간의 프로세스 통신
메시지를 교환함으로써 통신한다

Client/Server Process의 구분

Client Process

통신을 시작하는 입장의 프로세스

 

Server Process

통신을 대기하는 입장의 프로세스

 

P2P 아키텍처에서는 모든 프로세스가 Client이자 Server로 동작할 수 있다.

 

Network Model : Overview

 

 

OSI 7계층을 네트워크 측면으로 간소화하며 TCP/IP 4계층으로 정의하였고, 이를 다시 세분화하며 TCP/IP 5계층 모델이 탄생했다.

 

TCP/IP 5 Layer

각 네트워크 컴포넌트들의 구성과 동작을 추상화한 네트워크 모델중 하나.

	Layer	Protocol	Data Unit	Addressing
5	Application	HTTP, SMTP	Message	n/a
4	Transport	TCP/UDP	Segment (TCP), Datagram (UDP)	Port #
3	Network	IP	Datagram	IP address
2	Data Link	Ethernet, Wi-Fi	Frames	MAC address
1	Physical	10 Base T, 802.11	Bits	n/a

 

 

Handshake를 하는 이유?

응용 프로그램(5 계층)간의 통신이전에, 4 계층의 Handshake를 수행한다.

e.g. HTTP 통신을 위한 TCP 3-Way Handshake => 하위 프로토콜의 커넥션

 

이는 하위 계층에서 상위 계층으로 서비스를 제공하는 구조이기 때문이며,

신뢰성 보장 및 요구사항 충족을 위해 본격적인 통신 전의 사전 작업을 수행하는 것이다.

 

Sockets

프로세스는 소켓을 통해 메시지를 주고받는다.

소켓을 통해 전송된 메시지는 소켓 너머의 전송 인프라에 의존하여 수신 프로세스로 전달된다.

(소켓은 메세지의 진출/진입 지점으로서, 문과 같은 역할을 한다.)

 

TPC/IP 5Layer 에서의 측면으로 봤을 때,

앱 계층은 앱 개발자에 의해 조작되며, 이 외의 계층은 OS에 의해 조작된다.

(메시지 전송 이후 전달까지의 동작은 앱 개발자 외의 영역(OS/Network)에서 다뤄짐을 의의하고자 하는듯)

 

What transport service does an app need?

Data intergrity (신뢰성) - 데이터가 유실되지 않고 도착

일부 앱들은 100% 신뢰성있는 데이터 전송이 필요하다. 

이 외의 앱들은 일부의 손실(loss)를 견딜 수 있다.

UDP는 이를 제공하지 않는다.

 

Timing - 데이터가 의도한 시간내에 도착

일부 앱들은 패킷의 손실은 허용되지만, 낮은 딜레이(지연율, Latency)가 중요하다.

e.g. interactive games (FPS 등)

 

Throughput - 데이터가 의도한 대역폭을 지속하며 도착

일부 앱들은 서비스를 위해 매 순간 최소한의 품질을 유지해야 할 필요가 있다.

e.g. 멀티미디어 플랫폼 (Youtube 등)

 

Security - 데이터의 보안성

현대에서는 앱 계층에 직접적인 보안을 제공하지 않는다.

(이 외의 계층은 자체 제공하나, 추가 보안이 필요할 수도 있다.)

 

따라서, 앱 개발자가 보안 프로세스의 구현을 선택해야 한다.

(자체 구현, 관련 프레임워크/기술 사용, 외부 보안 프로그램 사용 등)

 

Web and HTTP

웹 페이지는 오브젝트로 구성된다.

e.g. HTML/image/audio/applet

 

좀 더 세부적으로, 기본(base)이 되는 HTML file에 포함된 다수의 참조된 객체들(referenced objects)로 구성된다.

HTML file 또한 오브젝트임을 기억하자.

 

Applet

Application에 작은 것을 뜻하는 접미사 -let이 덧붙여진 용어 자체로는 작은 프로그램을 의미한다.

호스트 프로그램(더 큰 프로그램)의 부분으로서, 특정한 작업을 수행하는 응용 프로그램이다.

 

각 객체는 URL 등으로 주소 지정이 가능(addressable)하다.

즉, 주소창에 URL을 입력하는 행위는 host와 resourse(혹은 오브젝트)의 path를 입력하는 것이다.

 

URL vs URI

 

IP/Port

 

IP Address

물리적 장치의 (인덱싱된) 인터넷상 주소

 

Port

해당 장치의 프로세스 번호, 정확히는 포트에 존재하는 소켓 식별자

 

Default Port가 80인 이유?

HTTP에 표준 포트로 정의되었기 때문이다.

- DNS는 IP Address만을 대체한다. Port마저 상이하면 DNS Server가 이 또한 다뤄야 하기 때문이다.

 

따라서, Host Name(혹은 도메인)만을 입력했을 때는 HTTP Default Port 번호 80이 생략되어 있는 것이다.

Port 80은 HTTPS Default Port인 443으로 Redirect될 수 있다.

 

 

HTTP : Overview

HTTP (Hypertext Trsnfer Protocol)

앱 계층의 프로토콜의 종류, (stateless 등의 키워드는 생략함)

 

Client/Server의 구분

 

Client

(HTTP를 사용하여) 웹 객체를 요청하고, 수신하고, 표시한다.

 

Server

(HTTP를 사용하여) 요청에 응답하여 웹 객체를 전송한다.

 

HTTP Connection : Persistent HTTP VS Non-Persistent HTTP

HTTP 가 TCP를 사용하는 방식에 따라 구분된다.

 

Non-Persistent HTTP

단일 객체의 전송 이후 연결이 끊기게 된다. 하나의 객체가 하나의 TCP 연결을 통해 전송된다.

N개의 오브젝트 처리를 위해, N번의 연결을 필요로 하게 된다.

 

Persistent HTTP

요청을 완료하기 전까지 TCP 연결이 지속된다.

 

1개의 HTML File에 10개의 이미지가 참조된 객체로 존재한다면,

 

Non-Persistent HTTP의 경우

 

HTML File을 전달받고, TCP 연결을 종료한다.

HTML File을 Parsing하여 10개의 이미지가 참조 객체로 포함되었음을 찾아낸다.

10번의 TCP 연결 및 HTTP 통신을 통해 객체들을 전달 받는다.

 

총, 11(1+10)번의 TCP 연결이 필요하다.

 

Persistent HTTP의 경우

 

HTML File을 전달받고 Parsing하여 10개의 이미지가 참조 객체로 포함되었음을 찾아낸다.

Parsing이후 추가 작업이 없다면 TCP 연결을 종료한다. 해당 경우에는 있으므로 연결을 유지한다.

10개의 이미지를 전달하고, TCP 연결을 종료한다.

 

총, 1번의 TCP 연결이 필요하다.

 

장단점

Non-Persistent HTTP

장점

간단한 구현 및 단순성, 명확한 연결과 종료, 독립적인 작업 단위로 인한 에러 처리

단점

연결 및 종료 반복으로 인한 오버헤드

 

Persistent HTTP

장점

연결 재사용으로 인한 성능 및 지연률 감소

단점

연결 유지 및 관리 비용, 타임아웃 처리

 

HTTP의 종류

HTTP/1.0 (TCP기반  Non-Persistent HTTP)

최초의 HTTP

Non-Persistent Connection - Connection: keep-alive 헤더를 통해 Persistent HTTP를 지원했지만, 모두 지원하진 않았음

 

HTTP/1.1 (TCP기반  Persistent HTTP)

Persistent Connection - Default "Connection: keep-alive" 헤더 사용

Pipelining - But 요청이 순차적으로 처리되므로 일부 성능 저하가 발생했음

많이 사용되지만, 프로토콜 개선에 따라 점차 감소 추세

 

HTTP/2 (TCP기반  Persistent HTTP)

Persistent Connection

Multiflexing - 단일 TCP 연결을 통해 여러 스트림을 동시에 처리 가능

헤더 압축  - QPACK을 사용하여 반복적인 헤더 데이터를 압축하여 전송

Server Push - 서버가 클라이언트 요청 이전에 자원을 푸쉬할 수 있음

많은 최신 웹 서버(e.g. Apache, Nginx)와 브라우저(e.g. Chrome, Firefox, Safari)에서 HTTP/2를 지원

 

HTTP/3 ( UDP기반 QUIC(Quick UDP Internet Connections))

Persistent Connection 

Multiflexing -  QUIC 기반

연결 지연 최소화 - 핸드쉐이크 지연 감소, 패킷 손실 및 재전송 처리 개선

QUIC의 이점 활용을 위해 Google이 개발, 아직은 적은 사용 지분 (표준화, 검증 등 필요)