강의 : http://www.kocw.net/home/cview.do?mty=p&kemId=1169634

네트워크 구조

네트워크 구조를 살펴보면

네트워크 엣지 에는 우리가 사용하는 컴퓨터 , 전화기 , 웹앱 등 말단에서 사용자가 이용하는 서비스가 존재

네트워크 코어 에는 라우터 들이 존재한다.

라우터 : 컴퓨터 네트워크에서 데이터 패킷을 전달하는 기기로, 다양한 네트워크 간의 통신을 관리하고 연결하는 역할
예를 들어 홈 라우터 는 집에서 사용하는 인터넷 서비스 제곱 업체에서 제공하는 모뎀과 연결된 공유기라고 생각 할 수 있다. 홈 라우터를 통해 랜선으로 인터넷을 연결하거나, 와이파이를 이용 할 수 있다.

이 때 네트워크 엣지 와 네트워크 코어 를 연결하는 링크 가 존재하며 링크 는 네트워크 코어와 코어를 연결하기도 한다.

예를 들어 우리의 컴퓨터는 랜선 이라는 링크를 이용하여 네트워크 통신망에 연결되어 있다.

네트워크 엣지

• 네트워크 엣지에 존재하는 컴퓨터 (클라이언트) : 내가 원할 때 링크 에 연결해서 서버로부터 정보를 가져오는 요소
• 서버 : 상시 (24시간) 연결되어 있어서 클라이언트로부터 언제 들어올지 모르는 요청을 기다리는 컴퓨터

데이터 통신 서비스의 종류

Connection oriented service

TCP : Connection oriented service 를 제공하는 통신 방법

다음 3가지를 사용자에게 제공한다.

• 신뢰 할 수 있는 데이터를 (보내려는 문자 그대로, 순서를 보존하며) 보내준다.
• flow control : sender 가 reciver 한테 데이터를 보낼 때 보내는 동안의 속도 를 알맞게 조정해준다.
  - 알맞게 ? : reciver 가 받을 수 있는 속도에 맞춰서 제공한다.
• congestion control : 둘 사이의 네트워크 환경에 맞춰서 받을 수 있는 능력치에 맞게 데이터를 전송한다.

예를 들어 슈퍼컴퓨터인 A 가 똥컴인 B 에게 데이터를 보낼 때
똥컴 B에 사양에 맞춰서 데이터를 전송하는 flow control
똥컴 B가 슈퍼컴퓨터로 업그레이드 하여서 flow control 은 올라가도 둘 사이를 연결하는 랜선이 좋지 않거나 네트워크 환경이 좋지 않다면
네트워크 환경에 맞춰서 전송하는 congestion control

UDP : User datagram protocol

아 몰랑 난 보내버릴거야 ~~!! 그냥 들이부어 ~~!~!!!

• connectionless
• unreilabel data transfer
• no flow control
• no congestion control

UDP 는 데이터를 신뢰성 있게 전송하지 않고 연결 설정이나 흐름 제어를 수행하지 않는 비 연결형 프로토콜이다.

그런 이유로 UDP 는 데이터의 손실 또는 순서 변경에 대한 보장이 없지만

데이터 전송 속도가 높고 상대적으로 더 낮은 대역폭을 사용한다.

몇 개 유실되도 상관 없는 경우 (실시간 음성, 비디오)에는 UDP 를 쓴다. (조금의 유실이 있어도 사람은 인식하지 못하니까)
UDP 는 주로 실시간 응용 프로그램에서 사용되며 스트리밍 혹은 게임과 같은 응용 분야에 널리 사용된다.

packet : 편지 봉투라는 개념으로 생각해보자

packet 에 편지 봉투에 내용을 담아서 우체통에 담아서 보내면 UDP (도착 하지 않을 수 있다는 보장이 있다.)

근데 만약 우체통이 아니라 중요한 내용이 담겨 있을 때 등기를 보내든지, 정말 믿을 수 있는 서비스를 이용 할 것이다.

등기는 우체통에 비해서 어떤데 ? 비용이 든다 , 컴퓨터 입장에서의 비용은 컴퓨터 자원 을 의미한다.

프로토콜

TCP , UDP 모두 프로토콜로 끝나는데 프로토콜이 뭐지 ?

사람과 사람이 전화 할 때 안부를 묻고, 소소한 이야기를 나누고, 목적을 말 하듯이

클라이언트와 서버 에게 어떤 데이터를 보내거나 요청하기까지의 일련된 과정을 의미한다.

네트워크 코어

네트워크 코어에는 라우터 들이 연결되어 있으며 라우터 들이 얽히고 섥힌 집합

라우터는 어떤 방식으로 데이터를 전달하는데 ?

1. circuit switching

출발지로부터 목적지까지 가는 길을 미리 예약을 해놓고 특정 사용자만을 위해서 그 길을 사용 (예전의 유선 전화가 circuit switching 에 해당)

2. packet-switching
   

들어온 packet 순에 따라서 순차적으로 전송 (미리 예약한 circuit 이 존재하지 않음)

