(8)

[네트워크] - 로드 밸런싱(Load Balancing)

Computer Science/네트워크 2020.09.25

로드 밸런싱(Load Balancing) 둘 이상의 CPU or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것 요즘 시대에는 웹 사이트에 접속하는 인원이 급격히 늘어나게 되었다. 따라서 이 사람들에 대해 모든 트래픽을 감당하기엔 1대의 서버로는 부족하다. 대응 방안으로 하드웨어의 성능을 올리거나(Scale-up) 여러대의 서버가 나눠서 일하도록 만드는 것(Scale-out)이 있다. 하드웨어 향상 비용이 더욱 비싸기도 하고, 여러대면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scalue-out이 효과적이다. 이때 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드 밸런싱이다. 로드 밸런싱은 분산식 웹 서비스로, 여러 서버에 부하(Load)를 나누어주는 역할을 한다. Load Bala..

[네트워크] - 대칭키 & 공개키

Computer Science/네트워크 2020.09.25

대칭키 & 공개키 [대칭키 암호화] 암호화에 사용되는 키와 복호화에 사용되는 키가 동일한 암호화 기법이다. 대칭키 암호 방식으로 암호화한 정보를 누군가에게 보낼 때, 암호키도 함께 보내야 한다. 암호키 자체는 암호화가 되지 않은 평문으로 분실하거나 타인에게 노출되면 보안에 매우 취약할 수 있다. 키 전달 및 관리에 어려움이 있지만, 대칭키 암호화 방식은 암호화 연산 속도가 빠르기 때문에 효율적인 암호 시스템을 구축할 수 있다는 장점이 있다 블록 암호화, 스트림 암호화가 있다. [공개키 암호화] 대칭키 암호화 방식의 키 전달의 취약점을 해결하기 위해 나온 방식이다. 암호화에 사용하는 키와 복호화에 사용하는 키를 분리했다. 따라서 비대칭키 암호화라고도 부른다. 자신기 가지고 있는 고유한 암호키(개인키 or ..

[네트워크] - Blocking I/O & Non-Blocking I/O

Computer Science/네트워크 2020.09.25

I/O 작업 I/O 작업은 Input/Output의 약자이다. 주로 파일 입출력을 다룰 때, 흔히 볼 수 있다. ex) 2대 이상의 컴퓨터끼리 서로 네트워크를 통해 통신을 한다고 가정할 때, 한 컴퓨터에서 출력(send)을 하고 다른 한 컴퓨터에서 입력(read)을 받는 과정을 통해 통신할 수 있다. I/O 작업은 User Level에서 직접 진행할 수 없고, 실제 I/O 작업을 수행하는 것은 Kernel Level에서만 가능하다. User Process, Thread는 커널에게 요청하고 작업 완료 후, 커널이 반환하는 결과를 기다릴 뿐이다. Blocking Model 가장 기본적인 I/O 모델로, 리눅스에서 모든 소켓 통신은 기본 blocking으로 동작한다. I/O 작업이 진행되는 동안 유저 프로세스..

[네트워크] - Cookie & Session

Computer Science/네트워크 2020.09.25

Cookie & Session HTTP는 비상태성(Stateless) 프로토콜로 상태 정보를 유지하지 않는다. 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 큰 장점이지만 통신할 때마다 매번 연결 설정을 해야 하며, 이전 요청과 현재 요청이 같은 사용자의 요청인지 알 수 없다는 단점이 존재한다. 쿠키와 세션을 통해서 HTTP의 Stateless한 문제점을 해결할 수 있다. 저장위치 쿠키: 클라이언트의 웹 브라우저가 지정하는 메모리 or 하드 디스크 세션: 서버의 메모리 만료 시점 쿠키: 저장할 때, expires 속성을 정의하여 무효화시키면 삭제될 날짜를 지정할 수 있다. 세션: 클라이언트가 로그아웃하거나 설정 시간 동안 반응이 없으면 무효화되기 때문에 정확한 시점을 알 수 없다. 리소스 쿠키..

[네트워크] - HTTP, HTTPS

Computer Science/네트워크 2020.09.25

HTTP (HyperText Transfer Protocol) 웹 서버와 클라이언트 간의 문서를 교환하기 위한 통신 규약 웹에서만 사용하는 프로토콜로 TCP/IP 기반으로 서버와 클라이언트 간의 요청과 응답을 전송한다. HTTP의 특징 TCP 기반의 통신 방식 비연결 지향 브라우저를 통해 사용자의 요청으로 서버와 접속하여 요청에 대한 응답의 데이터를 전송 후, 연결을 종료한다. 간단하기 때문에 자원이 적게드는 장점이 있다. 하지만, 연결이 지속적이지 않기 때문에 사용자와 연결 종료후 추가적인 요청시 어떤 사용자의 요청인지 모른다는 점이 존재한다. 즉, 여러 사용자가 요청할 시 각각의 사용자 요청을 구분할 수 없어서 제대로 된 응답 데이터를 전송할 수 없다는 단점이 있다. 해결 방법으로는 쿠키, 세션, 히..

[네트워크] - UDP

카테고리 없음 2020.09.24

UDP User Datagram Protocol의 약자이다 데이터를 데이터 그램 단위로 처리하는 프로토콜 (데이터 그램: 독립적인 관계를 지니는 패킷) 비연결형 프로토콜로 사전에 연결 설정 없이 데이터를 전달한다 사전에 연결 설정을 하지 않은 데이터 그램 방식을 통해 데이터를 전달하기 때문에 하나의 메시지에서 분할된 각각의 패킷은 서로 다른 경로로 전송될 수 있다 송신측에서 전송한 패킷의 순서와 수신측에 도착한 패킷의 순서가 다를 수 있다. 그러나 서로 다른 경로로 패킷을 처리함에도 불구하고 순서를 부여하거나 재조립하지 않는다 흐름 제어, 혼잡 제어, 오류 제어를 하지 않으므로 손상된 세그먼트에 대한 재전송을 하지 않는다 이로 인해 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만, 신뢰성 있는 데이터..

Computer Science/네트워크

[네트워크] - 로드 밸런싱(Load Balancing)

로ᄏｌ 2020. 9. 25. 08:40

728x90

로드 밸런싱(Load Balancing)

둘 이상의 CPU or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것

요즘 시대에는 웹 사이트에 접속하는 인원이 급격히 늘어나게 되었다.
따라서 이 사람들에 대해 모든 트래픽을 감당하기엔 1대의 서버로는 부족하다. 대응 방안으로 하드웨어의 성능을 올리거나(Scale-up) 여러대의 서버가 나눠서 일하도록 만드는 것(Scale-out)이 있다. 하드웨어 향상 비용이 더욱 비싸기도 하고, 여러대면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scalue-out이 효과적이다. 이때 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드 밸런싱이다.

로드 밸런싱은 분산식 웹 서비스로, 여러 서버에 부하(Load)를 나누어주는 역할을 한다. Load Balancer를 클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 여러 서버에 분산시켜주는 방식이다. 서비스를 운영하는 사이트의 규모에 따라 웹 서버를 추가로 증설하면서 로드 밸런서로 관리해주면 웹 서버의 부하를 해결할 수 있다.

로드 밸런서가 서버를 선택하는 방식

라운드 로빈(Round Robin): CPU 스케줄링의 라운드 로빈 방식 활용
Least Connections: 연결 개수가 가장 적은 서버 선택 (트래픽으로 인해 세션이 길어지는 경우 권장)
Source: 사용자 IP를 해싱하여 분배 (특정 사용자가 항상 같은 서버로 연결되는 것 보장)

로드 밸런서 장애 대비

서버를 분배하는 로드 밸런서에 문제가 생길 수 있기 때문에 로드 밸런서를 이중화하여 대비한다.

Active 상태와 Passive 상태

728x90

저작자표시 (새창열림)

'Computer Science > 네트워크' 카테고리의 다른 글

[네트워크] - 대칭키 & 공개키 (0)	2020.09.25
[네트워크] - Blocking I/O & Non-Blocking I/O (0)	2020.09.25
[네트워크] - Cookie & Session (0)	2020.09.25
[네트워크] - HTTP, HTTPS (0)	2020.09.25
[네트워크] - 주소창에 naver.com을 치면 일어나는 일 (0)	2020.09.24

Computer Science/네트워크

[네트워크] - 대칭키 & 공개키

로ᄏｌ 2020. 9. 25. 08:26

728x90

대칭키 & 공개키

[대칭키 암호화]

