Xin giúp đỡ về TCP state diagram!

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

Xin giúp đỡ về TCP state diagram!

[Question] Xin giúp đỡ về TCP state diagram!	23/06/2010 01:48:06 (+0700) \| #1 \| 213935

stylish_man
Member

Joined: 26/10/2007 11:05:48
Messages: 17
Offline

Chào mọi người . Mình đọc về TCP state diagram và tham khảo một số tài liệu nhưng mình vẫn chưa hiểu rõ cơ chế chuyển giao giữa các trạng thái diễn ra như thế nào ( nhất là giữa các unusual event ). Nếu ai biết có thể giải thích một cách chi tiết giúp mình được không.
Thank in advance !

[Question] Xin giúp đỡ về TCP state diagram!	09/07/2010 10:58:37 (+0700) \| #2 \| 214946

invalid-password
Member

Joined: 09/03/2010 21:22:46
Messages: 161
Offline

stylish_man wrote:

Chào mọi người . Mình đọc về TCP state diagram và tham khảo một số tài liệu nhưng mình vẫn chưa hiểu rõ cơ chế chuyển giao giữa các trạng thái diễn ra như thế nào ( nhất là giữa các unusual event ). Nếu ai biết có thể giải thích một cách chi tiết giúp mình được không.
Thank in advance !

Khi nó gửi/nhận thêm 1 bản tin thì sẽ chuyển trạng thái

Spam thêm một bài là góp một viên gạch xây diễn đàn lớn mạnh

[Question] Xin giúp đỡ về TCP state diagram!	09/07/2010 13:06:20 (+0700) \| #3 \| 214964

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Chủ đề này hay vậy mà sao không thấy ai tham gia vậy cà? smilie

What bringing us together is stronger than what pulling us apart.

[Question] Xin giúp đỡ về TCP state diagram!	09/07/2010 13:56:55 (+0700) \| #4 \| 214968

invalid-password
Member

Joined: 09/03/2010 21:22:46
Messages: 161
Offline

Chủ đề phhức tạp, diễn giải dài dòng, bình thường biết cũng chẳng để là gì, bởi vậy không mấy ai quan tâm.

Spam thêm một bài là góp một viên gạch xây diễn đàn lớn mạnh

[Question] Xin giúp đỡ về TCP state diagram!	09/07/2010 14:19:34 (+0700) \| #5 \| 214970

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

invalid-password wrote:

Chủ đề phhức tạp, diễn giải dài dòng, bình thường biết cũng chẳng để là gì, bởi vậy không mấy ai quan tâm.

Không hẳn vậy đâu. Chủ đề này toàn là căn bản TCP/IP và chủ của chủ đề chẳng diễn giải gì hết.

Còn "biết cũng chẳng để làm gì" có vẻ thiếu chính xác. Đây là những kiến thức nền tảng TCP/IP thì sao lại "biết cũng chẳng để làm gì"?

What bringing us together is stronger than what pulling us apart.

[Question] Xin giúp đỡ về TCP state diagram!	09/07/2010 15:48:07 (+0700) \| #6 \| 214972

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Hi anh em !

Mình cũng chưa nắm rõ TCP/IP lắm . Khống biết hiểu thế này đúng không :d

- Listen ---RST --- Syn Received : thông thường nmap hoạt động theo nguyên tắc này, gởi gói tin SYN rồi gới gói RST để scan trên những port đang bị close
- SYN/SYN + ACK (simultaneous open ) : one application on host A could have a local port of 7777 and perform an active open to port 8888 on host B. The application on host B would have a local port of 8888 and perform an active open to port 7777 on host A.

[Question] Xin giúp đỡ về TCP state diagram!	09/07/2010 21:36:30 (+0700) \| #7 \| 214987

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

Nhìn cái hình này đủ phức tạp rồi. Đâu cần thiết phải "PRO" tới mức toàn nền màu đen cho nó khác người, như vậy làm khó người đọc hơn.
Dùng màu sắc để phân biệt thứ tự thời gian , nên để nền màu trắng đi bạn.
PS: có thể cấu trúc hình nảy ảnh hưởng tới suy luận của người xem, cho nên
http://www.google.com.vn/imglanding?q=TCP%20state%20diagram!&imgurl=http://webpages.cs.luc.edu/~pld/courses/443/spr10/notes/tcpStateDiagram1.gif&imgrefurl=http://webpages.cs.luc.edu/~pld/courses/443/spr10/notes/07.html&usg=__Z6pfMieZ6Mh_jRDjwfdpyDLf_nc=&h=654&w=679&sz=18&hl=vi&itbs=1&tbnid=lO5WuD_z4Ugd7M:&tbnh=134&tbnw=139&prev=/images%3Fq%3DTCP%2Bstate%2Bdiagram!%26hl%3Dvi%26sa%3DG%26gbv%3D2%26tbs%3Disch:1&sa=G&gbv=2&tbs=isch:1&start=0#tbnid=S4M8k79DxzsOaM&start=8
có thêm một số hình ảnh tuơng tự nữa để người đọc lựa chọn

