<![CDATA[Latest posts for the topic "Lại một câu hỏi thú vị về mạng"]]> /hvaonline/posts/list/31.html JForum - http://www.jforum.net Lại một câu hỏi thú vị về mạng 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.]]> /hvaonline/posts/list/28875.html#177986 /hvaonline/posts/list/28875.html#177986 GMT Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#177990 /hvaonline/posts/list/28875.html#177990 GMT Re: Lại một câu hỏi thú vị về mạng

conmale wrote:
Cổ chai lớn rót rượu nhiều, cổ chai bé rót rượu ít. :P  
Hix, lẽ ra phải lưu ý là các mods nên là những người post cuối cùng :P , vì mình cho rằng các bài post của mods rất có ảnh hưởng đến ý kiến của members. Anyway, nếu bạn nào có ý kiến khác anh conmale dù ít hay nhiều mình mong các bạn đưa lên đây để cùng thảo luận, vì còn chưa biết ai đúng ai sai. @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 ạ. ;) ]]>
/hvaonline/posts/list/28875.html#177994 /hvaonline/posts/list/28875.html#177994 GMT
Re: Lại một câu hỏi thú vị về mạng

StarGhost wrote:

conmale wrote:
Cổ chai lớn rót rượu nhiều, cổ chai bé rót rượu ít. :P  
Hix, lẽ ra phải lưu ý là các mods nên là những người post cuối cùng :P , vì mình cho rằng các bài post của mods rất có ảnh hưởng đến ý kiến của members. Anyway, nếu bạn nào có ý kiến khác anh conmale dù ít hay nhiều mình mong các bạn đưa lên đây để cùng thảo luận, vì còn chưa biết ai đúng ai sai. @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 ạ. ;)  
Thì anh chỉ phát biểu một câu "mờ mờ nhân ảnh" vậy để tham gia thôi mà :P. Câu đó chẳng có gì cụ thể hết.]]>
/hvaonline/posts/list/28875.html#177999 /hvaonline/posts/list/28875.html#177999 GMT
Re: Lại một câu hỏi thú vị về mạng @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à.]]> /hvaonline/posts/list/28875.html#178012 /hvaonline/posts/list/28875.html#178012 GMT Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#178013 /hvaonline/posts/list/28875.html#178013 GMT Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#178017 /hvaonline/posts/list/28875.html#178017 GMT Re: Lại một câu hỏi thú vị về mạng 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. :D.]]> /hvaonline/posts/list/28875.html#178043 /hvaonline/posts/list/28875.html#178043 GMT Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#178104 /hvaonline/posts/list/28875.html#178104 GMT Re: Lại một câu hỏi thú vị về mạng

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 :D đạ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. ]]>
/hvaonline/posts/list/28875.html#178105 /hvaonline/posts/list/28875.html#178105 GMT
Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#178113 /hvaonline/posts/list/28875.html#178113 GMT Re: Lại một câu hỏi thú vị về mạng

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 :D.  
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.]]>
/hvaonline/posts/list/28875.html#178115 /hvaonline/posts/list/28875.html#178115 GMT
Re: Lại một câu hỏi thú vị về mạng

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. :D. 
Ý 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. ]]>
/hvaonline/posts/list/28875.html#178194 /hvaonline/posts/list/28875.html#178194 GMT
Re: Lại một câu hỏi thú vị về mạng

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. ]]>
/hvaonline/posts/list/28875.html#178322 /hvaonline/posts/list/28875.html#178322 GMT
Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#178323 /hvaonline/posts/list/28875.html#178323 GMT Re: Lại một câu hỏi thú vị về mạng

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.]]>
/hvaonline/posts/list/28875.html#178332 /hvaonline/posts/list/28875.html#178332 GMT
Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#180148 /hvaonline/posts/list/28875.html#180148 GMT Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#180225 /hvaonline/posts/list/28875.html#180225 GMT Re: Lại một câu hỏi thú vị về mạng 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/posts/list/28875.html#180315 /hvaonline/posts/list/28875.html#180315 GMT
Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#180406 /hvaonline/posts/list/28875.html#180406 GMT Re: Lại một câu hỏi thú vị về mạng 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/posts/list/28875.html#180528 /hvaonline/posts/list/28875.html#180528 GMT
Re: Lại một câu hỏi thú vị về mạng

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.]]>
/hvaonline/posts/list/28875.html#180537 /hvaonline/posts/list/28875.html#180537 GMT
Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#184045 /hvaonline/posts/list/28875.html#184045 GMT Lại một câu hỏi thú vị về mạng đồ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.]]> /hvaonline/posts/list/28875.html#184098 /hvaonline/posts/list/28875.html#184098 GMT Lại một câu hỏi thú vị về mạng /hvaonline/posts/list/28875.html#184243 /hvaonline/posts/list/28875.html#184243 GMT Lại một câu hỏi thú vị về mạng

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).]]>
/hvaonline/posts/list/28875.html#184613 /hvaonline/posts/list/28875.html#184613 GMT