ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % COMP5311 프로젝트: TCP 및 UDP 성능 분석
newpage
Youtube 비디오를 볼 때 Chrome 브라우저가 Firefox보다 훨씬 빠르게 느껴지는 이유가 궁금하십니까? 나는 호기심이 많은 학생으로서 Wireshark를 실행하여 일부 트래픽을 캡처했고 내가 찾은 것은 이것이었습니다.
Wiki 1 에 따르면 QUIC은 Chrome 웹 브라우저에서 Google 서버로의 모든 연결 중 절반 이상에서 사용됩니다.
QUIC는 다수의 다중화된 UDP를 설정하여 현재 TCP 2를 사용하고 있는 웹 애플리케이션을 개선하는 것을 목표로 하는 프로토콜이며 일부에서는 이를 "TCP/2"라고도 합니다. 곧 출시될 HTTP/3(2021년 2월 현재 인터넷 초안)도 QUIC를 사용하는 것으로 알려져 있습니다.
잠깐... TCP를 대체하기 위해 UDP를 사용하고 있다고요? 우리는 UDP가 신뢰할 수 없다는 말을 들었습니다. 왜 UDP가 "낡은" TCP를 목표로 할 수 있습니까? 두 프로토콜(TCP 및 UDP)의 비교는 Boeing과 Airbus(두 가지 모두 전송 )보다는 Train과 비행기를 비교하는 것과 유사합니다. 그러나 우리는 이 QUIC가 개선하기 위해 UDP를 선택한 것이 무엇인지 엿볼 수 있도록 몇 가지 주요 지표와 비교할 수 있습니다.
newpage
newpage
전송 계층 프로토콜을 비교하는 것은 쉬운 작업이 아닙니다. 결과에 영향을 미칠 수 있는 요소가 많기 때문입니다.
프로토콜 내의 일부 매개변수(예: TCP)는 구현에 따라 결정됩니다(TCP/IP 핑거프린팅이 발생하여 악의적인 행위자가 호스트의 OS 등을 식별할 수 있음). 성과 측정
패킷이 취하는 즉각적인 경로는 확실히 결과에 영향을 미치므로 즉각적인 라우터, 병목 현상 사이의 링크 및 기타 트래픽도 결과에 영향을 미칠 수 있습니다.
위에서 언급했듯이, 우리는 종종 즉각적인 링크의 대역폭이나 단순히 클라이언트와 서버 간의 링크에 대해 확신하지 못할 수도 있습니다. 언급된 논문 중 하나는 링크에 충돌이 없을 것이라고 가정했습니다.
우리는 버퍼가 이러한 프로토콜의 성능에 영향을 미칠 수 있으며 소프트웨어 측면뿐만 아니라 하드웨어 부분도 중요하며 종종 이러한 하위 수준 세부 사항을 제어할 수 없다는 것을 확인했습니다.
대부분의 이전 연구에서 저자는 실험을 수행하기 위해 사용자 정의 프로그램을 구현하는 경우가 많았으며 이러한 소프트웨어 구현이 결과에 어떤 영향을 미칠 수 있는지, 즉 UDP 패킷이 전송되는 간격과 제한 사항이 있는지도 고려해야 합니다. 현재 목적을 위해 전송 간격에 사용되는 언어입니다.
이러한 모든 고려 사항을 고려하여 가능한 한 현실에 가까운 설정을 갖춘 간단한 네트워크 토폴로지를 사용하겠습니다. 버퍼 큐 크기 또는 프로토콜과 같은 기본 세부 정보가 있는 경우 두 프로토콜 모두에 대해 동일하게 사용합니다. 따라서 성능 지표로 처리량, 평균 지연 및 평균 지터를 사용하여 유선 일대일 호스트에서 IPv4를 통한 TCP와 UDP를 비교할 것입니다.
UDP 애플리케이션에서는 각각 1472바이트이고 TCP 애플리케이션에서는 이에 상응하는 바이트 수인 10, 100 및 range(1e4, 1e5, 1e4) 패킷을 전송하여 TCP 및 UDP 애플리케이션의 흐름을 관찰합니다.
JitterSum 에는 흐름의 모든 수신 패킷에 대한 모든 엔드투엔드 지연 지터(지연 변동) 값의 합계가 포함됩니다. 여기서는 패킷의 지터를 스트림의 마지막 패킷에 대한 지연 변화로 정의합니다. 즉,
newpage
해당 실험을 설계하는 첫 번째 질문은 시뮬레이션 여부입니다. 우리가 언급한 고려 사항을 더 잘 제어할 수 있으므로 우리 연구에서는 시뮬레이션이 더 나을 수 있습니다. 가장 큰 단점은 결과가 "실제"인지 어떻게 확신할 수 있는가입니다. 이에 대한 대답은 실험 범위가 명확하게 정의되어 있고 이러한 범위에 대한 온전성 검사를 자주 수행하는 한 결과가 얼마나 "실제"일 수 있는지에 대한 아이디어를 얻을 수 있다는 것입니다.
ns-3 C++로 작성된 연구 또는 교육 목적으로 주로 사용되는 오픈 소스 이산 이벤트 네트워크 시뮬레이터입니다. 시뮬레이터 자체에는 온라인으로 제공되는 포괄적인 문서가 있습니다.
현재 목적을 위해서는 ns-3 의 주요 추상화만 이해하면 됩니다.
{ 너비=75% }
이는 컴퓨터의 프로세스와 유사하며 "소켓"을 사용하여 하위 계층으로 데이터를 보냅니다. TCP 소켓과 UDP 패킷 전송을 위한 UDPClient 및 UDPServer 사용하고 두 경우 모두 패킷을 모니터링하기 위한 FlowMonitor 를 사용하여 ns-3 에 상용 BulkSendApplication 설치합니다.
아래에 지정된 기본 채널의 지연인 2마이크로초 간격으로 패킷을 전송합니다.
여기서는 페이로드를 의미합니다. MTU가 1500이므로 당연히 1500바이트를 사용하려고 합니다. 그러나 IP 헤더와 UDP 헤더에는 20 + 8바이트가 필요하므로 5 대신 1472를 사용해야 합니다. 이는 시뮬레이션에서 확인되었습니다. 1500바이트 패킷을 사용하면 처리량 성능이 저하될 수 있습니다.
BulkSendApplication"이 트래픽 생성기는 MaxBytes까지 또는 애플리케이션이 중지될 때까지(MaxBytes가 0인 경우) 가능한 한 빨리 데이터를 보냅니다. 하위 계층 전송 버퍼가 채워지면 더 많은 데이터를 보낼 수 있는 공간이 확보될 때까지 기다립니다. 지속적인 데이터 흐름."
성능을 비교하기 위해 MaxBytes를 UDP의 총 바이트(PacketCount * PacketSize)로 설정했으며 일부 실험에서는 SendSize가 중요하지 않습니다.
일반적으로 UDP, TCP 소켓, IPv4를 포함하는 InternetStackHelper 라고도 하며 현재 목적으로는 대기열을 포함하는 TrafficControlLayer 가 가득 차면 상위 계층에 알립니다.
이는 하드웨어(네트워크 인터페이스 카드, NIC) 및 해당 소프트웨어 드라이버에 해당하며 패킷 대기열도 포함하므로 ns-3 에는 두 가지 수준의 대기열이 있습니다.
이는 컴퓨터와 유사하게 Application , InternetStack 및 NetDevice 설치할 수 있는 최종 호스트입니다. 두 개의 Node 생성하고 이를 이더넷 케이블과 유사한 것으로 연결하겠습니다.
Node 에 통신 채널을 제공하며 이더넷과 같은 CSMA 채널을 사용합니다. 여기서 중요한 세부 사항은 MTU, DataRate 및 Delay와 같은 조정에 사용할 수 있는 속성을 선택하는 것입니다. 우리는 표준 MTU(점보 프레임 없음, 때로는 특정 네트워크에서 사용 가능), 기가비트 및 2마이크로초 지연을 사용할 것입니다. 2마이크로초인 이유는 빛이 600m를 이동하기 때문인데, 다른 연구에서는 0 지연을 사용합니다.
newpage
결과는 다음과 같습니다:
우리는 전송된 14720, 147200바이트에 대한 UDP 처리량이 1000Mbps를 초과하는 것을 관찰했습니다(우리의 대역폭은 1Gbps입니다). 그런 다음 패킷 손실을 살펴보았습니다.
100개 패킷 중 147200바이트 97개가 손실된 것을 볼 수 있습니다. 이 2개를 삭제하고 추가 조사를 해야 한다고 말해도 무방합니다.
또한 TCP 처리량이 점진적으로 증가하여 약 400Mbps 수준으로 유지되는 것을 볼 수 있습니다.
트래픽 제어가 부족하기 때문에 UDP 패킷은 하위 계층의 대기열에 "고착"될 수 있습니다. 그 결과는 혼잡을 일으키는 빠른 상시 전송 패킷 때문일 수도 있습니다. 지연이 실제로 증가하는지 확인하기 위해 버퍼를 낮추는 등 추가 조사가 필요합니다.
평균 지연은 "피크" 직후 감소한 다음 점차적으로 다시 증가합니다. 이는 혼잡 회피를 조정하는 cwnd 때문일 수 있습니다. ns-3 (Veno, Cubic... 등)에는 선택 항목이 많기 때문에 혼잡 제어 알고리즘이 실제로 그러한 패턴을 생성하는지 확인해야 하므로 추가 조사가 필요합니다.
시스템이 "안정"되고 지연의 변동이 적어짐에 따라 평균 지터가 감소할 것으로 예상됩니다.
UDP에 트래픽 제어가 없다는 것은 패킷이 지속적으로 스택 아래로 푸시되어 간섭 없이 전송된다는 것을 의미합니다. 지연의 변화는 최소화되어야 하며, 상기 트래픽 제어로 인해 연속 패킷의 패킷 지연이 커질 수 있습니다.
newpage
BulkSendApplication 은 하위 계층 전송 버퍼가 채워지면 대기하도록 했습니다. 따라서 우리가 패킷을 삭제할 수 있는 유일한 장소는 오류를 도입해야 하는 채널입니다.
UDPClient 에는 이러한 트래픽 제어 기능이 없으므로 패킷 손실을 관찰할 수 있습니다.
단순히 처리량(더 큰 처리량) 및 지터(지연 변동 감소)일 수 있습니다. 더 큰 평균 지연은 주로 QUIC가 "정체 제어 알고리즘을 커널 공간이 아닌 사용자 공간으로 이동"하는 것을 목표로 하는 트래픽 제어가 부족하기 때문입니다 1 .
https://github.com/alfredtso/ns-3-project
newpage
ns-3 교육 리소스
HTTP/3 초안
빠른 ↩ ↩ 2
빠른 GoogleDoc ↩
Yuan-Cheng Lai, Ahsan Ali, Md. Shohrab Hossain, Ying-Dar Lin, 소프트웨어 정의 네트워크를 통한 TCP 및 UDP 흐름의 성능 모델링 및 분석, 네트워크 및 컴퓨터 애플리케이션 저널, 130권, 2019년, 76-88페이지, ISSN 1084-8045 ↩
Jingyi He, S.-H.Gary Chan, 광 패킷 교환 네트워크를 통한 인터넷의 TCP 및 UDP 성능, 컴퓨터 네트워크, 45권, 4호, 2004년, 페이지 505-521, ISSN 1389-1286 ↩
Eric Gamess, Rina Surós, IPv4 및 IPv6의 TCP 및 UDP 처리량에 대한 상한 모델, Journal of Network and Computer Application, Volume 31, Issue 4, 2008, Pages 585-602, ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor, Raaid Alubady, Wisam Abduladeem Kamil, 4G 네트워크를 통한 TCP, SCTP, DCCP 및 UDP 프로토콜의 시뮬레이션된 성능, Procedia Computer Science, 111권, 2017, 페이지 2-7, ISSN 1877-0509 ↩