PS: mà đọc tài liệu nào nói về cái này cũng nên chú thích kèm theo tên tài liệu để dễ tham chiếu nhẩy.

3 giai đoạn của con... người, ban đầu dek biết gì thì phải thăm dò, sau đó biết rồi thì phải thân thiết, sau cùng khi quá thân thiết rồi thì phải tình thương mến thương. Nhưng mà không thương được thì ...

[Question] Xin giúp đỡ về TCP state diagram!	10/07/2010 04:27:14 (+0700) \| #8 \| 214998

Bướm Đêm
Member

Joined: 25/03/2008 18:30:01
Messages: 223
Location: Phố Hoa
Offline

Hình transparent cha nội ơi, anh rảnh mà bôi đen smilie

Thớt hay

GZ tqf zìeq ˘ऐ xखc sड़e cav xন qrqr

[Question] Xin giúp đỡ về TCP state diagram!	12/07/2010 09:42:31 (+0700) \| #9 \| 215137

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Hi !
Sao không anh em nào tham gia chủ đề này hêt vậy. Đáng lẽ phải hot chứ ta smilie

,mấy cái chủ đề như " phê bình conmale" thì thấy mấy bác nhảy vô ào ào smilie

[Question] Xin giúp đỡ về TCP state diagram!	12/07/2010 09:53:58 (+0700) \| #10 \| 215139

invalid-password
Member

Joined: 09/03/2010 21:22:46
Messages: 161
Offline

Cái hình vẽ thẳng thớm tinh tế nhìn có vẻ pro ghê, đem copy vào đề tài được đây mà.
Nhưng nhìn cái hình chạy loằng ngoằng như sơ đồ di chuyển của đội bóng ấy, hoa cả mắt smilie

Chủ topic chạy mất rồi.

Spam thêm một bài là góp một viên gạch xây diễn đàn lớn mạnh

[Question] Xin giúp đỡ về TCP state diagram!	12/07/2010 10:33:35 (+0700) \| #11 \| 215148

longkt90
Member

Joined: 27/08/2009 20:44:22
Messages: 61
Offline

Mình cũng chưa hiểu lắm nên đang chờ xem đây. Không biết cái link này có giúp ích gì ko

http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html

vikjava wrote:

Sao không anh em nào tham gia chủ đề này hêt vậy. Đáng lẽ phải hot chứ ta smilie ,mấy cái chủ đề như " phê bình conmale" thì thấy mấy bác nhảy vô ào ào

Tại vì phê bình conmale thì người bị phê bình sẽ không "sửa gáy". Còn chủ để này mà post tầm bậy vô là biết tay chú conmale + mods smilie

[Question] Xin giúp đỡ về TCP state diagram!	12/07/2010 11:45:47 (+0700) \| #12 \| 215153

StarGhost
Elite Member

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

Chủ đề này đáng ra phải hot, nhưng còn chưa hot vì:
- người đặt câu hỏi/thắc mắc còn chưa nêu rõ vấn đề mình cần hỏi/thắc mắc, mà chỉ nói chung chung là khó hiểu, hoặc giả đặt câu hỏi không đến đầu đến đũa.
- người đặt câu hỏi/thắc mắc chưa chứng minh được rằng mình đã tìm tòi, nghiên cứu, và gặp khó khăn trong việc hiểu các tài liệu căn bản có liên quan.

TCP có quá nhiều corner cases và unusual cases để mà có thể bao quát hết trong một chủ đề, đặc biệt nếu lại liên quan đến cả operation lẫn security.

Mind your thought.

[Question] Xin giúp đỡ về TCP state diagram!	12/07/2010 12:11:47 (+0700) \| #13 \| 215157

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Thử khai triển một phần nhỏ nhá smilie

Bước 2 của 3 bước bắt tay (3-ways handshake) của TCP là gì? Hãy đi xuyên qua vài điểm căn bản:

