통패킷을 보낼시 속도가 느리지만 패킷분할로 해결되는 경우가 있습니다.
단,이떼 패킷분할을 먼저 킨ㄴ뒤 vpn 연결을 하면 실패학기 떼문에 vpn연결을 먼저 해야 합니다.
즉 vpn클라서 먼저 연결한 뒤 패킷을 분활하면 될 것 같습니다.
음.. 패킷 분할이라고 하시면 IP Fragmentation 을 말씀하시는 건가요?
goodbye dpi처럼 통 패킷을 나누는것을 의미합니다.
(사실 시크릿 dns처럼 sni만 건드려도 꽤 빨라지지만요.)
음.. 무슨 말씀인지는 알겠습니다. @Haiseiko 님께서는 아래와 같은 기능을 말씀하시는 것으로 이해를 하였습니다.
다만 위의 두가지 프로그램은 보통 http://warning.or.kr/ 검열을 우회하기 위해서 사용하는 것으로 알고 있는데요, 혹시 미꾸라지를 통해서 패킷 분할을 하실 필요가 있으실까요?
검열을 우회하기 위한 것이 아니라면 보통 MTU 조절을 통해 충분히 말씀하신 분할을 자연스럽게 실행할 수 있지 않을까 합니다.
Mtu를 줄일시
프로그램등에서 생긴 각 패킷(A,B)들을 mtu에 맞춰 모아서 클라와 서버사이 통신을 위한 패킷(C)을 만들고 그걸 서버로 보내고 서버는 C를 다시 풀어 A,B 패킷을 목적지로 보낸다.
VPN 긴 후 pc에 분할을 킬시
각프로그램서 생긴 A,B 패킷은 프로그램이 a,a,b,b로 나누고 클라는 그걸로 mtu에 맞춰 패킷(C)를 서버에 보내고 서버는 C를 풀어 a,a,b,b를 목적지로 보낸다.이때 a,a,b,b는 작고 각각 망을 타고 목적지로 가기 때문에 더 빠르다.
우선 의견 주셔서 감사합니다. 말씀하신 부분은 제가 좀 더 구현 여부를 살펴보도록 하겠습니다. 아래는 제가 조금 의견을 넣었으니 참고 바랍니다.
음.. 이 부분은 사실이 아닐 가능성이 높습니다. 일단 TCP 통신이냐 UDP 통신이냐에 따라 다릅니다만, 만약 UDP 통신이면 위와 같은 현상 자체가 발생되지 않습니다. TCP 통신이면 프로그램이 보내는 payload 가 nagle algorithm 에 의해 합쳐져서 MTU 크기에 맞게 끔 패킷이 만들어져 보내지만, 프로그램이 NO_DELAY socket 옵션을 켰을 경우, 이러한 합치는 과정 자체도 발생되지 않습니다.
음.. 이 부분도 사실 case by case 로 보입니다만 @Haiseiko 님이 말씀하신 것 처럼 패킷을 잘게 자를 경우, 조금 더 packet drop 이 될 확률이 낮아지긴 할 듯 합니다. 다만 중간에 패킷 일부가 loss 가 발생되면 그것 또한 이슈가 될 가능성이 높아 보입니다.
아시다시피 보통 라우터의 경우, QoS 정책에 따라 다르겠지만 packet count 로 drop 을 할수도 혹은 packet size 로 drop 을 할수도 있는데, 크기가 큰 패킷일수도 queue bucket 을 많이 차지할 가능성이 높아 좀더 drop 이 될 가능성이 높은 것으로 알고 있습니다.
음.. 이 부분도 case by case 로 보입니다. 각각의 망을 타고 간다고 가정했을 때, 오히려 packet ordering 이 거꾸로 되어 도착하면 먼저 보낸 것이 큰 의미가 없을 수 있습니다.