☰

TCP/IP-over-Ethernet 네트워크의 대기 시간

tag-icon • tag-icon linux networking tcpip ethernet latency
TCP/IP-over-Ethernet 네트워크의 대기 시간

다음과 같이 어떤 리소스(도서, 웹 페이지 등)를 추천하시겠습니까?

  • TCP/IP-over-Ethernet 네트워크의 지연 원인을 설명합니다.
  • netstat -s대기 시간을 유발하는 항목(예: 의 특정 항목 ) 을 찾기 위한 도구를 언급합니다 .
  • TCP 대기 시간(Nagle, 소켓 버퍼 등)을 줄이기 위해 Linux TCP 스택을 조정하는 방법을 제안합니다.

내가 아는 가장 가까운 것은이 문서, 하지만 다소 짧습니다.

또는 위의 질문에 직접 답변하셔도 됩니다.

편집하다분명히 말하면 문제는 "비정상적인" 대기 시간에 관한 것이 아니라 일반적인 대기 시간에 관한 것입니다. 또한 이는 특히 TCP/IP-over-Ethernet에 관한 것이며 다른 프로토콜에 관한 것이 아닙니다(더 나은 대기 시간 특성이 있더라도).

답변1

지연 시간에 대한 커널 조정 가능 항목과 관련하여 다음 사항을 염두에 두어야 합니다.

echo 1 > /proc/sys/net/ipv4/tcp_low_latency

로부터선적 서류 비치:

설정된 경우 TCP 스택은 높은 처리량보다 낮은 대기 시간을 선호하는 결정을 내립니다. 기본적으로 이 옵션은 더 높은 처리량을 선호한다는 의미로 설정되지 않습니다. 이 기본값을 변경해야 하는 애플리케이션의 예로는 베오울프 컴퓨팅 클러스터가 있습니다. 기본값: 0

다음과 같이 애플리케이션에서 Nagle 알고리즘을 비활성화할 수도 있습니다(최대 세그먼트 크기까지 TCP 출력을 버퍼링함).

#include <sys/types.h>
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <linux/tcp.h>

int optval = 1;
int mysock;