Bước 1: A -- SYN --> B (A là client, B là server có cổng dịch vụ đang lắng nghe)

Bước 2: B -- SYN - ACK --> A (B nhận SYN request và gởi lại A SYN-ACK để báo rằng nó tiếp nhận)

Bước 3: A -- ACK --> B (A nhận được SYN-ACK từ B và nó gởi ngược lại ACK để báo rằng nó nhận được hồi báo của B).

Xét ba bước trên thì rõ ràng để một TCP session hình thành, hoàn toàn không có gói nào khác ngoài SYN, SYN-ACK và ACK xen vào. Nếu bất thình lình có RST xuất hiện trong quá trình này thì rõ ràng rằng một trong hai đầu (client và server) có vấn đề.

RST là gì? Nôm na, nó là một gói tin dùng để ngắt ngang một xuất truy cập. Nếu RST xuất hiện trong hoàn cảnh trên thì rõ rằng giữa hai đầu không bao giờ có thể hoàn tất các bước "bắt tay" ban đầu để hình thành một TCP session hoàn chỉnh.

Vậy, RST có hại như thế nào? và nếu nó có hại, có những cách nào để ngăn chặn?

What bringing us together is stronger than what pulling us apart.

[Question] Xin giúp đỡ về TCP state diagram!	12/07/2010 14:36:56 (+0700) \| #14 \| 215168

longkt90
Member

Joined: 27/08/2009 20:44:22
Messages: 61
Offline

RST có hại:
1> Ngắt kết nối trong quá trình thiết lập kết nối.

conmale wrote:

Bước 1: A -- SYN --> B (A là client, B là server có cổng dịch vụ đang lắng nghe)

Bước 2: B -- SYN - ACK --> A (B nhận SYN request và gởi lại A SYN-ACK để báo rằng nó tiếp nhận)

Bước 3: A -- ACK --> B (A nhận được SYN-ACK từ B và nó gởi ngược lại ACK để báo rằng nó nhận được hồi báo của B).

Sau bước 2, có một máy C mạo danh B gửi tới A một gói tin RST, A lập tức đóng kết nối này, sau đó C tiếp tục mạo danh B để mở kết nối với A với sequence number mới.
Lúc này B sẽ ignore toàn bộ thông điệp từ A vì A đang sử dụng (ACK cho) sequence number của C.
A sẽ ignore toàn bộ thông điệp từ B vì B ACK khác sequence number của A (sequence number của A đã thay đổi)
C đã có số sequence hợp lệ của cả A và B nên có thể giả mạo để trao đổi dữ liệu dưới vai trò của A hoặc B

2> Ngắt kết nối trong quá trình trao đổi dữ liệu giữa A và B: Cách này không hay vì application sẽ nhận biết được một kết nối bị khởi động lại (=> cải tiến thay vì đóng kết nối thì chỉ thay đổi sequence number (không dùng RST)).

3> Port scan: Khi gửi SYN đến một host A với port P mà P đó không mở thì A tự động gởi gói tin reply với cờ RST bật lên => Dễ dàng xác định cổng nào đang mở.

Ngăn chặn: Chưa biết smilie

Chờ nghe ý kiến mọi người

Tham khảo
http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html
http://en.wikipedia.org/wiki/TCP_reset_attack
http://www.firewall.cx/tcp-analysis-section-4.php
http://kerneltrap.org/node/3072

[Question] Xin giúp đỡ về TCP state diagram!	13/07/2010 08:20:30 (+0700) \| #15 \| 215215

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Việc ngăn chặn RST theo emthì có thể thưc hiện theo 2 cách :

- Kích hoạt việc xác minh TCP Sequence trên firewall.
- Để thưc hiện tấn công RST, kẻ tấn công phải đoán gần đúng sequence number, để thực hiện điều này cần "flood of RST packets " . Ta chỉ cần cấu hình firewall detect và drop các kết nối này.

[Question] Xin giúp đỡ về TCP state diagram!	13/07/2010 10:32:30 (+0700) \| #16 \| 215232

longkt90
Member

Joined: 27/08/2009 20:44:22
Messages: 61
Offline

Nếu có thể làm như sau thì sẽ ngăn chặn đáng kể được gói tin RST giả mạo.
Chọn một số delta > 0. Mỗi khi một kết nối TCP được mở thì lấy trường TTL của các IP datagram của kết nối đó (lấy trung bình của 1 số IP datagram đầu tiên hoặc lấy TTL của gói SYN đầu tiên) gọi là T.

