Chapter 3.3 UDP

Computer Networking : A Top Down Approach 7th Edition, Global Edition Jim Kurose, Keith Ross

UDP : User Datagram Protocol [RFC768]

User Datagram Protocol의 축약어로 컴퓨터가 다른 컴퓨터와 데이터 통신을 하기 위한 규약(프로토콜)의 일종이다. 

UDP는 TCP와 달리 Transport-layer Protocol이 할 수 있는 최소 기능인 Multiplexing과 Demultiplexing, 오류 검사(checksum)만으로 동작한다. 

UDP는 Segment를 송신하기 전에 TCP 처럼 상대방과의 연결이 잘 이루어졌는지 확인(3-way handshake) 하지 않는다. 

더보기

* TCP 3-way Handshake 란?

 

TCP는 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 3-way handshake를 사용한다.

TCP 3-way handshake는 TCP/IP프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 

먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미한다.

 

이러한 이유로 비연결형(connectionless)이라고 한다.

connectionless:

•no handshaking between UDP sender, receiver

•each UDP segment handled independently of others

UDP의 사용

• 도메인 이름 서비스(DNS)
• IPTV
• 음성 인터넷 프로토콜(VoIP)
• TFTP, RTSP, RIP, OSPF
• NTP(Network Time Protocol)
• IP Tunnel
• Online game(Client - Server)

UDP를 사용하는 애플리케이션 계층 프로토콜의 하나인 DNS의 경우, 브라우져가 서버와의 데이터 교환을 위해서는 DNS를 통해 서버 컴퓨터의 IP주소를 알아낸다.

UDP 특징

1. Finer application-level control over what data is sent, and when

(애플리케이션 레벨이 데이터 송신에 대해서 정교한 제어를 할 수 있다.)

UDP의 경우, 애플리케이션 프로세스가 데이터를 UDP에게 전달하자마자 UDP는 데이터를 Segment로 만들고 즉시 아래의 Network-layer로 전달한다. 

이에 반해 TCP는 혼잡제어(congestion control) 매커니즘을 가지고 있어서 이를 이용해 호스트들 사이의 링크가 혼잡해지면 TCP 송신자를 조절한다. 또한, 목적지로부터 Segment의 수신 여부 확인(ACK)응답을 받기 전까지 계속해서 Segment를 재전송하게 된다.

TCP의 이러한 특징은 실시간(Real-time) 어플리케이션(예: 라이브 방송)에서는 적합하지 않다. 영상의 픽셀에서 점(.)의 크기만한 픽셀을 받지 못하였다고 버퍼링에 걸리는 것은 매우 비효율적이기 때문이다. 최소한의 전송률만을 요구하고 지나지게 지연되는 전송은 적절하지 않다.

이러한 실시간 어플리케이션의 경우 UDP를 사용한다면 기본 세그먼트 전달 외에 필요한 추가 기능을 구현할 수 있다. 

2. No connection establishment(연결 설정이 없다)

위에서 설명하였 듯 UDP는 connectionless 이다. TCP처럼 데이터 전송을 시작하기 전에 3-way handshake를 사용하지 않는다.

3. No connection state(연결 상태가 없다)

TCP는 종단 시스템(End system)에서 연결 상태를 유지한다. 이 연결상태에는 수신버퍼, 송신버터, 혼잡제어 파라미터, sequence number, ACK number 가 포함된다. 허나 UDP는 연결 상태를 유지하는 기능의 프로토콜이 아니므로 이 파라미터 중 아무것도 기록하지 않는다. 따라서 일반적으로 특정 어플리케이션에 할당된 서버는 애플리케이션이 TCP보다 UDP가 더 많은 클라이언트를 수용할 수 있다.

4. Small packet header overhead(작은 패킷 헤더 오버헤드)

TCP가 Segment 마다 20byte의 헤더 오버헤드를 갖는 반면, UDP는 겨우 8byte의 오버헤드를 가진다.

UDP segment header

애플리케이션 데이터는 UDP 세그먼트의 data 필드에 위치한다. 즉, 실질적으로 보내려고 하는 data가 위치하는 곳이다.

