Về một số vấn đề khi đọc TCP/IP

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận mạng và thiết bị mạng

Về một số vấn đề khi đọc TCP/IP

[Discussion] Về một số vấn đề khi đọc TCP/IP	05/01/2009 06:03:52 (+0700) \| #1 \| 165145

quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline

Chào anh em,

Mình dùng tcpdump capture lại một mớ packet liên quan đến ARP:

Để ý ở Frame 2, có kích thước 60 bytes: ngoài 42 bytes thông thường của một ARP packet (14 bytes Ethernet header + 28 bytes ARP), còn có phần Ethernet trailer với kích thước 18 bytes. Theo bạn, phần Ethernet trailer này có ý nghĩa gì?

Let's build on a great foundation!

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 08:06:18 (+0700) \| #2 \| 165154

thangdiablo
HVA Friend

Joined: 11/05/2003 17:31:58
Messages: 734
Offline

Hi Quân,

Trong 1 frame ngoài Frame Header thì phía cuối của mỗi frame còn có 1 phần gọi là Trailer.

Trong phần trailer có chứa 1 trường gọi là FCS ( Frame Check Sequent ). Trường FCS này có tác dụng dùng để kiểm tra khi nó tới 1 thiết bị xử lý từ layer 2 trở lên.
Các Router hay Switch sẽ nhìn vào FCS này để kiểm tra xem Frame có bị lỗi hay không dẫn tới quyết định tiếp tục gửi hay hủy gói frame này.

Hãy sống có Tuệ Giác.

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 08:13:59 (+0700) \| #3 \| 165156

zerozeroone
Member

Joined: 24/12/2006 13:29:23
Messages: 149
Offline

Chào anh quanta,
Theo em thì mỗi Ethernet frame có kích thước tối thiểu là 64 bytes (đã bao gồm phần Ethernet trailer 4 bytes) hoặc 60 bytes (không bao gồm phần Ethernet trailer 4 bytes) hoặc 46 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes) và kích thước tối đa là 1500 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes).
Các gói ARP bao gồm 28 bytes cho phần ARP message và 14 bytes Ethernet header như anh nói như vậy thì chỉ mới có 42 bytes, như vậy chưa đạt được kích thước tối thiểu nên chúng được "thêm vào " các byte 0 (padding) để đạt kích thước tối thiểu 60 bytes (không bao gồm Ethernet trailer).

[Question] Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 08:42:51 (+0700) \| #4 \| 165159

secmask
Elite Member

Joined: 29/10/2004 13:52:24
Messages: 553
Location: graveyard
Offline

quanta wrote:

Chào anh em,
Mình dùng tcpdump capture lại một mớ packet liên quan đến ARP

anh dùng bản tcpdump nào mà khủng thế smilie

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 09:13:30 (+0700) \| #5 \| 165160

quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline

zerozeroone wrote:

Chào anh quanta,
Theo em thì mỗi Ethernet frame có kích thước tối thiểu là 64 bytes (đã bao gồm phần Ethernet trailer 4 bytes) hoặc 60 bytes (không bao gồm phần Ethernet trailer 4 bytes) hoặc 46 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes) và kích thước tối đa là 1500 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes).
Các gói ARP bao gồm 28 bytes cho phần ARP message và 14 bytes Ethernet header như anh nói như vậy thì chỉ mới có 42 bytes, như vậy chưa đạt được kích thước tối thiểu nên chúng được "thêm vào " các byte 0 (padding) để đạt kích thước tối thiểu 60 bytes (không bao gồm Ethernet trailer).

Trong 42 bytes này đã bao gồm 14 bytes Ethernet header rồi mà:

14 = 6 (Dst addr) + 6 (Src addr) + 2 (Frame type)

--> phần Ethernet trailer = 18 bytes?

Tại sao cũng một gói ARP reply khác lại không có phần Ethernet trailer (chỉ có 42 bytes)?

Let's build on a great foundation!

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 09:15:14 (+0700) \| #6 \| 165161

boom_jt
Member

Joined: 02/08/2007 23:51:10
Messages: 125
Offline

zerozeroone wrote:

... mỗi Ethernet frame có kích thước tối thiểu là 64 bytes (đã bao gồm phần Ethernet trailer 4 bytes) hoặc 60 bytes (không bao gồm phần Ethernet trailer 4 bytes) hoặc 46 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes) và kích thước tối đa là 1500 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes).
Các gói ARP bao gồm 28 bytes cho phần ARP message và 14 bytes Ethernet header như anh nói như vậy thì chỉ mới có 42 bytes, như vậy chưa đạt được kích thước tối thiểu nên chúng được "thêm vào " các byte 0 (padding) để đạt kích thước tối thiểu 60 bytes (không bao gồm Ethernet trailer).

hi,
boom làm rõ thêm ý này chút bằng 1 quote từ TCP/IP illustrated nha:

There is a minimum size for 802.3 and Ethernet frames. This minimum requires that the data portion be at least 38 bytes for 802.3 or 46 bytes for Ethernet. To handle this, pad bytes are inserted to assure that the frame is long enough.

Như vậy trong trường hợp này (Ethernet), số byte padding sẽ là 46 - 28 (cho ARP) = 18 hoàn toàn khớp với gói tin quanta đã capture.

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 10:03:10 (+0700) \| #7 \| 165166

kipu
Member

Joined: 13/05/2008 21:05:38
Messages: 18
Offline

thangdiablo wrote:

Hi Quân,

Trong 1 frame ngoài Frame Header thì phía cuối của mỗi frame còn có 1 phần gọi là Trailer.

Trong phần trailer có chứa 1 trường gọi là FCS ( Frame Check Sequent ). Trường FCS này có tác dụng dùng để kiểm tra khi nó tới 1 thiết bị xử lý từ layer 2 trở lên.
Các Router hay Switch sẽ nhìn vào FCS này để kiểm tra xem Frame có bị lỗi hay không dẫn tới quyết định tiếp tục gửi hay hủy gói frame này.

Bạn cho mình hỏi: ngoài FCS ra, trong Ethernet trailer còn cái gì nữa không? Hay là Ethernet trailer và FCS là một và có kích thước bằng 4 bytes?

P/S: Sequence chứ không phải Sequent.

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 10:05:29 (+0700) \| #8 \| 165167

No.13
Moderator

Joined: 25/08/2003 22:07:38
Messages: 500
Offline

Lời giải thích của boom_jt và zerozeroone là hợp lý cho cái frame 60 bytes (4 bytes FCS không được hiển thị)
Về cái frame 42 bytes, quanta xem thử có phải nó gửi đi từ chính máy local của bác không? Vì cái frame này chưa được đưa ra wire nên pad chưa được thêm vào. Bác qua cái máy remote thử xem cái frame này có được padded không?
@secmask: Có lẽ quanta dùng wireshark để "show hàng" cái file captured bằng tcpdump thôi.

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 10:24:49 (+0700) \| #9 \| 165171

quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline

No.13 wrote:

Lời giải thích của boom_jt và zerozeroone là hợp lý cho cái frame 60 bytes (4 bytes FCS không được hiển thị)

Ơ, thế 60 bytes này gồm những cái gì nhỉ?
14 bytes Ethernet header
28 bytes ARP reply
18 bytes Trailer

còn lại 4 bytes FCS (là nơi lưu giá trị CRC - Cyclic Redundancy Check) không được hiển thị. Vậy Trailer và FCS là 2 cái hoàn toàn tách biệt à?

No.13 wrote:

Về cái frame 42 bytes, quanta xem thử có phải nó gửi đi từ chính máy local của bác không? Vì cái frame này chưa được đưa ra wire nên pad chưa được thêm vào. Bác qua cái máy remote thử xem cái frame này có được padded không?

Em đã hiểu, cảm ơn bác nhiều.

Let's build on a great foundation!

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 10:32:23 (+0700) \| #10 \| 165173

zerozeroone
Member

Joined: 24/12/2006 13:29:23
Messages: 149
Offline

quanta wrote:

zerozeroone wrote:

Chào anh quanta,
Theo em thì mỗi Ethernet frame có kích thước tối thiểu là 64 bytes (đã bao gồm phần Ethernet trailer 4 bytes) hoặc 60 bytes (không bao gồm phần Ethernet trailer 4 bytes) hoặc 46 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes) và kích thước tối đa là 1500 bytes (không bao gồm phần Ethernet header 14 bytes và Ethernet trailer 4 bytes).
Các gói ARP bao gồm 28 bytes cho phần ARP message và 14 bytes Ethernet header như anh nói như vậy thì chỉ mới có 42 bytes, như vậy chưa đạt được kích thước tối thiểu nên chúng được "thêm vào " các byte 0 (padding) để đạt kích thước tối thiểu 60 bytes (không bao gồm Ethernet trailer).

Trong 42 bytes này đã bao gồm 14 bytes Ethernet header rồi mà:
Code:
14 = 6 (Dst addr) + 6 (Src addr) + 2 (Frame type)

à, thì em nói là trong 42 bytes này đã có Ethernet trailer rồi mà.

zerozeroone wrote:

...
Các gói ARP bao gồm 28 bytes cho phần ARP message và 14 bytes Ethernet header như anh nói như vậy thì chỉ mới có 42 bytes, như vậy chưa đạt được kích thước tối thiểu nên chúng được "thêm vào " các byte 0 (padding) để đạt kích thước tối thiểu 60 bytes (không bao gồm Ethernet trailer).

quanta wrote:

--> phần Ethernet trailer = 18 bytes?

Phần Ethernet trailer em hiểu là "phần còn lại" của một frame Ethernet ngoài trừ phần header và data. Sau khi đặt data vào trong frame thì nếu frame chưa đủ kích thước tối thiểu thì sẽ được 'padding" để đảm bảo kích thước tối thiểu. Nếu sau khi đặt data vào mà đã đảm bảo điều kiện thì phần trailer chỉ là phần FCS như thangdiablo đã nói.

Còn cái gói 42 bytes thì em nghĩ giống như No.13 đã nói, có thể cái frame này chưa được đưa xuống thiết bị truyền dẫn nên chưa được "pad" vào. Phần "padding" thường do các device driver hoặc các NIC thực hiện. Có thể là do thực hiện trên máy ảo nên có một số frame chưa được xử lý "đúng đắn" (do chưa đưa xuống wire). Em cũng đã thử thực hiện trên máy ảo và đều capture được cái gói tin chỉ có 42 bytes.

[Question] Re: Thảo luận thêm về một số vấn đề khi đọc TCP/IP	05/01/2009 11:38:37 (+0700) \| #11 \| 165186

zerozeroone
Member

Joined: 24/12/2006 13:29:23
Messages: 149
Offline

quanta wrote:

còn lại 4 bytes FCS (là nơi lưu giá trị CRC - Cyclic Redundancy Check) không được hiển thị. Vậy Trailer và FCS là 2 cái hoàn toàn tách biệt à?

Thế này nè anh:

zerozeroone wrote:

....
Phần Ethernet trailer em hiểu là "phần còn lại" của một frame Ethernet ngoài trừ phần header và data......

Như vậy nó bao gồm cả phần FCS. "Trailer" có thể dich là "phần đuôi" của frame.

Còn tại sao cái FCS nó không được hiển thị khi frame bị capture thì do các chương trình capture gói tin mình xài, anh tham khảo tại đây (Cái câu 7.10 đó): http://www.ethereal.com/faq.html#q7.10

[Discussion] Thảo luận thêm về một số vấn đề khi đọc TCP/IP	02/06/2009 05:52:48 (+0700) \| #12 \| 182594

quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline

Chào các bạn,

Mình muốn thảo luận thêm về trường TCP Window size. Theo mọi người thì:
- Ý nghĩa chính của Window size là gì?
- Trường này ảnh hưởng thế nào đến performance?
- Cách thay đổi các giá trị liên quan đến Window size trên mỗi hệ điều hành? Giá trị lớn nhất mà nó có thể nhận là bao nhiêu?
- ...

Let's build on a great foundation!

[Discussion] Thảo luận thêm về một số vấn đề khi đọc TCP/IP	02/06/2009 08:57:06 (+0700) \| #13 \| 182600

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