Sau đó mỗi khi nhận được một gói tin RST có TTL là T' thì so sánh: Nếu |T - T'| > delta thì drop gói tin đó, ngược lại thì cho qua.

Vì theo em TTL của các gói tin từ một nguồn thì không cách nhau là mấy (không vượt qua delta) còn số delta thì còn tuỳ người chọn (dựa trên thực tế). Cũng có trường hợp gói tin hợp lệ bị drop nhưnng vì drop ở firewall nên sẽ không có ACK cho gói đó và nó sẽ được gửi lại. smilie

[Question] Xin giúp đỡ về TCP state diagram!	13/07/2010 13:19:37 (+0700) \| #17 \| 215240

1mp0ss1bl3
Member

Joined: 14/02/2008 21:32:58
Messages: 41
Location: ...
Offline

Mô hình trên sai ở chổ RST/-. Theo như RFC 793 trang 36 thì:

...If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state...

Hướng mũi tên phải đi theo chiều ngược lại mới phải.

@stylish_man: Bạn có thẻ tham khảo thêm ở

http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm

để hiểu rõ hơn về TCP States, events và transitions.

Thân

To achieve the impossible, one must thing the absurd - to look where everyone else has looked, but to see what no else has seen.

[Question] Xin giúp đỡ về TCP state diagram!	15/07/2010 12:22:50 (+0700) \| #18 \| 215402

longkt90
Member

Joined: 27/08/2009 20:44:22
Messages: 61
Offline

Chủ topic lặn mất tiêu, chú conmale cũng ko thấy smilie

[Question] Xin giúp đỡ về TCP state diagram!	21/07/2010 16:41:13 (+0700) \| #19 \| 215915

eff3
Member

Joined: 06/07/2010 09:30:32
Messages: 24
Offline

mình thấy chủ đề này với câu hỏi của anh conmale hay mà ít bạn tham gia nhỉ...

conmale wrote:

Vậy, RST có hại như thế nào? và nếu nó có hại, có những cách nào để ngăn chặn?

rõ ràng RST có hại ở chỗ packet có RST-Flag được dùng để ngắt 1 kết nối đang diễn ra hoặc thậm chí là là ngắt quá trính thiết lập kết nối bắt tay 3 bước như ví dụ của anh conmale.

Nhưng để cách thức tấn công này thành công thì phải biết TCP chấp nhận những gói tin có đặc điểm thế nào cho 1 cái TCP Session:
1. src IP
2. dst IP
3. src Port
4. dst Port
5. sequence nr.

Như thế có nghĩa là attacker chỉ cần biết 5 dữ liệu trên cộng với việc bật cái RST Flag lên là sẽ thành công. Ở đây mình xét trường hợp attacker sẽ gửi 1 RST packet giả đến server để ngắt kết nối. Khi đó thì dst IP với dst Port đã biết đc, ko vấn đề gì cả. Src IP trong trường hợp này thì tất nhiên attacker bắt buộc phải biết nhưng attacker trước hết phải spoof cái IP (cái này nhiều khi ISP có thể ngăn chặn bằng cách filter IP). Tuy nhiên cái khó nhất ở đây là phải đoán đc đúng src port và sequence nr. Cái này thì attacker ko cách nào khác ngoài brute force, tuy nhiên có thể giảm đc số lần thử rất nhiều bằng cách xác định cái OS mà victim đang dùng rồi dựa trên implementation TCP của OS đó để giới hạn đc số lần đoán đi rất nhiều. Ngoài ra cái có 1 điểm khá hay là attacker ko nhất thiết phải đoán đúng 100% cái seqeunce nr vì server thực ra chấp nhận cả những sequence nr chênh lệch 1 chút so với cái mà server mong đợi, miễn sao là nó vẫn nằm trong cái rcv window là ok ...

@Conmale: em thấy gửi RST trong khi trao đổi data dễ hơn nhiều chứ anh. Vì thật ra các SYN, SYN/ACK và ACK diễn ra rất nhanh, cho nên em nghĩ là khả năng thành công của kiểu tấn công trong bước thiết lập kết nối này là ko nhiều.

[Question] Xin giúp đỡ về TCP state diagram!	21/07/2010 19:41:56 (+0700) \| #20 \| 215923

1mp0ss1bl3
Member

Joined: 14/02/2008 21:32:58
Messages: 41
Location: ...
Offline