암호화에 사용되는 키와 복호화에 사용되는 키가 동일한 암호화 기법이다.
대칭키 암호 방식으로 암호화한 정보를 누군가에게 보낼 때, 암호키도 함께 보내야 한다. 암호키 자체는 암호화가 되지 않은 평문으로 분실하거나 타인에게 노출되면 보안에 매우 취약할 수 있다.
키 전달 및 관리에 어려움이 있지만, 대칭키 암호화 방식은 암호화 연산 속도가 빠르기 때문에 효율적인 암호 시스템을 구축할 수 있다는 장점이 있다
블록 암호화, 스트림 암호화가 있다.

[공개키 암호화]

대칭키 암호화 방식의 키 전달의 취약점을 해결하기 위해 나온 방식이다. 암호화에 사용하는 키와 복호화에 사용하는 키를 분리했다. 따라서 비대칭키 암호화라고도 부른다.
자신기 가지고 있는 고유한 암호키(개인키 or 비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에게 공개한다.
공개키 암호화 방식의 진행과정
- B 사용자는 자신의 공개키를 공개한다. 이 공개키는 암호화에 사용되는 키이며, 누구든지 열람이 가능하다. (복호화에 사용되는 키는 B 자신만 가지고 있다. 잃어버리면 안된다)
- A 사용자는 B 사용자의 공개키로 데이터를 암호화한다.
- 암호화된 문서를 B 사용자에게 전송한다.
- B 사용자는 자신만의 개인키(복호화키)를 이용하여 전송받은 암호화 문서를 복호화하여 데이터를 열람한다.
대칭키 암호화 방식의 키 전달 문제를 해결했지만 암호화, 복호화를 위해 복잡한 수학 연산을 수행하기 때문에 대칭키 방식에 비해 속도가 느리고 복잡하다는 단점이 있다.

공개키 기반 구조

특정 사람의 개인키와 공개키는 어떻게 생성할 것이며, 어떻게 배포할 것이고 어떻게 관리해야 하는가에 대한 이슈가 존재한다. 또한, 어떤 공개키가 특정한 사람의 공개키라는 것을 어떻게 보장할 수 있는지에 대한 이슈도 존재한다.

이를 해결하기 위해 디지털 인증서도 도입했고 이를 활용하는 소프트웨어, 하드웨어, 정책, 제도, 사용자 등을 총칭해서 공개키 기반 구조라고 한다.

대칭키와 공개키 암호화 방식을 적절히 혼합해보면?

SSL 탄생의 시초가 됨

1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화고 B에게 보냄
2. B는 암호문을 받고, 자신의 비밀키로 복호화함.
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄 
4. A는 자신의 대칭키로 암호문을 복호화함
5. 앞으로 이 대칭키로 암호화를 통신함

즉, 대칭키를 주고받을 때만 공개키로 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것!

728x90

저작자표시 (새창열림)

'Computer Science > 네트워크' 카테고리의 다른 글

[네트워크] - 로드 밸런싱(Load Balancing) (0)	2020.09.25
[네트워크] - Blocking I/O & Non-Blocking I/O (0)	2020.09.25
[네트워크] - Cookie & Session (0)	2020.09.25
[네트워크] - HTTP, HTTPS (0)	2020.09.25
[네트워크] - 주소창에 naver.com을 치면 일어나는 일 (0)	2020.09.24

Computer Science/네트워크

[네트워크] - Blocking I/O & Non-Blocking I/O

로ᄏｌ 2020. 9. 25. 07:55

728x90

I/O 작업

I/O 작업은 Input/Output의 약자이다.
주로 파일 입출력을 다룰 때, 흔히 볼 수 있다.
ex) 2대 이상의 컴퓨터끼리 서로 네트워크를 통해 통신을 한다고 가정할 때, 한 컴퓨터에서 출력(send)을 하고 다른 한 컴퓨터에서 입력(read)을 받는 과정을 통해 통신할 수 있다.
I/O 작업은 User Level에서 직접 진행할 수 없고, 실제 I/O 작업을 수행하는 것은 Kernel Level에서만 가능하다.
User Process, Thread는 커널에게 요청하고 작업 완료 후, 커널이 반환하는 결과를 기다릴 뿐이다.

Blocking Model

가장 기본적인 I/O 모델로, 리눅스에서 모든 소켓 통신은 기본 blocking으로 동작한다.
I/O 작업이 진행되는 동안 유저 프로세스는 자신의 작업을 중단한 채 대기하는 방식이다.

위의 그림처럼