그 위에 위치한 4가지의 필드들은 이 data를 주고 받기 위한 최소한의 형식적인 필드이다. (최소 기능으로만 동작한다는 것은 위에서도 언급하였음) 체크섬(checksum)은 Segment에 오류가 발생했는지 검사하기 위해 수신 호스트에 의해 사용된다.

한눈에 봐도 UDP가 좀 더 가벼워(=만들기 간단, 빠름) 보인다.

UDP checksum

체크섬은 오류를 검출하기 위해 사용한다.

간단히 말해서 지금 받은 데이터가 출발지로부터 목적지까지 이상없이 잘 받아졌는가 확인할 때 사용한다는 것이다.

송신측

송신측에서 UDP는 세그먼트를 16byte로 나누어 서로 더하고

treat segment contents, including header fields,  as sequence of 16-bit integers

이에 대하여 1의 보수를 수행하며, 덧셈 과정에서 발생하는 overflow는 자리 올림을 한다.

checksum: addition (one’s complement sum) of segment contents

이 결과는 UDP 세그먼트의 체크섬 필드에 삽입된다.

sender puts checksum value into UDP checksum field

수신측

수신측에서는 체크섬을 포함한 모든 16비트 워드를 더한다. 위 그림에서 만약 패킷에 어떤 오류도 존재하지 않는다면 소신자에서의 합은 1111 1111 1111 1111 이 될 것이다. 만약 비트 중 하나라도 0이 있다면 (가령 1011 1111 1111 1111) 패킷에 오류가 발생했음을 알 수 있다.

UDP는 오류가 있는지 없는지 검사를 하지만 오류가 있다고 해서 어떠한 일도 하지 않는다.

CREATE

CREATE 문을 사용하여 데이터베이스와 테이블을 만들 수 있다

SELECT

SELECT 문을 사용하여 테이블의 레코드를 선택할 수 있다.

INSERT

INSERT INTO 문을 사용하여 테이블에 새로운 레코드를 추가할 수 있다.

두 번째 문법처럼 필드의 이름을 생략할 수 있으며, 이 경우에는 데이터베이스의 스키마와 같은 순서대로 필드의 값이 자동 대입된다.

이때 생략할 수 있는 필드는 다음과 같다.

1. NULL을 저장할 수 있도록 설정된 필드

2. DEFAULT 제약 조건이 설정된 필드

3. AUTO_INCREMENT 키워드가 설정된 필드

ALTER

ALTER DATABASE 문은 데이터베이스의 전체적인 특성을 수정할 수 있다.

UPDATE

UPDATE 문을 사용하여 레코드의 내용을 수정할 수 있다.

ALTER과 UPDATE 모두 수정을 하기 위한 명령이지만 차이점이 있다.

ALTER는 데이터베이스의 관계 (테이블) 구조를 수정하는 데 사용되며,

UPDATE 명령은 데이터베이스 관계에 저장된 데이터를 수정하는 데 사용된다.

즉, ALTER 명령은 데이터 정의 언어 명령 이고, UPDATE 명령은 데이터 조작 언어 명령이다.

DELETE

DELETE 문을 사용하여 테이블의 레코드를 삭제할 수 있다.

자료 출처 : http://tcpschool.com/mysql/ ,

https://ko.gadget-info.com/difference-between-alter

Chapter 3.2 Multiplexing / Demultiplexing

Computer Networking : A Top Down Approach 7th Edition, Global Edition Jim Kurose, Keith Ross

목적지 호스트의 Transport-layer 은 바로 아래의 Network-layer 로부터 Segment를 수신 받는다.

Segment를 받은 Transport-layer은 호스트에서 실행중인 애플리케이션 프로세스에게 이 Segment의

데이터를 전달한다. 이 때, 프로세스는 소켓(socket)에서 이 데이터를 받아들인다.

위 그림에서 볼 수 있듯이 소켓(socket)은 Application-layer 와 Transport-layer의 사이에 위치하여,

데이터를 서로에게 전달해주는 중재자 역할을 한다. 그런데 이 소켓은 꼭 1개만 존재하는 것이 아니라

여러 개가 존재할 수가 있다. 이때, 소켓을 구별하기 위한 식별자를 가지게 된다.

