Linux Slow Start: Thay đổi tuyến ip không có bất kỳ ảnh hưởng nào đến cửa sổ ban đầu


10

Tôi đã thay đổi cửa sổ ban đầu tcp trong máy của mình thành 10 như hình dưới đây

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 

Và thay đổi tcp_slow_start_after_idlenhư hình dưới đây

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

một xác nhận lộ trình ip được đưa ra dưới đây

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

Bây giờ khi tôi thực hiện một tcpdump trên trang web, tôi dường như không thấy sự thay đổi trong cửa sổ ban đầu với WIN / MSS còn lại4 mặc định. 5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

Lần truy cập curl tôi đã làm cho trang web yêu cầu khoảng 30 KB dữ liệu.

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

Điều gì có thể sai trong cách tiếp cận của tôi?

Hạt nhân

[user~]$ uname -r
3.0.4x86_64-linode21

Là một bản cập nhật, đây là kết quả khi tôi dùng thử google.com

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

Như bạn có thể thấy WIN / MSS là 14600/1460 = 10 trong trường hợp này

Tôi đã thử đánh trang web của mình từ chính máy chủ thông qua curl và đây là kết quả:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

THẮNG / MSS là 32792/1696 = 2 trong trường hợp này


Hãy nhớ rằng, nếu bạn đang nhấn nó từ máy linux, bạn cũng sẽ cần phải có trên 3.0, sẽ tìm hiểu kỹ về nguồn / thẻ để xác nhận phiên bản 3 chính xác bắt nguồn thay đổi
Sam Saffron

@QuintinPar Bạn có thể thêm đầu ra tcpdump với kết nối đi từ máy thử nghiệm của mình không?
kupson

@kupson Tôi đã cập nhật câu hỏi
Quintin Par

Theo tôi biết bạn không thể ảnh hưởng đến Cửa sổ ban đầu trên các kết nối đến. Kết nối của bạn với google cho thấy rằng bạn đã đặt IW thành 10. Inferface khá đặc biệt với MTU lớn đó, có thể có một số giới hạn trên Cửa sổ ban đầu trong nguồn kernel.
kupson

Hãy ghi nhớ, 2 điều sẽ quyết định IW. Cửa sổ tắc nghẽn tối đa ban đầu của khách hàng và Máy chủ IW. Những chiến thắng nhỏ hơn. Chạy thử nghiệm từ 2 máy, máy chủ nên đặt IW theo mặc định trong 3.0 ... và các máy khách XP / Vista / Win7 không hạn chế IW để tạo ra các máy khách tốt cho thử nghiệm. Máy khách Linux 3.0 cũng hoạt động, nhưng phải là một máy riêng biệt.
Sam Saffron

Câu trả lời:


9

Tôi nghĩ bạn đang hiểu sai về cách thức hoạt động của TCP.

Mỗi gói được gửi sẽ luôn quảng cáo một cửa sổ nhận (hay còn gọi là RWIN) và hệ số tỷ lệ tùy chọn, xem RFC 1323

Người gửi không được phép gửi nhiều hơn lượng dữ liệu được chỉ định trong RWIN mà không được xác nhận. Tùy thuộc vào cửa sổ tắc nghẽn, người gửi có thể quyết định điền vào RWIN hay không.

Vì vậy, có hai bit thông tin được công khai trong các gói TCP. RWIN trên Máy chủ và RWIN trên máy khách. Cả hai hình này cho biết kích thước tối đa của cửa sổ tắc nghẽn có thể ở cả hai đầu.

RWIN trên máy chủ rất thú vị khi chúng tôi đang cố gắng tối ưu hóa hiệu suất để tải lên tệp.

RWIN trên máy khách rất thú vị khi chúng tôi đang cố gắng xác định tốc độ tải xuống.

Cả hai con số này làm cho cửa sổ tắc nghẽn ở đầu kia công khai .

Vì vậy, nếu tôi có RWIN là 64k, cửa sổ tắc nghẽn trên máy chủ có thể BẤT K number số nào thấp hơn 64k.

Cách duy nhất để xác định cửa sổ tắc nghẽn thực tế là gì để đếm các gói.

Nếu tôi biết:

  1. Thời gian khứ hồi của tôi (RTT) là ~ 200ms.
  2. Tôi chỉ yêu cầu một tài nguyên là 100k.
  3. Tôi có RWIN là 64k.

Nếu tôi nhận được 2 gói trở lại từ máy chủ dài 1452 byte trong vòng ~ 200ms, có khả năng cửa sổ tắc nghẽn trên máy chủ nhỏ hơn 4356, vì nếu 3 gói lớn hơn sẽ được gửi. Nếu IW được đặt thành 10, tôi sẽ thấy một loạt 10 gói xung quanh mốc 200ms.

