[NetWork] 네트워크 정리 (3)

 
트렌스포트 레이어 정리 
 
전송 계층 서비스 뒤에 있는 원리를 이해하기.
• 다중화, 역다중화 ( multiplexing, demultiplexing)
• 신뢰성 있는 데이터 전송
• 흐름 제어
• 혼잡 제어

인터넷 전송 계층 프로토콜에 대해 배운다.
• UDP: 연결 없는 전송
• TCP: 연결 지향 신뢰성 있는 전송
• TCP 혼잡 제어
 

Transport services and protocols

서로 다른 호스트에서 실행되는 어플리케이션 프로세스 간의 논리적인 통신을 제공한다. 
 
전송 프로토콜은 끝 시스템에서 다음과 같은 작업을 수행한다:
• 송신자: 어플리케이션 프로그램에서 메시지를 보내면 이 메세지를 세그먼트로 나누고  가 다음 네트워크 계층에 전달한다.
• 수신자: 세그먼트를 메시지로 재조립하고 어플리케이션 계층에 전달한다.

 두 가지 전송 프로토콜 사용 가능
▪ TCP, UDP
 

Transport vs. network layer services and protocols

os 안에 커널 안에 network stack이 있다. (tcp/udp 함수 호출, ip 함수 호출, mac 함수 호출)
 
호스트에는 NIC이 있다. 호스트에 부착되고 운영체제의 영향을 받지 않는다.
NIC은 운영체제에 인터럽트를 걸어서 패킷 도착을 알린다. 
NIC안에는 패킷을 처리하는 전용 칩이 있다. 
 
가운데 있는 트랜스포트 레이어 프로토콜이나 네트워크 레이어 프로토콜은 운영 체제가 제어를 하는 거고 리눅스 커널 안에 다 구현이 되어있다.
 
링크 레이어의 맥 부분은 이제 운영 체제 네트워크 스택에도 포함이 되어 있지만   
네트워크 인터페이스 카드 하드웨어의 이제 나머지 부분들이 다 구현이 되어있다.
 
최종적으로 받아서 패킷 넘겨주고  운영 체제한테 인터럭트를 보낸다는 것 (패킷 도착했습니다라고 푸시 알림 보내는 거라고 생각하면 된다) 운영체제가 그걸 받아서 역순으로 처리하여  애플리케이션 레이어에 올려준다.
 
 

▪ 네트워크 계층: 호스트 간의 논리적인 통신
▪ 전송 계층: 프로세스 간의 논리적 통신
      네트워크 계층 서비스를 기반으로 하며 개선한다. 
 

가정 비유:
Ann의 집에 있는 12명의 아이가 Bill의 집에 있는 12명의 아이에게 편지를 보내는 경우:
▪ 호스트 = 집
▪ 프로세스 = 아이
▪ 응용 프로그램 메시지 = 봉투 안의 편지
 
 

Transport Layer Actions

 
발신자(Sender)는 다음과 같은 작업을 수행한다
 
▪ 응용 계층 메시지를 전달받는다
▪ 세그먼트 헤더 필드의 값을 결정한다. layer에 내려갈 수록 헤더를 붙인다(캡슐화)
▪ 세그먼트를 생성한다.
▪ 세그먼트를 네트워크(IP) 계층에 전달한다.

 
 
수신자(Receiver)는 다음과 같은 작업을 수행한다.
▪ 응용 계층 메시지를 추출한다.
▪ 헤더 값들을 확인한다. layer에 올라갈 수록 헤더를 제거한다
▪ IP에서 세그먼트를 수신한다.
▪ 소켓을 통해 메시지를 응용 프로그램까지 역다중화하여 전달한다.

Two principal Internet transport protocols

TCP: 전송 제어 프로토콜 (Transmission Control Protocol)
• 연결 설정
• 신뢰성 있는 순서대로 전달
• 혼잡 제어
• 흐름 제어

UDP: 사용자 데이터그램 프로토콜 (User Datagram Protocol)
• 신뢰성 없는, 순서가 뒤죽박죽인 전달
 
사용할 수 없는 서비스:
• 지연 보장
• 대역폭 보장
 
TCP는 신뢰성 있지만 delay 와 bandwidth는 보장하지 않는다
-> 패킷 스위칭 방식을 사용하기 때문에 보장하지 않는다! 
 

Multiplexing and demultiplexing

다중화 (발신자 측):
데이터를 전송해야 할 때, 발신자 측에서는 여러 소켓에서 오는 데이터를 처리해야 할 수 있다..
이 데이터를 한 개의 네트워크 연결 또는 링크를 통해 전송하기 위해, 각 데이터 패킷에 전송 헤더를 추가한다.
전송 헤더에는 데이터를 수신 측에서 어떻게 처리해야 하는지에 대한 정보가 들어 있다.
 