소켓의 갯수가 1개가 아니기 때문에, Transport-layer에서 받은 Segment를 구별하여 각각 지정된 소켓에

보내줄 필요가 있다. 

따라서 이를 위해, Segment에 소켓을 구별하기 위한 필드를 추가를 하게 된다.

• 출발지 포트번호 필드(src port number field)
• 목적지 포트번호 필드(dot port number field)

더보기

포트번호는 0~65535까지의 16비트 정수이며, 1~1023번까지의 포트는 잘 알려진 포트 번호(Well-Known Port 

Number)라고 하여 사용을 제한한다.

 

<주요 포트 번호>

소켓은 다른 소켓과 구분되는 자신의 포트번호를 할당 받는다. 따라서 Transport-layer에서 Segment 안의 목적지 포트 번호를 확인하고, 이와 맞는 포트 번호를 가진 소켓으로 해당 Segment를 전달한다. Segment를 받은 소켓과 연결된 

Application은 해당 데이터를 무사히 받을 수 있게 된다.

여기서 Transport-layer의 Segment를 알맞은 소켓으로 보내는 작업을 Demultiplexing이라고 한다.

최초로 데이터가 출발한 호스트에서 Segment 앞에 Header를 붙혀 캡슐화하고

Network-layer로 내려보내는 작업을 Mutiplexing이라고 한다.

Connectionless demultiplexing

UDP 소켓 9157을 가진 호스트 A의 프로세스 P3에서 UDP 소켓 6428을 가진 호스트 B의 프로세스

P1에게 데이터 전송을 한다고 가정하자.

Multiplexing

이때, 호스트 A에서의 Transport-layer에서는 프로세스 P3 -> 소켓으로부터 전달 받은 데이터와 출발지 포트 번호(9157),

도착지 포트 번호(6428) + α 를 가지고 있는 Segment를 생성한다. 이 Segment를 Network-layer로 전달한다.

Segment를 받은 Network-layer은 이 것을 IP Datagram으로 캡슐화하고 best-effort delivery Service 로 목적지인

호스트B로 전달한다.

Demultiplexing

호스트 B의 Transport-layer에서는 받은 Segment 안의 목적지 포트 번호(6428)를 확인하고, 일치하는 포트 번호를

갖는 소켓에 해당 Segment를 전달한다.

※ 그럼 출발지 포트 번호는 언제 사용하는가? 

Connection-oriented demux

TCP 소캣은 4개의 요소(tuple)로 식별된다.

• source IP address
• source port number
• dest IP address
• dest port number

따라서, TCP Segment를 전달 받았다면 알맞은 socket에 전달하는 작업(Demultiplexing)을 위해 4개의 값을 사용한다.

호스트 A의 프로레스 P3가 호스트 B의 프로세스 P4에게 데이터를 보낼 때

    P3 : src IP : address A  | src Port : 9157 |  dest IP : address B | dest Port : 80

호스트 C의 프로세스 P2, P3가 호스트 B의 프로세스 P3에게 데이터를 보낼 때

 P2 : src IP : address C | src Port : 5775 | dest IP : address B | dest Port : 80

 P3 : src IP : address C | src Port : 9157 | dest IP : address B | dest Port : 80

프로세스 P2, P3는 출발지 포트 번호가 각각 5775, 9157로 다르기 때문에 다른 소켓으로 향한다.

그렇다면 연결이 많이 생긴다면 그만큼 소켓의 개수가 늘어날까?

Server는 Client에서 오는 Segment를 구별하여 많으면 많을수록 연결 소켓을 많이 생성하며,

각 연결을 따라서 새로운 프로세스도 많이 만들 것이다.

하지만, 오늘날의 고성능 Sever들은 하나의 프로세스만을 사용한다.

새로운 Client와의 연결을 위해 새로운 연결 소켓과 함께 Thread를 만들어 사용한다.

아직까지 특별하게 어려운 것은 없는 거 같다.

중학생 시절, Visual basic으로 Winsock을 이용해 멀티 chat 같은 걸 만들어보곤 했는데

그때 찾아봤던 내용인 것 같다. 전공으로 들으니 재밌구만.

