현재 위치

홈 ›› Forums ›› 이슈 ›› 뉴스, 새소식

인터넷 속도 최고 1만배 갱신

mobigo의 이미지
글쓴이: mobigo / 작성시간: 목, 2004/04/22 - 8:55오후

현재 일반 가정에 설치된 광대역 통신망을 통해 데이터를 전송하는 것보다 약 1만배 이상 빠른 데이터 전송실험이 성공적으로 이뤄졌다.

　C넷에 따르면 인터넷 관련 컨소시엄인 ‘인터넷 2’는 로스앤젤레스와 제네바 사이의 대략 1만1000㎞ 구간에서 ‘인터넷2’의 초고속 백본망을 활용해 평균 초당 6.25Gb의 속도로 데이터를 전송하는 데 성공했다고 발표했다.

　이번 테스트에는 캘리포니아 기술연구소(Caltech)와 제네바 유럽입자물리학연구소(CERN)가 공동으로 참여했으며 실험 과정에는 현재 인터넷 주소체계인 IPv4가 사용됐다.이 팀은 이미 차세대 인터넷 프로토콜인 IPv6를 같은 지역에서 초당 4Gb 속도로 테스트한 바 있다.

　‘인터넷2’ 컨소시엄에는 차세대 인터넷 기술을 개발하기 위해 각국 정부와 산업계, 전세계 200여개 대학들이 공동으로 참여하고 있다. 현재 이 컨소시엄내 그룹들이 많은 양의 데이터를 효과적으로 공유할 수 있도록 초고속 그리드를 개발하고 있다.

<이병희기자 shake@etnews.co.kr>

Forums: 
뉴스, 새소식
박영선의 이미지

글쓴이: 박영선 / 작성시간: 일, 2004/04/25 - 10:50오후

DWDM쓰면 몇백기가까지 전송가능하다고 하던데 6기가면 적은거 아닌가요?

설마 전화선을 통해서 6기가를 전송한건 아닐것같구요...

^^;;

ysch0i의 이미지

글쓴이: ysch0i / 작성시간: 월, 2004/04/26 - 2:31오전

칼텍에서 실험했다는걸 보니깐 Fast라는 프로젝트 일환인것 같은데

현재 TCP는 TCP 자체의 한계로 TCP 파라미터를 튜닝 하더라도(물론 컴퓨터 하드웨어 병목이 없다구 하더라도) 속도의 제한이 있습니다.

글은 아마 안읽어봤지만 Fast 프로젝트일환이라면 TCP 자체를 바꾸어서 하나의 연결이 그정도의 속도가 나오게 했다는 것일겁니다.

서명없어요.

Necromancer의 이미지

글쓴이: Necromancer / 작성시간: 월, 2004/04/26 - 8:37오전

아마 packet reassembling, Window Size와 관련이 있을듯 하네요.
현재 TCP에서는 Window의 크기가 64k이고, 또 수신자는 receive한 지점에
대해서 반드시 ack를 보내게 되어 있는데(안보냈으면 오류로 간주),

저속에서는 64k 다 보내기 전에 receive한 지점에 대한 ack가 들어오지만
고속으로 가다보면 receive한 지점에 대한 ack가 들어오기 전에 64k를
다 보내버리고도 시간이 남죠. 그러면 송신하는 쪽은 놀 수밖에 없고
그나마 64k란 것도 TCP 상에서 정한 최대크기를
가정한 거고 실제로는 상대방의 수신 버퍼 크기에 제약을 받으니.

ysch0i wrote:
칼텍에서 실험했다는걸 보니깐 Fast라는 프로젝트 일환인것 같은데

현재 TCP는 TCP 자체의 한계로 TCP 파라미터를 튜닝 하더라도(물론 컴퓨터 하드웨어 병목이 없다구 하더라도) 속도의 제한이 있습니다.

글은 아마 안읽어봤지만 Fast 프로젝트일환이라면 TCP 자체를 바꾸어서 하나의 연결이 그정도의 속도가 나오게 했다는 것일겁니다.

Written By the Black Knight of Destruction

cdpark의 이미지

글쓴이: cdpark / 작성시간: 월, 2004/04/26 - 6:07오후

mobigo wrote:
현재 일반 가정에 설치된 광대역 통신망을 통해 데이터를 전송하는 것보다 약 1만배 이상 빠른 데이터 전송실험이 성공적으로 이뤄졌다.

　C넷에 따르면 인터넷 관련 컨소시엄인 ‘인터넷 2’는 로스앤젤레스와 제네바 사이의 대략 1만1000㎞ 구간에서 ‘인터넷2’의 초고속 백본망을 활용해 평균 초당 6.25Gb의 속도로 데이터를 전송하는 데 성공했다고 발표했다.

광대역 통신망이 6.25Gb/s 보다 1만배 느리다는 뜻이니... 625kb/s 겠군요. 한국의 일반가정 기준은 아닌 듯.. :)

Prentice의 이미지

글쓴이: Prentice / 작성시간: 월, 2004/04/26 - 6:16오후

비트와 바이트 단위 환산을 안하셨네요.. ^^; 8로 나눠보시면.. 78.125가 나옵니다.

http://ultralight.caltech.edu/lsr/

실제로 여길 보시면 498587545600 바이트를 보내는 데에 638.740초가 걸렸다고 나옵니다. 약 780579806Bps이고, 8을 곱해보면 약 6244638451bps이니까, 대충 맞아떨어지죠?

저희 집 업로드 속도가 잘 나올 때 85000Bps이니까 약 9183배 빠른 것 같습니다.

ysch0i의 이미지

