3-way hand shake của TCP

[myquartz]

Vụ bắt tay mấy bước thì không liên quan đến việc truyền tin cậy hay không tin cậy. Tin cậy hay không là do sequnce number, windows size, ACK, và check sum đảm bảo.

Tại sao TFTP bắt tay có 2 bước ? Nó chỉ cần bắt tay 2 bước là truyền được dữ liệu :
+ Máy A Gửi request
+ Máy B gửi ACK.
và bắt đầu truyền data ...

Đừng nói là TFTP không tin cậy, nếu có lỗi thì nó cũng truyền lại.

Mà tin cậy hay không là ở giai đoạn truyền dữ liệu, chứ không phải ở giai đoạn bắt tay.

So sánh TCP với TFTP là khập khiễng, bởi vì TCP là giao thức lớp 4, nó "đa mục đích", so với TFTP là layer 5 trở lên, có mục đích rõ ràng ngay khi nó gửi cái TFTP request đầu tiên (server biết là client muốn gì), và reply sẽ đáp ứng luôn điều đó mà không cần thắc mắc gì thêm.
Ví dụ:
Với TCP, A và B khi thực hiện 3-way handshake, thì cả A và B đều không biết kết nối sẽ truyền cái gì, đầu nào gửi trước. Phải đợi sau khi 3-way xong rồi thì A hoặc B mới tiếp tục làm các request ở lớp trên để biết truyền cái gì. 3-way là cách tin cậy duy nhất để cả A và B chắc chắn với nhau là kênh nối đã được tạo lập, và rồi A hoặc B ở layer trên tuỳ giao thức sẽ tiếp tục. Nó rất giống ví dụ quân đội truyền tin kia.
Xét thử trường hợp POP3 chạy trên TCP nhé:
1. A (client) gửi SYN cho B (server) tới port 110.
2. B trả về SYN-ACK cho A, xác nhận kết nối.
Nếu ở bước 1. mất gói tin, thì B không nhận được, B không ACK, A suy ra là gói tin của mình gửi đi bị mất, gửi SYN lại. Trường hợp này ok.
Nếu ở bước 2. bị mất gói tin, thi B đã reply, A ko nhận được ACK, A gửi lại SYN, B lại gửi lại ACK. Tuy nhiên, mỗi khi B nhận đc và reply, chỉ dừng ở đây, nó sẽ hiểu là kết nối thành công, lúc phải allocate resource để layer cao hơn 4 handle cái kết nối này. Với POP3, câu chào của POP3 Server sẽ gửi đi vào lúc này. Như thế, sẽ có 2 gói tin gửi đi: 1 gói ACK, 1 gói là câu chào của POP3 gửi cho B theo thứ tự đó.
A ko nhận được gói SYN-ACK từ B, nhưng lại nhận được gói chứa câu chào (data), nó sẽ rất khó xử trường hợp này. Nó sẽ coi là kết nối OK với gói data đó hay là lại SYN lại? Hơn nữa, gói SYN-ACK có 1 thông tin cực kỳ quan trọng, đó là sequence number đầu tiên B bắt đầu gửi cho A trong phiên truyền, dựa vào đó A sẽ biết khúc nào bị thiếu mà gửi ACK tới đó thôi. Với 1 gói tin data nhận được mà không có SYN-ACK từ B, nó sẽ ko biết là gói chứa data đó thiếu hay đủ tính từ đầu phiên (server có thể gửi 1 hay nhiều gói data) để mà gửi ACK cho hợp lý (confirm số seq nào đây?). Chưa kể thứ tự các gói tin nó đến không theo như thứ tự gửi.
Do đó, người ta cần bước 3.
3. A -> B ACK với gói SYN-ACK, ACK này thực ra là A confirm cho B là "tôi đã nhận được số start sequence của anh trong gói SYN-ACK đó, anh hãy gửi từ số đó, nếu nhận khúc nào tôi báo lại seq đến lúc đó".
Không cần 4-way vì đến đây là đủ thông tin, cần thêm gì nữa đâu?