_끗

DBMS (Database Management System)

데이터베이스란?

대량의 정보를 컴퓨터가 효율적으로 접근할 수 있도록 가공 및 저장한 것.

DBMS란?

데이터베이스를 관리하고 다수의 사용자가 데이터베이스 내의 데이터를 공유하며

사용할 수 있는 환경을 제공하는 소프트웨어.

DBMS를 사용하지 않는다면

• 다수의 사람이 데이터를 공유하기 어려움.
• 대량의 데이터를 다루기 어려움.
• 읽기/쓰기를 자동화하려면 프로그래밍 기술이 필요.
• 만일의 사고에 대응하기 어려움 (보안, 백업)

관계형 데이터베이스 (Relational Database)

현재 가장 많이 사용되고 있는 데이터베이스의 한 종류이며 현대 데이터베이스 시스템들의 기준.

관계형 데이터베이스는 테이블(table)로 이루어져 있으며, 이 테이블 안에서 키(key) 와 값(value)의 간단한 관계를

2차원 형식으로 나타낸다. 하나의 데이터베이스 안에는 여러 개의 테이블이 존재할 수 있다.

테이블의 행(row)은 레코드(record)라고도 부르며, 데이터 한 건에 해당한다.

테이블의 열에 해당하는 컬럼(column)은 데이터를 구분하기 쉽게 이름을 붙혀 분류한다. (ex: 제목, 장르, 시간 등)

또한 각 컬럼은 특정한 데이터 타입을 가진다. (ex. 평점의 데이터 타입은 DOUBLE)

관계형 데이터베이스의 특징

1. 데이터의 분류, 정렬, 탐색 속도가 빠름.
2. 오랫동안 사용된 만큼 신뢰성이 높고, 어떤 상황에서도 데이터의 무결성을 보장.
3. 데이터는 관계를 통해서 연결된 여러 개의 테이블에 분산됨.
4. 기존에 작성된 스키마(Structure)를 수정하기가 어려움.
5. 데이터베이스의 부하를 분석하는 것이 어려움.

RDMBS ( Relational Database Management System)

: 관계형 데이터베이스를 생성, 갱신, 관리하기 위한 시스템.

Client가 데이터를 조회하고 싶을 때, SQL로 요청을 RDMBS에 보내면 RDMBS는 요청된 데이터를

2차원 표 형태로 반환.

대표적인 RDMBS

• ORACLE DB : 가장 오래되었고 신뢰도가 높다. 뛰어난 기술력과 안정성. 은행에서 많이 쓰이며 유료.
• MySQL : 오픈 소스 기반으로 무료. 썬마이크로시스템즈를 거쳐 현재 오라클에 흡수합병.
• Microsoft SQL Server : 마이크로소프트가 개발한 RDMBS. 윈도우 시스템 환경을 지원.
• PostgreSQL : 버클리 대학의 프로젝트로 만들어진 오픈 소스 ORDBMS이다. (객체 - 관계형 DB)
• Maria DB : MySQL 5.5를 기반으로 만들어졌다.
• SQLite : DB를 서버가 아닌 파일로 저장한다. 가벼운 DB를 저장하는 목적으로 설계되어 스마트폰에 사용된다.

SQL, Structured Query Language

관계형 데이터베이스 시스템(RDBMS : relational database management system)의 데이터를 관리하기 위해

설계된 특수 목적의 프로그래밍 언어(쿼리)이다.

SQL을 사용하면 RDBMS에서 데이터의 저장, 수정, 삭제 및 검색을 할 수 있다.

중요한 SQL 명령어

• SELECT - 데이터베이스에서 데이터 추출
• INSERT INTO - 데이터베이스에 새로운 데이터 삽입
• UPDATE - 데이터베이스의 데이터 갱신
• DELETE - 데이터 삭제
• CREATE DATABASE- 새로운 데이터베이스 생성
• ALTER DATABASE - 데이터베이스 변경
• CREATE TABLE - 테이블 생성
• ALTER TABLE - 테이블 변경
• DROP TABLE - 테이블 삭제
• CREATE INDEX- 인덱스 생성
• DROP INDEX - 인덱스 삭제

