Khoảng cách vật lý có ảnh hưởng đến tốc độ tải xuống không?

Tôi vừa cãi nhau với một đồng nghiệp của mình và nghĩ rằng tôi chỉ cần liên hệ với các chuyên gia về vấn đề này. Đây là kịch bản. Chúng tôi đang sử dụng một trang web đo tốc độ kết nối của bạn. Chúng tôi đã thử nghiệm bằng một máy chủ cách xa chúng tôi (Chúng tôi đang ở Malaysia và máy chủ ở Mỹ). Đó là khoảng 2 Mbps. Sau đó, chúng tôi đã thử với một máy chủ ở Singapore và nó nhanh hơn nhiều (khoảng 15 Mbps). Đồng nghiệp của tôi tin rằng đó là do khoảng cách vật lý trong khi tôi không nghĩ nó quan trọng. Sự hiểu biết của tôi là một khi bạn đã thực hiện bắt tay ban đầu và luồng dữ liệu đã bắt đầu, không quan trọng máy chủ được đặt ở đâu và kết quả sẽ gần như giống nhau. Am i thiếu cái gì ở đây? Làm thế nào nó thực sự làm việc?

Đồng nghiệp của tôi tin rằng đó là do khoảng cách vật lý trong khi tôi không nghĩ nó quan trọng. Sự hiểu biết của tôi là một khi bạn đã thực hiện bắt tay ban đầu và luồng dữ liệu đã bắt đầu, không quan trọng máy chủ được đặt ở đâu và kết quả sẽ gần như giống nhau. Am i thiếu cái gì ở đây? Làm thế nào nó thực sự làm việc?

Cả hai bạn đều đúng ở một thời điểm nào đó trong lịch sử, nhưng sự hiểu biết của bạn chủ yếu là chính xác ... ngày hôm nay :). Có một vài yếu tố thay đổi giữa câu trả lời cũ hơn mà bạn của bạn đưa ra và khả năng chúng ta có ngày hôm nay.

• Mở rộng cửa sổ TCP
• Điều chỉnh bộ đệm máy chủ

Sự khác biệt trong kết quả mà bạn thấy có thể đã bị ảnh hưởng bởi:

• Mất gói
• Chuyển giao song song TCP

TCP Window Scale: Hiệu ứng trễ băng thông

Như bạn của bạn đã đề cập, các triển khai TCP cũ hơn phải chịu các giới hạn được đặt ra bởi kích thước cửa sổ nhận 16 bit ban đầu trong tiêu đề TCP (ref RFC 793: Mục 3.1 ); RWIN kiểm soát số lượng dữ liệu chưa được xử lý có thể chờ trong một ổ cắm TCP. Giá trị RWIN 16 bit giới hạn đường dẫn internet với các sản phẩm có độ trễ băng thông cao (và nhiều kết nối internet băng thông cao ngày nay sẽ bị giới hạn bởi giá trị 16 bit).

Đối với các giá trị RTT cao, thật hữu ích khi có một RWIN rất lớn. Ví dụ: nếu đường dẫn RTT của bạn từ Malaysia đến Mỹ khoảng 200ms, TCP RWIN ban đầu sẽ giới hạn bạn ở mức 2,6Mb / giây.

Thông lượng _{tối đa} = Rcv_Win / RTT

* Thông lượng _{tối đa} = 65535 * 8 / 0.200 *

Thông lượng _{tối đa} = 2,6Mb / giây

RFC 1323 đã định nghĩa một số "Tùy chọn TCP" để khắc phục những hạn chế này; một trong những tùy chọn TCP đó là "chia tỷ lệ cửa sổ". Nó giới thiệu một hệ số tỷ lệ, nhân giá trị RWIN ban đầu, để có được giá trị cửa sổ nhận đầy đủ; sử dụng các tùy chọn chia tỷ lệ cửa sổ cho phép RWIN tối đa 1073725440 byte. Áp dụng các tính toán tương tự:

Thông lượng _{tối đa} = Rcv_Win / RTT

* Thông lượng _{tối đa} = 1073725440 * 8 / 0.200 *

Thông lượng _{tối đa} = 42,96Gbps

Hãy nhớ rằng TCP tăng RWIN dần dần trong suốt thời gian chuyển, miễn là mất gói không phải là vấn đề. Để xem tốc độ truyền thực sự lớn qua kết nối có độ trễ cao, bạn phải chuyển một tệp lớn (để TCP có thời gian tăng cửa sổ) và mất gói không thể là vấn đề đối với kết nối.