유저는 커널에게 read 작업을 요청
데이터가 입력될 때까지 대기
데이터가 입력되면 유저 (커널 -> 유저)에게 결과가 전달되어야만 유저 자신의 작업에 비로소 복귀할 수 있다.
* 말 그대로 block이 되고, 어플리케이션에서 다른 작업을 수행하지 못하고 대기하게 되므로 자원이 낭비된다.

Non-Blocking Model

위와 같은 blocking 방식의 비효율성을 극복하고자 도입된 방식이다.
I/O 작업이 진행되는 동안 유저 프로세스의 작업을 중단시키지 않는 방식이다.

How to

유저가 커널에게 read 작업을 요청
데이터가 입력되었든 입력되지 않았든 요청하는 그 순간, 바로 결과가 반환된다.
* 이때, 입력 데이터가 없으면 입력 데이터가 없다는 결과 메시지를 반환한다.
입력 데이터가 있을 때까지 1 ~ 2번을 반복. (2번에서 결과 메시지를 받은 유저는 다른 작업 진행이 가능하다.)
입력 데이터가 있으면 유저(커널 -> 유저)에게 결과가 전달된다.
1. 이 경우 I/O의 진행시간과 관계가 없기 때문에(대기X) 어플리케이션에서 작업을 오랜 시간 중지하지 않고도 I/O 작업을 진행할 수 있다.
2. 그러나 반복적으로 시스템 호출이 발생하기 때문에 이 경우 역시 자원이 낭비된다.

728x90

저작자표시 (새창열림)

'Computer Science > 네트워크' 카테고리의 다른 글

[네트워크] - 로드 밸런싱(Load Balancing) (0)	2020.09.25
[네트워크] - 대칭키 & 공개키 (0)	2020.09.25
[네트워크] - Cookie & Session (0)	2020.09.25
[네트워크] - HTTP, HTTPS (0)	2020.09.25
[네트워크] - 주소창에 naver.com을 치면 일어나는 일 (0)	2020.09.24

Computer Science/네트워크

[네트워크] - Cookie & Session

로ᄏｌ 2020. 9. 25. 07:16

728x90

Cookie & Session

HTTP는 비상태성(Stateless) 프로토콜로 상태 정보를 유지하지 않는다. 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 큰 장점이지만 통신할 때마다 매번 연결 설정을 해야 하며, 이전 요청과 현재 요청이 같은 사용자의 요청인지 알 수 없다는 단점이 존재한다.

쿠키와 세션을 통해서 HTTP의 Stateless한 문제점을 해결할 수 있다.

저장위치

쿠키: 클라이언트의 웹 브라우저가 지정하는 메모리 or 하드 디스크
세션: 서버의 메모리

만료 시점

쿠키: 저장할 때, expires 속성을 정의하여 무효화시키면 삭제될 날짜를 지정할 수 있다.
세션: 클라이언트가 로그아웃하거나 설정 시간 동안 반응이 없으면 무효화되기 때문에 정확한 시점을 알 수 없다.

리소스

쿠키: 클라이언트에 저장되고 클라이언트의 메모리를 사용하기 때문에 서버 자원을 사용하지 않는다.
세션: 서버에 저장되고, 서버 메모리로 로딩되기 때문에 세션이 생길 때마다 리소스를 차지한다.

용량 제한

쿠키: 클라이언트도 모르게 접속되는 사이트에 의하여 설정될 수 있기 때문에 쿠키로 인해 문제가 발생하는 걸 막고자 한 도메인당 20개, 하나의 쿠키당 4KB로 제한해두었다.
세션: 클라이언트가 접속하면 서버에 의해 생성되므로 개수나 용량 제한이 없다.

보안

쿠키: 클라이언트에 저장하기 때문에 보안에 취약하다.
세션: 서버에 저장하기 때문에 쿠키에 비해서는 보안에 우수하다.

참조: github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/Cookie_Session.md

WooVictory/Ready-For-Tech-Interview

💻 신입 개발자로서 준비를 하기 위해 지식을 정리하는 공간 👨‍💻. Contribute to WooVictory/Ready-For-Tech-Interview development by creating an account on GitHub.

github.com

728x90

저작자표시 (새창열림)

'Computer Science > 네트워크' 카테고리의 다른 글

[네트워크] - 대칭키 & 공개키 (0)	2020.09.25
[네트워크] - Blocking I/O & Non-Blocking I/O (0)	2020.09.25
[네트워크] - HTTP, HTTPS (0)	2020.09.25
[네트워크] - 주소창에 naver.com을 치면 일어나는 일 (0)	2020.09.24
[네트워크] - TCP (3 way handshake & 4 way handshake) (0)	2020.09.24

Computer Science/네트워크

[네트워크] - HTTP, HTTPS

로ᄏｌ 2020. 9. 25. 07:06

728x90

HTTP (HyperText Transfer Protocol)

웹 서버와 클라이언트 간의 문서를 교환하기 위한 통신 규약
웹에서만 사용하는 프로토콜로 TCP/IP 기반으로 서버와 클라이언트 간의 요청과 응답을 전송한다.

HTTP의 특징

TCP 기반의 통신 방식
비연결 지향
- 브라우저를 통해 사용자의 요청으로 서버와 접속하여 요청에 대한 응답의 데이터를 전송 후, 연결을 종료한다.
- 간단하기 때문에 자원이 적게드는 장점이 있다.
- 하지만, 연결이 지속적이지 않기 때문에 사용자와 연결 종료후 추가적인 요청시 어떤 사용자의 요청인지 모른다는 점이 존재한다.
- 즉, 여러 사용자가 요청할 시 각각의 사용자 요청을 구분할 수 없어서 제대로 된 응답 데이터를 전송할 수 없다는 단점이 있다.
- 해결 방법으로는 쿠키, 세션, 히든 폼 필드 등이 있다.
단방향성
- 사용자의 요청 한개에 대한 한 개의 응답을 하는 방식이기 때문에 서버가 먼저 응답하지 않는다.

HTTP의 문제점

HTTP는 평문 통신이기 때문에 도청이 가능하다.
통신 상대를 확인하지 않기 때문에 위장이 가능하다.
완전성을 증명할 수 없기 때문에 변조가 가능하다.

이러한 문제점을 해결하기 위해 HTTPS가 등장했다.

HTTPS

HTTP 통신하는 소켓 부분을 인터넷 상에서 정보를 암호화하는 SSL(Security Socket Layer)라는 프로토콜로 대체한 것이다.
HTTP는 TCP와 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
즉, 하나의 레이어를 더 둔 것이다.
HTTP의 SSL에서는 대칭키 암호화 방식과 공개키 암호화 방식을 모두 사용한다.

SSL

SSL 프로토콜은 Netscape 사에서 웹 서버와 웹 브라우저 사이의 보완을 위해 만들어졌다. CA(Certification Authority)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다.

애플리케이션 서버를 운영하는 기업은 CA를 통해 인증서를 만든다.

애플리케이션 서버를 운영하는 기업은 HTTPS 적용을 위해 공개키와 개인키를 만든다.
신뢰할 수 있는 CA 기업을 선택하고 인증서 생성을 요청한다.
CA는 서버의 공개키, 암호화 방법 등의 정보를 담은 인증서를 만들고 해당 CA의 개인키로 암호화하여 서버에 제공한다.
클라이언트가 SSL로 암호화된 페이지(https://)를 요청시 서버는 인증서를 전송한다.

클라이언트와 서버의 통신 흐름 과정

클라이언트가 SSL로 암호화된 페이지를 요청한다.
서버는 클라이언트에게 인증서를 전송한다.
클라이언트는 인증서가 신용이 있는 CA로부터 서명된 것인지 판단한다. 브라우저는 CA 리스트와 해당 CA의 공개키를 가지고 있다. 공개키를 활용하여 인증서가 복호화가 가능하다면 접속한 사이트가 CA에 의해 검토되었다는 것을 의미한다. 따라서 서버가 신용이 있다고 판단한다. 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것으로 이러한 것을 전자 서명이라고 한다.
클라이언트는 CA의 공개키를 이용해 인증서를 복호화하고, 서버의 공개키를 획득한다.
클라이언트는 서버의 공개키를 사용해 랜덤 대칭 암호화키, 데이터 등을 암호화하여 서버로 전송한다.
서버는 자신의 개인키를 이용해 복호화하고 랜덤 대칭 암호화키, 데이터 등을 획득한다.
서버는 랜덤 대칭 암호화키로 클라이언트 요청에 대한 응답을 암호화하여 전송한다.
클라이언트는 랜덤 대칭 암호화키를 이용해 복호화하고 데이터를 이용한다.

인증서에 포함된 내용

서버측 공개키 (public key)
공개키 암호화 방법
인증서를 사용한 웹서버의 URL
인증서를 발행한 기관 이름

모든 웹페이지에서 HTTPS를 사용하지 않는다. 이유는 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 많이 필요로 하기 때문이다. 통신할 때마다 암호화를 하면 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 Request 수가 줄어들게 된다.

따라서 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용해야 한다. 또한, HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서를 발급한 경우 etc..) 이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.

