<![CDATA[Latest posts for the topic "Xin giúp đỡ về TCP state diagram!"]]> /hvaonline/posts/list/31.html JForum - http://www.jforum.net Xin giúp đỡ về TCP state diagram!
]]> /hvaonline/posts/list/34830.html#213935 /hvaonline/posts/list/34830.html#213935 GMT Xin giúp đỡ về TCP state diagram!

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]]> /hvaonline/posts/list/34830.html#214946 /hvaonline/posts/list/34830.html#214946 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#214964 /hvaonline/posts/list/34830.html#214964 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#214968 /hvaonline/posts/list/34830.html#214968 GMT Xin giúp đỡ về TCP state diagram!

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ì"?]]> /hvaonline/posts/list/34830.html#214970 /hvaonline/posts/list/34830.html#214970 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#214972 /hvaonline/posts/list/34830.html#214972 GMT Xin giúp đỡ về TCP state diagram! 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.]]> /hvaonline/posts/list/34830.html#214987 /hvaonline/posts/list/34830.html#214987 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#214998 /hvaonline/posts/list/34830.html#214998 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#215137 /hvaonline/posts/list/34830.html#215137 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#215139 /hvaonline/posts/list/34830.html#215139 GMT Xin giúp đỡ về TCP state diagram! 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 :D]]> /hvaonline/posts/list/34830.html#215148 /hvaonline/posts/list/34830.html#215148 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#215153 /hvaonline/posts/list/34830.html#215153 GMT Xin giúp đỡ về TCP state diagram! 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?]]> /hvaonline/posts/list/34830.html#215157 /hvaonline/posts/list/34830.html#215157 GMT Xin giúp đỡ về TCP state diagram!

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 :D 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]]> /hvaonline/posts/list/34830.html#215168 /hvaonline/posts/list/34830.html#215168 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#215215 /hvaonline/posts/list/34830.html#215215 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#215232 /hvaonline/posts/list/34830.html#215232 GMT Xin giúp đỡ về TCP state diagram! 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]]> /hvaonline/posts/list/34830.html#215240 /hvaonline/posts/list/34830.html#215240 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#215402 /hvaonline/posts/list/34830.html#215402 GMT Xin giúp đỡ về TCP state diagram!

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.]]> /hvaonline/posts/list/34830.html#215915 /hvaonline/posts/list/34830.html#215915 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#215923 /hvaonline/posts/list/34830.html#215923 GMT Xin giúp đỡ về TCP state diagram! /hvaonline/posts/list/34830.html#216030 /hvaonline/posts/list/34830.html#216030 GMT Xin giúp đỡ về TCP state diagram!

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.]]> /hvaonline/posts/list/34830.html#216043 /hvaonline/posts/list/34830.html#216043 GMT Xin giúp đỡ về TCP state diagram!

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 :D ... 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 :-S --> 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 ...]]> /hvaonline/posts/list/34830.html#216056 /hvaonline/posts/list/34830.html#216056 GMT Xin giúp đỡ về TCP state diagram!

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? :). 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.]]> /hvaonline/posts/list/34830.html#216105 /hvaonline/posts/list/34830.html#216105 GMT Xin giúp đỡ về TCP state diagram!

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]]> /hvaonline/posts/list/34830.html#216113 /hvaonline/posts/list/34830.html#216113 GMT Xin giúp đỡ về TCP state diagram!

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?]]> /hvaonline/posts/list/34830.html#216127 /hvaonline/posts/list/34830.html#216127 GMT Xin giúp đỡ về TCP state diagram!

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 đó :D. 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. :D

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 :(

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í. 
]]> /hvaonline/posts/list/34830.html#216144 /hvaonline/posts/list/34830.html#216144 GMT Xin giúp đỡ về TCP state diagram!

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ũ :-S. 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 :-S]]> /hvaonline/posts/list/34830.html#216175 /hvaonline/posts/list/34830.html#216175 GMT Xin giúp đỡ về TCP state diagram!

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. :(

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.]]> /hvaonline/posts/list/34830.html#216178 /hvaonline/posts/list/34830.html#216178 GMT Xin giúp đỡ về TCP state diagram!

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ế ...]]> /hvaonline/posts/list/34830.html#216180 /hvaonline/posts/list/34830.html#216180 GMT Xin giúp đỡ về TCP state diagram!

longkt90 wrote:
Chủ topic lặn mất tiêu, chú conmale cũng ko thấy :( 
là mình post bài từ hôm 23/06 mà đến hôm 09/07 mới có 1 trả lời của invaild password.(mấy ngày đầu post xong hôm nào chả vào xem có ai reply hay không nhưng càng đợi càng nản) Đến hôm nay thì cái đồ án cũng xong lâu rồi nhưng dù sao cũng rất cảm ơn mọi người đã nhiệt tình thảo luận @ 1mp0ss1bl3 longkt90 cảm ơn vì các link reference khá hữu ích của các bạn. À mình đọc thấy có ai bảo sao kết thúc kết nối lại xài 4 way thì lý do là vì TCP là full-duplex, dữ liệu có thể truyền đồng thời trên cả 2 chiều. Nên 4 bước là cần thiết để chấm dứt hoàn toàn 1 kết nối Thân]]> /hvaonline/posts/list/34830.html#221059 /hvaonline/posts/list/34830.html#221059 GMT Xin giúp đỡ về TCP state diagram!

