속도 제한 수신 트래픽

들어오는 트래픽의 속도를 제한 할 수 있는지 여부를 전혀 이해하지 못했습니다 . 원격 서버의 패킷 전송 속도를 제어하는 직접적인 방법 이 없다는 것을 알고 있지만 (두 끝점을 모두 제어하지 않는 한)이 제한 사항을 고려하면 다운로드 관리자가 정확하게 다운로드 속도 제한을 설정하는 방법 ?

TCP 느린 시작 과 속도 제한 수신 트래픽 사이에 링크가 있습니까? 보낸 사람의 패킷 전송 속도를 인위적으로 제한하기 위해 slow-start에 설명 된 방법을 사용할 수 있습니까?

추가 고려 사항으로, 트래픽 형성을 구현하려는 서버는 PPPoE 연결 자체를 설정하고 나머지 네트워크의 라우터 역할을합니다.

업데이트 : 지금까지 답변은 내가 요청한 질문에 대한 공정한 개요를 제공했지만 다운로드 관리자가 들어오는 트래픽을 제한하는 방법, 특히 더 유사한 방법으로 유사한 전략을 구현할 수 있는지 여부는 여전히 알지 못합니다. 리눅스 게이트웨이 박스.

다운로드 관리자는 간지에 설명 된대로 작동 합니다 .

BSD 소켓을 사용하는 프로세스는 자체 속도 제한을 수행 할 수 있습니다. 업스트림 제한의 경우 응용 프로그램은 소켓에 기록되는 데이터 속도를 간단히 제한하여이를 수행 할 수 있습니다. 마찬가지로 다운 스트림 제한의 경우 응용 프로그램은 소켓에서 읽는 데이터 속도를 제한 할 수 있습니다. 그러나 이것이 작동하는 이유는 즉시 분명하지 않습니다. 응용 프로그램이 소켓에서 일부 데이터를 읽지 않으면 소켓 수신 버퍼가 채워집니다. 그러면 수신 TCP가 더 작은 수신자 창 (rwnd)을 알리고 기본 TCP 연결에 대한 압력이 발생하여 데이터 흐름이 제한됩니다. 결국이 "세속 효과"효과는 종단 간 속도 제한을 달성합니다. 네트워크 스택의 모든 계층에서 버퍼링에 따라이 효과가 전파되는 데 시간이 걸릴 수 있습니다.

가끔 UNIX 시스템에서 속도 제한에 하나의 프로그램이 필요하면 간단한 솔루션입니다 물방울 . 게이트웨이에서 수행하는 것처럼 실제 트래픽 형성은으로 수행 할 수 있습니다 tc. 이것은 9 장 . 리눅스 고급 라우팅 및 트래픽 제어 하우투의 대역폭 관리 를 위한 큐잉 규율에 설명되어있다 .

56k 모뎀 대 4 Mbps DSl 라인의 경우 속도 차이를 만드는 (일반적으로) 형성이 없으며 링크 속도의 차이 일뿐입니다.

들어오는 트래픽을 구체화하기 어려운 이유는 전송 매체에 버퍼가 없기 때문입니다. 수신 비트를 수락하거나 손실됩니다. 트래픽 taht가 인터페이스를 떠나려고하는 경우 원하는만큼 (또는 최소한 장치에서 사용 가능한 버퍼 메모리까지) 패킷을 버퍼링하고 순서를 변경할 수 있습니다.

TCP 위에 레이어가있는 프로토콜의 경우 (토렌트의 경우인지 모르겠습니다) 추가 데이터에 대한 요청을 페이싱하는 간단한 문제 일 것입니다. 그렇지 않으면 응용 프로그램이 OS와 통신하여 패킷 ACK를 지연시켜야합니다. 대부분의 UDP 기반 프로토콜은 필요에 따라 앱별 프로토콜에 ACK / 재전송 로직이 있으므로, 그 시점에서 속도를 맞추기 위해 사소한 경계가 설정됩니다.

하나의 가능한 경로는 DSL 라우터의 LAN 쪽에서 인터넷의 트래픽을 형성하는 것입니다.이 시점에서 송신 포트를 형성 할 것입니다.

수신 데이터를 형성 할 수있는 솔루션을 찾지 못한 이유 (그리고 머리 꼭대기를 모르는)를 찾지 못했지만 발신자가 수신자가 데이터를 얼마나 빨리받을 수 있는지 알 수 있습니다.

TCP / IP의 기본 설계는 소스가 대상으로 전송하는 모든 패킷에 대해 대상 ACK이 패킷을 수신했다는 응답을 패킷 과 함께 회신 할 때까지 기다려야 한다는 것입니다.

따라서 4Mbps 발신자와 56Kbps 수신자가있는 경우, 발신자는 수신자가 각 패킷에 응답하기 위해 패킷을 송신하는 사이에 대기해야합니다 (이 오버 헤드를 줄이기위한 기술적 세부 사항이 있지만 전제는 여전히 요약을 유지합니다) 수평).

발신자가 이미 56Kbps의 데이터를 전송 한 다음 조금 더 보내려고하면 어떻게됩니까?

패킷이 손실됩니다. (글쎄, 잠재적으로 스위치의 버퍼에 대기 중이지만 채워질 때 패킷이 손실됩니다). 패킷이 손실되었다 때문에, 수신기는 수신하지, 그리고 따라서 전송하지 ACK패킷. 보낸 사람은이 ACK패킷을받지 못하기 때문에 (전송되지 않았지만 손실되거나 네트워크 중단이 발생할 수 있기 때문에) 추가 패킷 을 다시 보내야합니다 . 패킷이 도착하고 ACK응답이 다시 돌아올 때까지 패킷을 다시 보내려고 시도 합니다.

요약하자면, 발신자가 수신자의 대역폭을 최대한 활용 한 후에는 통과 할 수있는 충분한 대역폭이 확보 될 때까지 다음 패킷을 계속 반복해서 다시 보내야합니다. 이렇게하면 클라이언트가받을 수있는 최대 속도로 전송 속도가 효과적으로 줄어 듭니다. (이 경우 패킷을 다시 보내야하는 횟수를 줄이는 최적화 방법이 있습니다. 기본적으로 발신자는 패킷을 다시 보내야 할 때마다 속도가 느려지지만이 간단한 설명의 범위를 벗어납니다.

ifb 인터페이스로 할 수 있습니다.

ifb 인터페이스를 사용하면 eth0 (또는 기타)의 수신 흐름을 ifb0 (예 :)의 송신으로 라우팅하고 제한 규칙을 적용 할 수 있습니다.

Linux Foundation의이 URL을 확인하십시오. http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

그리고이 스크립트는 수신 및 수신 대역폭을 제한합니다 : https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

wondershaper를 확인하십시오 : http://lartc.org/wondershaper/

들어오는 트래픽과 관련하여 :

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

UFW (복잡한 방화벽) 사용 http://ubuntuforums.org/showthread.php?t=1260812

이 스레드는 기본적으로 30 초 내에 6 번의 적중이 IP로 거부되는 간단한 예를 보여줍니다.

sudo ufw limit ssh/tcp

또한 시간 및 적중 횟수에 대해 지정된 값을 가진 더 '고급'명령

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP