공유 인터넷 연결에서 대역폭 관리 옵션


13

전제 :

농촌 지역, 고 대역폭 인터넷 연결을위한 많은 옵션은 없습니다. 지금까지 가장 빠른 속도는 위성 인터넷이지만 비싸고 (장비 및 월간 비용과 대기 시간 단점이 있음) 여러 가정에서 공유하고 싶습니다.

이는 자체적으로 간단합니다. 각 가정 (VLAN 또는 물리적 포트)에 서브넷이있는 라우터를 설정하고 이들 간의 트래픽을 차단하고 해당 서브넷으로 라우팅하거나 이중 NAT를 설정하도록 모뎀을 구성하십시오.

문제 :

TCP가 정상적으로 작동하는 방식은 각 TCP 연결이 사용 가능한 대역폭의 1 / n을 어느 정도 얻습니다. 여기서 n은 연결 수입니다. 따라서 한 가구 / 사용자가 많은 연결을 만들면 전체 연결에서 더 큰 점유율을 얻게됩니다. 이것은 특히 공평하지는 않습니다. 포화 된 연결 고리로 인해 각 가정 은 동등한 지분을 가져야합니다. 반면, 아무도 연결을 사용하지 않을 때는 전체 대역폭을 사용할 수 있어야합니다.

예를 들어, 12Mbit / s 다운 연결을 공유하는 4 가구가 있다고 가정하십시오. 그들 중 하나가 다운로드 / 스트리밍 / 무엇이든 전체 12Mbit / s (또는 거의 근접)를 사용할 수 있어야합니다. 두 세대가 연결을 사용하는 경우 한 세대가 1 개 파일을 다운로드하고 다른 하나는 11 개를 다운로드하는지 여부에 관계없이 각각 6Mbit / s를 가져와야합니다. 각각 4Mbit / s를 얻는다.

내가 지금까지 해결 한 것 :

이와 같은 정책을 구현하기에 가장 좋은 위치 (다운 스트림)는 좁은 파이프의 다른 쪽 끝에 있습니다 (예 : ISP). 분명히이 경우에는 가능하지 않으므로 어떻게 든 근사 할 수있는 것이 좋습니다. 그러나 어떻게? 이와 같은 기능을 지원하는 상용 라우터가 있습니까? Linux 또는 BSD 상자를 구성하여 구성 할 수 있습니까? 방탄 할 필요는 없습니다. TCP 서버 나 공격적인 UDP 서비스가 제대로 작동하지 않으면 아마도 내가 할 수있는 일을 피할 수있을 것입니다. 그러나 많은 RFC 호환으로 구성된 대부분의 트래픽의 일반적인 경우에는 작동해야합니다. TCP 연결.

명확하게하기 위해, 난 하지 특정 응용 프로그램의 우선 순위에 대해 이야기하지만, 오히려 집계 트래픽을 특정 이더넷 장치 또는 IP 주소 범위에서 /로. 일부 트래픽을 다른 트래픽보다 우선 순위가 높은 것은 잘 지원되는 것으로 보이지만 트래픽 클래스에 대역폭을 동일하게 할당하려고 할 때 상황이 명확하지 않습니다.

웹에서 발생하는 트래픽에 대한 정보가 잘못 작성되었거나 생각 나지 않고 역설적이거나 기타 정보가없는 정보가 많이 있습니다. 라우터 하드웨어에 대한 문서는 매우 구체적이지 않으므로 원으로 돌아 다니는 것 같습니다.

내가 이해하는 것처럼 TCP 가이 방식으로 작동하게하는 방법은 실제로 실제로 사용할 수있는 것보다 약간 좁은 파이프를 시뮬레이션하고 인위적으로 패킷을 삭제하여 되돌릴 수 있습니다. 따라서 위의 예제에서 추가 패킷을 인위적으로 삭제하여 모든 사람에게 정확히 3Mbit / s를 제공하는 것이 매우 간단하다고 생각합니다. 대부분의 경우 여분의 용량이 있으므로 연결을 효율적으로 사용하지는 않습니다.

내가 원하는 것을 할 수있는 방법이 있습니까? 내가 잘못 가고 있습니까? 나는 적당히 가격이 책정 된 라우터 / 어플라이언스 또는 리눅스 또는 BSD 배포판을 운영하기위한 일반적인 상자 일지라도 이것에 돈을 쓰려고한다.

답변:


4

이 문제를 해결하기 위해 무언가를 만들려면 다음을 설정하십시오.

하나의 링크를 공유하는 4 대의 컴퓨터를 예로 들어 보겠습니다. 네트워크는 다음과 같이 구성됩니다.

{ ISP }=========[ SOHO router] ===LAN1=== [eth0 |Linux Box| eth1] ===LAN2=== Home Desktops/Laptops

LAN2에서 고정 IP 주소를 사용한다고 가정 해 보겠습니다.

