UDP 프로토콜은 안정적인 네트워크 전송 전략을 실현합니다.

1 안정적인 전송

UDP의 신뢰성은 실제로 TCP의 안정적인 전송 전략을 기반으로 하며 그 본질은 단순화되어 있습니다. 먼저 TCP가 안정성을 보장하는 방법을 이해해야 합니다.

1.1 신뢰성을 보장하기 위한 일반적인 전략은 무엇입니까?

(1) ACK 메커니즘
(2) 재전송 메커니즘
(3) 시퀀스 번호 메커니즘
(4) 재배열 메커니즘
(5) 윈도우 메커니즘

ACK 메커니즘은 이해하기 쉽습니다. 즉, 패킷이 수신되면 확인을 위해 ACK가 전송됩니다. 시퀀스 번호 메커니즘과 재정렬 메커니즘도 더 많이 사용됩니다.네트워크는 데이터 패킷을 순서 없이 수신할 수 있습니다.이 때 각 패킷의 시퀀스 번호를 전송 시작 ​​시 추가한 다음 수신 후 재정렬해야 합니다. . 재전송 및 창 메커니즘은 더 복잡하며 아래에서 별도로 설명합니다.

1.2 재전송 메커니즘
1.2.1 재전송을 위한 세 가지 전략
1. 정지 대기 프로토콜
이것은 주로 데이터 프레임이 전송될 때마다 다음 프레임을 보내기 전에 상대방으로부터 응답을 받아야 하기 때문에 효율성이 낮은 오래된 방법입니다. 1. 프레임 데이터, 주로 대화 모드, 하나의 질문 및 하나의 답변.

여기에 이미지 설명 삽입

2. 롤백 N 프레임 재전송 방법
은 현재 계속 사용 중이며 일련의 연속 패킷을 보내는 것입니다.중간에 패킷 손실이 있을 때 연속 수신 패킷의 최대값을 확인하기 위해 응답합니다. 모든 패킷은 재전송되어야 합니다.

여기에 이미지 설명 삽입 

( C/C++ , Linux , FFmpeg , webRTC , rtmp , hls , rtsp , ffplay , srs ) 를 포함하여 2022년 에 가장 완전한 최신 학습 및 개선 자료 를 받으려면 개인 메시지를 보내주십시오.

 

3. 선택적 재전송

위에서 N개의 프레임을 롤백하는 방식은 대역폭 낭비라고 판단되어 상대방이 잃어버린 패킷만 재전송하는 한 가지 방식을 생각한다. 어떤 패킷이 손실되었는지 정방향으로 보낸 사람에게 알리고 손실된 패킷을 다시 전송할 수 있습니다.

1.2.2 재전송 타이밍
(1) 발신자가 ACK를 받지 못한 경우 해당 패킷을 재전송하고,
(2) 수신자가 수신한 시퀀스 번호가 누락된 경우 발신자에게 다음을 알리는 메시지를 보냅니다. 해당 패킷을 재전송합니다.

1.2 흐름 제어
1. 흐름 제어의 목적 흐름 제어의
주요 목적은 원활한 네트워크 대역폭을 보장하고 대역폭 낭비를 방지하는 것이며 도입된 메커니즘은 주로 보낸 사람 측의 흐름을 제어, 즉 보낸 사람의 전송 속도를 제어하는 ​​것입니다.
2. 흐름 제어 원리
발신자와 수신자의 창을 사용하여 현재 흐름을 조정합니다. 경계 조건, 수신자 창이 0일 때 발신자는 전송을 중지해야 합니다. 즉, 수신할 공간이 없고 전송을 종료해야 합니다.
3. 전송 종료 후 전송 속도는 언제 재개되나요?
(1) 수신자가 데이터를 읽을 때 송신자에게 창을 업데이트해야 합니다.
(2) 간격을 두고 조회하기 위해 프로브 패킷을 보냅니다. 수신기는 창 크기로 응답해야 합니다.

1.3 Congestion Control
두 가지 전략을 소개합니다.대부분의 사람들은 이 그림에 익숙합니다.

1.3.1 느린 시작

느린 시작: 실제로 느린 것은 아닙니다. 주로 시작점이 낮고 패킷에서 시작하여 기하급수적으로 증가하기 때문입니다.

