Nếu host và router là 2 đối tượng có nguy cơ thường xảy ra sự cố thì việc phục hồi sự cố lại là vấn đề rất đáng quan tâm. Nếu toàn bộ các thực thể ở lớp giao vận hoàn toàn ở trong host, khôi phục mạng và sự cố router là dĩ nhiên. Nếu lớp network đang sử dụng dịch vụ gói dữ liệu (datagram service) thì các thực thể ở lớp giao vận luôn sẵn sàng cho các gói tin TPDU bị mất và có cách xử lý. Nếu đường truyền là kết nối tin cậy (connection-oriented service) thì mạch ảo bị fail có thể được thay thế bằng 1 mạch ảo khác và thăm dò các thực thể ở lớp giao vận của đầu bên kia xem những bản tin TPDU nào đã được nhận và những bản tin nào chưa? Sau đó truyền các bản tin chưa được nhận là xong.
Một vấn đề khó chịu hơn là làm thế nào để khôi phục host sau khi gặp sự cố. Một cách cụ thể, sẽ rất thuận lợi cho client khi mà có thể tiếp tục làm việc khi server gặp sự cố và khởi động lại. Để minh họa cho ví dụ này, xét trường hợp 1 client đang gửi 1 file dung lượng lớn cho server, sử dụng giao thức stop-and-wait. Lớp giao vận của server đơn giản chỉ cho qua lần lượt những bản tin TPDU tới người dùng. Vì một lý do nào đó, server gặp sự cố. Khi server hoạt động bình thường trở lại, các bảng danh sách client của nó bị khởi tạo lại do đó nó không biết được chính xác quá trình đang dang dở ở đâu.
Để khôi phục sự cố trên, server phải gửi bản tin TPDU đến tất cả các host khác, thông báo về việc vừa gặp sự cố và yêu cầu các client báo lại cho nó về trạng thái của các kết nối đang mở. Từng client ở 1 trong 2 trạng thái: 1 bản tin TPDU hiện tại – S1 hoặc 0 có bản tin TPDU – S0. Dựa vào thông tin về trạng thái này, client quyết định xem có truyền lại bản tin TPDU gần nhất hay không.
Thoạt nhiên có vẻ là client sẽ truyền lại nếu và chỉ nếu nó có bản tin TPDU không được xác nhận hiện tại trong lúc server gặp sự cố. Tuy nhiên sẽ có những khó khăn đáng kể cho cách tiếp cận vấn đề nghiệp dư như thế này. Hãy xem xét trường hợp khi mà các thực thể của lớp giao vận lúc đầu được gửi bản tin ACK và sau khi ACK được gửi, viết nó vào application process. Viết TPDU vào luồng ra và gửi bản tin ACK là 2 sự kiện không thể tiến hành đồng thời. Nếu sự cố xảy ra sau khi ACK được gửi nhưng lại trước khi quá trình viết TPDU diễn ra, client sẽ nhận được ACK và rơi vào trạng thái S0 khi thông báo khôi phục sự cố đến nơi. Client bởi vậy sẽ không truyền lại, thậm chí nghĩ về bản tin TPDU vừa mới đến. Điều này dẫn đến lỗi của quá trình khắc phục sự cố.
Theo đó nhiều người cho rằng cách khắc phục khác đơn giản hơn là thông báo cho các thực thể ở lớp giao vận bằng cách viết bản tin TPDU trước và gửi bản tin ACK sau. Phương án này cũng không ổn ở chỗ nếu như sự cố xảy ra tại thời điểm vừa viết xong bản tin TPDU nhưng trước khi gửi bản tin ACK. Như vậy client sẽ rơi vào trạng thái S1 và truyền lại, dẫn đến việc TPDU bị lặp tại luồng ra đến server process.
Dù cho server được lập trình như thế nào thì khả năng thất bại trong việc khôi phục sự cố ở một số trường hợp là vẫn có. Server chỉ có thể được lập trình theo 1 trong 2 kiểu: bản tin ACK trước hoặc bản tin TPDU trước. client chỉ có thể được lập trình 1 trong 4 cách: luôn truyền lại TPDU cuối; không bao giờ truyền TPDU cuối; truyền lại chỉ khi ở trạng thái S0 hoặc S1. Như vậy ta có 8 sự lựa chọn cho các cặp server và client. Dĩ nhiên mỗi cách sẽ lại có lỗi trong một số trường hợp.
3 sự kiện có khả năng được thực hiện tại server: (A) gửi bản tin ACK , (B) viết lên tiến trình đầu ra, (C) gặp sự cố. 3 sự kiện có thể xuất hiện theo 6 thứ tự: AC(W), AW(C),C(AW),C(WA),WAC và WC(A). Dấu ngoặc đơn nhằm chỉ không phải A hoặc W có thể giống trạng thái của C. Hình dưới đây cho ta thấy 8 trạng thái của client & server đồng thời thể hiện các chính sách của server ; thứ tự các sự kiện đúng cho từng trường hợp. Lưu ý là với từng chính sách của server, vẫn có những thứ tự có thể làm cho server thất bại trong khôi phục sự cố. Ví dụ như client luôn truyền lại, sự kiện AWC sẽ tạo ra các bản sao không xác định, dù cho 2 sự kiện còn lại hoạt động chính xác.
Trong trường hợp client và server trao đổi một vài bản tin TPDU trước khi server cố viết dữ liệu tại luồng ra. Theo đó client biết chính xác sự cố nào có thể xảy ra chứ không thể biết được chính xác thời điểm gặp sự cố là trước hoặc sau quá trình viết. Do đó kết luận không thể khác đi được là: dựa trên những nguyên tắc cơ bản của việc không có sự kiện xảy ra đồng thời, sự cố tại host và biện pháp khắc phục là không thể tối ưu tuyệt đối đối với các layer trên.
Nói một cách tổng quát hơn, khi sự cố tại lớp N xảy ra thì chỉ có thể được khắc phục tại lớp N+1; và chỉ khôi phục được khi các lớp trên còn giữ lại đủ thông tin về trạng thái. Như vậy, lớp transport có thể khắc phục được sự cố ở lớp network,, đảm bảo các kết nối hoạt động đúng với mục đích ban đầu.
*** Bổ sung:
1. Các loại port của lớp transport.
2. Cơ chế 3 way handshake với mạng cisco.
* Tài liệu tham khảo:
1. Computer network – 4th edition – Prentice Hall
2. CCNA curriculum –s semester 1 – network fundamental 3. google.com
2. Thực tiễn:
Phân loại dịch vụ trên lớp giao vận dựa theo các port. IANA là tổ chức cao nhất trên thế giới phụ trách về vấn đề cấp phát port cho các ứng dụng. Port được chia làm 3 loại chính:
+ Well known port (0 -1023)
Well-known port Protocol Application
20 TCP File Transfer Protocol (Data) FTP
21 TCP File Transfer Protocol (Control) FTP
23 TCP Telnet
25 TCP Simple Mail Transfer Protocol (SMTP)
69 UDP Trivial File Transfer Protocol (TFTP)
80 TCP Hypertext Transfer Protocol ( HTTP)
110 TCP Post Office Protocol 3 ( POP3)
194 TCP Internet Relay Chat (IRC)
443 TCP Secure HTTP (HTTPS)
520 UDP Routing Information Protocol (RIP)
+ Registered port (1024- 49151)
+ Dynamic / Private port (49152 – 65535)
Mail group:
ductrung5190@gmail.com vnduybk@gmail.com