void main() {
    void errmsg(char *msg) {perror(msg);exit(1);}

    if((mysock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
        errmsg("setsock failed");
    }

    if((setsockopt(mysock, SOL_SOCKET, TCP_NODELAY, &optval, sizeof(optval))) < 0) {
        errmsg("setsock failed");
    }

    /* Some more code here ... */

    close(mysock);
}

이 옵션의 "반대"는 TCP_CORK패킷을 "다시 Nagle"하는 것입니다. 그러나 TCP_NODELAY기대한 대로 항상 작동하지 않을 수도 있고 경우에 따라 성능이 저하될 수도 있으므로 주의하세요. 예를 들어 대용량 데이터를 전송하는 경우 패킷당 처리량을 최대화하려고 하므로 TCP_CORK. 즉각적인 상호작용이 필요한 애플리케이션이 있는 경우(또는 응답이 요청보다 훨씬 커서 오버헤드가 발생하지 않는 경우) 를 사용하세요 TCP _NODELAY. 또 다른 참고로, 이 동작은 Linux에만 해당되며 BSD는 다를 수 있으므로경고 관리자.

애플리케이션과 인프라를 철저하게 테스트해야 합니다.

답변2

제 경험상 가장 큰 원인은이상정상적인 고속 네트워크의 대기 시간은 TCP Windowing(RFC1323, 섹션 2) 오류, TCP 지연 승인을 둘러싼 오류와 밀접하게 관련된 두 번째 오류(RFC1122 섹션 4.2.3.2). 이 두 가지 방법 모두 고속 네트워크를 더 잘 처리하기 위해 TCP를 개선한 것입니다. 파손되면 속도가 매우 느린 수준으로 떨어집니다. 이러한 경우의 결함은 대규모 전송(백업 스트림을 생각해 보세요)에 영향을 미치며, 트랜잭션이 매우 적은 트래픽(평균 데이터 전송은 MTU 크기 미만이고 앞뒤로 많이 발생함)은 이러한 영향을 덜 받습니다.

다시 말하지만, 나는 두 개의 서로 다른 TCP/IP 스택이 통신할 때 이 두 가지 문제의 가장 큰 문제점을 확인했습니다. Windows/Linux, 2.4-Linux/2.6-Linux, Windows/NetWare, Linux/BSD 등. 작품을 아주 아주 좋아합니다. Microsoft는 Server 2003에 존재하지 않았던 Linux 상호 운용성 문제를 도입한 Windows TCP/IP 스택을 Server 2008에서 다시 작성했습니다(이 문제가 수정되었다고 생각하지만 100% 확신할 수는 없습니다).

지연 또는 선택적 승인의 정확한 방법에 대한 불일치로 인해 다음과 같은 경우가 발생할 수 있습니다.

192.168.128.5 -> 192.168.128.20: 1500b 페이로드, SEQ 1562
192.168.128.5 -> 192.168.128.20: 1500b 페이로드, SEQ 9524
[200ms 통과]
192.168.128.20 -> 192.168.128.5: ACK 1562
192.168.128.5 -> 192.168.128.20: 1500b 페이로드, SEQ 12025
192.168.128.5 -> 192.168.128.20: 1500b 페이로드, SEQ 13824
[200ms 통과]
192.168.128.20 -> 192.168.128.5: ACK 12025

처리량은 모든 200ms 시간 제한으로 인해 바닥을 통과합니다(Windows에서는 기본적으로 지연 승인 타이머가 200ms로 설정되어 있음). 이 경우 대화의 양쪽 모두 TCP 지연 승인을 처리하지 못했습니다.

TCP 윈도우 오류는 그 영향이 덜 명확할 수 있기 때문에 알아차리기가 더 어렵습니다. 극단적인 경우 Windowing이 완전히 실패하고 패킷->ack->패킷->ack->패킷->ack가 발생합니다. 이는 약 10KB보다 훨씬 큰 항목을 전송할 때 속도가 매우 느리고 모든 용량이 확대됩니다.기본 대기 시간링크에. 감지하기 어려운 모드는 양측이 지속적으로 창 크기를 재협상하고 한쪽(발신자)이 데이터가 계속 전달되기 전에 처리해야 하는 몇 개의 패킷이 필요한 협상을 준수하지 못하는 경우입니다. 이러한 종류의 오류는 Wireshark 추적에서 빨간색으로 깜박이는 표시등으로 표시되지만 예상 처리량보다 낮은 것으로 나타납니다.

앞서 언급했듯이 위의 내용은 대규모 이체를 방해하는 경향이 있습니다. 스트리밍 비디오 또는 백업 스트림과 같은 트래픽은 실제로 매우 큰 파일(예: Linux distro ISO 파일)의 간단한 다운로드뿐만 아니라 실제로 고정될 수 있습니다. 공교롭게도 TCP Windowing은 데이터 파이프라인을 허용하므로 근본적인 대기 시간 문제를 해결하는 방법으로 설계되었습니다. 전송된 각 패킷에 대해 왕복 시간을 기다릴 필요가 없습니다. 큰 블록을 보내고 더 보내기 전에 단일 ACK를 기다리면 됩니다.

즉, 특정 네트워크 패턴은 이러한 해결 방법의 이점을 얻지 못합니다. 데이터베이스에서 생성되는 것과 같이 트랜잭션이 많고 소규모 전송은 다음과 같은 문제를 가장 많이 겪습니다.정상회선의 대기 시간. RTT가 높으면 이러한 워크로드는 큰 어려움을 겪게 되며, 대규모 스트리밍 워크로드는 훨씬 적은 어려움을 겪게 됩니다.

답변3

이 질문에 대한 답변은 많습니다.

TCP가 어떻게 작동하는지 기억하세요. 클라이언트는 SYN을 보내고, 서버는 SYN/ACK에 응답하고, 클라이언트는 ACK에 응답합니다. 서버가 ACK를 수신하면 이제 데이터를 보낼 수 있습니다. 이는 의미 있는 데이터의 첫 번째 비트를 전송하려면 RTT(왕복 시간)의 2배를 기다려야 함을 의미합니다. RTT가 500ms인 경우 처음부터 바로 1초 지연이 발생합니다. 세션의 수명이 짧지만 많으면 대기 시간이 많이 발생합니다.

세션이 설정되면 서버는 클라이언트가 승인해야 하는 데이터 단위를 보냅니다. 서버는 첫 번째 데이터 단위에 대한 승인을 요구하기 전까지만 야생에서 너무 많은 데이터를 보낼 수 있습니다. 이로 인해 대기 시간도 발생할 수 있습니다. 데이터 단위가 삭제되면 거기에서 전송을 선택해야 하므로 대기 시간이 추가로 발생합니다.

IP 수준에서는 조각화가 발생합니다(현재는 매우 드물지만). 1501바이트 프레임을 전송하고 상대방이 1500의 MTU만 지원하는 경우 데이터의 마지막 비트에 대해서만 추가 IP 패킷을 전송하게 됩니다. 이는 점보 프레임을 사용하여 극복할 수 있습니다.

TCP/IP 처리량을 늘리는 가장 좋은 방법은 대기 시간을 최대한 줄이고 전송 오류를 최대한 방지하는 것입니다. 나는 커널 조정에 대해 모르지만 누군가는 그렇게 할 것이라고 확신합니다.

답변4

아마도 당신이 찾고 있는 대답은 아닐 것입니다. WAN에서 대기 시간이 발생하는 주요 원인은 빛의 속도입니다(너무 느립니다!). 또한 도중에 큰 버퍼가 있는 포화된 링크는 인상적인 대기 시간을 얻는 경향이 있습니다.

관련 정보