1.3.2 빠른 복구

빠른 회복: 빠른 회복은 빠르지 않으며 주로 임계값의 절반에서 시작하는 선형 증가 방법을 채택합니다.

1.4 기본 개념
RTO:
타이머 타임아웃 시간, 즉 타임아웃 후에 데이터 패킷 재전송이 필요합니다.
참고:
tcp 시간 초과 계산: 첫 번째 재전송 시간: RTO2, 세 번의 연속 패킷 손실 후: RTO8, 지연이 매우 큽니다.
RTT:
네트워크 왕복 지연, 발신자와 수신자의 타임스탬프를 기록해야 합니다.

2 UDP 신뢰성 설계

응용 계층의 안정적인 전송을 기반으로 하는 udp의 안정적인 설계에는 에센셜 오일이 없으며 특정 사용 시나리오를 기반으로 해야 합니다.

2.1 프로토콜 설계

协议设计:
|同步字|总字节大小|分片数|分片编号|载荷大小|预留|荷载|
typedef struct packet
{
    int recv_pieces;								//当前已经接收的数量;
    int total_size; 								//总数据大小
    int left; 										//最后一片大小
    int paiece_size; 								//分片大小
    int recv_len;  									//接收数据长度
    uint8_t *recv_buf;								//保存接收数据
    uint8_t * send_pt; 								//指向发送数据buffer
   	uint8_t piece_buf[PIECE_FIX_SIZE+HEAD_SIZE+1] ;	//单帧的buf
   	circular_buffer_t *circular_buffer; 			//环形缓存
}packet;

2.2 특정 구현
구체적인 구현 은 여기에 작성되지 않지만 몇 가지 주의해야 할 사항이 있습니다. UDP 신뢰할 수 있는 전송을 위해 고려해야 할 몇 가지 사항, 하나는 재전송 메커니즘, 패킷 손실 재전송 필요 , ACK 또는 NACK 중 하나를 사용할 수 있습니다. 메서드, 두 번째는 재정렬 메커니즘, 순서가 잘못된 데이터를 수신할 때 데이터를 재정렬하기 위해 버퍼를 추가해야 합니다. 세 번째는 타임아웃 메커니즘으로, 상대방의 회신을 장기간 압수, 넷째, 교통 통제, 이 부분은 일반적으로 근거리 통신망에서 고려되지 않고 구현이 더 복잡하고 이점이 크지 않습니다.

3 UDP 사용 시나리오

  1. 실시간 고려
  2. 리소스 소비 고려 사항

특정 시나리오에는 주로 다음과 같은 측면이 포함됩니다.

1 음성 및 화상 통화(네트워크 지연, tcp는 재전송을 제어할 수 없음, 지연이 너무 커서 udp는 재전송 시간을 제어할 수 있음),
2 게임 개발(실시간 작동: 영광의 왕, 전송 위치, 지연으로 인해 지연이 발생함)
3 DNS 쿼리(질문 1개, 답변 1개, 패킷 1개로 충분, 분실 시 바로 재전송 가능)
4 IoT 기기 모니터링, 배터리 사용(활성 상태 전력 소모, 슬립, 소량 데이터 전송) )
5 장치가 오프라인 하트비트 패킷인지 여부를 모니터링하는 하트비트 메커니즘

4 UDP 프로그래밍에서 주의해야 할 몇 가지 구덩이

4.1 UDP out-of-order 문제
일반적으로 수신 버퍼는 정렬에 사용됩니다.

4.2 sendto 패킷 크기
sendto는 한 번에 1400바이트를 전송
하며 최소 MTU보다 작아야 합니다. 이더넷 데이터 프레임은 일반적으로 1500바이트
입니다. 경험치: 1400(실시간 통신) 500(게임) 주로 패킷이 상대적으로 작고 특정 우선 순위가 있음
4.3 수신 데이터 수신
은 한 번 에 메시지를 완전히 읽을 필요가 있고
udp는 한 번에 하나의 패킷만 수신할 수 있으며 경계 문제가 없습니다(메시지 전송)
tcp는 한 번에 데이터의 일부를 수신할 수 있습니다 , 그리고 스티키 패킷 문제가 있습니다(스트리밍 전송)

추천

출처blog.csdn.net/m0_60259116/article/details/124331666