Ta lại xem TFTP, nó hoàn toàn khác, thông tin chỉ truyền 1 chiều sau khi kết nối được (mục đích cụ thể, ko "đa mục đích" như là TCP):
1. Khi A (TFTP client) gửi cho B (TFTP Server), trong đó, nó đã gồm thông tin yêu cầu tên file nào, đọc hay ghi.
2. B nhận được request, nếu là write request, thì B nó ACK cho A và bắt đầu nhận data (rồi cứ ack đều đều với mỗi packet nó nhận được). A nhận được ACK, sẽ biết B đã nhận được bao nhiêu data rồi để mà truyền tiếp (hay truyền lại).
3. B nhận được request, nếu là read request, thì B nó gửi luôn Data cho A và bắt đầu nhận ACK. A nhận được data, ACK lại cho B biết. B thấy thiếu ACK nào thì sẽ truyền lại (hay truyền tiếp).
TFTP không cần 3-way bắt tay là vậy. Thực chất nó ẩn 1 trong 3 way trong gói data nó gửi đầu tiên rồi.
(Xem http://en.wikipedia.org/wiki/Trivial...nsfer_Protocol)

[stylish_man]

Mình cũng vửa xem kỹ lại thì thấy chắc invalid-password ghi nhầm, 2-way mới là tạo cơ hội cho syn flood chứ không phải 3-way.

3-way vẫn syn flood đuợc nhưng không giả ip source đuợc vì vậy nếu firewall có thiết lập maximum session per source = 100 chẳng hạn thì không thể flood quá 100 session. Tuy nhiên giả sử nếu 2-way tạo đuợc 1 session thì sẽ flood chết luôn cả con firewall vì nguời ta tạo session từ nhiều ip source giả khác nhau. 3-way không thể giả ip source vì bản tin syn-ack không trả về đuợc thì không thể gửi ack để hoàn thiện 1 session.

Mục đích của SYN Flood không phải là để "hoàn thiện 1 session" bạn ạ. Hacker có thể giả mạo IP source cũng được mà không giả mạo IP source cũng được. Trong trường hợp không giả mạo IP thì hacker đơn giản là discard các gói tin ACK ở bước cuối. Và invaild-password ghi đúng chứ không phải ghi nhầm đâu. Bạn nghiên cứu kĩ lại chắc chắn sẽ rõ ràng thôi.
Chúc bạn một ngày nghỉ lễ vui vẻ!

[eyear]

Nếu bạn hỏi ưu/nhược điểm thì mình trả lời được, còn tại sao nó phải như thế này mà không như thế khác thì chắc có trời mới biết... Tại sao người ta không ra vào bằng cửa sổ và ngồi ngắm trăng bên cửa chính mà phải làm ngược lại...!?

[nguyendiep]

Nếu bạn hỏi ưu/nhược điểm thì mình trả lời được

Vậy nhược điểm của 3-way là gì ? Làm sao để khắc phục nhược điểm đó ?

[eyear]

Vậy nhược điểm của 3-way là gì ? Làm sao để khắc phục nhược điểm đó ?

http://www.windowsecurity.com/whitepapers/Examining_port_scan_methods__Analyzing_Audible_Techniques_.html

Mình vừa search hộ bạn, nếu bạn thực sự muốn biết thì nó nằm ở mục 1.2.

[daviddwilson]

Bạn nào có thể giải thích giùm mình tại sao trong TCP lại phải sử dụng 3-way hand shake? thanks.

Chào !!!
Vì nó giúp duy trì kết nối theo kiểu đáng tin cậy!!! (oriented-connection)

Chúc bạn vui !!!

[hoangtucodon121]

Chủ đề này lâu rồi mà :D Thử liên hệ với câu chuyện sau nha:
-----------------------------------------
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 :D
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 :D

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

mình thấy cái này rất hay và sinh động, dễ hiểu. Nếu muốn hiểu rõ cái ví dụ bạn này nói mình nghĩ nên đọc qua cái 3 ways hand-shake trong giáo trình là ok ;)

[hackchip2]

connection oriented chứ không phải oriented-connection

Chào !!!
Vì nó giúp duy trì kết nối theo kiểu đáng tin cậy!!! (oriented-connection)

Chúc bạn vui !!!