stylish_man wrote:
À mình đọc thấy có ai bảo sao kết thúc kết nối lại xài 4 way thì lý do là vì TCP là full-duplex, dữ liệu có thể truyền đồng thời trên cả 2 chiều. Nên 4 bước là cần thiết để chấm dứt hoàn toàn 1 kết nối 
Chà vụ này nói tiếp thì còn nhiều nữa à nhen. Hỏi thêm câu nữa : tại sao lúc kết thúc nó lại không xài 3-way như lúc thiết lập ? Vì lúc thiết lập là "Tui muốn kết nối với anh" còn lúc kết thúc là "Tui muốn kết thúc với anh" > thấy cũng giống giống nhau. Mà thực sự nó lại xài 2-way cho 2 chiều: FIN-ACK và ACK cho cả 2 chiều.]]> /hvaonline/posts/list/34830.html#221075 /hvaonline/posts/list/34830.html#221075 GMT Xin giúp đỡ về TCP state diagram!

invalid-password wrote:
Mà thực sự nó lại xài 2-way cho 2 chiều: FIN-ACK và ACK cho cả 2 chiều. 
xài 2-way cho 2 chiều la sao? Cái kiểu 2-way mà bạn dùng ở đây có tắt toàn bộ kết nối ko? Rồi cái ACK trong FIN-ACK là từ đâu ra á? chuyện này hông có gì mà bạn cứ làm nó trở nên nguy hiểm :-j ]]> /hvaonline/posts/list/34830.html#221194 /hvaonline/posts/list/34830.html#221194 GMT Xin giúp đỡ về TCP state diagram!

invalid-password wrote:

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 
Mình thấy bạn nói như thế này(link ở trên)
Mình xin nêu 1 lý do như vầy : Đầu tiên mình xin nhấn mạnh rằng 3-way handshake không phải là kỹ thuật riêng của TCP, mà nó là một kỹ thuật được thiết kế để bắt tay giữa 2 side. Nhiều giao thức khi tạo kết nối có sử dụng cách thức bắt tay 3 chiều này. 3-way handshake giúp một client kết nối đến một server chưa xác định trước, trong trường hợp có nhiều server cùng đáp ứng yêu cầu. VD : Hiện tại ở VN mỗi nhà cung cấp ADSL có đường cáp riêng, bạn gắn modem vào cáp VNN thì chỉ kết nối được đến VNN. Điều này gây lãng phí cáp. Ở nước ngoài dân cư tập trung trong các khu riêng, những nhà cung cấp đường cáp thì khác với các ISP. Bạn chỉ cần kéo 1 sợi cáp duy nhất nhưng lúc nào bạn cũng có thể chọn kết nối với ISP nào bạn muốn, vì nhà cung cấp đường cáp có kết nối với các ISP. Khi bật modem ADSL thì nó sẽ gửi broadcast để tìm ISP (vì nó chưa có MAC của ISP), lúc này có nhiều ISP cùng trả lời, tuy nhiên modem được cấu hình chỉ kết nối với ISP nào nó muốn, và nó gửi xác nhận kết nối đến đúng ISP đó. Có thể minh họa như sau : + Tôi đứng giữa đám đông la lên : "Tui muốn nói chuyện, có ai muốn nói không ?" (pha 1, broadcast tìm server) + Có nhiều người cùng đáp "Tôi có thể nói chuyện đây" (pha 2, nhiều server trả lời) + Tôi chọn lấy 1 người tôi thích, và nói với anh ta "OK, tôi sẽ nói chuyện với anh" (pha 3, xác nhận kết nối) Nếu không có pha thứ 3, mà trong trường hợp có nhiều server trả lời, và client chỉ kết nối đến 1 server thì các server kia không biết nó có được nối hay không. Còn nếu dùng 3-way, khi các server khác không nhận được pha 3 thì nó biết rằng client không muốn kết nối và free tiến trình SYN đó. Tuy nhiên, 3-way lại tạo ra một cơ hội cho kiểu tấn công SYN Flood.  
Cái ví dụ này không phải là 3-way, hình như bạn "bị lầm".]]> /hvaonline/posts/list/34830.html#221331 /hvaonline/posts/list/34830.html#221331 GMT Xin giúp đỡ về TCP state diagram!
Sorry vì em đào mộ chút xíu, nhưng hiện tại em đang bị vấn đề là đang gửi nhận dữ liệu bình thường thì nhận TCP có flag RST: Set. Máy em là xxx.xxx.xxx.18, còn máy server là xxx.xxx.5.30 và kết nối từ máy em không qua firewall nên hiện tại không có thiết lập ngăn chặn gì cả. Không biết có ở trong tình trạng bị TCP reset attack hay là không? Nhờ mấy anh tư vấn dùm. Thanks.]]> /hvaonline/posts/list/34830.html#273113 /hvaonline/posts/list/34830.html#273113 GMT