Messages posted by: StarGhost

rongthien87 wrote:

em đang tìm hiểu về bảo mật và thâm nhập , rất cần tài liệu về nó , huhu, anh em có ai có tài liệu hay có thể share cho em hay không ? Xin cảm ơn và hậu tạ.
Chúc diễn đàn thành công

hoangtu256 wrote:

bạn có gì cứ share cho anh em đi. Càng nhiều càng tốt mà, đọc không kiệp thì từ từ đọc cũng được.

Thế vậy những thứ trong HVA library và phòng đọc chắc là vô giá trị.

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).

Trời, thời đại khủng hoảng này mà mình không hiểu sao lại có suất đi du học bên Mỹ mà đến ngành học cũng còn không biết. Không biết suất học của bạn do univ nào cấp mà flexible thế, mình biết mình cũng thử mon men một phát.

@thangdiablo: vậy mình mới không dám nói chắc. Nếu bạn có thời gian, mình đề nghị bạn thay vì dùng show cpu process, thử dùng show interface để xem lượng traffic ra/vào 2 ports bị loop xem thế nào. Sau đó, bạn thử disable spanning-tree và kiểm tra lại rồi so sánh kết quả.

Còn đối với switch thường như của bạn huan_ng, khi mà khó có thể kiểm tra như Cisco switch, thì mình đề nghị thay vì nối trực tiếp hai ports để tạo loop, ta có thể nối 2 ports với một cái hub, và nối một PC với cái hub đó để kiểm tra xem traffic của cái loop đó ra sao.

thangdiablo wrote:

---> Ồ, thế bây giờ mình có 2 PCs riêng lẻ, sau đó mình mua một cái switch mới tinh về, cắm vào 2 PCs đó. Giả sử mỗi PC tiến hành gửi một packet đầu tiên đến PC còn lại cùng một lúc, vậy có xảy ra collision không? Để cho đơn giản, cứ giả sử mỗi PC đều biết MAC của PC kia.

Theo mình là có, vì ngay tại lúc này 2 host đang sử dụng chung 1 collision domain.

Theo suy nghĩ chủ quan của mình thì sẽ không có collision. Mình nói chủ quan là vì mình còn chưa kiểm chứng nên không dám nói chắc. Thôi để lúc nào mình có thời gian test thì sẽ bàn tới sau vậy. Ngoài ra, mình cho rằng kể cả switch có hỗ trợ STP thì vẫn bị "ngu" như thường. Tuy nhiên, cũng chưa có result chống lưng nên đành để sau vậy.

@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.

thangdiablo wrote:

Nếu switchs loại " xịn " như cisco hay nortel thì tự bản thân switch sẽ có cơ chế STP. Nếu xảy ra tình trạng loop thì 1 trong 2 port kết nối trực tiếp với nhau sẽ bị block lại.

Còn nếu là switch loại " dỏm " nếu xảy ra tình trạng loop thì bảng CAM trên switch sẽ bị tràn, do dữ liệu chạy vòng vòng dẫn tới khả năng switch bị treo.

Collision domain thường không xảy ra trong switch. Vì mỗi port trên switch đều là 1 collision domain riêng biệt.
Collision domain xảy ra khi 1 gói tin được gửi ra từ 1 host thì gói này nó sẽ chạy tới tất cả các port còn lại. Do đó, nếu trong cùng 1 thời điểm có 2 hay nhiều host gửi ra đồng thời sẽ dẫn tới việc nghẽn mạng.

---> Ý kiến hay, cái này mình lúc đó chưa nghĩ tới. Nhưng nếu switch bị "ngu" đi như bạn OP đề cập, thì chắc nó không có khả năng này.
---> Cái này mình nghĩ là không phải, vì mình cho rằng switch sẽ update CAM table chứ không add thêm entries, nên CAM table chắc không bị tràn (subject to implementation). Hơn nữa, cái vòng lặp này sẽ bị terminated rất nhanh, trong tầm vài ms thôi.
---> Ồ, thế bây giờ mình có 2 PCs riêng lẻ, sau đó mình mua một cái switch mới tinh về, cắm vào 2 PCs đó. Giả sử mỗi PC tiến hành gửi một packet đầu tiên đến PC còn lại cùng một lúc, vậy có xảy ra collision không? Để cho đơn giản, cứ giả sử mỗi PC đều biết MAC của PC kia.

@consoko: bạn còn chưa đọc kĩ bài của mình. Còn bạn huan_ng do chưa rõ nên mới nghĩ là do collision, bạn hỏi lại như thế cũng bằng thừa.

@huan_ng: bạn cứ thử vẽ sơ đồ ra, rồi thử hình dung từng bước khi một packet được gửi từ một PC qua cái switch đó, giả sử rằng CAM table của nó trống trơn, thì bạn sẽ thấy vấn đề ngay.

Ồ, thực ra thì điều này cũng dễ hiểu thôi. Khi bạn gửi một packet đến một peer mới kết nối vào mạng, thì switch sẽ broadcast packet này, dẫn đến việc switch nhận định sai về port mà nó dùng để kết nối đến máy của bạn. Vì vậy khi cái peer kia gửi packet đến máy bạn, nó sẽ mãi mãi bị gửi vào cái port sai (mãi mãi là vì khi gửi đi nó sẽ quay lại switch và lại bị gửi đi).

Như vậy bạn có thể gửi packet đi đến peer nhưng không thể nhận được packet từ peer gửi lại. Tuy nhiên nếu MAC của máy bạn và peer xuất hiện trên CAM table của switch ngay từ đầu thì không có vấn đề gì.

@myquartz: hình như bạn không rành lắm về việc linux kernel xử lý cái khoản network thế nào ấy nhỉ? Ở trên mrro đã có nhắc đến vấn đề cookies rồi.

SYN flooding ít hiệu quả không phải là vì đã có một fancy mechanism để chống lại nó (kể cả syn cookies cũng chỉ là cực chẳng đã thôi), mà là vì các tay admin có trình độ thì biết cách tune system để "sống chung với lũ", cộng thêm khả năng của hệ thống. Chính vì vậy, nếu một hệ thống hoặc là có ít tài nguyên, hoặc là được quản lý bởi một tay mơ thì việc SYN flooding thành công là đương nhiên, và không cần thiết phải làm nghẽn đường truyền, vì bản thân SYN flooding cũng khó mà làm được như vậy. Những hệ thống như vậy thì nhan nhản ra.

mrro wrote:

@StarGhost: mình thấy bạn myquartz đề cập đến cái syncookies vì bạn ấy cho rằng chỉ cần kích hoạt syncookies thì không cần quan tâm đến giá trị của tcp_synack_retries, điều mà mình tin là sai, còn sai như thế nào thì hai bạn thảo luận tiếp đi nha, mình chưa từng bao giờ coi code phần network stack của linux kernel cũng như chưa bị tấn công DDoS nặng nề nên mình không biết .

À, cái này có lẽ là do trong Linux khi set tcp_syncookies=1 không có nghĩa là lúc nào syn cookies cũng được dùng. Còn ý của bạn myquartz mình nghĩ là về mặt nguyên tắc thôi. Mà mrro cần gì phải đợi tấn công DDoS nặng nề, cứ tự tấn công mình là rõ ngay ấy mà. Với lại mrro có mấy con servers hàng khủng, làm công cụ tấn công thì quá ổn.

myquartz wrote:

Có mấy ý kiến phản hồi nhỏ với chuyên gia StarGhost.

Ý gì đây?

myquartz wrote:

StarGhost wrote:

Khi một hệ thống bị DDoS (SYN-flooding), nhiều khả năng backlog sẽ bị đầy, và OS không thể nhận thêm connections, và phải đợi cho đến khi lifetime của một số connections kết thúc thì mới tiếp tục nhận SYN. Như vậy, việc tăng số lượng retries sẽ khiến tình hình trở nên tồi tệ hơn, vì OS sẽ không có khả năng nhận thêm connections trong một khoảng lớn thời gian (e.g., 180s).

Điều này đúng, nhưng cũng là không đúng vì bất kể lifetime dài hay ngắn, OS cũng ko thể tiếp nhận được thêm kết nối khi đó => kết quả đều là toi như nhau và hầu như ko thể tồi tệ hơn.

Bây giờ mình có một hệ thống có lifetime của half-open connections là 20s, bây giờ mình tăng số retries sao cho nó lên đến 100s, mình không hiểu bạn nghĩ sao mà lại nói hầu như không thể tồi tệ hơn.

myquartz wrote:

- Sai: Khi bị SYN flooding, việc mất packet sẽ vẫn ít khi xảy ra (nghĩa là không có tắc nghẽn), bởi đơn giản là là gói SYN nó rất bé và thường thì khả năng đáp ứng của đg truyền của server là thừa sức. SYN flood là cách tấn công của những client có băng thông nhỏ, với mục tiêu tốn ít để đạt đc kết quả. Nó làm cho server đầy backlog không thể nhận thêm kết nối chứ không phải là nhằm làm cho đường truyền bị nghẽn. Nếu muốn làm đường truyền nghẽn, người ta gửi gói thật to như là ICMP to hay UDP to, chứ không gửi gói TCP SYN bé tí làm gì.

Ồ, việc mất bất cứ một packet nào trong 3 thứ SYN, SYN_ACK, ACK đều dẫn đến việc legitimate users không thể tạo connection, sao bạn chỉ nhắc đến mỗi SYN thôi vậy. Hơn nữa, vấn đề không phải ở chỗ khả năng packet bị lost cao bao nhiêu, mà là khả năng packet cần retransmission cao bao nhiêu. Nếu bạn vẫn cho rằng không cao (đặc biệt là khi bị flooded), thì mình xin hỏi là do bạn đã thực nghiệm cẩn thận nhiều lần, hoặc tham khảo từ đâu đó, hay chỉ là ý kiến chủ quan. Về phần mình, mình đề nghị bạn xem qua paper titled "Studies of TCP's Retransmission Timeout Mechanism". À quên mất, mình thích dùng từ DDoS hơn là SYN flooding.

myquartz wrote:

Cách người ta chống back-log bị đầy: ví dụ Linux nó dùng Syn Cookies http://en.wikipedia.org/wiki/Syn_cookies), Khi back-log bị đầy, linux host vẫn trả lời gói SYN gửi tới bằng 1 gói tin SYN-ACK với cái sequence là 1 giá trị được tính toán đặc biệt gọi là cookie, nó không cần lưu cái haft connection này và không cần back-log buffer đang bị đầy kia. Nếu client xịn, nó sẽ reply cái gói SYN-ACK của server kia bằng 1 gói ACK có chứa cái seq đúng là cái cookie của server kia. Server nhận được gói ACK, check được đúng cookies mà mình gửi, cho dù không tìm được haft connection trong backlog tương ứng với cái ACK này (lúc trước có lưu đâu?), nó vẫn cho tạo kết nối và kết nối được thiết lập với đủ 3 bước, và mặc kệ cái back-log đang bị full.
Tất nhiên lúc này sẽ chậm hơn 1 chút đối với các client xịn mà có đường truyền tệ, vì nếu SYN-ACK trả lời mà bị mất, server sẽ không retries việc gửi này (vì có lưu lại đâu mà biết retry?), client sẽ buộc phải gửi lại SYN mới và sẽ nhận SYN-ACK khác. Tham số retries lúc này cũng vô nghĩa.
Và mọi thứ vẫn chạy được, kệ SYN flooding.

Hì, có vẻ bạn myquartz hay có bệnh lan man, topic nói về một chuyện thì bạn lại cứ bàn sang chuyện khác.

@ham_choi: bạn nghĩ thế cũng vui, nhưng mà thế là oan cho mình lắm nhé. Mình không có "chọt" đâu, mà nói thật là load rất lâu. Cái topic truyện tranh của bạn mình bật nó lên, định xem, thấy load lâu quá, thế là để đấy đi ăn cơm, xong vào thấy vẫn đang load.

p/s: chết thật, lại "lộn" topic rồi.

Ồ, bạn ham_choi nói winrar chỉ xài được 45 ngày, sao mình chưa bao giờ phải đăng ký key nhỉ? Mình nghĩ cái file bạn ghostman download về bị corrupt thế nào đó rồi, vì nếu icon của nó là foxit thay vì winrar, hiển nhiên tức là extension của nó là .pdf, chứ không phải là .gz. Mình đề nghị bạn ghostman download lại thử xem, và nhớ so sánh kích cỡ file với con số ghi trên website.

p/s: sao mấy cái topic có hình của bạn ham_choi là máy mình load rất lâu, ví dụ topic truyện cười trước máy mình mất 15 phút mới load xong, còn topic này thì mất 2 phút, trong khi đó chỗ mình dùng Fast Ethernet lận.

SYN, SYN/ACK retransmission là cách thức TCP đối phó với việc các packets loại này bị mất trong network. Số lượng synack retranmissions quyết định lifetime của một half-opend connection: retries càng nhiều thì lifetime càng lâu, và ngược lại.

Khi một hệ thống bị DDoS (SYN-flooding), nhiều khả năng backlog sẽ bị đầy, và OS không thể nhận thêm connections, và phải đợi cho đến khi lifetime của một số connections kết thúc thì mới tiếp tục nhận SYN. Như vậy, việc tăng số lượng retries sẽ khiến tình hình trở nên tồi tệ hơn, vì OS sẽ không có khả năng nhận thêm connections trong một khoảng lớn thời gian (e.g., 180s).

Việc giảm số lượng retries ở một khía cạnh nhỏ có hiệu ứng tốt, vì half-opened connection lifetime sẽ giảm, dẫn đến OS sẽ nhanh chóng loại bỏ half-opened connections và nhận các SYN mới. Tuy nhiên, điều đó cũng có nghĩa là khả năng legitimate peer có thể connect đến cũng giảm mạnh, vì 2 lí do:
- Trong khi bị DDoS, legitimate peers có rất ít cơ hội để nhảy vào được backlog.
- (cũng) trong khi bị DDoS (massively), việc packets loss là đương nhiên (gồm syn, syn/ack, ack), nên retransmission là cần thiết.

Cuối cùng, việc giảm số lượng retries không thực sự cải thiện được tình hình DDoS, vì attacker chỉ cần tăng attack frequency thì mọi việc lại như cũ.

Hai hành động trên thực hiện được bạn ạ. Cách triệt để nhất là dùng encryption, ví dụ HTTPS khi login.

Ồ, nếu tính bằng tay thì không có cách nào bạn ạ. Cách duy nhất là thử lại, và bằng tay thì cũng làm được nhưng... lâu. Một trong những cách test là đem so sánh kết quả của mình với kết quả từ một state-of-the-art program. Mình recommend Mathematica, một symbolic computing software chưa bao giờ tính sai.

Đây là kết quả của 1000!, còn nếu cần 2000! thì cứ pm mình. Đảm bảo nhanh gọn. Tính giai thừa vài nghìn thì đâu có lâu gì đâu.

4023872600770937735437024339230039857193748642107146325437999104299385\
1239862902059204420848696940480047998861019719605863166687299480855890\
1323829669944590997424504087073759918823627727188732519779505950995276\
1208749754624970436014182780946464962910563938874378864873371191810458\
2578364784997701247663288983595573543251318532395846307555740911426241\
7474349347553428646576611667797396668820291207379143853719588249808126\
8678383745597317461360853795345242215865932019280908782973084313928444\
0328123155861103697680135730421616874760967587134831202547858932076716\
9132448426236131412508780208000261683151027341827977704784635868170164\
3650241536913982812648102130927612448963599287051149649754199093422215\
6683257208082133318611681155361583654698404670897560290095053761647584\
7728421889679646244945160765353408198901385442487984959953319101723355\
5566021394503997362807501378376153071277619268490343526252000158885351\
4733161170210396817592151090778801939317811419454525722386554146106289\
2187960223838971476088506276862967146674697562911234082439208160153780\
8898939645182632436716167621791689097799119037540312746222899880051954\
4441428201218736174599264295658174662830295557029902432415318161721046\
5832036786906117260158783520751516284225540265170483304226143974286933\
0616908979684825901254583271682264580665267699586526822728070757813918\
5817888965220816434834482599326604336766017699961283186078838615027946\
5955131156552036093988180612138558600301435694527224206344631797460594\
6825731037900840244324384656572450144028218852524709351906209290231364\
9327349756551395872055965422874977401141334696271542284586237738753823\
0483865688976461927383814900140767310446640259899490222221765904339901\
8860185665264850617997023561938970178600408118897299183110211712298459\
0164192106888438712185564612496079872290851929681937238864261483965738\
2291123125024186649353143970137428531926649875337218940694281434118520\
1580141233448280150513996942901534830776445690990731524332782882698646\
0278986432113908350621709500259738986355427719674282224875758676575234\
4220207573630569498825087968928162753848863396909959826280956121450994\
8717012445164612603790293091208890869420285106401821543994571568059418\
7274899809425474217358240106367740459574178516082923013535808184009699\
6372524230560855903700624271243416909004153690105933983835777939410970\
0277534720000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
000000000000000000000000000000000000000000000000

Mr.Khoai wrote:

TCP có segmentation không nhỉ. Cứ nghĩ chỉ có IP là có fragmentation. Nếu vậy, hai field để xách định fragmentation sẽ là: MF (more fragment bit) và Fragmentation offset.

1. Nếu MF == 0, Frag. offset == 0: Đây là một gói IP hoàn chỉnh (hoặc là một TCP segment nằm trong một gói IP hoàn chỉnh)
2. Nếu MF == 1, Frag. offset == 0: Đây là segment đầu tiên của một IP packet.
3. Nếu MF == 0, Frag. offset != 0: Đây là segment cuối cùng của một IP packet.
4. Nếu MF == 1, Frag. offset != 0: Đây là một segment nào đó ở khoản giữa của một IP packet (đã bị segment).

Mỗi gói IP có một TCP segment nằm bên trong, nên mới có vụ "TCP Segment of a reassembled PDU".

MF và Fragementation offset chỉ dùng cho IP fragmentation thôi, thế nên chúng không thể dùng để phân biệt giữa một TCP segment nằm độc lập và một TCP segment cuối cùng.

Tại sao? Bởi vì trong TCP cũng không có khái niệm segment fragmentation. Trong cái câu "TCP segment of a reassembled PDU", thì cái từ PDU này không phải chỉ IP packet, cũng không phải chỉ TCP segment, mà chính là để chỉ một data unit của application layer protocol, ví dụ như một HTTP POST request, hoặc một HTTP reply.

Một PDU của HTTP có thể lớn, và nó phải bao gồm nhiều TCP segments. Chính vì vậy, cái bị fragmented không phải là TCP segment, mà chính là HTTP request/reply, rồi bị chia ra nhiều TCP segments. Trong số segments đó, cái cuối cùng có PUSH flag set để đảm bảo 2 mục đích đã đề cập ở trên.

Mr.Khoai wrote:

Còn thông tin về phần Continuation or Non-HTTP traffic thì wireshark chỉ hiển thị khi HTTP traffic (trên port 80) ở dạng binary thay vì toàn là text (hình ảnh, phim, applet, flast vân vân). Mình thử chạy HTTPS trên port 80 thì hình như cũng có thông báo tương tự.

Như đã nói ở trên, "Continuation or Non-HTTP traffic" xảy ra trong các trường hợp sau:
- Một trong 2 ports là 80 (HTTP), và TCP checksum bị sai.
- Một trong 2 ports là 80 (HTTP), và wireshark không thể interpret nổi cấu trúc của HTTP message, ví dụ như khi không có HTTP header, như trong trường hợp Mr.Khoai sử dụng HTTPS trên port 80.

@zerozeroone: một câu hỏi hay. Tuy nhiên, theo hiểu biết của mình thì không có sự khác nhau nào để có thể phân biệt nếu mang 2 packets của 2 dạng đó ra so sánh với nhau.

@quanta: digging expert smilie

OK. Khi bạn enable offload checksum, wireshark sẽ chỉ thấy TCP packet với incorrect checksum (vì chúng chưa được calculated). Như vậy wireshark sẽ không cố gắng intepret payload đằng sau TCP header nữa mà coi payload đó đơn giản là một data stream. Thêm vào đó, vì một trong các port là 80 (HTTP), nên status của packet trở thành "Continuation or non-HTTP Traffic".

Khi bạn disable offload checksum, wireshark sẽ thấy TCP packet với correct checksum (vì chúng đã được calculated bởi OS). Câu hỏi là tại sao wireshark có thể phân biệt giữa một TCP segment và một fragment của segment khi mà checksum của cả hai đều correct.

Câu trả lời nằm ở chỗ OS handle TCP segment như thế nào trước khi nó được gửi đi:

- ở tầng transport, data stream được đóng gói vào TCP segment, cũng giống như chúng ta đóng đồ vào thùng hàng trước khi gửi đi.
- Thường thì chúng ta đợi đóng đầy thùng rồi mới gửi đi (cho tiết kiệm). OS cũng vậy, nó thường đợi data stream đến khi một TCP segment được filled đầy rồi mới gửi đi.
- Vậy nếu data stream chỉ có đến vậy mà không fill đầy một segment thì chẳng lẽ OS cứ đợi mãi? Không, cứ mỗi khi application thực hiện một send (write) syscall, thì syscall này sẽ làm nhiệm vụ fill segment, và đến khi nó không còn data nữa thì nó sẽ bắt OS đóng gói TCP và gửi đi.
- Nếu data stream nhiều hơn một TCP segment, thì một segment sẽ bị filled đầy trước khi data stream kết thúc, dẫn đến việc OS tiến hành đóng gói và gửi segment đó đi mà không cần application phải nhắc nhở. Việc nhắc nhở chỉ xuất hiện sau khi toàn bộ data stream đã kết thúc.
- Để thể hiện sự nhắc nhở này, OS set PUSH flag trong TCP option của segment cuối trong data stream. Còn các segments trước đó của cùng một data stream thì có PUSH flag unset.

Như vậy, wireshark nhận biết sự khác nhau giữa một TCP segment hoàn chỉnh và một fragmented segment qua PUSH flag.

Trust that helps.

@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).

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.

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.

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.

Bạn cho rằng bạn đuối hay là quyển sách nó đuối? Nếu bạn đuối thì bạn nên xem lại động lực và mục đích học assembly của bạn. Còn nếu bạn cho rằng quyển sách nó đuối thì mình khuyên bạn nên tìm hiểu kĩ hơn, chứ mình thấy quyển sách đó phù hợp cả khi bạn cần tra cứu lẫn khi bạn muốn học một cách hệ thống, vì cách thức bố trí rất logic. Hơn nữa để học được assembly bạn cũng không nhất thiết phải đọc hết 1500 trang sách, bạn phải tự lựa chọn ra những gì cần đọc.

Còn link CD thì rất tiếc là mình không có.

Thân mến.

Mình lúc mới bắt đầu học assembly cũng học từ cuốn art of assembly language. Bạn nói thử xem như thế nào là không phù hợp?

zerozeroone wrote:

Khi mình làm VPN site to site thì trên hai cái VPN server, mỗi cái nó sẽ add route đến cái LAN bên kia. Như thế nếu hai cái LAN hai bên nó cùng subnet thì chuyện gì sẽ xảy ra? Khi cần trao đổi với các máy ở LAN bên kia thì cái route đó đúng, rồi khi cần trao đổi với các máy trên cùng cái LAN với nó thì nó cũng theo cái route đó để đi thì làm sao mà có thể tới được.

Thế nếu mình biến hai cái VPN servers đó từ 2 cái routers thành 2 cái switches thì sao hả bạn?

myquartz wrote:

Bạn này hỏi ko rõ khiến mọi người nhầm. Không phải là hỏi về VPN, mà là AD.

Ơ, sao bạn biết hay vậy?

St Konqueror wrote:

@ Doorkeeper: Bạn có phải là tác giả bài này hay không? Nếu không phải thì tôi không có ý kiến. nhưng nếu bạn là tác giả thì bạn post bài trên nhiều forum để làm gì, phải chăng là 1 hình thức câu bài?

Câu trả lời là đây:

Doorkeeper wrote:

Bài viết này Mod XuanHy viết dành riêng cho diễn đàn Ubuntu-Vn.org

vantam09 wrote:

Mình có 1 câu hỏi mà tìm hiểu mãi vẫn chưa trả lời được, mong được các anh em hổ trợ!

Mình có 2 site; site1 là forest, site2 là tree (dùng VPN site to site để kết nối 2 site).
Tại sao range IP Wan của site2 không được cùng range với range IP Wan của site1; range IP Lan của site2 cũng không được cùng range IP Lan của site1 (đây là câu hỏi của giáo viên mình).
(Nếu Wan cùng range nhau, và Lan cũng cùng range nhau thì có được không? Tại sao?)

Về mặt nguyên tắc, mình chả thấy có gì không được ở đây cả. Nếu 2 site nối trực tiếp với nhau, thì phần public của 2 sites đó phải nằm trong cùng một subnet, còn nếu chúng nằm ở 2 đầu của Internet, thì hiển nhiên phải khác subnet. Còn lại đối với LAN thì trong bất cứ trường hợp nào cũng có thể nằm trong cùng subnet (các kĩ thuật như NAT, VPN để làm gì đây?)