TCP / IP에서 통신 대기 시간을 어떻게 공식화 할 수 있습니까?


12

TCP / IP를 사용하여 통신하는 두 노드 간의 왕복 지연 시간을 추정하기 위해 수학적 모델 / 방정식을 도출하는 데 어려움이 있습니다. 노드는 HTTP 프로토콜을 기반으로 데이터를 교환합니다. 이 모델에서 연구해야 할 가장 중요한 요소는 네트워크의 두 노드 간 물리적 거리, 중간 홉 수, 대역폭, 각 홉에서의 처리 지연입니다. 나는 웹을 검색했지만이 의미에서 아무것도 찾을 수 없었고 회로 교환 네트워크와 UDP 프로토콜에 관한 것을 발견했습니다. TCP에 맞게 사용자 정의 할 수 있습니까?


이것은 움직이는 대상이며 모델의 상수를 변경하는 많은 종속성이 있습니다. 예를 들어, 홉당 전달 지연을 포함하려면 기준선으로 각 장치의 제조업체와 모델을 일렬로 알아야합니다. 인터넷이나 다른 네트워크와 같이 경로에있는 각 장치를 제어하거나 알지 못하면 실제로 고려할 수 없습니다. 경로의 각 홉에 대한 모든 정보를 알고 있다고 가정하면 스위치 모델 "A"의 경우 1.2 마이크로 초, 스위치 모델 "B"의 경우 5.0과 같은 기준선 전달 지연을 적용 할 수 있습니다.
netdad

1
+1 여기 너무!에 대한 당신의해야 플래그 , 지금은 중복 질문을 제거하는 SO
Grijesh 차우를

:의 소스 코드 httping를 사용 주석httping -Gbg www.google.com -c 5
Grijesh 차우

@Espanta, 당신의 목표는 대기 시간 또는 처리량을 추정하는 것입니까? 처리량은 SACK, RWIN, 앱 프로토콜 채팅 및 대기 시간과 같은 TCP 기능에 크게 의존합니다.
generalnetworkerror

@generalnetworkerror, http get 및 post 요청 및 응답을 위해 왕복 대기 시간이 필요합니다.
Espanta

답변:


8