역다중화 (수신자 측):
수신자 측에서는 전송 헤더를 사용하여 각 데이터 패킷을 해당 소켓으로 분리하고 전달하는 과정, 즉 다중화 해제를 수행한다. 각 데이터 패킷의 전송 헤더를 확인하여 데이터를 올바른 수신 소켓으로 라우팅한다. 
 

How demultiplexing works

soucre port #와 dest port #은 trans header

호스트는 IP 데이터그램을 수신한다.

• 각 데이터그램에는 출발지 IP 주소와 목적지 IP 주소가 포함되어 있다.
• 각 데이터그램은 하나의 전송 계층 세그먼트를 운반하며, 각 세그먼트에는 출발지와 목적지 포트 번호가 있다.
• 호스트는 IP 주소와 포트 번호를 사용하여 세그먼트를 적절한 소켓으로 전달한다.

 

Connectionless demultiplexing

 
소켓을 생성할 때는 호스트 로컬 포트 번호를 지정해야 한다.
예를 들어, DatagramSocket을 생성할 때 다음과 같이 호스트 로컬 포트 번호를 지정한다:
DatagramSocket mySocket1 = new DatagramSocket(12534);.

UDP 소켓으로 전송할 데이터그램을 생성할 때는 반드시 다음 정보를 지정해야한다:

• 목적지 IP 주소
• 목적지 포트 번호

UDP 데이터그램을 수신하는 호스트가 다음과 같은 단계를 따른다
 

• 수신 호스트는 UDP 세그먼트의 목적지 포트 번호를 확인한다.
• 해당 목적지 포트 번호를 갖는 소켓으로 UDP 세그먼트를 보낸다.

 
 
수신 호스트에서는 목적지 포트 번호를 기반으로 UDP 세그먼트를 해당 포트 번호를 갖는 소켓으로 전달한다.
또한, 동일한 목적지 포트 번호를 가지고 있지만 다른 출발지 IP 주소 및/또는 출발지 포트 번호를 가진 IP/UDP 데이터그램은 수신 호스트에서 동일한 소켓으로 전달된다. -> 받는 쪽의 포트번호가 중요하다.
 
 

클라이언트에선 포트 바인딩을 해도 되고 안해도 된다. 하지만 일반적으로 안하는 편이다
sendto함수를 호출할 때 os가 포트번호를 랜덤으로 할당해주기 때문이다. -> 개발의 편리를 위해 
 
 

Connection-oriented demultiplexing

TCP가 사용하는 방법이다. 
 
 
TCP 소켓은 4-튜플을 사용하여 식별됩니다. 이 4-튜플은 다음과 같은 정보로 구성된다
 

• 출발지 IP 주소 (source IP address)
• 출발지 포트 번호 (source port number)
• 목적지 IP 주소 (destination IP address)
• 목적지 포트 번호 (destination port number)

 
Demux (다중화 해제): 수신자가 모든 네 가지 값(4-튜플)을 사용하여 세그먼트를 적절한 소켓으로 라우팅하는 것이다.
 
서버는 동시에 여러 TCP 소켓을 지원할 수 있다. 각 소켓은 고유한 4-튜플로 식별되며, 각 소켓은 서로 다른 연결을 설정하는 클라이언트와 관련된다.
 

다중화와 다중화 해제는 세그먼트 및 데이터그램 헤더 필드 값에 기반하다.
 
 
<정리 >

UDP: 목적지 포트 번호를 사용하여 다중화 해제된다.
TCP: 4-튜플을 사용하여 다중화 해제된다. 4-튜플은 출발지 및 목적지 IP 주소 및 포트 번호를 포함한다.
다중화 및 다중화 해제는 모든 계층에서 발생한다.
 

UDP: User Datagram Protocol

 
최소한의 기능을 제공하는 "미니멀"한 인터넷 전송 프로토콜
 
최선의 노력 서비스, UDP 세그먼트는 다음과 같은 상황이 발생할 수 있다.

• 손실될 수 있음
• 애플리케이션으로 순서가 뒤바뀌어 전달될 수 있음

 
연결 없음:

• UDP 송신자와 수신자 간에 핸드셰이킹(연결 설정)이 없다.
• 각 UDP 세그먼트는 다른 세그먼트와 독립적으로 처리된다.

.
 