Mình cũng đồng ý với bạn chủ đề và câu hỏi gợi mở của anh conmale hay. Vì mình cũng đang ngâm TCP/IP và nhờ chủ đề này mình đào sâu và mở rộng thêm khá nhiều vấn đề. Nhưng, lý do chính mình không trả lời cho câu hỏi của anh conmale chính là những gì mình biết để trả lời đều toàn là lý thuyết, những điều mà mình nghĩ những ai đã từng ngâm sẽ dễ dàng tìm thấy và đã biết (ví dụ như: Filtering, TCP MD5 Signature, Window size tunning...). Vì thế, mong rằng anh conmale smilie

(hoặc những ai đã từng trải qua) trả lời cho câu hỏi của anh conmale hoặc nêu ra các trường hợp cụ thể hơn cho mọi người.

Thân

To achieve the impossible, one must thing the absurd - to look where everyone else has looked, but to see what no else has seen.

[Question] Xin giúp đỡ về TCP state diagram!	22/07/2010 17:24:17 (+0700) \| #21 \| 216030

eff3
Member

Joined: 06/07/2010 09:30:32
Messages: 24
Offline

haizzz sao chả thấy ai tham gia chủ đề này nhỉ ...

mình có 1 câu hỏi tương đối hay muốn hỏi mọi người:
Tại sao TCP ko dùng 2-way-handshake để thiết lập kết nối TCP ban đầu? Vấn đề nào có thể xảy ra nếu dùng 2-way-handshake và liệu tất cả những vấn đề này có đc giải quyết bởi 3-way-handshake ko?

ps: anh conmale có thể giải đáp câu hỏi của a ko?

[Question] Xin giúp đỡ về TCP state diagram!	22/07/2010 18:52:24 (+0700) \| #22 \| 216043

longkt90
Member

Joined: 27/08/2009 20:44:22
Messages: 61
Offline

eff3 wrote:

mình có 1 câu hỏi tương đối hay muốn hỏi mọi người:
Tại sao TCP ko dùng 2-way-handshake để thiết lập kết nối TCP ban đầu? Vấn đề nào có thể xảy ra nếu dùng 2-way-handshake và liệu tất cả những vấn đề này có đc giải quyết bởi 3-way-handshake ko?

Nên lập topic khác.

[Question] Xin giúp đỡ về TCP state diagram!	22/07/2010 20:05:11 (+0700) \| #23 \| 216056

eff3
Member

Joined: 06/07/2010 09:30:32
Messages: 24
Offline

@longkt90

longkt90 wrote:

RST có hại:
1> Ngắt kết nối trong quá trình thiết lập kết nối.

conmale wrote:

Bước 1: A -- SYN --> B (A là client, B là server có cổng dịch vụ đang lắng nghe)
Bước 2: B -- SYN - ACK --> A (B nhận SYN request và gởi lại A SYN-ACK để báo rằng nó tiếp nhận)
Bước 3: A -- ACK --> B (A nhận được SYN-ACK từ B và nó gởi ngược lại ACK để báo rằng nó nhận được hồi báo của B).

Sau bước 2, có một máy C mạo danh B gửi tới A một gói tin RST, A lập tức đóng kết nối này, sau đó C tiếp tục mạo danh B để mở kết nối với A với sequence number mới.
......

cái đoạn này là bạn dịch ra đúng ko? Mình thấy khá là chính xác và sát nghĩa smilie

... chỉ có 1 chỗ mình hơi thắc mắc là đoạn "sau đó C tiếp tục mạo danh B để mở kết nối với A"... bạn có thể giải thích rõ ra xem là C mạo danh B tạo kết nối với A thế nào đc ko?

ps: ngoài ra đang nói về TCP thì mềnh hỏi câu hỏi trên có gì lạc đề đâu mà topic cũ với mới haizzz

@chủ đề:
thực ra tấn công kiểu này mình thấy có 2 khả năng:
1) là attacker ở giữa client và server nên có thể bắt đc toàn bộ packets. Khi đó thì chả cần đoán này đoán nọ gì mệt người. Cứ thế mà làm giả packet, bật RST rồi quất thôi. Bước này xong roài thì coi như có thể hijack cái TCP connection đấy. Mỗi lần chỉ cần sửa sequence nr, chửa checksum rồi send là xong. Cái dở của cách tấn công này là ở cả client và server sẽ phải discards rất nhiều packets smilie

