편집 : 처음에는 이것이 얼마나 많은 브라우저 탭을 열어 놓을 지의 함수라고 생각했기 때문에 TCP / IP 스택의 "정상적인"기능으로 인해 새로운 TCP 연결의 속도 제한이 발생했습니다 사용 가능한 임시 포트의 수). 하지만 원래 게시물을 다시 읽고 SYN_SENT 연결이 쌓여 있다고 말한 것으로 나타났습니다. 즉, 한 번에 많은 연결을 생성 할 수 있도록 관리하고 있습니다. 나는 원래의 대답에 대한 옛 텍스트를 그대로 남겨 둘 것이다. (만약 내가 몇 시간을 보냈다는 것 외에 다른 이유가 없다면 꽤 흥미 롭다.)하지만 나는 독자가 좌절하지 않도록이 편집을 처음부터 추가하고 싶다. 내 게시물의 끝 라우터 제한을 다루고, 나는 이것이 문제라고 생각한다. 다른 인터넷 연결 (예 : iPhone의 개인 핫스팟을 사용하는 3G)에서 동일한 테스트를 시도 할 수 있습니다.
원본 게시물 ...
방금 실험을했습니다. Chrome의 개발자 도구 창을 사용하여 www.ft.com을로드하는 동안 페이지로드를 모니터링했습니다. 그런 다음 개발자 도구 창의 네트워크 탭에있는 모든 단일 행을 검토하고 www.ft.com의 기본 페이지를로드 할 때 액세스 한 각 고유 호스트 / 서버를 직접 복사했습니다. 총 71 개의 고유 한 서버에 액세스했습니다.
ft.com
s1.ft-static.com
navigation.webservices.ft.com
s4.media.ft.com
s2.ft-static.com
im.ft-static.com
www.googleadservices.com
www.ft-static.com
amch.questionmarket.com
reg.ft-static.com
service.maxymiser.net
personalisation.ft.com
pong.qubitproducts.com
track.ft.com
stats.ft.com
www.googletagservices.com
js.revsci.net
cdn.krxd.net
partner.googleadservices.com
admin.brightcove.com
mostpopular.sp.ft-static.com
googleads.g.doubleclick.net
fastft.ftdata.co.uk
widget-cdn.rpxnow.com
static.chartbeat.com
pubads.g.doubleclick.net
www.google.com
4235225.fls.doubleclick.net
ads.rubiconproject.com
ping.chartbeat.net
pagead2.googlesyndication.com
c.brightcove.com
ads.revsci.net
media.ft.com
pix04.revsci.net
beacon.krxd.net
secure.fastclick.net
leadback.advertising.com
ib.adnxs.com
api.adsymptotic.com
optimized-by.rubiconproject.com
cdn.quilt.janrain.com
s1.test.ft-static.com
www.facebook.com
b.scorecardresearch.com
tap2-cdn.rubiconproject.com
b.scorecardresearch.com
im.test.ft-static.com
clamo.ftdata.co.uk
assets.rubiconproject.com
tap.rubiconproject.com
x.bidswitch.net
rp.gwallet.com
rc.d.chango.com
i.w55c.net
tags.bluekai.com
rbp.mxptint.net
ads.p161.net
magnetic.t.domdex.com
ads.mediade.sk
ad.turn.com
video.ft.com
pool.adizio.com
cdn.trn.com
p.brilig.com
s.ixiaa.com
api.bizographics.com
metrics.brightcove.com
goku.brightcove.com
www.google-analytics.com
brightcove.vo.llnwd.net
그것은 더 나 빠지게된다! 이러한 호스트 중 많은 수가 여러 번 액세스했지만 웹 브라우저 (또는 OS)가 TCP 연결을 수 초 동안 열어 두어 재사용 할만큼 지능적이라고 가정합니다. 사용 lsof -n -p 8420 | grep -c "IPv4" (Chrome은 PID 8420을 사용하고 있으며 크롬에서는 다른 페이지가 열려 있지 않으며 캐시를 완전히 지웠고 사전에 AdBlock을 사용 중지했습니다.) 페이지를 새로 고침하는 동안, 나는 간단히 lsof 명령을 반복적으로 사용하여 위의 파이프로 grep 나에게 셀 수 :
$ lsof -n -p 8420 | grep -c "IPv4"
42
$ lsof -n -p 8420 | grep -c "IPv4"
64
$ lsof -n -p 8420 | grep -c "IPv4"
75
$ lsof -n -p 8420 | grep -c "IPv4"
85
$ lsof -n -p 8420 | grep -c "IPv4"
111
$ lsof -n -p 8420 | grep -c "IPv4"
129
$ lsof -n -p 8420 | grep -c "IPv4"
127
$ lsof -n -p 8420 | grep -c "IPv4"
128
$ lsof -n -p 8420 | grep -c "IPv4"
129
$ lsof -n -p 8420 | grep -c "IPv4"
128
$ lsof -n -p 8420 | grep -c "IPv4"
128
$
보시다시피 하나의 웹 페이지를로드하면 최대 129 개의 TCP 연결이 발생합니다. CLOSE_WAIT와 같은 ESTABLISHED 또는 CLOSE_WAIT와 같은 닫는 상태와 관계가 없습니다. 해당 포트는 사용할 수 없으므로 기본적으로 풀에 반환되는 데 60-480 초가 걸릴 것입니다 (RFC793 원래 지정됨). MSL (Max Segment Lifetime)은 4 분이지만 요즘은 60-120 초가 기본값이라고 생각합니다. Windows XP 및 Vista에는 기본적으로 사용 가능한 임시 포트가 수천 개 밖에 없었으므로 사용 가능한 포트가 부족해지기 쉽습니다. * 처음부터 알 수 있듯이 lsof 실행, 내 시스템은 이미 42 개의 연결을 열었으므로이 웹 페이지는 87 개의 새로운 연결을 열었습니다. 나는 다른 애플 리케이션 (이메일 클라이언트 등)이 테스트 중에 그 숫자를 일시적으로 늘리지 않았는지 확인하기 위해 두 번 실행했다.
다른 한계도 있습니다. Windows에서이 문제를 조사 할 시간이 없었기 때문에 여기서는 Linux에 대해서만 말할 수 있습니다. (이미이 문제를 조사하는데 몇 시간을 소비 했으므로 먹어야합니다!) ... Linux (및 OSX)에는 최대 파일 디스크립터 수가 제한되어 있습니다 당 프로세스가 있으며 그 제한은 몇 곳에서 설정됩니다. 한계는 256입니다. 일부 웹 브라우저는 탭 당 하나의 프로세스를 시작하므로이 벽을 치는 지 확신 할 수 없지만 한계를 변경하고 다시 테스트하기가 쉽습니다. "ulimit max file descriptors"와 "launchctl maxfiles"에 대해 Google이 설정되어있는 곳을 찾습니다. 또한 보아라. 이 Stackoverflow 게시물 .
내 OSX 이전 날부터 Windows XP가 새로운 TCP 연결을 만드는 데 속도 제한을 가지고 있음을 안다. 이것은 Sasser와 같은 웜의 확산을 줄이기 위해 얼마나 빨리 새 TCP 연결을 만들 수 있는지 제한함으로써 OS 자원을 삼켜 버리는 것을 방지하기위한 것이 었습니다. 새로운 TCP 연결마다 일반적으로 OS에 의해 사전 할당 된 자원이 필요합니다 부팅 중 (TCP 연결이 열리거나 닫힐 때마다 버퍼를 할당 / 제거하는 데 시간이 오래 걸리므로 OS가 연결 테이블을 미리 작성합니다). Torrent 클라이언트의 구성 페이지 (예 : 전송)를 보면 새로운 TCP 연결에 대한 기본 전역 제한은 120이며, 토런트 제한은 60입니다. 사용자 설명서는 120을 고수 할 것을 권장합니다. 내 웹 브라우징 성능은 200-240을 말하는 것으로 설정하면 실제로 다이빙을합니다. 실제로 TCP의 MSL은 TCP 포트에 대해 걸리는 시간을 실제로 제한합니다. TIME_WAIT 수영장으로 돌려 보내야합니다.
내 직감은 각 브라우저 탭이 많은 새로운 TCP 연결을 만들고, 한꺼번에 15 개의 탭을로드함으로써 OS가 많은 TCP 연결을 모두 열도록 요청한다는 사실로 인해 제한되고 있다고합니다. 동시에. 테스트를 다시 실행할 때 테스트 실행 사이에 적어도 4 분을 기다렸다가 사용하십시오 netstat -n -p tcp (Windows에서 그냥 사용 netstat -no ). * nix를 사용하는 경우 lsof -n -i | grep -c 사전에 컴퓨터가 이미 열려있는 연결 수를 확인하십시오.
잠시 ... 라우터 / 게이트웨이를 확인하십시오. 이전에 BusyBox 기반 ADSL 라우터 중 최대 1024 개의 동시 TCP 연결 (모든 상태, 즉 established, close_wait, etC)이있는 ADSL 라우터를 많이 보았습니다. P2P 다운로드를 실행하는 한 클라이언트가 라우터를 완전히 멈추게 할만큼 충분했습니다. 증상은 설명대로 정확하게 나타 났지만 하나의 웹 페이지를로드하려고 시도 했더라도. 1024 연결은 p2p로 몇 분 안에 먹을 수 있습니다. 왜냐하면 4 분 안에 1024 개의 연결을 열고 닫을 수 있고 새로운 연결을 허용하지 않기 때문입니다. 일반적인 불만은 "느린 다운로드 속도 제한으로도 eMule을 실행할 때 내 집에있는 모든 사람들이 인터넷이 거의 사용할 수 없게된다는 불평입니다"라고 불평합니다. 가정용 인터넷 라우터가 TCP 연결에 관한 정보를 제공하는 이유는 거의 항상 NAT / PAT를 실행하고 종종 모든 연결을 추적해야하는 상태 저장 / SPI 방화벽이 있기 때문입니다. 즉, 지난 몇 년 동안 만든 라우터가이를 처리하는 것이 더 낫습니다.
희망이 도움이됩니다.