연결 설정 없음: UDP는 연결 설정 절차를 거치지 않으므로 RTT(라운드 트립 타임) 딜레이가 추가되지 않는다.
간단한 프로토콜: 송신자와 수신자 간에 연결 상태를 유지하지 않으므로 간단하다.
작은 헤더 크기: UDP 헤더 크기가 작아서 오버헤드가 작다.
혼잡 제어 없음: UDP는 혼잡 제어 기능을 제공하지 않으므로 데이터를 빠르게 전송할 수 있다.
원하는 속도로 데이터를 보낼 수 있음: UDP는 원하는 속도로 데이터를 전송할 수 있으므로 데이터 폭발적으로 전송할 수 있다.
혼잡 상황에서도 동작 가능: UDP는 혼잡 상황에서도 동작할 수 있다.

 
 
 

UDP(User Datagram Protocol)의 사용 사례는 다음과 같다:
 

• 스트리밍 멀티미디어 응용 프로그램 (손실을 허용하며 전송 속도에 민감)
• DNS(Domain Name System)
• SNMP(Simple Network Management Protocol)
• HTTP/3

 

만약 UDP 상에서 신뢰성 있는 전송이 필요한 경우 (예: HTTP/3)

• 신뢰성을 필요로 하는 부분은 응용 프로그램 계층에서 처리하며, 혼잡 제어도 응용 프로그램 계층에서 추가할 수 있습니다.
• UDP 자체는 데이터를 빠르게 전송하는 데 중점을 두고 있으며, 데이터 무결성 및 순서 보장은 응용 프로그램에서 처리해야 합니다

UDP: Transport Layer Actions

UDP 송신자의 동작은 다음과 같습니다:
 

• 응용 계층 메시지를 받는다.
• UDP 세그먼트의 헤더 필드 값을 결정한다.
• UDP 세그먼트를 생성한다.
• 세그먼트를 IP 계층으로 전달한다.

UDP 수신자의 동작은 다음과 같습니다:
 

• 응용 계층 메시지를 추출한다.
• UDP 세그먼트의 체크섬 헤더 값을 확인한다.
• IP로부터 세그먼트를 수신한다.
• 소켓을 통해 응용 프로그램으로 메시지를 다중화(demultiplexes)한다.

 
 

UDP segment header

UDP checksum

UDP의 목표 중 하나는 전송된 세그먼트에서 오류 (예: 비트가 뒤집힌 경우)를 감지하는 것
 

 
발신자는 다음과 같은 단계를 수행한다:

• UDP 세그먼트의 내용을 (UDP 헤더 필드 및 IP 주소를 포함한) 16비트 정수의 연속으로 처리한다.
• 체크섬: 세그먼트 내용의 덧셈 (원 보수 합)을 계산한다.
• 계산된 체크섬 값은 UDP 체크섬 필드에 저장된다.
  
  
  

수신자는 다음과 같은 단계를 수행한다. 

• 받은 세그먼트의 내용으로부터 체크섬을 계산합니다.

 

계산된 체크섬 값과 세그먼트의 체크섬 필드 값이 동일한지 확인한다.
만약 계산된 체크섬 값이 세그먼트의 체크섬 필드 값과 동일하다면, 오류가 감지되지 않았으며 데이터의 무결성이 확인된다. 그러나 만약 두 값이 다르다면, 오류가 감지되었음을 나타내며 데이터에 문제가 있을 수 있다.

 

Summary: UDP

 
UDP는 "간소한" 프로토콜로, 세그먼트가 손실되거나 순서대로 전달되지 않을 수 있다. 이는 "최선을 다하고 기대하는" 서비스를 의미합니다. UDP에는 다음과 같은 장점이 있다:
 
 

• 설정/핸드셰이킹이 필요하지 않으므로 라운드 트립 타임(RTT)이 발생하지 않는다.
• 네트워크 서비스가 손상된 경우에도 작동할 수 있다.
• 신뢰성을 향상시키는데 도움을 주는 체크섬 기능이 있다.

 

Principles of reliable data transfer

신뢰성 있는 데이터 전송 프로토콜의 복잡성은 불안정한 채널의 특성에 강하게 의존합니다 (데이터 유실, 손상, 재배열 등).

발신자와 수신자는 서로의 상태를 모르며 메세지를 통해 전달되지 않는 한 통신되지 않는다
sender는 메세지를 보냄
receiver는 메세지가 도착해야 보낸 상태를 안다 
 
발신자와 수신자는 서로의 "상태"를 알지 못한다. 예를 들어, 메시지가 수신되었는지에 대한 정보는 메시지를 통해 통신하지 않는 이상 알 수 없다.

