[Question] Lại một câu hỏi thú vị về mạng |
21/04/2009 18:08:36 (+0700) | #1 | 177986 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
Hôm nay mình "nhàn cư vi bất thiện" nên cố gắng tìm một vấn đề thú vị đưa lên đây để mọi người cùng thảo luận.
Vấn đề như sau: một công ty có trụ sở tại NY (USA) mở một chi nhánh tại HN (VN). Để tiện việc liên lạc, công ty thiết lập một kết nối Internet cho chi nhánh để nhân viên tại VN có thể truy cập upload/download vào các servers đặt tại NY như Web, FTP, SSH, etc. Tất nhiên, do yêu cầu về security policy, công ty này cũng yêu cầu ISP thiết lập các phương thức bảo vệ tại ISP premise để ngăn chặn tấn công vào mạng nội bộ của chi nhánh, và hiển nhiên việc này cũng được tiến hành với trụ sở ở NY.
Sau 2 năm, giám đốc chi nhánh nhận được phàn nàn của nhân viên rằng tốc độ mạng vẫn như xưa, mà họ bây giờ lại cần phải truy cập vào servers tại NY với lượng thông tin lớn hơn, nên thực tế mạng đã trở nên quá chậm so với nhu cầu. Sau khi bàn bạc với trụ sở chính, vị giám đốc này quyết định thiết lập thêm một kết nối nữa song song với kết nối cũ để chia sẻ loads.
May mắn thay, bên phía trụ sở thông báo rằng họ tìm được một ISP (hoặc ISPs cooperation) cung cấp dịch vụ cả ở NY và VN, có nghĩa là nếu hai phía muốn kết nối với nhau, thì khoảng cách truyền sẽ được tối ưu hóa. Thật vậy, sau khi lắp đặt kết nối mới (cả ở NY và HN) lẫn các điều kiện security cần thiết, tính toán cho thấy RTT giữa trụ sở và chi nhánh qua kết nối này chỉ bằng 1/4 RTT qua kết nối cũ, và bandwidth thì gấp 3 lần. Chú ý là kết nối mới vẫn cho phép người dùng truy cập Internet như bình thường.
Tỏ ra hài lòng với kết nối mới, và để thiết lập việc chia sẻ loads, các kĩ sư quyết định đặt một gateway router ở phía chi nhánh với 3 interfaces, một cái nối vào LAN của chi nhánh, và 2 cái còn lại, mỗi cái nối vào một kết nối Internet, một mới, một cũ. Việc chia sẻ diễn ra như sau: cứ mỗi khi có một outgoing packet từ trong LAN, router sẽ chọn bias random giữa 2 kết nối, với weight của kết nối cũ là 1, và weight của kết nối mới là 3 (do bandwidth mới = 3 x bandwidth cũ), và gửi packet qua kết nối được chọn. Tương tự, kĩ thuật này cũng được thiết lập ở trụ sở tại NY.
Câu hỏi đặt ra là: việc thiết lập trên đã cải thiện những gì trong communication giữa trụ sở và chi nhánh? Như thế nào? Và tại sao?.
Edited 1: các số liệu trong bài dù có ý nghĩa của riêng chúng, nhưng cũng chỉ mang tính tương đối thôi, và mình không nghĩ là cần một sự tính toán gì ở đây cả. Câu trả lời cho câu hỏi "what" theo mình thực sự là ngắn gọn và đơn giản.
Edited 2: thêm một số assumptions nữa: giả sử traffic được quan tâm ở đây là giữa 2 site (và traffic này rất heavy) chứ không tính traffic dùng Internet services. Ngoài ra, giả sử các vấn đề về IP addressing/routing đã được giải quyết.
Edited 3: bỏ đi mấy câu không cần thiết. |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
21/04/2009 20:11:41 (+0700) | #2 | 177990 |
![[Avatar] [Avatar]](/hvaonline/images/avatar/089f41810321eefc3f4eef5d4a388e42.png)
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
Cổ chai lớn rót rượu nhiều, cổ chai bé rót rượu ít. |
|
What bringing us together is stronger than what pulling us apart. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
21/04/2009 20:52:36 (+0700) | #3 | 177994 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
21/04/2009 22:05:58 (+0700) | #4 | 177999 |
![[Avatar] [Avatar]](/hvaonline/images/avatar/089f41810321eefc3f4eef5d4a388e42.png)
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
|
What bringing us together is stronger than what pulling us apart. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 01:04:07 (+0700) | #5 | 178012 |
mR.Bi
Member
|
0 |
|
|
Joined: 22/03/2006 13:17:49
Messages: 812
Offline
|
|
Cho em đua đòi: Thiết kế này có cải thiện bandwidth, nhưng khả năng là bị phàn nàn tiếp.
@conmale: cổ chai lớn rót rượu nhiều nhưng nếu rót không khéo thì khi rơi xuống ly sẽ bắn tung tóe, vừa phí phạm và có khi phải rót lại anh ạ.
Giống ngồi ở Mĩ truy cập web site host tại VN đây mà. |
|
All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children" |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 01:23:19 (+0700) | #6 | 178013 |
![[Avatar] [Avatar]](/hvaonline/images/avatar/0ad68c3c92a171334f4137d14787da3b.jpg)
|
vikjava
Elite Member
|
0 |
|
|
Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline
|
|
Theo tớ thì cách giải quyết trên sẽ giải quyết được vấn đề : nếu thằng cũ out thì còn có thằng mới thay thế. Vấn đề tối ưu bandwidth thì có vẻ không đúng lắm. Chẳng hạn từ A đến B luc đầu đi đường Lê Lợi,bi giờ mớ thêm con đường mới Lê Lai . Dân đi đường Lê Lợi đông quá thì rẽ sang Lê Lai đi thôi.
|
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 02:25:23 (+0700) | #7 | 178017 |
choc_
Member
|
0 |
|
|
Joined: 27/01/2009 06:46:01
Messages: 122
Offline
|
|
Mình kô làm về network nhưng phán chơi cho nó máu: cách làm dở hơi này sẽ làm cho đường truyền chậm đi, có khi chậm chỉ bằng mỗi đường truyền cũ thôi. |
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 06:41:10 (+0700) | #8 | 178043 |
![[Avatar] [Avatar]](/hvaonline/images/avatar/5dca4c6b9e244d24a30b4c45601d9720.jpg)
|
rongchaua
Elite Member
|
0 |
|
|
Joined: 19/01/2003 04:09:23
Messages: 124
Offline
|
|
Câu hỏi đặt ra là: việc thiết lập trên đã cải thiện những gì trong communication giữa trụ sở và chi nhánh? Như thế nào? Và tại sao?.
Hên xui. Với kiểu bias random 1:3 này thì 25% packet sẽ chạy với tốc độ đường truyền cũ và 75% chạy với tốc độ đường truyền mới. Ví dụ trong trường hợp xui: gởi 1 file đi, 1/4 file chạy bên line cũ, 3/4 còn lại chạy bên line mới. 3/4 file tới trước ngồi chờ 1/4 file tới sau để góp lại đủ 1 file. Thì coi như cả đám chạy với tốc độ đường truyền cũ. Trường hợp hên thì cả đám chạy trên line mới thì tới nhanh hơn. Vi hên xui như vậy nên trong trường hợp xui thì cũng chạy ít nhất với tốc độ line cũ (bỏ qua thời gian xử lý của router) còn hên thì chạy với tốc độ line mới cho nên là có cải thiện. Nhưng cải thiện bao nhiêu thì ... hem biết. . |
|
My website: http://rongchaua.net |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 14:38:50 (+0700) | #9 | 178104 |
![[Avatar] [Avatar]](/hvaonline/images/avatar/7ed9cfa2a42f54b16e0ed189a35d84f4.png)
|
Bướm Đêm
Member
|
0 |
|
|
Joined: 25/03/2008 18:30:01
Messages: 223
Location: Phố Hoa
Offline
|
|
Theo em thì nếu vấn đề phân luồng băng thông (enforce per-flow fair bandwidth allocation) không ngon thì vẫn xảy ra hàng chờ trong các phiên giao thông như thường đại loại như các packet sẽ chạy loạn xà ngầu trong một phiên transmissions hoặc receive một gói tin >"<
3-3 thì cân bằng được chứ 1-3 chắc thằng nhỏ cho đi đường nhỏ, thằng to đi đường to
........... |
|
GZ tqf zìeq ˘ऐ xखc sड़e cav xন qrqr |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 14:58:20 (+0700) | #10 | 178105 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
Bướm Đêm wrote:
Theo em thì nếu vấn đề phân luồng băng thông (enforce per-flow fair bandwidth allocation) không ngon thì vẫn xảy ra hàng chờ trong các phiên giao thông như thường đại loại như các packet sẽ chạy loạn xà ngầu trong một phiên transmissions hoặc receive một gói tin >"<
3-3 thì cân bằng được chứ 1-3 chắc thằng nhỏ cho đi đường nhỏ, thằng to đi đường to
...........
Vâng, cám ơn góp ý của bạn. Thực ra thì với những traffic lớn giữa 2 sites, các data packets đều xấp xỉ MTU nên chúng tương đối bằng nhau.
Mình xin lưu ý là ở đây mình chỉ quan tâm đến traffic giữa 2 sites thôi, còn với Internet bên ngoài thì mình không quan tâm lắm, vì dù sao nhân viên đến đây để làm việc là chính. Vì vậy theo mình là tương đối fair. |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 21:00:40 (+0700) | #11 | 178113 |
MrNothing
Member
|
0 |
|
|
Joined: 04/01/2008 11:05:37
Messages: 76
Offline
|
|
Cải thiện bao nhiêu thì còn phụ thuộc phân bố của các gói tin gửi đi trong ngày hoặc trong một khoảng thời gian nhất định. Sau đó tính giá trị trung bình gì đó. Em không thạo cái xác suất này lắm.
Em chọn thuật toán tham lam là: Đi đường to đã, khi đường to tắc ta chuyển sang đường nhỏ.
Đang đứng Mai dịch đường 32 còn rộng chán cứ phóng 32 qua cầu vượt mà lên Sư Phạm tán gái tội gì mà đi vòng vào khu Đồng Xa ra Trần Quốc Hoàn rẽ cổng sau Sư Phạm .
Ở bài toán em nghĩ phát biểu vẫn còn thiếu.
Anh nói trọng số là 1 và 3. Bias random là như thế nào? Em nghĩ 3 với 1 chưa nói lên giải thuật điều khiển như thế nào. còn xem tốc độ, băng thông còn lại của 2 đường truyền nữa chứ? Ví dụ một số bọn đang chiếm rồi? phân bố số gói tin trong ngày so với băng thông thế nào?
|
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
22/04/2009 21:51:13 (+0700) | #12 | 178115 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
MrNothing wrote:
Cải thiện bao nhiêu thì còn phụ thuộc phân bố của các gói tin gửi đi trong ngày hoặc trong một khoảng thời gian nhất định. Sau đó tính giá trị trung bình gì đó. Em không thạo cái xác suất này lắm.
Em chọn thuật toán tham lam là: Đi đường to đã, khi đường to tắc ta chuyển sang đường nhỏ.
Đang đứng Mai dịch đường 32 còn rộng chán cứ phóng 32 qua cầu vượt mà lên Sư Phạm tán gái tội gì mà đi vòng vào khu Đồng Xa ra Trần Quốc Hoàn rẽ cổng sau Sư Phạm .
Vâng, ý tưởng của bạn thì về mặt tổng quát rõ ràng là hay hơn trong đề bài, nhưng trong trường hợp như đề bài thì việc chia sẻ load giữa 2 thuật toán không khác nhau là mấy, khi mà lượng outgoing traffic khi không cần thì rất nhỏ, khi cần thì bao giờ cũng lớn hơn total bandwidth. Tuy nhiên, kể cả khi thay thuật toán của bạn vào thì câu trả lời của mình cho vấn đề hầu như không thay đổi.
MrNothing wrote:
Ở bài toán em nghĩ phát biểu vẫn còn thiếu.
Anh nói trọng số là 1 và 3. Bias random là như thế nào? Em nghĩ 3 với 1 chưa nói lên giải thuật điều khiển như thế nào. còn xem tốc độ, băng thông còn lại của 2 đường truyền nữa chứ? Ví dụ một số bọn đang chiếm rồi? phân bố số gói tin trong ngày so với băng thông thế nào?
À, thế này cho dễ hiểu. Bây giờ mình chọn statistically uniformly random giữa 4 số 1, 2, 3, 4. Nếu số 1 được chọn thì mình gửi packet đi kết nối cũ. Còn lại thì mình gửi đi kết nối mới. Như vậy chắc bạn hiểu rồi chứ.
Bạn lưu ý là câu hỏi của mình không đòi hỏi phải tính performance của hệ thống, mà là so sánh một cách tổng quát giữa tình hình hiện tại và trước kia, tức là đã bỏ qua rất nhiều các yếu tố kĩ thuật như lượng traffic mỗi ngày, distribute ra sao, vì chúng vẫn như nhau trong cả 2 trường hợp mới và cũ.
Tất nhiên, khi tính toán yêu cầu về bandwidth cho kết nối mới, các kĩ sư đã suy nghĩ cẩn thận để đảm bảo kết nối chấp nhận được. Ví dụ: nếu kết nối cũ là 1MBps và mới là 3MBps, thì ắt hẳn traffic đòi tại burst time (xảy ra thường xuyên) cũng không quá 10MBps, nhưng nếu chỉ với một kết nối cũ 1MBps thì hiển nhiên khá là chậm. |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
23/04/2009 16:40:18 (+0700) | #13 | 178194 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
Bây giờ mình xin "bình loạn" một chút về ý tưởng của các bạn đã đưa ra câu trả lời kèm một chút giải thích. Còn các câu trả lời còn lại mình xin chờ cắt nghĩa.
vikjava wrote:
Theo tớ thì cách giải quyết trên sẽ giải quyết được vấn đề : nếu thằng cũ out thì còn có thằng mới thay thế. Vấn đề tối ưu bandwidth thì có vẻ không đúng lắm. Chẳng hạn từ A đến B luc đầu đi đường Lê Lợi,bi giờ mớ thêm con đường mới Lê Lai . Dân đi đường Lê Lợi đông quá thì rẽ sang Lê Lai đi thôi.
Bạn so sánh như vậy mình thấy có một số vấn đề sau:
- Việc một người đi đường Lê Lợi hay Lê Lai là do người đó quyết định, còn việc một packet đi đường nào thì không phải do nó quyết định.
- Một packet có thể bị mất trong network, một người thì không.
- dòng người đi trên đường là đi một cách ồ ạt, còn packets di chuyển trong network thì không như vậy, mà có hàng lối của chúng.
Theo bạn những vấn đề trên có thể tạo ra sự khác biệt nào không?
rongchaua wrote:
Câu hỏi đặt ra là: việc thiết lập trên đã cải thiện những gì trong communication giữa trụ sở và chi nhánh? Như thế nào? Và tại sao?.
Hên xui. Với kiểu bias random 1:3 này thì 25% packet sẽ chạy với tốc độ đường truyền cũ và 75% chạy với tốc độ đường truyền mới. Ví dụ trong trường hợp xui: gởi 1 file đi, 1/4 file chạy bên line cũ, 3/4 còn lại chạy bên line mới. 3/4 file tới trước ngồi chờ 1/4 file tới sau để góp lại đủ 1 file. Thì coi như cả đám chạy với tốc độ đường truyền cũ. Trường hợp hên thì cả đám chạy trên line mới thì tới nhanh hơn. Vi hên xui như vậy nên trong trường hợp xui thì cũng chạy ít nhất với tốc độ line cũ (bỏ qua thời gian xử lý của router) còn hên thì chạy với tốc độ line mới cho nên là có cải thiện. Nhưng cải thiện bao nhiêu thì ... hem biết. .
Ý tưởng của bạn khá thú vị. Bây giờ mình thử làm một vài tính toán xem thế nào. Để cho đơn giản, mình giả sử như sau:
- Kết nối cũ có bandwidth là 5MB/s, và kết nối mới là 15MB/s.
- Kết nối cũ có RTT là 200ms và mới là 50ms.
- Ta muốn gửi một file 1GB.
Trong trường hợp đầu, tức là chỉ có một kết nối cũ, tức là bandwidth = 1 MB mỗi 1/5s. Do 1/5s này bằng với RTT, nên ở mức tối ưu, TCP có thể cho phép chuyển 1MB mỗi RTT. Như vậy delay để chuyển 1MB cho đến khi sender có thể chuyển 1MB tiếp theo = RTT + 1MB/bandwidth = 400ms. Như vậy thời gian để gửi đi 1GB sẽ là 400 * 1000 = 400000ms = 400s.
Trong trường hợp thứ hai, tức là cũ + mới, khi chuyển 1MB, thì 3/4MB sẽ đến trước, và 1/MB sẽ đến sau, nên RTT để chuyển 1MB này là RTT của kết nối cũ, tức là 200ms. Trong khi đó, do tổng bandwidth là 20MB/s, nên trong 1 RTT = 200ms, TCP có thể cho phép chuyển tới 4MB. Như vậy delay để chuyển 4MB cho đến khi sender có thể chuyển 4MB tiếp theo là RTT + 4MB/bandwidth = 400ms. Như vậy thời gian gửi đi 1GB sẽ là 400 * 1000/4 = 100000ms = 100s.
So sánh cả hai trường hợp thì mình thấy trường hợp thứ 2 vẫn cho kết quả khả quan hơn nhiều.
|
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
24/04/2009 11:33:32 (+0700) | #14 | 178322 |
mR.Bi
Member
|
0 |
|
|
Joined: 22/03/2006 13:17:49
Messages: 812
Offline
|
|
rongchaua wrote:
Hên xui. Với kiểu bias random 1:3 này thì 25% packet sẽ chạy với tốc độ đường truyền cũ và 75% chạy với tốc độ đường truyền mới. Ví dụ trong trường hợp xui: gởi 1 file đi, 1/4 file chạy bên line cũ, 3/4 còn lại chạy bên line mới. 3/4 file tới trước ngồi chờ 1/4 file tới sau để góp lại đủ 1 file. Thì coi như cả đám chạy với tốc độ đường truyền cũ. Trường hợp hên thì cả đám chạy trên line mới thì tới nhanh hơn. Vi hên xui như vậy nên trong trường hợp xui thì cũng chạy ít nhất với tốc độ line cũ (bỏ qua thời gian xử lý của router) còn hên thì chạy với tốc độ line mới cho nên là có cải thiện. Nhưng cải thiện bao nhiêu thì ... hem biết.
Tính toán thế này thì không được, giả dụ trong trường hợp bị cắt làm 1/4:3/4 đi nữa, thì 3/4 file chạy với đường truyền mới, sẽ rất nhanh, theo như lí thuyết của đề bài thì bằng 3x tốc độ đường truyền cũ. 1/4 còn lại chạy với đường cũ thì không thể nào chạy với thời gian truyền đi cả file, 1/4:1 mà. Dù sao nó vẫn nhanh hơn khá là nhiều nếu như được phân chia như vậy.
Nói về câu trả lời của em, thực chất em cũng không hiểu được cái random bias là thế nào, nói trước là đua đòi mà . Nhưng nếu random thì có trường hợp một file truyền đi trên chính đường truyền cũ, hoặc chỉ sử dụng đường truyền mới, hoặc sử dụng cả 2 ---> tốc độ không thể ổn định. Có khi rất chậm, lại có khi rất nhanh, dĩ nhiên sẽ nhanh hơn so với lúc chưa triển khai đường truyền mới. Cứ giả sử như có ông A ngày 1 gửi một file 10MB với thời gian là 2.5s, ngày thứ 2 cũng gửi một file 10MB nhưng với thời gian là 8s, thể nào ông ấy không la toáng lên.
Theo em giải pháp này không thực sự tốt, nếu đã như thế thì ngắt luôn đường truyền cũ, giảm chi phí, tốc độ tăng lên mà còn ổn định.
Xin hết.
|
|
All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children" |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
24/04/2009 11:34:36 (+0700) | #15 | 178323 |
frankenstein
Member
|
0 |
|
|
Joined: 23/04/2009 12:08:05
Messages: 1
Offline
|
|
Để trả lời cho câu hỏi của bạn đặt ra.Tui xin có vài lời thế này
Với kiểu bias random 1:3 |
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
24/04/2009 13:13:26 (+0700) | #16 | 178332 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
mR.Bi wrote:
Nói về câu trả lời của em, thực chất em cũng không hiểu được cái random bias là thế nào, nói trước là đua đòi mà . Nhưng nếu random thì có trường hợp một file truyền đi trên chính đường truyền cũ, hoặc chỉ sử dụng đường truyền mới, hoặc sử dụng cả 2 ---> tốc độ không thể ổn định. Có khi rất chậm, lại có khi rất nhanh, dĩ nhiên sẽ nhanh hơn so với lúc chưa triển khai đường truyền mới. Cứ giả sử như có ông A ngày 1 gửi một file 10MB với thời gian là 2.5s, ngày thứ 2 cũng gửi một file 10MB nhưng với thời gian là 8s, thể nào ông ấy không la toáng lên.
Theo em giải pháp này không thực sự tốt, nếu đã như thế thì ngắt luôn đường truyền cũ, giảm chi phí, tốc độ tăng lên mà còn ổn định.
--> bias random thì mình đã giải thích ở một post phía trên. Và không thể có chuyện một file chỉ đi trên kết nối cũ hoặc mới, mà phải là cả hai, theo tỉ lệ 1:3, trừ phi file đó quá nhỏ, cỡ vài trăm KB chẳng hạn.
--> Vấn đề của mình là so sánh giữa hai trường hợp, chứ mình còn chưa nghĩ đến một giải pháp tốt bạn ạ.
@choc_: mình thấy phán đoán của bạn khá thú vị, mình chờ giải thích của bạn. |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
10/05/2009 19:03:08 (+0700) | #17 | 180148 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
Chà, lâu lâu không lên, vẫn chưa thấy một lời giải thích mang nhiều yếu tố kĩ thuật. Chắc tại ai cũng bận nên quên mất.
Thôi mình đành tiếp tục câu chuyện vậy, hy vọng tình huống có thể thú vị hơn:
...
Sau khi lắp đặt xong kết nối mới, vị giám đốc đưa mấy tay kĩ sư đi ăn mừng (nhậu), rồi sau đó về nhà nghỉ ngơi sau một hồi làm việc vất vả.
Sáng hôm sau ông ta đến cơ quan và chắc mẩm thế nào cũng nhìn thấy bộ mặt "mãn nguyện" của đám nhân viên. Tuy nhiên, đứng đợi ông ở trước cửa cơ quan vẫn là anh nhân viên đã phàn nàn hôm trước. Lần này, trông anh ta có vẻ còn thảm hại hơn, và ngay khi nhìn thấy vị giám đốc, anh ta liền nói: "Sếp ơi, nguy rôi, không hiểu sao chúng tôi vừa đến cơ quan làm việc mà hầu như không ai download được gì từ server bên US. Chúng tôi cảm tưởng kết nối cứ như thời còn dùng dial-up modem ấy".
Vị giám đốc ngớ người ra, nhưng sau đó phì cười: "Cậu chỉ khéo đùa, hôm qua chúng tôi mới lắp đặt xong, mặc dù chưa có thời gian thử nghiệm vì tối muộn, nhưng đã ping thấy OK, không có lẽ nào. Hơn nữa, chúng tôi cũng chả động gì đến đường dây cũ nên không thể có chuyện chậm hơn được".
Vậy theo các bạn, anh nhân viên đó thực ra đang nói đùa hay nói thật? |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
11/05/2009 14:00:16 (+0700) | #18 | 180225 |
cocondihoc
Member
|
0 |
|
|
Joined: 27/04/2008 13:15:35
Messages: 61
Offline
|
|
Tôi nghĩ là anh nhân viên đó nói thật. Với cách làm đó thì có lẽ vấn đề ở chỗ 2 đường truyền của 2 ISP khác nhau. |
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
12/05/2009 12:26:58 (+0700) | #19 | 180315 |
myquartz
Member
|
0 |
|
|
Joined: 04/01/2005 04:58:30
Messages: 563
Offline
|
|
Thấy hỏi thế nên trả lời lại. Bài này các giả thiết nói chung là thiếu, khó có thể rút ra 1 kết luận chính xác. Chỉ có khả năng nó sẽ xảy ra như thế này hoặc như thế kia.
Căn bản vấn đề của việc sử dụng 2 đường truyền như thế, là con router tại CN VN hay NY đều chỉ điều khiển được các packet out-going, không thể điều khiển được hay phân luồng được các packet incoming từ ISP gửi về.
Cho rằng mạng của CN hay NY mỗi nơi chỉ là 1 subnet. Do đó, giả sử router điều khiển 1000 packet đi từ VN sang NY, cho 200p đi theo kênh cũ, 800p đi theo kênh mới, thì đến đầu CN NY nó sẽ đi vào đường nào? điều đó hoàn toàn do ISP các bên Mỹ quyết định.
Điều ngược lại cũng như thế.
Dù là 2 đường với các ISP khác nhau, việc điều khiển luồng đi tới 1 subnet qua 2 đường họ phải trao đổi thông tin định tuyến cho nhau, và cuối cùng sẽ ra con 1 đường tốt hơn.
Do giải thiết là có 1 ISP liên thông giữa 2 bên và đường mới nối với ISP này, giải thiết mọi packet đi từ đường này sẽ qua đường kia, nhưng còn packet đi ra từ kênh cũ chậm còn lại sẽ đi vào đâu ở bên kia? Nó đi vào kênh mới to hơn? Kênh to hơn thì tốt nhưng vẫn sẽ mất cân đối, 1 bên gửi thì tổng gửi = cũ + mới, tổng nhận chỉ là đường mới.
Xem cái hình vẽ trường hợp này:
Code:
1/5 gửi ->
+--------cũ--------- [ ISP 1] --{ Internet }-- [ ISP 2 ] -------cũ--------+
VN subnet-- [router] | [router]-- NY subnet
+--------mới---------------------- [ ISP mới ]----------------------mới------+
4/5 gửi -> 1/5 đến -> 4/5 đến ->
Tại sao nếu gửi và nhận bằng nhiều con đường và mất cân đối khiến có thể tệ hơn? Do các dịch vụ sử dụng (như giả sử của bài) hầu hết là TCP. TCP là giao thức truyền đảm bảo, theo chuỗi đúng thứ tự và luôn có xu hướng "ăn hết khả năng băng thông". TCP sẽ gửi liên tục hết tốc độ các packet theo thứ tự và chờ nhận ACK. Nếu ở 1 khúc nào đó mất packet, thì việc chờ nhận ACK sẽ bị quá thời gian, TCP sẽ gửi lại cả loạt packet nó cho là bị mất và giảm tốc độ gửi đi.
Hãy tưởng tượng 1 chuỗi 1000 packet đi, có xen kẽ 200 packet đi theo kênh cũ và 800 đi theo kênh mới. Đến bên nhận (giả sử CN NY), nó bị nhét tất vào 1 kênh mới. Do độ trễ chênh nhau 1/4 (4 lần, quá lớn), có khi 650/800 packet đến thì 150/200 packet kia mới tới. Chỉ có đúng số này 650 + 150 = 800 packet đi lọt kênh mới, có thể theo thứ tự là 650 đi trước, 150 đi sau. Trong khi đó 150 này đúng ra phải nhận xen kẽ với 650 (cứ 4 cái xen 1 cái).
TCP trong trường hợp có nhận được 650 packet thì vẫn phải chờ 150 packet kia mới đủ 1 chuỗi liên tục, và nó sẽ không thèm gửi ACK cho đến khi chờ đủ. Bên gửi thấy lâu quá không có ACK, tưởng chuỗi packet bị mất, giảm tốc độ chút và gửi lại cả chuỗi 1000 packet (gần 1000 thôi).
Lúc bên ISP nhận có thể bị overbuffer của đường mới, nó drop 1 số lượng nhất định packet (có thể ngẫu nhiên hoặc tuần tự).
Cứ thế, hiệu quả của đường truyền giảm đi, do bên gửi cứ phải gửi đi, gửi lại. Việc sếp vẫn bị phàn nàn về đường truyền hoàn toàn có thể xảy ra theo khả năng này.
Việc này có thể khắc phục bằng cách bỏ đường cũ đi. Trường hợp cần giữ đường cũ vì cần dự phòng và muốn chạy nhanh hơn chút, thì phải thay 2 con router 2 đầu CN có khả năng cân bằng tải tốt hơn theo kiểu per-packet như trên. Nếu subnet nhiều địa chỉ thì kiểu per-destination có thể giúp ích. Nếu ít địa chỉ, nhiều kết nối, thì kiểu xịn hơn là per-session sẽ giúp ích. Các session TCP nhất định sẽ chỉ đi theo 1 đường do router chọn (mới hoặc cũ), sẽ không gây ra việc packet tới sớm, tới muộn, lộn xộn thứ tự một cách tệ hại như thế. |
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
13/05/2009 08:29:21 (+0700) | #20 | 180406 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
@myquartz: hoan hô một bài phân tích khá kĩ thuật. Như thường lệ, mình xin có nhận xét sau:
- Bạn sử dụng khá tốt các dữ kiện của đề bài, và đưa ra các nhận xét khá logic.
- Về thiếu sót trong đề bài, mình công nhận cũng hơi phức tạp. Thôi thì bạn cứ tưởng tượng 2 kết nối đó là hoàn toàn disjoint giữa 2 routers của 2 bên, như vậy đơn giản hơn.
- Về chuyện 650 packets phải đợi 150 packets: mình cho rằng giao thức TCP đủ thông minh để có thể ước lượng khoảng thời gian nó phải đợi trước khi gửi lại số packets trên, tức là, chắc chắn khoảng thời gian đợi đó sẽ nhiều hơn RTT của kết nối cũ, cũng là khoảng thời gian để 150 packets đi trên kết nối cũ đến nơi, và xấp xỉ 150 ACKS trở về cũng trên kết nối cũ.
- Mình cho rằng bạn đang đi rất đúng hướng, chỉ thiếu chút xíu nữa thôi. Hy vọng bạn đóng góp thêm một câu trả lời rõ ràng và giải thích cho câu trả lời đó.
Thân mến. |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
14/05/2009 13:23:18 (+0700) | #21 | 180528 |
myquartz
Member
|
0 |
|
|
Joined: 04/01/2005 04:58:30
Messages: 563
Offline
|
|
Hi StarGhost!
Suy đoán của mình lúc trước ko phải là chính xác lắm (thời gian đợi của TCP khá lớn, và nó giảm cái gọi là window gửi của nó nếu bị trễ/mất gói).
Khả năng TCP sai thứ tự gói, quá bandwidth làm cho đầu router nhận đầy buffer, nó drop packet đến sau (nhưng theo thứ tự TCP thì lại ở đầu) và khiến TCP phải truyền lại, là có thể, và đó là khả năng cao nhất khiến hệ thống mạng trở nên chậm chạp (theo như suy đoán của tôi).
Bạn đã bổ sung thêm yếu tố là dữ liệu tống vào đường cũ sẽ đến đầu kia theo đường cũ, đường mới đi đường mới. Hình vẽ nó sẽ rút thành như sau:
Code:
1/4 gửi -> 1/4 đến
+--------cũ--------------cũ--------+
VN subnet-- [router] [router]-- NY subnet
+--------mới-------------mới------+
3/4 gửi -> 3/4 đến ->
Hình vẽ này cho thấy sẽ không có khả năng bên nhận bị đầy buffer, vì gửi có nhiều hơn khả năng nhận được đâu. Với giả thiết thêm là đường truyền tốt, tỉ lệ 2 đường truyền phân chia đúng như bandwidth. Trừ RTT 2 bên khác nhau ra. MTU ngon lành, router tốt.
Vậy thì câu trả lời mới của mình là: kiểu nối mạng này hoàn toàn chạy tốt, ở tốc độ tốt hơn khi chưa nâng cấp. Bởi bài toán thực tế mình đã từng thực hiện nó kiểu như thế này (trừ việc 2 kênh này 1 là leased line và 1 cái khác là MegaWAN - của VTN, ko phải Internet như ví dụ), cũng per-packet load balancing, sai khác nhau bandwidth, gấp 2 lần, và cả RTT cũng có sự chênh nhau, tuy không quá lớn. Mô hình chạy tốt, tuy không phải hoàn hảo (tốc độ kết nối không ổn định lắm, tăng giảm, nhưng luôn có min = kênh chậm hơn, tổng lại vẫn nhanh hơn). Dù sau đó mình chuyển sử dụng per-destination còn tốt hơn, khai thác hết tốc độ 2 kênh và rất ổn định tốc độ cho kết nối TCP.
Không có lý do gì, dù TCP nhận gói không hẳn theo thứ tự đúng, nhưng lại rất đảm bảo để không bị mất gói (bên router gửi gửi bao nhiêu, đầy buffer, thì bên nhận sẽ đủ bandwidth nhận bằng ấy, ko drop đi cái nào), thì TCP sẽ chạy tốt. Dù rằng cái cửa số gửi của TCP bị co dãn liên tục do ACK nhận không đều đặn nhau. TCP sợ bị mất gói hơn là bị trễ.
Với đề bài (giả sử và giải trên lý thuyết) của bạn, có 1 kết quả khác, mạng lại tồi hơn. Thì tốt nhất là bạn nên nói suy luận và giải thích ra.
Mình không thi sát hạch, không thi thố tài năng, chỉ sử dụng kinh nghiệm và kiến thức cá nhân để suy đoán cho 1 trường hợp. Coi đó là giải trí hoặc nếu có giúp ích cho người khác hiểu hơn. Chứ kiến thức bao la, thực tế vô vàn, chưa biết được ai nhiều ai ít, ai biết cái này cái nọ đâu.
P/S: mình có bỏ qua 1 giả thiết, nhưng nó ko ảnh hưởng: router chọn random theo weight cũng đạt tỉ lệ phân chia gần với việc router chọn theo cách đếm packet: cứ 3 packet đi theo lối này thì cho 1 cái đi theo lối kia. Khi có nhiều kết nối TCP thì 2 kiểu sẽ thành ngẫu nhiên vì packet đến router là ngẫu nhiên, 1 hay 2 sự ngẫu nhiên đều ra 1 kết quả ngẫu nhiên cả. |
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Re: Lại một câu hỏi thú vị về mạng |
14/05/2009 16:24:04 (+0700) | #22 | 180537 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
myquartz wrote:
Vậy thì câu trả lời mới của mình là: kiểu nối mạng này hoàn toàn chạy tốt, ở tốc độ tốt hơn khi chưa nâng cấp. Bởi bài toán thực tế mình đã từng thực hiện nó kiểu như thế này (trừ việc 2 kênh này 1 là leased line và 1 cái khác là MegaWAN - của VTN, ko phải Internet như ví dụ), cũng per-packet load balancing, sai khác nhau bandwidth, gấp 2 lần, và cả RTT cũng có sự chênh nhau, tuy không quá lớn. Mô hình chạy tốt, tuy không phải hoàn hảo (tốc độ kết nối không ổn định lắm, tăng giảm, nhưng luôn có min = kênh chậm hơn, tổng lại vẫn nhanh hơn). Dù sau đó mình chuyển sử dụng per-destination còn tốt hơn, khai thác hết tốc độ 2 kênh và rất ổn định tốc độ cho kết nối TCP.
Hì hì, không phải ngẫu nhiên mà mình lại cho một kết nối có bandwidth gấp 3 lần cái kia, và RTT thì chỉ bằng 1/4. Giá như cái mạng thực tế của bạn mà tương tự như vậy mà có kết quả tốt thì sẽ rất thú vị.
myquartz wrote:
Với đề bài (giả sử và giải trên lý thuyết) của bạn, có 1 kết quả khác, mạng lại tồi hơn. Thì tốt nhất là bạn nên nói suy luận và giải thích ra.
Mình không thi sát hạch, không thi thố tài năng, chỉ sử dụng kinh nghiệm và kiến thức cá nhân để suy đoán cho 1 trường hợp. Coi đó là giải trí hoặc nếu có giúp ích cho người khác hiểu hơn. Chứ kiến thức bao la, thực tế vô vàn, chưa biết được ai nhiều ai ít, ai biết cái này cái nọ đâu.
Thực ra mình đưa vấn đề lên không phải để đánh đố ai cả, mà mục đích chỉ là để mọi người cùng thảo luận, đưa ra các suy nghĩ và phản biện. Chứ nếu mình đưa vấn đề rồi giải đáp luôn, thì chẳng khác gì bảo các bạn đi đọc sách còn hữu dụng hơn.
Sẵn bạn đã nhận xét ra là trung bình cứ một packet đi trên kết nối cũ thì có 3 packets đi trên kết nối mới. Như vậy theo bạn điều gì sẽ xảy ra ở phía receiver, và sau đó là sender? Và cái điều xảy ra đó dẫn đến ảnh hưởng thế nào đến tốc độ truyền dữ liệu? Ảnh hưởng đó lớn hay nhỏ? Nếu nhỏ thì có khả năng nào nó bị "từ bé xé ra to" không?
Tất cả những điều ở trên đều chỉ xoay quanh câu chuyện TCP hoạt động ra sao, và nó xử lý những tình huống bất thường như thế nào thôi. |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Lại một câu hỏi thú vị về mạng |
19/06/2009 21:54:09 (+0700) | #23 | 184045 |
camazalraman
Member
|
0 |
|
|
Joined: 19/05/2004 01:57:32
Messages: 23
Offline
|
|
Topic này có vẻ không thêm được thảo luận nào nữa,
Bạn StarGhost cho đáp án đi vậy.
Thanks |
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Lại một câu hỏi thú vị về mạng |
20/06/2009 05:49:23 (+0700) | #24 | 184098 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
@camazalraman: ồ mình gần như quên khuấy cái topic này. Thực ra câu trả lời cũng đơn giản thôi, mặc dù phải giải thích một chút:
- Trong TCP có một khái niệm là sliding window dùng để chỉ lượng data mà một TCP sender có thể gửi đi trong một RTT.
- Giá trị sliding window được quyết định bởi min của hai loại windows, một từ sender (gọi là congestion window), và một từ receiver (gọi là receive window).
- Receive window thường không thay đổi nhiều trong suốt quá trình data transfer của một TCP connection, nên điều này cũng không có gì đáng quan tâm. Hoặc giả mình giả sử máy receiver đủ mạnh để không gây ảnh hưởng đến receive window.
- Congestion window là thứ window liên quan chủ yếu đến network path giữa hai TCP peers.
- TCP sử dụng 2 loại kĩ thuật cơ bản để đối phó với network issues, gọi là congestion avoidance và retransmission. Congestion avoidance dùng để tune congestion window sao cho phù hợp với khả năng của network. Retransmission dùng để retransmit một packet khi mà TCP phát hiện ra vấn đề với packet đó.
- Vấn đề với hệ thống này chính là ở kĩ thuật retranmission mà TCP sử dụng. Ví dụ trong Linux khi bạn sử dụng command "sysctl -a | grep congestion_control" thì sẽ thấy rằng hai algorithm cơ bản là reno và cubic, trong đó một trong hai sẽ được dùng by default.
- Cả hai algorithm này đều dùng một sub-algorithm cho retransmission gọi là fast recovery. Nguyên lý của fast recovery như sau: Nếu sender nhận được ba duplicate acks, tức là ví dụ sender gửi packets 1,2,3,4, nhưng receiver chỉ nhận được 2,3,4, thì ba duplicates sẽ được gửi về sender, thì nó sẽ tiến hành gửi lại packet 1, đồng thời giảm congestion window đi một nửa.
- Quay lại topology của đề bài, có thể nhận thấy rằng chắc chắn tình trạng gửi packet theo thứ tự 1,2,3,4 và nhận theo thứ tự 2,3,4,1 sẽ xảy ra liên tục. Điều này dẫn đến congestion window sẽ liên tục bị giảm đi một nửa mà không có thời gian để phục hồi, và cuối cùng sẽ quay trở về 1 packet per RTT, và đây sẽ chính là TCP window được sử dụng.
==> Vậy 1 packet per RTT thì chắc bạn cũng đã biết là tệ đến mức nào.
Ngoài ra, một bonus point về vấn đề của topology của đề bài cũng liên quan đến security. Giả sử khi một PC ở đầu này gửi một SYN đến đầu kia qua kết nối cũ, sau đó PC đầu kia gửi SYN_ACK qua kết nối mới, nhiều khả năng SYN_ACK này sẽ bị denied bởi ISP của kết nối mới, vì nó còn chưa thấy SYN nào tương ứng đi qua. Như vậy khả năng tạo thành công một TCP connection cũng không cao. Tuy nhiên cái này thì không liên quan đến transfer rate.
Thân mến.
p/s: Đây không phải là câu đố của mình (kẻo một vài bạn lại nghĩ mình là chuyên gia), và mình cũng không biết câu trả lời đi kèm với nó, và trên đây chỉ là câu trả lời của riêng mình. Thế nên bất cứ ý kiến nào khác dù là bổ sung hay đối nghịch cũng đáng được suy xét. |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Lại một câu hỏi thú vị về mạng |
22/06/2009 02:03:29 (+0700) | #25 | 184243 |
camazalraman
Member
|
0 |
|
|
Joined: 19/05/2004 01:57:32
Messages: 23
Offline
|
|
Theo bạn trong trường hợp này tình trạng gửi packet theo thứ tự 1,2,3,4 và nhận theo thứ tự 2,3,4,1 sẽ xảy ra liên tục, vậy thì ngay sau khi kết nối được thiết lập, trong pha Slow Start với congestion window (cwnd) khởi tạo với 1 segment
- cwnd = 1 segment , ssthresh = 65535 bytes --> oki sender nhận được 1 ack trả về
- cwnd = 2 segment , ssthresh = 65535 bytes --> oki sender nhận được 2 ack trả về
- cwnd = 4 segment , ssthresh = 65535 bytes --> lúc này có thể sẽ nhận được 3 duplicate ack hoặc là 4 ack
nếu nhận được 4 ack thì cwnd sẽ tiếp tục tăng theo hàm mũ cho đến khi nhận được 3 duplicate ack hoặc bị mất gói tin. khi đó ssthresh = 1/2 cwnd, và bắt đầu lại quá trình Slow Start hoặc Congestion Avoidance
Trường hợp với mạng như bạn nêu việc nhận 3 duplicate ack sẽ liên tục -->vậy thì ngay từ đầu việc truyền dữ liệu đã bị "vùi dập" bởi giá trị cwnd sẽ không thể lớn được mà rất nhỏ ( có thể là 1packet) ngay từ quá trình thăm dò khả năng đường truyền (Slow Start).
Mình có chút ý kiến như vậy.
Để thảo luận tiếp mọi người có thử đưa ra giải pháp khắc phục mà vẫn sử dụng mô hình kết nối như ban đầu thì sao nhỉ |
|
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
[Question] Lại một câu hỏi thú vị về mạng |
25/06/2009 15:25:56 (+0700) | #26 | 184613 |
StarGhost
Elite Member
|
0 |
|
|
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
|
|
Sorry mình quên không check topic này nên reply hơi muộn.
camazalraman wrote:
Theo bạn trong trường hợp này tình trạng gửi packet theo thứ tự 1,2,3,4 và nhận theo thứ tự 2,3,4,1 sẽ xảy ra liên tục, vậy thì ngay sau khi kết nối được thiết lập, trong pha Slow Start với congestion window (cwnd) khởi tạo với 1 segment
- cwnd = 1 segment , ssthresh = 65535 bytes --> oki sender nhận được 1 ack trả về
- cwnd = 2 segment , ssthresh = 65535 bytes --> oki sender nhận được 2 ack trả về
- cwnd = 4 segment , ssthresh = 65535 bytes --> lúc này có thể sẽ nhận được 3 duplicate ack hoặc là 4 ack
nếu nhận được 4 ack thì cwnd sẽ tiếp tục tăng theo hàm mũ cho đến khi nhận được 3 duplicate ack hoặc bị mất gói tin. khi đó ssthresh = 1/2 cwnd, và bắt đầu lại quá trình Slow Start hoặc Congestion Avoidance
Trường hợp với mạng như bạn nêu việc nhận 3 duplicate ack sẽ liên tục -->vậy thì ngay từ đầu việc truyền dữ liệu đã bị "vùi dập" bởi giá trị cwnd sẽ không thể lớn được mà rất nhỏ ( có thể là 1packet) ngay từ quá trình thăm dò khả năng đường truyền (Slow Start).
Chính xác. Còn về giải pháp thì một trong các giải pháp như có bạn đã đề cập ở trên là cho phép mỗi TCP connection hoạt động chỉ trên một kết nối. Ngoài ra, một giải pháp khác là cấu hình kernel để tăng số lượng duplicate acks nhận được trước khi giảm cwnd. Một giải pháp nữa là delay packets ở kết nối mới để RTT của nó bằng với kết nối cũ (việc này hầu như không làm ảnh hưởng đến performance của network). |
|
Mind your thought. |
|
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
![](/hvaonline/templates/viet/images/spacer.gif) |
Users currently in here |
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|