--> sơ hở dễ bị phát hiện. Thế nên nếu mà kết hợp đc với ARP Poisioning (tất nhiên là attacker đang ở cùng LAN với client) ở đây nữa là thì attack sẽ chạy rất êm và đẹp.
2) attacker chả có gì ngoài việc biết là: à thằng A đang vào trang B coi phim. Giờ muốn ko cho nó xem phim nữa thì chỉ có cách flood RST Packets thôi. Điểm yếu của cách này là sự tăng đột ngột của số lượng các RST Packets sẽ dễ bị Firewall hay các IDS phát hiện ...

[Question] Xin giúp đỡ về TCP state diagram!	23/07/2010 10:44:05 (+0700) \| #24 \| 216105

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

eff3 wrote:

ps: anh conmale có thể giải đáp câu hỏi của a ko?

Hì hì, chủ đề này đâu phải là "đố vui có giải đáp" đâu mà anh phải giải đáp em? smilie

. Anh chỉ gợi ý một câu để lấy trớn mà thảo luận thôi. Đúng hay sai đều có trong RFC hết rồi.

What bringing us together is stronger than what pulling us apart.

[Question] Xin giúp đỡ về TCP state diagram!	23/07/2010 11:52:02 (+0700) \| #25 \| 216113

invalid-password
Member

Joined: 09/03/2010 21:22:46
Messages: 161
Offline

eff3 wrote:

mình có 1 câu hỏi tương đối hay muốn hỏi mọi người:
Tại sao TCP ko dùng 2-way-handshake để thiết lập kết nối TCP ban đầu? Vấn đề nào có thể xảy ra nếu dùng 2-way-handshake và liệu tất cả những vấn đề này có đc giải quyết bởi 3-way-handshake ko?

Vụ này invalid-password có tham gia cãi nhau tại đây http://vnpro.org/forum/showthread.php/16251-3-way-hand-shake-c%E1%BB%A7a-TCP

Spam thêm một bài là góp một viên gạch xây diễn đàn lớn mạnh

[Question] Xin giúp đỡ về TCP state diagram!	23/07/2010 14:56:42 (+0700) \| #26 \| 216127

eff3
Member

Joined: 06/07/2010 09:30:32
Messages: 24
Offline

invalid-password wrote:

Vụ này invalid-password có tham gia cãi nhau tại đây http://vnpro.org/forum/showthread.php/16251-3-way-hand-shake-c%E1%BB%A7a-TCP

thanks bạn nhé, mình mới đọc qua cái topic bên đó rồi, nhiều bạn cho ví dụ đánh nhau rất sinh động và khí thế lolz ... chẳng hạn như ví dụ này

1 đc nào đó wrote:

Trong một trận chiến có 2 đội quân A và B.
Đội quân B hiện đang bị bao vây phía dưới thung lũng, và có khoảng 10 nghìn quân
Đội quân A ở phía trên, chia thành 2 nhóm là A1 và A2 đóng ở 2 đầu thung lũng, mỗi nhóm nhỏ có khoảng 7 nghìn quân
Rõ ràng là nếu đội quân A tiến công từng nhóm lẻ tẻ thì sẽ không thể thắng được, muốn thắng thì đòi hỏi cả 2 nhóm quân A1 và A2 cùng tiến đánh một lúc. Thời ngày xưa thì không có các phương tiện truyền thông hiện đại như bây giờ, mỗi khi muốn trao đổi thông tin thì cần cử người đem thông điệp sang tận nơi. Vậy làm thế nào để đảm bảo cả 2 đội quân đều ồ ạt tấn công 1 lúc?
Như vậy trong trường hợp này, quân A muốn đánh thắng thì trước hết 2 nhóm A1 và A2 phải "đồng bộ" thời gian tấn công như sau:
Bước 1: A1 gửi thư sang cho A2, yêu cầu đúng giờ X thì tấn công
Bước 2: A2 gửi trả lời: "đồng ý, giờ X nhé!"
Tuy nhiên nếu chỉ 2 bước thế này thì vẫn chưa chặt chẽ. Trong trường hợp anh lính liên lạc bị giết chết trong quá trình mang thư trả lời của A2, A1 không nhận được trả lời thì không dám tấn công một mình, còn A2 thì cứ đinh ninh rằng giờ đó tấn công là được --> đến giờ đó A2 tấn công 1 mình --> hy sinh
Như vậy cần thêm 1 bước nữa để đảm bảo rằng A1 đã nhận được trả lời của A2:
Bước 3: A1 gửi trả lời: "đã nhận thông điệp thành công!"
Đến lúc này, qua 3 bước thì quân A có thể đảm bảo sự thống nhất giữa 2 nhóm quân, chỉ việc chờ đến giờ X cùng tấn công đồng loạt là giành phần thắng