장단점

1MB/s link : 초당 1MB 를 전달할 수 있는 link

해당 link 를 가지고 N 명의 클라이언트들이 100kb/s 의 속도로 데이터를 전송한다고 해보자

circuit switching

circuit switching 을 사용하게 되면 10명의 유저들의 데이터만 전송 할 수 있다.
(이미 circuit 이 1MB/S 니까)

packet switching

packet switching 은 용량과 상관 없이 몇 명의 유저가 데이터를 보내든 제약 없이 전송 할 수 있다.

하지만 10명 이상 모이게 되면 문제가 생길 수 있지 않을까 ?
웹 같은 경우는 어떤 데이터를 지속적으로 전송하는게 아니라 한 번 데이터를 전송하고
본인 패턴에 맞춰서 좀 기다렸다가 데이터를 요청하거나 전송하게 될 것이다.
그러니 하나 ! 둘 ! 셋 ! 하고 데이터를 요청하거나 보내는 것이 아닌 이상 괜찮다.

확률적으로 35명의 유저가 존재 할 때 10명 이상의 유저가 서버에 동시에 접속 할 확률이 0.004 밖에 되지 않는다.

packet switching 을 써서 어쩔 수 없이 생기는 문제들

데이터가 들어오면 무조건적으로 발생하는 프로세싱이 존재한다.

• 데이터를 신뢰 할 수 있도록 확인
• 보내고자 하는 위치 확인

이 때 나가는 속도보다 들어오는 속도가 빠를 경우 데이터를 차곡 차곡 담아둘 buffer 혹은 queue 공간이 존재한다.

정리하면
라우터에 패킷이 들어오면 패킷을 확인하고 아웃고잉 링크에 데이터를 보내는데
나가는 속도보다 들어오는 속도가 빠르면 큐 안에 데이터들이 차곡 차곡 쌓이고
들어온 순대로 아웃고잉 링크로 들어가게 된다.

이 때 큐 안에서 기다리는 시간을 큐잉 딜레이 라고 한다.

큐에서의 기다림이 끝나고 아웃 고잉 링크로 가는 동안 데이터의 첫 비트가 출발해서 마지막 비트까지 출발하는 시간까지의 딜레이가 존재한다.

이 때 link 의 bandwidth 가 크고 packet 의 length 가 작을 수록 딜레이가 적기 때문에

transmission delay : packet length (bits) / link bandwidth (bps) 라고 한다.

이후 라우터에서 다른 라우터로 보내는 동안의 딜레이도 존재하는데

이는 라우터 간의 연결된 만큼의 길이를 빛의 속도로 나눈 만큼의 딜레이가 존재한다.

비트가 이동하는 속도는 빛의 속도와 같다

그러니 라우터간 연결된 만큼의 길이만큼의 딜레이가 존재한다.

그러니 packet switching 의 4가지 딜레이는

1. processing delay : 라우터에 데이터가 들어왔을 때 데이터 확인 및 아웃고잉 링크 확인하는 동안의 딜레이
2. queueing delay : 라우터에서 아웃 고잉 링크로 가기 전 큐에서 기다리는 동안의 딜레이
3. Transmission delay : 라우터에서 라우터로 출발 시키는 동안의 딜레이 (전송하고자 하는 데이터의 크기와 링크의 너비와 관련)
4. Propagation delay : 라우터에서 라우터로 가는 동안의 딜레이

가 존재한다.

delay 를 어떻게 줄일 수 있을까 ?

1. processing delay

• 라우터 성능 개선

2. queueing delay

• 클라이언트가 기여하는 영역이기에 어떻게 할 수 없음

  예를 들어 사용자가 많을 때에는 큐잉 딜레이가 많을 수 밖에 없고 사용자가 적을 땐 큐잉 딜레이가 적을 수 밖에 없다.

• 하지만 큐의 크기는 유한적인데 들어오는 양이 큐의 크기보다 많을 경우를 해결 하기 위해 노력 할 수 있다.
  - 자리가 날 때 까지 몇 개의 데이터를 받지 못하고 버려야됨
  • 사용자가 늘어나면 packet loss 가 발생하게 되고 대부분의 packet loss 는 큐잉 딜레이에 의해서 발생한다.

    TCP 쓰면 유실 없이 잘 보내준다매

    유실 없게 보내기 위해선 결국 유실 된 패킷에 대해서 재전송 해야 할 것이다.
    TCP 는 라우터 간 이동하다가 패킷 로스가 일어난 경우 가장 맨 처음 데이터를 보낸 영역에서 유실 된 패킷에 대해서 재전송을 한다.
    라우터간 연결 되있는 애들은 유실 되든 말든 신경 안써버려 (할 일이 많아)
    유실 되든 말든 신경 안쓰는 애들은 dumb core 라고 한다.

3. transmission delay

• link 의 bandwidth 를 늘려버려 (케이블을 늘리든 뭐하든)

4. propagation delay

• 얘는 신의 영역이래 빛의 속도인데 더 어캐 줄여