Reliable data transfer protocol (rdt): interfaces

신뢰할 수 없는 채널을 통한 양방향 통신

 
 
rdt_send() : 어플리케이션에 의해 호출됨 수신자 상위 계층에 전달할 데이터 소캣을 전달 
udt_send(): rdt에 의해서 호출된다. 수신자에게 데이터 패킷을 신뢰할 수 없는 채널을 통해 전송하기 위해 호출됨 
rdt_rcv(): 패킷이 수신자 측 채널에 도착했을 대 호출된다
deliver_data(): rdt에 의해서 호출되어 상위 계층에 데이터를 전달하는데 사용된다. 
 
 

Reliable data transfer: getting started

 
신뢰성 있는 데이터 전송 프로토콜 (rdt)의 송신자 및 수신자 측면을 점진적으로 개발할 것이다.
 단방향 데이터 전송만 고려할 것이지만 제어 정보는 양방향으로 흐를 것이다.
또한 송신자 및 수신자를 명시하기 위해 유한 상태 기계 (FSM)를 사용할 것이다.

rdt1.0: reliable transfer over a reliable channel

밑에 있는 네트워크 채널이 완벽하게 신뢰성있다고 가정한다. 따라서 오류 검증 및 재전송 과정을 거치지 않고 단순 패키 송수신만 이뤄진다. 
 

• 비트 오류가 없음
• 패킷 유실이 없음

송신자와 수신자를 위한 별도의 유한 상태 기계 (FSM)가 있다.

송신자는 데이터를 기본 채널로 전송한다.
수신자는 기본 채널로부터 데이터를 읽어온다.

 

rdt2.0: channel with bit errors

기본 채널은 패킷 내의 비트를 뒤집을 수 있다고 가정한다. 이러한 비트 오류를 감지하기 위해 체크섬(예: 인터넷 체크섬)을 사용한다.
 
 
비트 오류가 발생했을 때 어떻게 복구할 것인가?

• 확인 응답 (ACKs): 수신자가 패킷을 정상적으로 수신했음을 송신자에게 명시적으로 알린다.
• 부정적인 확인 응답 (NAKs): 수신자가 패킷에 오류가 있음을 송신자에게 명시적으로 알린다.
• 송신자는 NAK를 수신하면 패킷을 다시 전송한다.

정지 및 대기 (stop and wait) 방식은 송신자가 하나의 패킷을 전송한 다음 수신자의 응답을 기다리는 방식.
 

수신자의 상태(수신자가 내 메세지를 올바르게 받았는지)는 수신자로부터 어떤 방식으로든 전달되지 않는다면 발신자에게 알려지지 않는다-> 따라서 프로토콜이 필요한 것 
 
 

rdt2.0 has a fatal flaw!

만약 ACK/NAK 메시지가 손상된다면 어떻게 될까요?

• 발신자는 수신자가 어떤 상황인지 알 수 없다
• 재전송만으로는 문제 해결이 어려울 수 있다. 중복된 패킷이 추가로 발생할 수 있다.

중복 처리:

• ACK/NAK가 손상된 경우 발신자는 현재 패킷을 다시 전송한다.
• 발신자는 각 패킷에 일련 번호를 추가한다..
• 수신자는 중복된 패킷을 폐기하고(상위 계층으로 전달하지 않음) 버린다.

정지하고 기다리기
 발신자는 하나의 패킷을 보내고, 그 후에 수신자의 응답을 기다린다.
 

rdt2.1: sender, handling garbled ACK/NAKs

 

Sender

receiver

NAK이 돌아온다면 패킷을 재전송한다. 
0번 패킷을 기다리고 있을 때 손상되지않은 0번 패킷이 도착-> deliever_data로 상위계층으로 보냄, 그 후 ack 전달
만약 0번 패킷을 기다리고 있는데 돌아온 데이터가 손실 -> NAK 전달 
 
발신자:

패킷에 일련 번호(seq #)가 추가된다.
두 개의 일련 번호(0, 1)만으로도 충분하다. 이유는 무엇인가요?
-> STOP AND WIAT 한번에 하나의 패킷만 전송하기 때문에
 
수신한 ACK/NAK가 손상되었는지 확인해야 한다.

상태의 두 배로 많아져야 한다.
상태는 "예상되는" 패킷의 일련 번호가 0 또는 1이어야 하는지를 "기억"해야 한다.
 
수신자:
받은 패킷이 중복인지 확인해야 한다.
상태는 예상되는 패킷의 일련 번호가 0 또는 1인지 나타낸다.
또한, 수신자는 마지막 ACK(확인 응답) 또는 NAK(부정 응답)이 발신자에게 제대로 수신되었는지 알 수 없다.
 

rdt2.2: a NAK-free protocol

 
rdt 2.1 과 기능적으로 동일하나 수신자는 ACK/NAK 말고 ACK만 사용한다
 ACK에 마지막 으로 수신 성공한 패킷의 일련번호를 포함한다. 
 
발신자에서 중복 ACK가 발생하면 NAK과 동일하게 패킷을 다시 전송
오늘날 TCP는 ACK만 사용한다. 
 
 

rdt2.2: sender, receiver fragments

 

발신자
0번 ACK를 기다리고 있을 대 1번 ACK가 날아오거나 응답이 손상되면 다시 0번 패킷을 재전송한다
 
수신자
1번 패킷을 받고 문제가 없으면 ACK 1을 전송
만약 문제가 있다면 ACK 0을 전송한다. 
 
 

rdt3.0: channels with errors and loss

rdt 3.0 보낸 패킷이 에러가 아니라 아예 소실되었다면?
->데이터와 ACK  손실 
체크섬, 일련 번호, ACK, 재전송은 도움이 될 것이지만 충분하지 않을 수 있다.
 
 
처리 방식: 발신자는 합리적인 시간 동안 ACK(확인 응답)을 기다린 후, 해당 시간 내에 ACK를 받지 못하면 패킷을 재전송한다.
 
만약 패킷(또는 ACK)이 지연된 경우(손실되지 않았을 경우):

재전송은 중복될 수 있지만 일련 번호(seq #s)가 이미 이를 처리한다.
수신자는 ACK한 패킷의 일련 번호를 명시해야 한다. 
 
타임아웃(timeout)을 사용하여 합리적인 시간이 경과한 후에 인터럽트를 발생시켜야 합니다.
 

 
 
 

rdt3.0 in action

 
 

 
 

Performance of rdt3.0 (stop-and-wait)

U(sender): 활용도 - 송신자가 데이터를 보내는데 바쁜 시간의 일부분으로 나타내는 것
패킷을 채널로 전송하는 데 걸리는 시간:

rdt3.0: stop-and-wait operation

RTT: 패킷 전송 완료 시점부터 패킷에 대한 응답이 도착할 때 까지의 시간
L/R 패킷이 끝까지 전송 시작될 때 까지 걸리는 시간
 
T=RTT+L/R 패킷을 보내기 시작했을 시점에서 ACK를 받을 때 까지의 시간 
 
 

 

• rdt 3.0 프로토콜의 성능이 좋지 않다.
• 프로토콜은 기반 인프라(채널)의 성능을 제한한다. 

 

rdt3.0: pipelined protocols operation

 
한번에 여러개 패킷을 전송한다, 
 
파이프라이닝(pipelining): 송신자는 여러 개의 "전송 중"이지만 아직 확인되지 않은 패킷을 허용한다.

• 일련 번호의 범위를 증가시켜야 한다.
• 송신자와/또는 수신자에서 버퍼링이 필요한다.
  
  
  
  

Go-Back-N: sender

송신자: 최대 N개의 연속적으로 전송되었지만 확인되지 않은 패킷에 대한 "윈도우"를 가진다.

패킷 헤더에 k-비트 일련 번호(seq #)가 있다.
누적형(누적) ACK: ACK(n) - 일련 번호 n를 포함하여 해당하는 모든 패킷에 대한 확인을 수행한다.
ACK(n)를 수신하면 윈도우를 n+1에서 시작하도록 이동시킨다.
가장 오래된 전송 중인 패킷에 대한 타이머가 있다.
타임아웃(n): 패킷 n 및 윈도우 내에서 더 높은 일련 번호 패킷을 재전송한다.
 

 
패킷 손실이 발생하면 타임아웃 이후 손실난 패킷을 포함하여 그 이후에 것들을 다 재전송한다. 
큐잉 딜레이 없음 
 

Selective repeat

 
선택적 반복(Selective Repeat):

수신자는 개별적으로 모든 정확히 수신한 패킷에 대한 확인을 수행한다.
필요한 경우 상위 계층으로 패킷을 순서대로 전달하기 위해 필요한 경우 패킷을 버퍼에 저장한다.
송신자는 확인을 받지 못한 패킷에 대해 개별적으로 타임아웃 및 재전송을 수행한다.
송신자는 확인을 받지 못한 각 패킷에 대한 타이머를 유지한다.

발신자 윈도우:
N개의 연속적인 일련 번호(seq #s)
보낸, 확인되지 않은 패킷의 일련 번호를 제한한다.