Tweet
Originally posted by invalid-password
View Post
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)
Comment