Chapter 3 Transport Layer

Computer Networking : A Top Down Approach 7th Edition, Global Edition Jim Kurose, Keith Ross

3.1 Transport-layer services

트랜스포트 계층 프로토콜은 서로 다른 호스트에서 동작하는 애플리케이션 프로세스들 간의 논리적 통신을 제공.

Provide logical communication between app processes running on different hosts.

    ※논리적 통신 : 애플리케이션의 관점에서 프로세스가 동작하는 호스끼리 직접 연결된 것처럼 보이는 것

트랜스포트 계층 프로토콜은 네트워크 라우터가 아닌 종단 시스템(end systems)에서 구현되어 있음.

Transport protocols run in end systems

1. 송신 측의 트랜스포트 계층은 송신 애플리케이션 프로세스로부터 수신한 메세지 앞에 트랜스포트 계층의 Header를 붙히고 이것을 세그먼트(Segments) 단위로 변환. 이후 아래 계층인 네트워크 계층으로 세그먼트를 전달한다.
2. 네트워크 계층은 받은 세그먼트를 데이터그램(Datagram)으로 변환 후, 링크 계층으로 전달한다.
3. 링크 계층은 받은 데이터그램을 프레임(Frame)으로 변환 후 수신측으로 전송한다. 

 이후, 이것을 받은 수신자는 링크계층 부터 애플리케이션 계층까지 순차적으로 Header을 읽어나가며

최종 데이터를 전송 받게 된다.

네트워크가 가능한 애플리케이션에서는 하나 이상의 전송 계층 프로토콜 사용이 가능하다. 

More than one transport protocol available to apps

 Ex) Internet : TCP, UDP

3.1.1 Transport vs network layer

• Network layer : logical communication between hosts
• Transport layer : logical comunication between processes

예) 두 집에 각각 6명의 아이, 총 12명의 아이가 있음. 한 집은 Ann이, 다른 한 집은 Bill이 아이들의 보호자이다.

두 집에 따로 살고 있는 아이들이 서로에게 편지를 쓰려고 한다.

  이때, 집은 host, 아이들은 그 집의 processes로 볼 수 있다.

집에서 서로 편지를 보내는 것은 host 사이의 이루어지는 일이므로 Network layer에 해당한다.

편지를 받는 집(host)에 있는 Ann과 Bill은 편지에 적혀져 있는 아이들의 이름에 맞게 편지를 전달해주어야 하니,

Transport layer로 볼 수 있다.

  편지를 받지 못하면 나눠주지 못한다. 따라서 Transport layer이 제공할 수 있는 서비스는

Network layer의 서비스의 제약을 받는다.

예를 들어, Network layer에서 전송되는 Segments에 대한 delay guarantees나 bandwidth guarantees를

보장할 수 없다면 Transport layer 역시 이러한 서비스를 제공할 수 없다.

3.1.2 Internet transport-layer protocals

TCP/IP (TCP와 IP는 별개) 네트워크는 애플리케이션 계층에게 두가지 트랜스포트 계층 프로토콜을 제공한다.

• TCP(Transmission Control Protocol) : 신뢰적, 연결기향형 서비스, reliable, in-order delivery
• UDP(User Datagram Protocol) : 비신뢰적 비연결형 서비스, unreliable, unordered delivery

UDP의 한 예) IP

 IP : Internet Protocol의 약자. 호스트 간에 논리적 통신을 제공하는 '최선형' 전달 서비스(best-effort delivery Service).

즉, Segment 전달을 위해 최대한 노력하나 어떠한 보장도 하지 않는다는 것. Segment를 순서대로 전달하는 것도 보장하지 않는다. 또한, Segment 내부 데이터의 무결성(Integrity)을 보장하지 않음. 이처럼 IP는 unreliable service 이다.

애플리케이션 개발자는 소켓을 생성할 시, TCP와 UDP 중 하나를 선택해야 한다.

코로나19(COVID-19)로 인해, 학교에 가지 않고 재택 수업을 하게 되었다.

전공 수업을 따로 혼자서 공부해야 하는 상황이 되어서 공부했던 내용은 정리해서 블로그에 올릴 생각이다.

_끗