Nếu bạn thay đổi IW của mình và muốn xác nhận thay đổi đã hoạt động, bạn cần đếm các gói để có ước tính về kích thước cửa sổ tắc nghẽn trên máy chủ.

Hãy nhớ rằng, bạn có thể muốn xem xét cuộc trò chuyện trực tiếp sau khi SYN, SYN-ACK, ACK để đảm bảo bạn không nhìn vào giữa cuộc hội thoại (nơi cửa sổ tắc nghẽn có thể đã phát triển).


1
Sự khác biệt giữa cửa sổ tắc nghẽn và cửa sổ tcp được nêu trong 20.6 (bắt đầu chậm) của TCP / IP Illustrated: "Slow start thêm một cửa sổ khác vào TCP của người gửi: cửa sổ tắc nghẽn, được gọi là cwnd" (in đậm là của tôi). Có một sơ đồ trình tự trong 20.7 cho thấy điều này khi chơi trong khi chuyển số lượng lớn.
Kyle Brandt

7

Kích thước cửa sổ sẽ nhỏ hơn: kích thước cửa sổ máy chủ hoặc máy khách RWIN. Vì 5840 là RWIN mặc định cho Linux 2.6, có vẻ như máy khách của bạn là yếu tố giới hạn ở đây.

Hãy thử từ một hộp cửa sổ. Windows XP có RWIN là 64k, phiên bản mới hơn 8k.

Nguồn: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (Phần thú vị nằm bên dưới video)

Chỉnh sửa: Mở rộng câu trả lời để làm cho nó rõ ràng hơn:

  • Trong bắt tay TCP, máy khách sẽ gửi một gói SYN đến máy chủ gửi kích thước cửa sổ tối đa được phép của nó. (Như đầu ra tcpdump của bạn hiển thị, đây là 5840 byte)
  • Bây giờ máy chủ phản hồi với SYN ACK và kích thước cửa sổ mà nó muốn đồng ý. Kích thước cửa sổ này chỉ có thể nhỏ hơn những gì khách hàng đề xuất, không lớn hơn. Cho dù máy chủ được cấu hình như thế nào, nó không bao giờ có thể có kích thước cửa sổ lớn hơn 5840 byte với máy khách đó.
  • Khách hàng trả lại ACK và họ vui vẻ trao đổi dữ liệu mãi mãi về sau.

Edit2: Các tcpdumps được thêm vào câu hỏi cho thấy máy chủ mở các kết nối tới google và chính nó HÀNH ĐỘNG NHƯ KHÁCH HÀNG.


Cửa sổ ban đầu (được đề xuất trong gói SYN) là 5840. Đây là gói đầu tiên và máy gửi không biết gì về máy thu tại thời điểm này (tôi đã thử nghiệm nó với "ip route flush cache").
kupson

Uh, 17.255.209.0 là mạng con máy chủ của bạn, phải không? Gói bạn đang thấy là TỪ 21.101.151.198.45873 ĐẾN 17.255.209.19.http. Tôi không phải là chuyên gia về đầu ra tcpdump, nhưng với tôi điều này có nội dung: Xin chào Máy chủ, tôi là khách hàng của bạn, tôi thích các cửa sổ 5840 byte. :) Gói tiếp theo sẽ là máy chủ phản hồi với ACK, 5840 thật tuyệt, chúc mừng. :)
Ai đó

Chỉ cần nhấn mạnh, tôi nghĩ rằng bạn đã hiểu sai về điều này: Máy gửi đầu tiên là máy khách vì nó mở kết nối chứ không phải máy chủ của bạn. Nó là máy khách cung cấp cửa sổ 5840 byte. Máy chủ không thể đề xuất kích thước cửa sổ lớn hơn, chỉ có kích thước nhỏ hơn.
Ai đó

1
Tôi không phải là tác giả chính của câu hỏi này. Tôi đã thử nghiệm nó (với kết quả tương tự) trên môi trường thử nghiệm của riêng tôi và không thể thay đổi nó. Kích thước cửa sổ tắc nghẽn ban đầu (initcwnd) không liên quan gì đến mặt khác của kết nối.
kupson

Tôi không biết thiết lập của bạn. Người đăng ban đầu hỏi tại sao mặc dù tăng kích thước cửa sổ ban đầu trên máy chủ, kết nối thử nghiệm của anh ta chỉ có kích thước cửa sổ là 5840 byte. Câu trả lời là: Bởi vì ứng dụng khách mà anh ta đã thử nghiệm không cho phép kích thước cửa sổ lớn hơn. Tôi không thể nhận xét về các thiết lập khác hoặc có thể các vấn đề / lỗi khác với khái niệm nói chung.
Ai đó
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.