글쓴이: ysch0i / 작성시간: 화, 2004/04/27 - 2:23오후

흑기사 wrote:
아마 packet reassembling, Window Size와 관련이 있을듯 하네요.
현재 TCP에서는 Window의 크기가 64k이고, 또 수신자는 receive한 지점에
대해서 반드시 ack를 보내게 되어 있는데(안보냈으면 오류로 간주),

저속에서는 64k 다 보내기 전에 receive한 지점에 대한 ack가 들어오지만
고속으로 가다보면 receive한 지점에 대한 ack가 들어오기 전에 64k를
다 보내버리고도 시간이 남죠. 그러면 송신하는 쪽은 놀 수밖에 없고
그나마 64k란 것도 TCP 상에서 정한 최대크기를
가정한 거고 실제로는 상대방의 수신 버퍼 크기에 제약을 받으니.

정확하게 말씀드리자면... 말씀하신 Window Size는 제가 언급한 TCP 튜닝에 관련된 것이구요, 그렇게 하더라도 TCP의 구조적인 문제상 속도가 나오지 않게 되어있습니다.

제가 알기론 packet reassembling은 FAST는 관련이 없을껍니다..

음... 간단히 말씀드리면 TCP의 전송 속도는 RTT동안 패킷 손실이 발생하지 않으면 다음 RTT에는 전송율을 아주 조금~올리게 되어있습니다.

즉, 손실 기반의 Window Control인데요,

FAST는 Delay based congestion control이라고... RTT와 이제껏 측정된 최소 RTT의 비를 통해서 윈도우 크기를 확~~ 올리거나 확~~~ 내릴수있습니다. 이제까지 우리가 사용하던 TCP와는 많이 다른 개념이죠.

따라서 링크 속도가 얼마가 되던지간에 이론적으로 매우 stable한 프로토콜이라고 저자가 그러더군요.

물론 FAST를 사용하더라도 TCP 튜닝은 해주는것으로 기억이 납니다.

물론 FAST말고도 이러한 시도가 몇군데 더 이루어지고 있는데요....

자세한 것은 web100, net100 프로젝트를...

http://www-iepm.slac.stanford.edu/bw/tcp-eval/

서명없어요.

cjh의 이미지

글쓴이: cjh / 작성시간: 수, 2004/04/28 - 10:48오전

많은 OS(윈도우 2000, XP, Linux, *BSD etc..)에서는 RFC1323을 구현하고 있는데, 이 방식을 쓰면 TCP에서 64k 이상의 윈도우로 보낼 수 있습니다. 보통 윈도용 TCP 스택 최적화 프로그램이 이 설정을 이용하고 있습니다. 그외 요즘 TCP 스택에는 SACK, FACK등을 통해서 고속 네트워크에서의 패킷 손실이나 시간 지연 문제 등을 보완하고 있습니다. 대부분의 OS에서는 이미 구현되어 있고요...

흑기사 wrote:
아마 packet reassembling, Window Size와 관련이 있을듯 하네요.
현재 TCP에서는 Window의 크기가 64k이고, 또 수신자는 receive한 지점에
대해서 반드시 ack를 보내게 되어 있는데(안보냈으면 오류로 간주),

저속에서는 64k 다 보내기 전에 receive한 지점에 대한 ack가 들어오지만
고속으로 가다보면 receive한 지점에 대한 ack가 들어오기 전에 64k를
다 보내버리고도 시간이 남죠. 그러면 송신하는 쪽은 놀 수밖에 없고
그나마 64k란 것도 TCP 상에서 정한 최대크기를
가정한 거고 실제로는 상대방의 수신 버퍼 크기에 제약을 받으니.

ysch0i wrote:
칼텍에서 실험했다는걸 보니깐 Fast라는 프로젝트 일환인것 같은데

현재 TCP는 TCP 자체의 한계로 TCP 파라미터를 튜닝 하더라도(물론 컴퓨터 하드웨어 병목이 없다구 하더라도) 속도의 제한이 있습니다.

글은 아마 안읽어봤지만 Fast 프로젝트일환이라면 TCP 자체를 바꾸어서 하나의 연결이 그정도의 속도가 나오게 했다는 것일겁니다.

--
익스펙토 페트로눔

Prentice의 이미지

글쓴이: Prentice / 작성시간: 화, 2004/05/04 - 9:19오전

/.에 떴네요.

http://proj.sunet.se/LSR2/

이번에 "Internet2 Land Speed" 세계기록이 깨졌다고 합니다. 전송률뿐만 아니라 전송거리까지도 비교대상이 되는 비교방식이라고 하네요.

mackie의 이미지

글쓴이: mackie / 작성시간: 화, 2004/05/04 - 9:49오전

실제 이런 환경이 오게 된다면..
신종 바이러스가 나오면 백신이 업데이트될 여유도 없이 바로 바이러스에 감염되지 않을까요?
전파속도도 걷잡을 수 없어질테고.. :(

ironiris의 이미지

글쓴이: ironiris / 작성시간: 화, 2004/05/04 - 10:18오전

mackie wrote:
실제 이런 환경이 오게 된다면..
신종 바이러스가 나오면 백신이 업데이트될 여유도 없이 바로 바이러스에 감염되지 않을까요?
전파속도도 걷잡을 수 없어질테고.. :(

바이러스나 웜 문제는 컴퓨터들이 얼마나 빨리 응답을 하느냐 문제지요.
네트워크 전송속도 문제는 둘째 문제..
고등학교때 배우죠? 반응속도 결정식...이라고..
바이러스 전파의 속도 결정요인은 얼마나 빨리 구멍난 컴퓨터를 찾느냐죠.. :)

둘러보기