Đó là ý nghĩa vì sao là 3 ways chứ ko phải 2 ways, 4 ways hay n ways...

Ví dụ rất cụ thể cơ mà mình thấy chưa thật sự chính xác để giải thích về tại sao lại xài 3-way-handshake, giải thích kiểu này sẽ dẫn đến cái vòng luẩn quẩn ...
Mở rộng ra tí nữa sẽ có câu hỏi là: thế tại sao ở bước thiết lập kết nối thì xài 3-way-handshake trong khi đến lúc kết thúc kết nối lại xài 4-way-handshake?

[Question] Xin giúp đỡ về TCP state diagram!	23/07/2010 18:03:06 (+0700) \| #27 \| 216144

longkt90
Member

Joined: 27/08/2009 20:44:22
Messages: 61
Offline

eff3 wrote:

cái đoạn này là bạn dịch ra đúng ko? Mình thấy khá là chính xác và sát nghĩa

sợ bạn không biết mình dịch nên có kèm link ở dưới đó smilie

. Tuy nhiên có rất nhiều chỗ là suy nghĩ của mình, thấy chỗ nào sai nhớ nhắc nha. Cám ơn trước. smilie

eff3 wrote:

bạn có thể giải thích rõ ra xem là C mạo danh B tạo kết nối với A thế nào đc ko?

Lúc này tất cả các gói tin từ B bị drop, C có số sequence number chính xác (thường là 0) nên có thể dùng thông tin của B (port, IP) để xin mở kết nối với A và trao đổi dữ liệu với A (A nghĩ là đang trao đổi với B)

eff3 wrote:

ps: ngoài ra đang nói về TCP thì mềnh hỏi câu hỏi trên có gì lạc đề đâu mà topic cũ với mới haizzz

Mình không nói lạc đề nhưng như vậy topic sẽ rất dài smilie

eff3 wrote:

mình có 1 câu hỏi tương đối hay muốn hỏi mọi người:
Tại sao TCP ko dùng 2-way-handshake để thiết lập kết nối TCP ban đầu? Vấn đề nào có thể xảy ra nếu dùng 2-way-handshake và liệu tất cả những vấn đề này có đc giải quyết bởi 3-way-handshake ko?

Câu này mình thấy có người trả lời như sau, có đúng ý bạn không?

Lê Ngọc Sơn wrote:

TCP là giao thức chạy trên nền IP mà IP là một giao thức không tin cậy (best effort) nên các gói tin bên receiver nhận có thể không theo theo thứ tự như bên sender gửi.
Đặt trường hợp nếu bắt tay 2 bước, khi bên receiver nhận gói tin yêu cầu kết nối, nó trả lại ACK. Lúc này, bên receiver cho rằng việc thiết lập kết nối đã thành công và nó có thể gửi dữ liệu. Tuy nhiên, khi gửi dữ liệu, các gói dữ liệu này có thể đến trước gói ACK mà nó gửi. Ở bên sender, vì chưa nhận được ACK nên drop tất cả các gói tin nó nhận từ receiver. Vì vậy, điều này là không hợp lí.

[Question] Xin giúp đỡ về TCP state diagram!	23/07/2010 21:01:06 (+0700) \| #28 \| 216175

eff3
Member

Joined: 06/07/2010 09:30:32
Messages: 24
Offline

longkt90 wrote:

Lúc này tất cả các gói tin từ B bị drop, C có số sequence number chính xác (thường là 0) nên có thể dùng thông tin của B (port, IP) để xin mở kết nối với A và trao đổi dữ liệu với A (A nghĩ là đang trao đổi với B)

ok, nếu xem lại ví dụ này thì mình sẽ xét theo cái model client-server điển hình nhé. Vì A là người gửi SYN packet ban đầu -> A là client (thông tin này wan trọng nà). Rồi bạn bảo là C gửi RST packet đến A (ngay sau khi A nhận SYN-ACK từ B) để ngắt kết nối của A, chính xác, vì sau đó A sẽ xoá tất cả buffer hay thông tin liên quan đến kết nối này. Giờ B có gửi gì đi chăng nữa thì A đều vứt bỏ hết, rất là phũ smilie