quanta wrote:

Chào các bạn,

Mình muốn thảo luận thêm về trường TCP Window size. Theo mọi người thì:
- Ý nghĩa chính của Window size là gì?
- Trường này ảnh hưởng thế nào đến performance?
- Cách thay đổi các giá trị liên quan đến Window size trên mỗi hệ điều hành? Giá trị lớn nhất mà nó có thể nhận là bao nhiêu?
- ...

- Window size là lượng thông tin mà receiver cho phép sender gửi đi mà chưa cần nhận ACK
- Giá trị này càng nhỏ thì lượng thông tin chuyển đi càng ít, và ngược lại. Tuy nhiên window size trong TCP packet lại chưa phải là thứ quyết định chủ yếu đến real performance của một TCP connection. Trong một topic trước của mình đã đề cập đến một vấn đề thú vị liên quan đến cái này, rất tiếc còn chưa đi đến hồi kết.
- Giá trị window thường dựa vào kích cỡ TCP buffer allocated cho socket tại thời điểm packet chuẩn bị được gửi đi. Việc thiết lập các tham số trong Linux thì có thể dùng sysctl, còn trong Windows thì mình chịu.
- Giá trị lớn nhất thì hình như có thể lên đến 1 GB thì phải.

Mind your thought.

[Discussion] Thảo luận thêm về một số vấn đề khi đọc TCP/IP	02/06/2009 10:07:06 (+0700) \| #14 \| 182606

quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline

StarGhost wrote:

- Window size là lượng thông tin mà receiver cho phép sender gửi đi mà chưa cần nhận ACK

Cái này là khái niệm rồi, mình muốn hỏi về ý nghĩa chính của nó?

StarGhost wrote:

- Giá trị này càng nhỏ thì lượng thông tin chuyển đi càng ít, và ngược lại. Tuy nhiên window size trong TCP packet lại chưa phải là thứ quyết định chủ yếu đến real performance của một TCP connection. Trong một topic trước của mình đã đề cập đến một vấn đề thú vị liên quan đến cái này, rất tiếc còn chưa đi đến hồi kết.

Chuyện gì xảy ra nếu window size quá nhỏ? Cho mình cái link của topic kia với.

StarGhost wrote:

- Giá trị window thường dựa vào kích cỡ TCP buffer allocated cho socket tại thời điểm packet chuẩn bị được gửi đi. Việc thiết lập các tham số trong Linux thì có thể dùng sysctl, còn trong Windows thì mình chịu.

Trên Windows thì mình tìm ra 2 cái khóa này:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts=1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowsize=[wmax]

Ngoài ra thì trên *BSD cũng hơi khác so với Linux.

StarGhost wrote:

- Giá trị lớn nhất thì hình như có thể lên đến 1 GB thì phải.

Ừ, window size thường dựa vào bandwidth và Round Trip Time (RTT). Chắc là window size 1GB tương đương với bandwidth 10Tb/s và RTT khoảng 100ms.

Let's build on a great foundation!

[Discussion] Về một số vấn đề khi đọc TCP/IP	02/06/2009 10:26:25 (+0700) \| #15 \| 182609

mfeng
Researcher

Joined: 29/10/2004 15:16:29
Messages: 243
Offline

Windows size liên quan tới khái niệm Congestion Control và Flow Control. Thông thường nếu mỗi một segment gửi đi xong mà sender mà chờ ACK từ receiver rồi mới gửi segment tiếp theo, thì throughput sẽ quá thấp so với bandwidth. Vì vậy mới cần giải pháp pipeline, mà Window size có thể coi là số lượng segment gửi đi liên tục theo pipeline trước khi nhận được ACK.

[Discussion] Thảo luận thêm về một số vấn đề khi đọc TCP/IP	02/06/2009 11:49:21 (+0700) \| #16 \| 182614

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

quanta wrote:

StarGhost wrote:

- Window size là lượng thông tin mà receiver cho phép sender gửi đi mà chưa cần nhận ACK

Cái này là khái niệm rồi, mình muốn hỏi về ý nghĩa chính của nó?

À, ý nghĩa của window size là để giảm thiểu vấn đề các packets bị gửi đi rồi lại phải gửi lại.

quanta wrote:

StarGhost wrote:

- Giá trị này càng nhỏ thì lượng thông tin chuyển đi càng ít, và ngược lại. Tuy nhiên window size trong TCP packet lại chưa phải là thứ quyết định chủ yếu đến real performance của một TCP connection. Trong một topic trước của mình đã đề cập đến một vấn đề thú vị liên quan đến cái này, rất tiếc còn chưa đi đến hồi kết.

Chuyện gì xảy ra nếu window size quá nhỏ? Cho mình cái link của topic kia với.

/hvaonline/posts/list/28875.html. Performance của TCP phụ thuộc vào cái gọi là TCP congestion control, chủ yếu diễn ra ở phía sender.

quanta wrote:

StarGhost wrote:

- Giá trị lớn nhất thì hình như có thể lên đến 1 GB thì phải.

Ừ, window size thường dựa vào bandwidth và Round Trip Time (RTT). Chắc là window size 1GB tương đương với bandwidth 10Tb/s và RTT khoảng 100ms.

Không, cái window size mà bạn nói là actual window size, còn cái window size trong TCP header thì không dựa vào bandwidth cũng không dựa vào RTT, vì cái window size trong TCP header là maximum allowed, và quyết định bởi receiver.

Mind your thought.

[Discussion] Thảo luận thêm về một số vấn đề khi đọc TCP/IP	02/06/2009 12:27:22 (+0700) \| #17 \| 182615

zerozeroone
Member

Joined: 24/12/2006 13:29:23
Messages: 149
Offline

StarGhost wrote:

quanta wrote:

StarGhost wrote:

- Window size là lượng thông tin mà receiver cho phép sender gửi đi mà chưa cần nhận ACK

Cái này là khái niệm rồi, mình muốn hỏi về ý nghĩa chính của nó?

À, ý nghĩa của window size là để giảm thiểu vấn đề các packets bị gửi đi rồi lại phải gửi lại.

- Nói cho dễ hiểu thì nó giải quyết tình trạng tràn ngập dữ liệu bên nhận, do bên gửi gửi quá nhanh, bên nhận xử lý không kịp. Do đó dẫn đến tình trạng các packets đã gửi đi phải được gửi lại.

StarGhost wrote:

quanta wrote:

Ừ, window size thường dựa vào bandwidth và Round Trip Time (RTT). Chắc là window size 1GB tương đương với bandwidth 10Tb/s và RTT khoảng 100ms.

Không, cái window size mà bạn nói là actual window size, còn cái window size trong TCP header thì không dựa vào bandwidth cũng không dựa vào RTT, vì cái window size trong TCP header là maximum allowed, và quyết định bởi receiver.

- Thực chất thì cái trường window size trong TCP header chỉ có 16 bits nên tối đa là 2^16 bytes, để mở rộng nó thì người ta dùng thêm 1 phần trong trường Option của nó (hình như là window scale) để có thể tăng cái window size maximum lên 1GB.

[Discussion] Về một số vấn đề khi đọc TCP/IP	02/06/2009 12:47:03 (+0700) \| #18 \| 182616

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Chuyện gì xảy ra nếu window size quá nhỏ?

Theo em nghĩ window size quá nhỏ ảnh hưởng tới tcp performance, nếu window size nhỏ thì quá trình gửi nhận dữ liệu sẽ lâu.
Nếu nói window size của receiver là 1 byte, có nghĩa: receiver chỉ có thể tiếp nhận tối đa 1 byte một lần client gửi dữ liệu trược khi nhận ACK.
Nhưng nếu như thế tại sao không thiết lập window size lên 1 GB cho nhanh, mà còn giảm thiểu nguy cơ TCP buffer overload nhỉ?

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"

[Discussion] Về một số vấn đề khi đọc TCP/IP	02/06/2009 13:04:43 (+0700) \| #19 \| 182617

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

mR.Bi wrote:

Chuyện gì xảy ra nếu window size quá nhỏ?

Theo em nghĩ window size quá nhỏ ảnh hưởng tới tcp performance, nếu window size nhỏ thì quá trình gửi nhận dữ liệu sẽ lâu.
Nếu nói window size của receiver là 1 byte, có nghĩa: receiver chỉ có thể tiếp nhận tối đa 1 byte một lần client gửi dữ liệu trược khi nhận ACK.
Nhưng nếu như thế tại sao không thiết lập window size lên 1 GB cho nhanh, mà còn giảm thiểu nguy cơ TCP buffer overload nhỉ?

TCP tuning có 2 kĩ thuật chính, là flow control, và congestion control. Flow control được thể hiện bởi giá trị window xuất hiện trong TCP header, còn congestion control là giá trị local cho mỗi peer. Câu hỏi của bạn mình hiểu là: tại sao lại phải dùng giá trị window size này làm gì, sao không set nó lên 1GB hoặc cao hơn?

Câu trả lời: tốc độ truyền thông tin thường cao hơn tốc độ xử lý thông tin, nếu bạn set window size lên 1GB thì rất nhanh buffer cho socket của receiver sẽ bị đầy, dẫn đến việc packet đến nhưng bị discarded. Vì vậy việc set window size trong TCP header là rất quan trọng, và nó thường phụ thuộc vào kích cỡ hiện tại của buffer cho socket bên receiver.

Ngược lại, ở phía sender thì việc đầy sending buffer do window size thấp không gây ra hậu quả gì cả, vì nó sẽ chỉ dẫn đến việc applications ở phía trên bị blocked thôi.

Mind your thought.

[Discussion] Thảo luận thêm về một số vấn đề khi đọc TCP/IP	02/06/2009 23:13:49 (+0700) \| #20 \| 182642

quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline

StarGhost wrote:

quanta wrote:

StarGhost wrote:

- Giá trị lớn nhất thì hình như có thể lên đến 1 GB thì phải.

Ừ, window size thường dựa vào bandwidth và Round Trip Time (RTT). Chắc là window size 1GB tương đương với bandwidth 10Tb/s và RTT khoảng 100ms.

Không, cái window size mà bạn nói là actual window size, còn cái window size trong TCP header thì không dựa vào bandwidth cũng không dựa vào RTT, vì cái window size trong TCP header là maximum allowed, và quyết định bởi receiver.

Đúng rồi, mình nhầm. Cái actual window size mà bạn nói tới chính là Bandwidth-delay product (BDP) à?

mR.Bi wrote:

Chuyện gì xảy ra nếu window size quá nhỏ?

Theo em nghĩ window size quá nhỏ ảnh hưởng tới tcp performance, nếu window size nhỏ thì quá trình gửi nhận dữ liệu sẽ lâu.
Nếu nói window size của receiver là 1 byte, có nghĩa: receiver chỉ có thể tiếp nhận tối đa 1 byte một lần client gửi dữ liệu trược khi nhận ACK.
Nhưng nếu như thế tại sao không thiết lập window size lên 1 GB cho nhanh, mà còn giảm thiểu nguy cơ TCP buffer overload nhỉ?

Theo mình, nếu window size quá cao có thể dẫn đến 2 hậu quả:
1. Chiếm dụng nhiều bộ nhớ, hết buffer space, các kết nối mới không mở được
2. Khi xảy ra bottleneck, các segments/packets liên tiếp nhau sẽ chiếm đầy bộ đệm --> buffer overflows và dẫn đến nhiều segments sẽ bị dropped.

Let's build on a great foundation!

[Discussion] Về một số vấn đề khi đọc TCP/IP	02/06/2009 23:24:49 (+0700) \| #21 \| 182643

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

@quanta: actual window size là min của 2 window sizes, một cái quyết định bởi receiver (flow control), và cái kia quyết định bởi sender (congestion control).

BDP vs window size: lượng max data được gửi đi trong network mà chưa được nhận vs lượng max data được gửi đi trong network mà chưa được công nhận (acknowledged).

Mind your thought.

[Discussion] Về một số vấn đề khi đọc TCP/IP	03/06/2009 00:16:03 (+0700) \| #22 \| 182644

camazalraman
Member

Joined: 19/05/2004 01:57:32
Messages: 23
Offline

mR.Bi wrote:

Chuyện gì xảy ra nếu window size quá nhỏ?

Theo em nghĩ window size quá nhỏ ảnh hưởng tới tcp performance, nếu window size nhỏ thì quá trình gửi nhận dữ liệu sẽ lâu.
Nếu nói window size của receiver là 1 byte, có nghĩa: receiver chỉ có thể tiếp nhận tối đa 1 byte một lần client gửi dữ liệu trược khi nhận ACK.
Nhưng nếu như thế tại sao không thiết lập window size lên 1 GB cho nhanh, mà còn giảm thiểu nguy cơ TCP buffer overload nhỉ?

Mình thấy đoạn này trên wiki khá hay, làm rõ một số vấn đề mọi người đang thắc mắc
http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Flow control

TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to reliably receive and process it. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate. For example, when a fast PC sends data to a slow hand-held PDA, the PDA needs to regulate the influx of data, or protocol software would be overrun quickly.[2] Similarly, flow control is essential if the application that is receiving the data is reading it more slowly than the sending application is sending it.

TCP uses a sliding window flow control protocol. In each TCP segment, the receiver specifies in the receive window field the amount of additional received data (in bytes) that it is willing to buffer for the connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host.
When a receiver advertises a window size of 0, the sender stops sending data and starts the persist timer. The persist timer is used to protect TCP from a deadlock situation that could arise if the window size update from the receiver is lost and the sender has no more data to send while the receiver is waiting for the new window size update. When the persist timer expires, the TCP sender sends a small packet so that the receiver sends an acknowledgement with the new window size.

If a receiver is processing incoming data in small increments, it may repeatedly advertise a small receive window. This is referred to as the silly window syndrome, since it is inefficient to send only a few bytes of data in a TCP segment, given the relatively large overhead of the TCP header. TCP senders and receivers typically employ flow control logic to specifically avoid repeatedly sending small segments. The sender-side silly window syndrome avoidance logic is referred to as Nagle's algorithm.

Congestion control

The final main aspect of TCP is congestion control. TCP uses a number of mechanisms to achieve high performance and avoid 'congestion collapse', where network performance can fall by several orders of magnitude. These mechanisms control the rate of data entering the network, keeping the data flow below a rate that would trigger collapse.

Acknowledgments for data sent, or lack of acknowledgments, are used by senders to infer network conditions between the TCP sender and receiver. Coupled with timers, TCP senders and receivers can alter the behavior of the flow of data. This is more generally referred to as congestion control and/or network congestion avoidance.

Modern implementations of TCP contain four intertwined algorithms: Slow-start, congestion avoidance, fast retransmit, and fast recovery (RFC2581).

In addition, senders employ a retransmission timer that is based on the estimated round-trip time (or RTT) between the sender and receiver, as well as the variance in this round trip time. The behavior of this timer is specified in RFC 2988. There are subtleties in the estimation of RTT. For example, senders must be careful when calculating RTT samples for retransmitted packets; typically they use Karn's Algorithm or TCP timestamps (see RFC 1323). These individual RTT samples are then averaged over time to create a Smoothed Round Trip Time (SRTT) using Jacobson's algorithm. This SRTT value is what is finally used as the round-trip time estimate.

Enhancing TCP to reliably handle loss, minimize errors, manage congestion and go fast in very high-speed environments are ongoing areas of research and standards development. As a result, there are a number of TCP congestion avoidance algorithm variations.

[Discussion] Về một số vấn đề khi đọc TCP/IP	03/06/2009 23:48:04 (+0700) \| #23 \| 182706

Mr.Khoai
Moderator

Joined: 27/06/2006 01:55:07
Messages: 954
Offline

anh quanta,

Nếu mình có nhiều buffer quá thì sao nhỉ? Ví dụ, mình có thật nhiều RAM, và có thể cung cấp ~ 10Gb RAM cho networking system thì bufffer bị fill sẽ không phải là vấn đề. Vậy, còn vấn đề nào khác khi TCP windows size quá cao (hoặc network buffer quá lớn) hay không?

khoai

Go to:

Users currently in here
1 Anonymous