이것은 매우 복잡한 과정이므로 RTT를 정확하게 예측하는 데 유용한 방정식을 공식화하는 것은 매우 어렵습니다. 기껏해야, 각 단계마다 평균을 많이 사용하여 특정 상황에 대해 "더 잘 알기"만하면 조정할 수있는 모델을 만들 수 있다고 말할 수 있습니다. 이것은 내가 현재 연구하고있는 것이므로 지금까지 내가 알고있는 것을 (물리적 층에서 시작하여) 알 수 있습니다.

  • Electronics SE에 대한 내 질문을 참조하십시오. 이더넷의 인코딩 지연 및 통신 지연을 위해 구리를 통한 케이블 주파수 등급전기 속도 (신호 전파?) 와의 관계 . 표준화 된 속도 (100Mbps, 1Gbps, 10Gbps 등)를 사용하므로 광섬유 나 구리를 다르게 취급하지 마십시오. 둘의 "지연"은 거의 같은 수준이지만 구리는 신호를 분명히 전달할 수 없습니다. 내가 가진 이 질문에 지금에 답을 알고 물리학 SE 사이트에 있습니다. 나는 단지 그것을 바로 잡을 시간을 찾기 만하면되므로, 관심이 있다면 계속 주목해야한다. 나는 내가 기회를 얻을 때 내가 알고있는 더 많은 통신 사용 섬유 관련 질문을 게시 할 것이다. ).

  • 링크 끝에 장치에 의해 훨씬 더 많은 지연이 추가 될 것입니다. "경로를 따라 2 개의 스위치는 Xms 지연, 4 개의 스위치는 2 * Xms, 2 개의 라우터는 Yms ... 등"이라는 표준 방법은 없습니다. 예를 들어 1Gpbs를 사용하고 경로 속도로 장치를 회선 속도로 사용한다고 가정하면 1000000000bps이므로 물리적 인터페이스가 고정 인코딩 속도로 실행됩니다 (비트 당 1 나노 초에서 최대 사용중인 기호 인코딩 체계 (예 : 10b )

  • (물리적 계층에서) 세 가지 주요 지연 유형이 있습니다 (실제 계층에서). 직렬화 지연, 인코딩 지연, 전파 지연 (및 처리 지연, 큐잉 지연, 인코딩 및 디코딩 지연, 그러나 물리 계층 이상이지만 언급이 필요합니다!). 인터넷, VoIP : 심층 분석 , 슬라이드 13, 여기Google Scholar 등이 포함되어 있습니다.

  • 프로토콜 스택을 위로 올라갈 때 대상 MAC이 각 스위치 캠 테이블에 있고 IP 계층에서 ARP 테이블의 대상 MAC에 있다고 가정합니다. 이러한 발견 프로세스에 의해 유발 된 추가 지연은 플로우의 첫 번째 패킷에 대해서만 발생하므로 시간 종료를 높이고 무상 ARP 등을 보내서 우회 할 수 있습니다.

  • 응용 프로그램 계층에 도달하면 요청을 처리하는 서버 (예 : 인터럽트 지연)에 따라 달라지기 때문에 실제로 어려워집니다. 로드로 인해 요청 및 컨텍스트 전환을 처리하는 데 필요한 인터럽트 수는 예측할 수 없습니다.

나는 당신의 질문에 당신을 돕고 싶습니다. 슬프게도 이것은 지금 내가 할 시간입니다. 나는 오늘 밤이나 내일이 답변을 업데이트 할 것입니다. 지금까지 가지고있는 것을 게시하고 싶었습니다.

한편, 대부분의 사람들은 약 0.6 * c (C = 광속)의 물리적 구리 / 섬유 층에서 지연에 대한 수치를 다루는 경향이 있습니다. 또한 X 패킷마다 TCP의 ACK 교환에 대해 고려해야합니다. 예를 들어 SACK을 사용하거나 점보 프레임 및 / 또는 더 큰 MSS 크기를 사용하는 경우 다릅니다 (이제 MTU도 고려해야합니다!). , 사이에 더 많은 ACK를 전송하는 경우 (전송되는 데이터의 양이 관심이있는 경우) 또한 악명의 요인에 필요한 대역폭 지연 제품 및 그 바보 잘못 해석하지 않는 내가 한 해당 페이지의를. 나는 여기에 다양한 단순하고 매우 추악한 데이터 계산기를 만들기 시작했습니다.. 다시 진행중인 작업 나는 곧 그들을 시도하고 업데이트 할 것입니다. 나는 당신이하려고하는 것과 비슷한 계산기를 추가 할 계획입니다. 당신이 관심이 있다면 나는 또한 빛과 섬유 계산기를 만들었지 만, 다시는 시간이 없다!, 나는 그것들을 아직 업로드하지 않았다. 앞으로이 답변을 좀 더 업데이트하기 위해 최대한 빨리 노력하겠습니다.

PS 나는 QoS를 언급하는 것을 잊었다! QoS가 경로의 어느 곳에서나 사용 중이라면 RTT를 요약하기가 정말 어려워 질 것입니다!


감사. 아주 자세하게 설명합니다. 두 노드 사이의 홉 수가 유선 네트워크에서 두 노드 사이의 물리적 거리에 큰 영향을 미친다는 점을 강조해야합니다. (최소한 실제 벤치마킹 결과가 나왔기 때문에) 모든 것을 함께 모아 곧 내 모델을 사용할 것입니다. 읽고, 높이고, 대답하고 대답 할 모든 사람들에게 감사드립니다.
Espanta

텔레콤의 광섬유 사용 (OP가 데이터 센터 내에서 지연을 처리하지 않거나 물리적 인프라를 완전히 제어 할 수있는 일부 설정을 가정 할 경우)는 흥미를 끌고 모델링을 거의 불가능하게 할 수 있습니다. 문제를 강조하기위한 일화. 나는 한때 T-1의 루이빌, 켄터키 주 렉싱턴, 켄터키와 루이지 빌, 켄터키 주 신시내티, 오하이오 주에있었습니다. 통신 회사에 전화를해서 일리노이 서부의 섬유 절단이 책임을 져야한다고 나에게 알렸다. 지도를보고 왜 그것이 미친 지보십시오. 그러나 더 높은 대역폭 링크는 이러한 종류의 통신 광기에 노출 될 가능성이 적습니다.
Jeff McAdams

5

(다른 사람들이 지연 등의 작동 방식과 그 원인에 대해 훌륭한 답변 을 게시했다고 지적하고 싶습니다 .하지만 OP는 모델링에 대해 질문했습니다. 기본 모델은 간단하고 예제 번호를 입력하면됩니다. 이유 를 알고 싶다면 지연은 그들이 무엇인지, 다른 사람의 답변을 참조하십시오 : ^)

네트워크 대기 시간은 단순히 한 끝점에서 다른 끝점으로이동 시간으로, 사이에 N 홉에 걸쳐 있습니다.

따라서 N-1 중간 노드가있는 N 세그먼트 (홉)가 있습니다. 각 노드에는 지연 (큐 지연, 처리 지연 등과 같은 해당 노드에서 여러 가지 누적 효과)이 있으며 각 세그먼트에는 전송 지연이 있습니다. 전체적으로 2N-1 독립 변수입니다. 그래서 그것은 seg1 + node1 + seg2 ... + node (N-1) + segN입니다. 하나의 홉은 단지 = seg1이고, 두 개의 희망은 seg1 + node1 + seg2입니다.

다음으로 모든 조각이 무엇인지 정의해야합니다. 따라서 CATV 네트워크, 위성 링크, 광섬유 링크, 이더넷 등을 사용하여 모델 네트워크를 구성 할 수 있습니다. 각 기술마다 예제 정보를 찾아야합니다.

전송 지연은 대략 데이터 크기를 세그먼트의 전송 속도로 나눈 값입니다. 보다 정확한 모델이 필요한 경우 비행 시간 지연을 대략 세그먼트의 길이를 데이터 흐름 속도 (약 빛의 속도로 나눈 값)로 나눈 값을 추가해야합니다. 이는 위성 링크가있는 경우에 중요합니다. 지구 동기화 위성의 위아래가 중요합니다.

각 노드의 지연은 모델에 어떤 장비를 배치하는지에 따라 추정해야합니다.

응용 프로그램 대기 시간 (예 : FTP 전송의 데이터 흐름이 시작될 때까지의 지연)을 원하는 경우 네트워크 대기 시간이 몇 번 재생되는지 계산하여 빌드합니다. 예를 들어, 3 방향 TCP 핸드 셰이크는 네트워크 대기 시간의 3 배를 증가시켜 애플리케이션이 보는 수준까지 쌓입니다.


3

양쪽에서 패킷을 캡처하여 왕복 대기 시간을 추정 한 다음 모니터링되는 시스템에서 나가는 요청과 응답이 다시 오는 지연을 측정 할 수 있습니다. 예를 들어, SYN이 원격 시스템으로 나가는 시간을 표시 한 다음 SYN + ACK 응답이 들어온 시간을 표시하면 왕복 TCP 대기 시간이 상당히 좋아질 것입니다.

이것은 실제 네트워크 대기 시간보다 클 것이며, 어느 쪽의 시스템에 얼마나 많은로드가 있는지에 따라 얼마나 커질 수 있습니다.


귀하의 답변에 감사하지만 기계의 코딩이나 해석을 사용하여 측정하고 싶지는 않지만 수학적 모델을 사용하여 공식화해야합니다. 예를 들어 총 지연 = 총 전파 + 총 전송 + 총 저장 및 전달 + 총 처리 등이 있습니다. 그리고 이러한 각 타이밍에 대해 다른 공식을 가질 수 있습니다. 수학적으로 측정 할 수 있습니다.
Espanta

3

두 호스트 간의 지연은 몇 가지 요인에 따라 달라집니다.

  • 전파 지연
  • 직렬화 지연
  • 큐잉 / 버퍼링 지연

전파 지연 은 패킷이 두 위치 사이를 물리적으로 이동하는 데 걸리는 시간입니다. 섬유에서 빛의 속도는 약 200000 km / s입니다. 내가 사는 스웨덴은 약 1570km이므로 7.85ms이지만 실제로는 조류 전망을 통한 거리이기 때문에 더 큽니다.

직렬화 지연 은 물리적 매체, 즉 네트워킹 장치의 인터페이스를 통해 패킷을 직렬화 하는 데 걸리는 시간입니다. 2Mbit 연결이 있고 패킷을 직렬화하는 데 6ms 인 1500 바이트 패킷을 보내는 경우 (12000/2000000).

큐잉 / 버퍼링 지연 은 인터페이스에서 발송되기 전에 패킷이 큐 / 버퍼에 머무르는 시간입니다. 인터페이스의 속도와 얼마나 큰 버퍼가 사용되는지에 따라 다음은 아무것도 아니거나 상당한 지연이 될 수 있습니다.

그런 다음 호스트에서 패킷을 생성하고 애플리케이션이 패킷을 처리하는 데 약간의 지연이 발생합니다. HTTP 지연을 측정하는 응용 프로그램이 있습니다. 사람들은 웹 사이트를 포기하기 전에 많은 지연을 수용하지 않으므로 중요한 요소입니다.


홉 수는 어떻습니까? 각 홉에서 지연?
Espanta

직렬화 및 대기열과 같은 일부 요인이 다양하기 때문에 일반 수식을 만드는 것은 어렵습니다. 여기에 쓴 사람이 있습니다. ccieflyer.com/pdf/2009-Mar-Oleg-Berzin.pdf - 수학은 내 수학 실력 넘어하지만 :)
다니엘 디브
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.