Mất gói

Đôi khi các mạng Internet trên Thái Bình Dương bị tắc nghẽn. Một số gia đình tôi sống ở Đài Loan và chúng tôi thường xuyên gặp phải các vấn đề khi chúng tôi sử dụng Google Talk với họ. Tôi thường thấy mất gói hơn 0,5% khi tôi ping đường DSL của họ từ Mỹ; nếu bạn thấy bất cứ thứ gì như mất 0,5% cho máy chủ "chậm hơn", rất dễ dàng sẽ hạn chế thông lượng trên một ổ cắm TCP.

Các luồng TCP song song

FYI, một số trang web kiểm tra tốc độ sử dụng các luồng TCP song song để tăng thông lượng ; điều này có thể ảnh hưởng đến kết quả mà bạn thấy, bởi vì các luồng TCP song song làm tăng đáng kể thông lượng trong trường hợp bạn có một số mất gói trong đường dẫn. Tôi đã thấy bốn luồng TCP song song bão hòa hoàn toàn một modem cáp 5Mbps bị mất gói 1% liên tục. Thông thường, mất 1% sẽ làm giảm thông lượng của một luồng TCP.

Phần thưởng: Điều chỉnh bộ đệm máy chủ

Nhiều triển khai hệ điều hành cũ hơn có ổ cắm với bộ đệm hạn chế; với hệ điều hành cũ hơn (như Windows 2000), việc TCP có cho phép một lượng lớn dữ liệu trong chuyến bay hay không ... bộ đệm ổ cắm của chúng không được điều chỉnh để tận dụng lợi thế của RWIN lớn. Đã có rất nhiều nghiên cứu được thực hiện để cho phép hiệu suất cao khi chuyển TCP . Các hệ điều hành hiện đại (đối với câu trả lời này, chúng ta có thể gọi Windows Vista và sau này là "hiện đại") bao gồm các cơ chế phân bổ bộ đệm tốt hơn trong việc triển khai bộ đệm ổ cắm của chúng.

Câu trả lời ngắn: Có, khoảng cách có ảnh hưởng đến băng thông luồng đơn.

Internet đã phát triển các phương tiện để hạn chế hiệu ứng đó ... trì hoãn ACK, mở rộng cửa sổ, các giao thức khác :-) Nhưng cuối cùng vật lý vẫn chiến thắng. Trong trường hợp này, nhiều khả năng là tắc nghẽn mạng chung qua rất nhiều bước nhảy - chỉ mất một gói bị rơi để giết luồng TCP.

Mặc dù đã có câu trả lời tuyệt vời cho vấn đề này, tôi muốn thêm: không, tốc độ không nhất thiết bị ảnh hưởng bởi khoảng cách và vâng, rất thường xuyên tốc độ bị ảnh hưởng bởi khoảng cách đều đúng.

Tại sao vậy?

Đơn giản hóa mạnh mẽ, khoảng cách càng dài, càng có nhiều "bước nhảy" liên quan đến con đường thông qua Internet. Băng thông tối đa được xác định bởi lưu lượng truy cập hop và đồng thời chậm nhất. Với khoảng cách ngày càng tăng và sự phân phối ngẫu nhiên của tốc độ hop, xác suất để có được tốc độ tổng thể chậm hơn đang tăng lên. Ngoài ra, vật lý cản trở và tăng độ trễ cũng có thể làm chậm liên kết.

Nhưng điều này không được coi là đương nhiên. Công nghệ cho phép chúng ta xây dựng một kết nối bao gồm hành tinh với gần như bất kỳ băng thông mong muốn nào. Tuy nhiên, băng thông và khoảng cách là kẻ thù và cả hai đều làm tăng đáng kể chi phí kết nối, một lần nữa khiến nó ít có khả năng tồn tại chỉ cho kết nối bạn có thể cần ngay bây giờ.

Tất nhiên, điều này là quá đơn giản nhưng trong thực tế, tình huống này là những gì bạn rất thường tìm thấy. Và một lần nữa, bạn không nên khi có một kết nối nhanh đáng kinh ngạc hoặc một proxy phân phối ở ngay gần đó - nhưng khi mọi thứ ngay lập tức chúng ta hiếm khi nghĩ về tốc độ của Internet ...

Theo Andrew Martin câu trả lời là có