728x90

저작자표시 (새창열림)

'Computer Science > 네트워크' 카테고리의 다른 글

[네트워크] - Blocking I/O & Non-Blocking I/O (0)	2020.09.25
[네트워크] - Cookie & Session (0)	2020.09.25
[네트워크] - 주소창에 naver.com을 치면 일어나는 일 (0)	2020.09.24
[네트워크] - TCP (3 way handshake & 4 way handshake) (0)	2020.09.24
[네트워크] - TCP (흐름제어/혼잡제어) (0)	2020.09.24

카테고리 없음

[네트워크] - UDP

로ᄏｌ 2020. 9. 24. 13:26

728x90

UDP

User Datagram Protocol의 약자이다
데이터를 데이터 그램 단위로 처리하는 프로토콜
(데이터 그램: 독립적인 관계를 지니는 패킷)
비연결형 프로토콜로 사전에 연결 설정 없이 데이터를 전달한다
사전에 연결 설정을 하지 않은 데이터 그램 방식을 통해 데이터를 전달하기 때문에 하나의 메시지에서 분할된 각각의 패킷은 서로 다른 경로로 전송될 수 있다
송신측에서 전송한 패킷의 순서와 수신측에 도착한 패킷의 순서가 다를 수 있다. 그러나 서로 다른 경로로 패킷을 처리함에도 불구하고 순서를 부여하거나 재조립하지 않는다
흐름 제어, 혼잡 제어, 오류 제어를 하지 않으므로 손상된 세그먼트에 대한 재전송을 하지 않는다
이로 인해 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만, 신뢰성 있는 데이터 전송을 보장하지 못한다
UDP는 RTP(Real Time Protocol), Multicast, DNS 등에서 사용된다

DNS 같은 경우 누군가 DNS 서비스를 요청할 때마다 TCP처럼 Session을 맺고 통신한다면 속도도 느리고, 서버 리소스도 엄청나게 소모될 것이다.

그런가하면 NMS(Network Management Server)가 5분에 한번씩 장비 상태를 점검하기 위해 정보를 읽어오는데 수백, 수천대의 장비와 Session을 맺어야 한다면 이것도 마찬가지로 문제가 생긴다. 그렇기 때문에 UDP를 사용한다.

재전송을 하면 안되는 서비스가 있다. 대표적으로 RTP이다. 또한, Multicast 서비스가 UDP를 사용한다. 1:N으로 통신하는 방식에서 한 사람이 데이터를 받지 못했다고 재전송을 요청한다고 가정해보자. 제대로 받은 사람들도 해당 데이터를 다시 받아서 처리해야 한다는 문제점이 발생할 수 있기 떄문에 UDP를 사용한다.

728x90

저작자표시 (새창열림)

이전 1 2 다음

(8)

[네트워크] - 로드 밸런싱(Load Balancing)

로드 밸런싱(Load Balancing)

로드 밸런서가 서버를 선택하는 방식

로드 밸런서 장애 대비

'Computer Science > 네트워크' 카테고리의 다른 글

관련 글

[네트워크] - 대칭키 & 공개키

대칭키 & 공개키

[대칭키 암호화]

[공개키 암호화]

대칭키와 공개키 암호화 방식을 적절히 혼합해보면?

'Computer Science > 네트워크' 카테고리의 다른 글

관련 글

[네트워크] - Blocking I/O & Non-Blocking I/O

I/O 작업

Blocking Model

Non-Blocking Model

'Computer Science > 네트워크' 카테고리의 다른 글

관련 글

[네트워크] - Cookie & Session

Cookie & Session

'Computer Science > 네트워크' 카테고리의 다른 글

관련 글

[네트워크] - HTTP, HTTPS

HTTP (HyperText Transfer Protocol)

HTTP의 특징

HTTP의 문제점

HTTPS

SSL

'Computer Science > 네트워크' 카테고리의 다른 글

관련 글

[네트워크] - UDP

UDP

티스토리툴바