. Thế rồi C của bạn sẽ tạo kết nối với A, theo bạn nói là sử dụng thông tin của B (port, IP) cũng đúng luôn nhưng mà trong cái header của IP với TCP còn 2 cái fields là IP và port của A. IP của A thì bạn có rồi, port của A thì bạn tính sao? A lại là client thì bạn thấy vào ngõ cụt chưa?

ps: cái nhận xét sequence number thường là 0 mình nghĩ là ko chính xác tí nào --> được chọn ngẫu nhiên --> câu hỏi mới: tại sao sequence lại được chọn ngẫu nhiên?

Lê Ngọc Sơn wrote:

TCP là giao thức chạy trên nền IP mà IP là một giao thức không tin cậy (best effort) nên các gói tin bên receiver nhận có thể không theo theo thứ tự như bên sender gửi.
Đặt trường hợp nếu bắt tay 2 bước, khi bên receiver nhận gói tin yêu cầu kết nối, nó trả lại ACK. Lúc này, bên receiver cho rằng việc thiết lập kết nối đã thành công và nó có thể gửi dữ liệu. Tuy nhiên, khi gửi dữ liệu, các gói dữ liệu này có thể đến trước gói ACK mà nó gửi. Ở bên sender, vì chưa nhận được ACK nên drop tất cả các gói tin nó nhận từ receiver. Vì vậy, điều này là không hợp lí.

lời giải thích này cũng có lí của nó nhưng nết xét cái ACK cuối cùng trong 3-way-handshake thì cũng thế ... bên sender sau khi gửi ACK thì bắt đầu gửi data qua bên B ... thế nếu những data này lại đến trước cái ACK kia thì sao ... bên B vẫn chưa nhận ACK nên vẫn chưa vào cái state established đc và sẽ discard tất cả các packets đc gủi đến ... thế là lại hỏng smilie

[Question] Xin giúp đỡ về TCP state diagram!	23/07/2010 21:26:32 (+0700) \| #29 \| 216178

longkt90
Member

Joined: 27/08/2009 20:44:22
Messages: 61
Offline

eff3 wrote:

IP của A thì bạn có rồi, port của A thì bạn tính sao? A lại là client thì bạn thấy vào ngõ cụt chưa?

Mình nhầm là khi nhận đc RST thì A trở về trạng thái listen. smilie

eff3 wrote:

câu hỏi mới: tại sao sequence lại được chọn ngẫu nhiên?

Để khó đoán hơn, khó bị tấn công.

eff3 wrote:

bên sender sau khi gửi ACK thì bắt đầu gửi data này qua bên B ... thế nếu những data lại đến trước cái ACK kia thì sao ... bên B vẫn chưa nhận ACK nên vẫn chưa vào cái state established đc và sẽ discard tất cả các packets đc gủi đến ... thế là lại hỏng

Đúng vậy mà, khi nào 2 thiết lập được kết nối thì chuyện trao đổi dữ liệu mới bình thường. Nếu A gửi data đến trước ACK thì bị B drop, và B sẽ không ACK cho data này nên A sẽ gửi lại.

[Question] Xin giúp đỡ về TCP state diagram!	23/07/2010 21:42:38 (+0700) \| #30 \| 216180

eff3
Member

Joined: 06/07/2010 09:30:32
Messages: 24
Offline

longkt90 wrote:

Để khó đoán hơn, khó bị tấn công.

đúng òi, nhưng còn 1 lí do nữa ...

longkt90 wrote:

Đúng vậy mà, khi nào 2 thiết lập được kết nối thì chuyện trao đổi dữ liệu mới bình thường. Nếu A gửi data đến trước ACK thì bị B drop, và B sẽ không ACK cho data này nên A sẽ gửi lại.

sao nói 1 hồi huề vốn vậy, ý mình là lí do bạn nêu ra ở trên ko giải thích được sự cần thiết của việc dùng 3-way-handshake ... vì vấn đề bạn nêu ra cũng gặp ở 3-way-handshake (tức là trường hợp cái packet cuối cùng trong bước thiết lập kết nối bị mất) --> 1 thằng thì nghĩ là kết nối đã thành công, 1 thằng thì ngẩn ngơ, chưa chịu nhận data thằng kia gửi vì cái packet cuối bị mất. Thế nên trong câu hỏi ban đầu mình mới bảo là có trường hợp mà cả 2 phương pháp đều ko giải quyết đc là vì thế ...

Go to:

Users currently in here
1 Anonymous