Linux Box 192.168.1.1
Home 1    192.168.1.11
Home 2    192.168.1.12
Home 3    192.168.1.13
Home 4    192.168.1.14

먼저 작은 스크립트를 작성하여 클라이언트를 핑하고 어딘가에 결과를 작성하여 어떤 클라이언트가 작동하는지 감지합니다. "이것은 독자를위한 연습으로 남습니다"연결된 총 호스트 수 계산 (1-4)

온라인으로 호스트가없는 경우를 처리하십시오.

전체 대역을 연결하지만 연결된 호스트 수로 나눕니다. (1의 경우 12Mb, 2의 경우 6Mb, 3의 경우 4Mb, 4의 경우 3Mb)

그런 다음 HTB 알고리즘과 함께 tc를 사용하여 WAN 측 장치에서 각 주소의 대역폭을 제한하십시오. 먼저 루트 클래스를 만듭니다.

DEV="eth0"
TC="/sbin/tc"
TOT_BW=12
$TC qdisc add dev $DEV root handle 1: htb default 99

그런 다음 각 "클라이언트"에 대한 클래스를 추가하십시오 (예 : 3 명의 클라이언트).

NB_CLT=3
CLT_BW=$(($TOT_BW/$NB_CLT))mbit
for i in seq $NB_CLT
do
    $TC class add def $DEV parent 1: classid 1:$i htb rate $CLT_BW ceil $CLT_BW burst 15k cburst 1500
    $TC filter add dev $DEV protocol ip parent 1:0 prio 1 flowid 1:$i u32 \
     match ip dst 192.168.1.1$i/32 \
     match ip src [Router IP in LAN1]/32
done

(위의 스크립트는 완전히 테스트되지 않았으며 입력 오류가 없습니다)

이제는 매분마다 실행할 스크립트를 올바르게 스크립팅하고 새 호스트가 올라갈 때마다 버킷 / 필터를 갱신해야합니다.

나는 그것이 당신에게 올바른 방향, 행운을 가리킬 수 있기를 바랍니다.

대체 솔루션

모든 호스트에 로컬 QoS 소프트웨어를 설치하여 대역폭을 제한하십시오. 나는 개인적으로 NetLimiter를 사용합니다 (무료)


내 접근 방식의 문제는 모든 호스트가 공유를 모두 사용하지 않아도 상대방의 대역폭을 줄인다는 것입니다. 그러나 수요가 많을 때만 공유하도록하는 것을 설계하는 것은 어렵습니다.
mveroone

2

OpenWRT는 그것을 직접 사용한 적이 없지만 그것을 지원하는 것 같습니다. 웹 사이트 의 네트워크 트래픽 제어 페이지와 특히 두 번째 예인 HTB와의 단순 단순 대역폭 공유 (트래픽 형성)를 살펴볼 수 있습니다 . 여기에는 qdisc에 대한 간단한 호출이 포함되므로 모든 Linux 상자에서 수행 할 수 있습니다.


이 예제는 업로드 측에 대한 것입니다. 나는 현재 다소 유망한 것으로 보이는 Linux Advanced Routing & Traffic Control HOWTO 를 통해 나의 길을 읽고 tc있습니다. 이 모든 규칙을 이해할 수 있기를 바랍니다 . 리눅스의 트래픽 셰이퍼는 확실히 유망한 것으로 보인다.
pmdj

0

/superuser//a/1210164/257859에 설명 된 설정은 다음을 정확하게 수행합니다.

[...] 대기열은 제한된 LAN을 모든 LAN 클라이언트간에 균등하게 분배합니다 (정확한 LAN IP).


1
여러 질문에 동일한 답변을 게시하지 마십시오. 동일한 정보가 실제로 두 질문에 모두 대답하는 경우 한 질문 (보통 새로운 질문)은 다른 질문과 중복하여 닫아야합니다. 다음과 같은 방법으로이를 표시 할 수 있습니다 중복으로 닫 투표 또는, 당신이 충분한 명성을하지 않은 경우, 플래그 인상 이 중복의 것을 나타냅니다. 그렇지 않으면이 질문에 대한 답을 맞추고 동일한 대답을 여러 곳에 붙여 넣지 마십시오.
DavidPostill

@DavidPostill 중복 투표로 마감하는 것에 대해 생각했지만 3 살짜리 질문이므로 망설였습니다. meta.superuser를 검색하고 meta.superuser.com/questions/3524/…에서 관련 질문을 찾았습니다 . 메타를 읽은 후에는 상황이 복잡하다고 생각합니다 (각 질문에 대한 충분한 토론으로 두 개의 오래된 질문에 대한 답변이 있음). 짧은 포인터 답변을 남기는 것은 적어도 "나쁘지 않습니다". 그래도 당신의 생각을들을 수 있습니다.
ndemou
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.