Bài 2 : Chi tiết các lớp trong Mô hình tham chiếu – Application và Transport

Sau bài 1, chúng ta đã biết thế nào là Mô hình tham chiếu, mô hình OSI và mô hình TCP/IP. Để hiểu thêm về quá trình truyền dữ liệu sử dụng mô hình tham chiếu, chúng ta sẽ đi sâu hơn vào các lớp.

Nhắc lại mô hình tham chiếu TCP/IP và mô hình OSI

1. Lớp Application

Các giao thức thuộc lớp Application sẽ cung cấp cho người dùng đầu cuối cách thức để gửi và nhận dữ liệu của một loại hình ứng dụng nào đó. Phạm vi của các ứng dụng rất rộng, chúng ta sẽ cùng điểm qua một vài loại hình ứng dụng được sử dụng phổ biến nhất trong mạng máy tính ngày nay.

1.1. Các giao thức phục vụ truy nhập web:

Ngày nay, lướt web là một hoạt động không thể thiếu trong sử dụng Internet hàng ngày. Về cơ bản, dữ liệu của một trang web sẽ được lưu trên một thiết bị đầu cuối là web – server; người dùng cần phải chạy một chương trình web – client trên máy tính của mình để tương tác với server, từ đó tải được nội dung web cần thiết về máy.

Hoạt động tương tác giữa web – client và web – server được thực hiện bởi giao thức HTTP (HyperText Transfer Protocol):

• Thông qua một “kết nối tưởng tượng” giữa hai host đã được cung cấp bởi lớp Transport, web – server và web – client sẽ sử dụng các thông điệp và thủ tục được quy định bởi HTTP để trao đổi các nội dung web với nhau. Nội dung web mà client có thể truy xuất và tải về từ server có phạm vi rất phong phú: từ các file HTML chứa code web, các file Word “.doc”, cho đến các file “.pdf”, các file ảnh “.jpeg”, file video “.avi”,.v.v…Sau khi được tải về máy, trình duyệt web sẽ tổng hợp dữ liệu đã nhận được thành trang web và hiển thị trước người dùng.
• Do sự phổ biến của hoạt động truy nhập web, HTTP là một trong các giao thức lớp Application được sử dụng nhiều nhất hiện nay.

Ngoài ra, bên cạnh HTTP, một phiên bản khác bảo mật hơn của giao thức này cũng được sử dụng rất nhiều là HTTPS (HTTP Security). Với HTTPS, toàn bộ các thông điệp HTTP cũng như dữ liệu web được trao đổi đều được mã hóa trước khi di chuyển qua hệ thống mạng, điều này giúp cho hoạt động truy nhập web đươc an toàn hơn rất nhiều.

Hình 1.1. Truy cập Web

1.2. Các giao thức gửi/nhận thư điện tử

Một hoạt động khác cũng diễn ra rất nhiều trong sử dụng mạng hàng ngày của người dùng là gửi/nhận thư điện tử (email). Để gửi/nhận email, lớp ứng dụng của mô hình TCP/IP có các giao thức SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol version 3) và IMAP (Internet Message Access Protocol). Trong các giao thức này, SMTP được sử dụng để gửi mail (push mail) từ người dùng đến các mail server và từ mail server này đến mail server kia; còn POP3 và IMAP thì được dùng để kéo mail (pull mail) từ mail server về máy tính của người dùng (hình 1.2).

Ta có thể hình dung mail server đối với người dùng email cũng giống như thùng thư của người gửi thư trong cuộc sống đời thường. Người dùng “bỏ thư” vào “thùng thư” bằng SMTP, thư được chuyển từ “thùng thư” của người dùng này tới “thùng thư” của người dùng khác cũng bằng SMTP; nhưng người nhận thư lấy thư từ “thùng thư” về máy thì bằng POP3 hoặc IMAP.

Hình 1.2. Các giao thức push/pull mail

1.3. Các giao thức truyền file

Một loại hình ứng dụng khác của người dùng cũng rất phổ biến là các ứng dụng chuyên để thực hiện truyền file từ host này đến host kia. Các giao thức loại này cũng được tổ chức thành mô hình client – server: hệ thống file dữ liệu của một doanh nghiệp/tổ chức sẽ được lưu trữ trên các file – server và người dùng sẽ phải chạy các chương trình file – client tương ứng để truy xuất vào hệ thống file này, từ đó thực hiện download hoặc upload các file dữ liệu cần thiết. Các giao thức truy xuất file thường gặp có thể kể ra gồm: FTP (File Transfer Protocol), TFTP (Trivial File Transfer Protocol), NFS (Network File System), SMB (Server Message Block).

Hình 1.3. Quá trình truyền file bằng FTP

1.4. Phân giải tên miền (DNS)

Về nguyên tắc, để truy nhập đến một server, người dùng cần phải chỉ rõ địa chỉ IP của server trong thao tác truy nhập của mình để máy tính của người dùng có thể thực hiện kết nối đến server. Tuy nhiên, vì địa chỉ IP có định dạng là các con số, rất khó nhớ và dễ nhầm lẫn khi thao tác, nên thay vì chỉ ra trực tiếp địa chỉ, người dùng được quyền chỉ ra tên miền (domain name) của server khi truy nhập. Tên miền thường là một chuỗi ký tự sử dụng ngôn ngữ thông thường có tính gợi nhớ cao nên rất thuận tiện cho người dùng sử dụng để định vị server. Mặc dù vậy, khi yêu cầu truy nhập của người dùng được truyền đạt đến máy tính để thực hiện, máy tính vẫn cần địa chỉ IP của server để kết nối, vì máy tính không sử dụng tên miền mà sử dụng IP để định vị server.

Để hỗ trợ cả người dùng và máy tính, một giao thức được đưa ra để chuyển đổi giữa tên miền và địa chỉ IP là giao thức DNS – Domain Name System. Giao thức này cũng hoạt động theo mô hình client – server: khi người dùng gõ tên miền của server muốn truy nhập, DNS – client trên máy tính của người dùng sẽ gửi chuỗi ký tự tên miền này đến một DNS – server; DNS – server sẽ tìm kiếm trong cơ sở dữ liệu của mình địa chỉ IP tương ứng với tên miền được gửi đến và trả kết quả về cho DNS – client; tiếp đó, máy tính người dùng sẽ sử dụng địa chỉ IP nhận được để thực hiện kết nối đến server mong muốn. Trong trường hợp DNS – server không phân giải được, nó sẽ gửi truy vấn tên miền đến các DNS server cấp cao hơn để tìm cho ra IP của server mà người dùng muốn truy nhập.

Ngày nay, gần như mọi hoạt động truy nhập Internet từ lướt web, gửi mail, download file,… đều tham chiếu đến tên miền của server chứa dữ liệu, nên DNS đã trở thành một thành phần không thể thiếu của các hệ thống mạng.

Hình 1.4. Quá trình phân giải tên miền

1.5. Các giao thức giúp truy nhập qua mạng vào giao diện dòng lệnh của thiết bị

Để người quản trị có thể thao tác cấu hình, các thiết bị sẽ cung cấp đến người quản trị một giao diện. Giao diện này có thể là giao diện đồ họa (GUI – Graphical User Interface) hoặc giao diện dòng lệnh (CLI – Command Line Interface).

• Giao diện đồ họa thường được xây dựng dưới dạng các trang web nhúng sẵn trên thiết bị và người quản trị sẽ dùng HTTP hoặc HTTPS để truy nhập đến giao diện này, từ đó thực hiện cấu hình bằng cách thao tác với các biểu tượng đồ họa trên giao diện.
• Giao diện dòng lệnh cho phép người quản trị tương tác với thiết bị bằng lệnh trong tập lệnh của hệ điều hành trên thiết bị. Để truy nhập vào được giao diện này từ xa thông qua kết nối mạng, có hai giao thức lớp Application thường được sử dụng là Telnet (Telecommunication Network) và SSH (Secure Shell). Thiết bị cần phải truy nhập sẽ chạy chương trình Telnet hoặc SSH Server; người quản trị muốn truy nhập CLI của thiết bị sẽ phải chạy chương trình Telnet hoặc SSH Client. Thông qua sự kết nối giữa client trên máy tính của người quản trị và server trên thiết bị, người quản trị có thể đăng nhập vào được giao diện dòng lệnh và gõ lệnh cấu hình thiết bị vừa nêu.

Điểm khác biệt giữa Telnet và SSH là dữ liệu Telnet không được mã hóa, còn dữ liệu SSH được mã hóa khi di chuyển qua hạ tầng mạng. Điều này khiến cho SSH có tính an toàn cao hơn và vì thế được sử dụng nhiều hơn trong truy nhập vào CLI trên thiết bị ngày nay.

Hình 1.5. Truy nhập CLI từ xa bằng Telnet

1.6. Các giao thức khác

• Quản lý và giám sát mạng: Syslog, SNMP – Simple Network Management Protocol).
• Đồng bộ thời gian thực giữa các thiết bị: NTP – Network Time Protocol.
• Các ứng dụng thời gian thực về truyền tải voice và video qua mạng: SIP – Session Initiation Protocol, H.323, RTP – Real time Transport Protocol, RTSP – Real Time Streaming Protocol,…

2. Lớp Transport

2.1. Vai trò của lớp Transport

Như đã trình bày ở trên, khi các lớp 1, 2, 3 hoàn thành vai trò của chúng, hai host bất kỳ kết nối vào mạng hoàn toàn có thể gửi được dữ liệu đến nhau mỗi khi chúng muốn, và vì vậy, một cách gần đúng, giữa hai host bất kỳ này cứ như thể được kết nối với nhau bởi một đường “kết nối tưởng tượng” đi xuyên qua cả hệ thống mạng. Ta thường gọi “kết nối tưởng tượng” vừa nêu là “end – to – end connection” hay “host – to – host connection”. Chức năng của các giao thức lớp Transport là quản lý và tối ưu hóa hoạt động truyền các dữ liệu nhận được từ lớp Application qua “kết nối tưởng tượng”,  “end – to – end” này.

Hình 1.6. End-to-end communication

Các thực thể từ lớp Transport trở lên chỉ biết đến sự hiện diện của kết nối “end – to – end”, chúng không cần biết về việc kết nối này được tạo ra bằng cách nào, làm sao để dữ liệu thực sự đi được từ host này đến host kia vì đó là nhiệm vụ của 3 lớp dưới. Do đó, đôi khi các giao thức lớp trên (4 đến 7) thường được gọi là các giao thức “host – to – host”, còn các giao thức và kỹ thuật ở các lớp dưới (1 đến 3) thường được gọi là các giao thức/kỹ thuật “hop – by – hop”.

Có hai “trường phái” mà các giao thức lớp Transport quản lý kết nối end – to – end giữa hai host:

• Reliable: Thực hiện truyền tải dữ liệu qua kết nối này sử dụng nhiều phương pháp nhằm đảm bảo độ tin cậy cao – tránh tối đa mất mát dữ liệu, đảm bảo tính toàn vẹn của dữ liệu nhận được, thích nghi tốt nhất với hiện trạng mạng.
• Best Effort: Thực hiện truyền tải dữ liệu qua kết nối này nhanh hết mức có thể, không chú trọng đến vấn đề đảm bảo độ tin cậy của hoạt động truyền tải.

Một số đặc điểm của hai trường phái này được mô tả sơ lược trên hình 1.7:

Hình 1.7. Reliable và Best-Effort

Trong đó:

• Connection Type (Loại hình kết nối): Connection – oriented và Connectionless.
  • Với kiểu Reliable, trước khi thực hiện truyền dữ liệu qua “kết nối tưởng tượng” end – to – end, hai thực thể ở hai đầu cần phải thực hiện một thao tác là xây dựng lại kết nối này bằng một thủ tục gọi là “bắt tay 3 bước” (“three way handshake”). Tiếp đó, hai host ở hai đầu sử dụng các phương thức phức tạp để có thể truyền dữ liệu một cách đảm bảo nhất qua kết nối này. Sau khi truyền xong dữ liệu, hai host ở hai đầu còn phải tiến hành thủ tục giải phóng kết nối đã xây dựng giữa chúng. Phương thức làm việc như vậy được gọi là Connection – Oriented. Cách làm việc này đem lại độ tin cậy rất cao cho hoạt động truyền dữ liệu host – to – host, tuy nhiên sẽ khiến cho thiết bị phải tốn kém thêm tài nguyên cho hoạt động truyền tải và có thể sẽ làm chậm lại tốc độ truyền, dẫn đến trễ (latency) trong tương tác ở lớp Application.
  • Với kiểu Best – effort, hai thực thể ở hai đầu không thực hiện thao tác xây dựng kết nối trước khi truyền dữ liệu mà thực hiện truyền ngay lập tức khi có dữ liệu cần truyền. Trong quá trình truyền cũng không có bất kỳ hoạt động nào được thực hiện để đảm bảo dữ liệu được truyền tin cậy. Phương thức làm việc như vậy được gọi là Tuy phương thức này có độ tin cậy không cao nhưng ít gây tốn kém tài nguyên của host thực hiện truyền tải và nhìn chung có tốc độ cao, đáp ứng nhanh được theo thời gian thực.
• Giao thức:
  • Ngày nay, có hai giao thức lớp Transport được sử dụng rộng rãi là giao thức TCP (Transmission Control Protocol) và UDP (User Datagram Protocol).
  • Trong đó, TCP là giao thức Reliable, connection – oriented;
  • UDP là giao thức Best – effort, connectionless.
• Sequencing – đánh số thứ tự:
  • Đây là một đặc điểm nổi bật trong hoạt động của giao thức TCP – một giao thức Reliable điển hình. Với Sequencing, mọi byte mà TCP gửi qua kết nối “end – to – end” đều được đánh số thứ tự, đảm bảo đầu nhận có thể sắp xếp lại đúng trình tự các segment dữ liệu mà đầu gửi đã gửi.
  • Đặc điểm này không có trong cách hoạt động Best – effort của UDP.
• Cách sử dụng:
  • Phương thức Reliable thường được sử dụng trong truyền tải dữ liệu của các loại ứng dụng mang thiên hướng truyền file như: email, web, chia sẻ file,…không quá đặt nặng vấn đề trễ trong truyền tải.
  • Phương thức Best – effort thường được sử dụng trong truyền tải dữ liệu của các loại ứng dụng có đòi hỏi cao về tính tức thời, các ứng dụng thời gian thực như: quản lý giám sát mạng, truyền voice hoặc video,…

2.2. UDP – User Datagram Protocol

UDP là một giao thức truyền tải best – effort, connectionless điển hình. UDP không sử dụng các phương pháp đảm bảo độ tin cậy như báo nhận hay điều khiển luồng (flow control), không thực hiện các biện pháp đánh số thứ tự cho các đơn vị dữ liệu được truyền,…

Với đặc điểm này, UDP sẽ thực hiện truyền tải rất nhanh cho dữ liệu của lớp ứng dụng, tuy nhiên, hoạt động truyền tải này lại không có độ tin cậy cao và dễ bị lỗi.

Hình 1.8 trình bày cấu trúc của một gói tin UDP (thường được gọi là UDP Datagram):

Hình 1.8. Cấu trúc của UDP Datagram

Từ hình 1.8 có thể thấy cấu trúc của UDP header rất đơn giản, phù hợp cho phương thức truyền best – effort connectionless. Trong đó:

• Các trường source port và destination port: cho phép định danh một session của một ứng dụng nào đó chạy trên UDP. Có thể coi port chính là địa chỉ của lớp thứ 4. Ta sẽ nói rõ về công dụng này của Port trong phần khác của mục 2 nói về lớp Transport.
• UDP length: cho biết chiều dài của toàn bộ UDP datagram.
• UDP checksum: thực hiện kiểm tra lỗi cho toàn bộ UDP datagram.
• Data: dữ liệu lớp trên được đóng gói vào UDP datagram đang xét.

2.3. TCP – Transmission Control Protocol

Đặc điểm chung:

Ngược lại với UDP, TCP là giao thức truyền tải connection – oriented điển hình. TCP mang các đặc điểm như sau:

• Phải thực hiện thiết lập kết nối với đầu xa trước khi thực hiện truyền dữ liệu. Tiến trình thiết lập kết nối ở TCP được gọi là tiến trình bắt tay 3 bước (threeway handshake).
• Phải thực hiện cơ chế báo nhận khi truyền dữ liệu. Mọi segment được gửi đi đều phải được báo nhận (acknowledge, hay viết gọn là ack). Các segment gửi đi mà không được báo nhận được xem như bị lỗi khi truyền và sẽ được thực hiện truyền lại.
• Phải thực hiện cơ chế đánh số thứ tự (sequencing) cho các đơn vị dữ liệu được truyền.
• Phải thực hiện các cơ chế điều khiển luồng thích hợp (flow control) để tránh nghẽn xảy ra.

Ngoài ra, một kết nối TCP có thể được xem như một cặp đường kết nối luận lý nối giữa hai host đầu cuối, mỗi đường phục vụ cho một hướng truyền dữ liệu. Ta nói TCP hỗ trợ truyền tải full duplex.

Hình 1.9 trình bày cấu trúc của một gói tin TCP (thường được gọi là TCP segment):

Hình 1.9. Cấu trúc của một TCP Segment

Trong đó:

• Source port và destination port (đều dài 16 bit): được sử dụng để định danh cho session của giao thức nào đó trên lớp Application đang được truyền tải trong TCP segment đang xét.
• Sequence number (32 bit): là số thứ tự của byte đầu tiên trong phần data của segment đang xét. Được sử dụng để đảm bảo sắp xếp đúng thứ tự của dữ liệu nhận được tại phía nhận.
• Acknowledge number (32 bit): số thứ tự của byte kế tiếp mà phía nhận mong muốn phía gửi gửi cho mình.
• Header length (4 bit): cho biết chiều dài của TCP header tính theo đơn vị word (32bit).
• Các bit reserverd (4 bit): đều được thiết lập bằng 0.
• Các bit control (9 bit): thực hiện các chức năng điều khiển như thiết lập, kết thúc một session, kiểm soát nghẽn,… Mỗi bit này còn được gọi là một cờ (flag).
• Windown size (16 bit): số lượng byte mà thiết bị sẵn sàng tiếp nhận.
• Checksum (16 bit): kiểm tra lỗi cho toàn bộ TCP segment.
• Urgent pointer (16bit): chỉ báo điểm kết thúc của dữ liệu khẩn cấp có tính ưu tiên cao (cần được xử lý trước).
• Options (tối đa 32 bit): cho phép thêm vào TCP các tính năng khác.
• Data: dữ liệu lớp trên được đóng gói vào segment TCP.

Bắt tay ba bước (Threeway handshake):

Ví dụ trên hình 1.10 minh họa cho tiến trình bắt tay 3 bước :

Hình 1.10. Quá trình bắt tay 3 bước

Giả sử Bên gửi (Sender) muốn truyền dữ liệu cho Bên nhận (Receiver) thông qua một kết nối TCP. Trước khi thực hiện truyền, sender cần phải thiết lập kết nối TCP với receiver. Việc này được tiến hành thông qua tiến trình bắt tay 3 bước:

1. Sender gửi cho receiver segment đầu tiên, segment này có cờ SYN được bật lên (xem các bit điều khiển trong hình 1.9).
2. Receiver khi nhận được cờ SYN từ đầu bên kia, thực hiện hồi đáp lại một TCP segment. Segment này có cờ SYN và cờ ACK cùng được bật lên.
3. Khi sender nhận được segment hồi đáp từ receiver, nó gửi segment có bật cờ ACK về lại cho receiver.

Sau khi 3 bước này được hoàn tất, kết nối TCP đã được thiết lập giữa sender và receiver, lúc này hai host đã có thể truyền dữ liệu được với nhau.

Điểu khiển luồng (flow control):

Hình 1.11. Điều khiển luồng (flow control)

Khi sender gửi dữ liệu quá nhanh và receiver tiếp nhận không kịp, dữ liệu có thể bị mất. Để tránh xảy ra hiện tượng này, receiver có thể thực hiện cơ chế flow control bằng cách gửi cho sender một chỉ báo cho biết rằng nó chưa sẵn sàng tiếp nhận dữ liệu. Sender khi nhận được chỉ báo này sẽ thực hiện dừng việc truyền dữ liệu và chờ đến khi receiver gửi tín hiệu thông báo là nó đã sẵn sàng nhận dữ liệu thì lại tiếp tục truyền.

ACK báo nhận (Acknowledgement), windowing, sequencing

Như đã nêu ở trên, TCP sử dụng cơ chế báo nhận cho dữ liệu đã gửi đi. Mọi dữ liệu đã gửi đi đều phải được phía nhận gửi ACK xác nhận về phía gửi.

Ví dụ trong hình 1.12 minh họa việc host nhận trả lời ACK cho từng segment dữ liệu nhận được:

Hình 1.12. ACK báo nhận cho từng segment

Trên hình 1.12, mỗi khi sender gửi đi một segment, nó sẽ bật lên một timer, trong thời gian timer này còn đang chạy, nó phải nhận được báo nhận (ACK) từ phía receiver cho segment đã gửi đi. Nếu quá thời gian này mà chưa nhận được ACK, sender sẽ gửi lại segment vừa nêu. Cứ như vậy, dữ liệu sender gửi cho receiver sẽ được tiếp nhận một cách an toàn và tin cậy, đảm bảo không bị bỏ lỡ trong quá trình truyền.

Để tăng hiệu suất của TCP, việc báo nhận có thể được thực hiện cho nhiều segment một lúc thông qua cơ chế windown. Ở ví dụ trong hình 1.13, receiver thực hiện báo nhận cho từng khối 3 segment nhận được từ sender bằng cách thiết lập window size = 3 thay vì báo nhận cho từng segment một.

Hình 1.13. ACK báo nhận với window size = 3

Kích thước cửa sổ cũng có thể được hiệu chỉnh tự động để thích nghi với điều kiện của mạng. Xét ví dụ trên hình 1.14, trong ví dụ này, vì receiver bị nghẽn không thể tiếp nhận được dữ liệu dẫn đến segment thứ 3 bị mất. Receiver chủ động yêu cầu sender lần này chỉ gửi đi một lúc 2 segment bằng cách hạ kích thước window xuống còn 2:

Hình 1.14. Thay đổi kích thước cửa sổ

Việc hạ kích thước window trong truyền tải TCP như vậy giúp các bên thích nghi được với hiện trạng mạng truyền tải.

Ngoài ra, như trong các hình vẽ minh họa đã chỉ ra ở trên, tất cả các segment TCP được gửi đi đều được đánh số thứ tự (sequencing). Điều này giúp kiểm soát lỗi và báo nhận chính xác cho từng segment cũng như có thể giúp phía receiver ghép nối lại dữ liệu người dùng một cách chính xác từ các segment nhận được vì chúng được đảm bảo nhận đúng với thứ tự đã gửi đi.

Trong thực tế, các hiện thực TCP thường đánh số thứ tự (sequencing) cho các byte dữ liệu được truyền và đo đạc kích thước cửa sổ (window) theo số lượng byte chứ không theo các segment được gửi đi.

2.4. Vai trò của Port

Cả UDP và TCP header đều có trường Source Port và Destination Port; đây là những trường rất quan trọng, đóng vai trò không thể thiếu trong hoạt động của các giao thức lớp Transport.

Tham số Port đảm nhận hai nhiệm vụ chính: xác định các application session và nhận diện application nào đang được truyền tải bởi giao thức Transport.

Xác định các application session:

Thông qua cặp source port và destination port của giao thức truyền tải, một session của một application sẽ được xác định trong quá trình truyền tải end – to – end. Ta có thể xem xét một ví dụ trong hình 1.28 để làm rõ điều này.

Trên hình 1.15, Host A ở phía đầu này của mạng muốn truy nhập đến Host B ở phía đầu kia của mạng bằng hai phương thức: HTTP và Telnet. Với HTTP, Host A có thể tải về từ Host B dữ liệu của một trang web nào đó đang được lưu trữ trên Host B; còn với Telnet, Host A có thể thực hiện thiết lập các thông số (mà ta hay gọi là “cấu hình”) cho Host B thông qua các lệnh trên giao diện dòng lệnh của Host B.

Hình 1.15. Session Multiplexing

HTTP và Telnet là hai ứng dụng thuộc lớp Application, hai ứng dụng nay hoạt động theo mô hình Client – Server; do đó, để đáp ứng yêu cầu như trên, trên Host B sẽ cài các chương trình HTTP Server và Telnet Server, còn phía Host A sẽ cài các chương trình HTTP Client và Telnet Client. Các client và server vừa nêu sẽ phải tương tác với nhau thông qua “đường truyền” chính là “kết nối tưởng tượng end – to – end” giữa Host A và Host B. Trên “đường truyền” này, như vậy xuất hiện đồng thời hai luồng dữ liệu: một của HTTP và một của Telnet và vì vậy, cần phải có một cơ chế phân biệt và nhận dạng hai luồng dữ liệu thuộc hai ứng dụng khác nhau này.

Khi xây dựng các giao thức Application, các developer có thể chọn phương thức truyền tải dưới lớp Transport là UDP hoặc TCP tùy theo các yêu cầu về Application. Với HTTP và Telnet, phương thức truyền tải được chọn là TCP: mọi thông điệp HTTP và Telnet đều được đóng gói vào các TCP segment ở lớp Transport và truyền đi trên các kết nối end – to – end TCP. Để phân biệt hai luồng TCP này, người ta sử dụng cặp tham số Source Port và Destination Port trong header của các segment TCP. Cụ thể, trong ví dụ trên hình 1.28:

• Mọi TCP segment truyền tải dữ liệu HTTP khi di chuyển từ Host A đến Host B sẽ có source port là 1024 và destination port là 80; khi di chuyển ngược lại từ Host B đến Host A sẽ có source port là 80 và destination port là 1024.
• Mọi TCP segment truyền tải dữ liệu Telnet khi di chuyển từ Host A đến Host B sẽ có source port là 1025 và destination port là 23; khi di chuyển ngược lại từ Host B đến Host A sẽ có source port là 23 là destination port là 1025.

Như vậy, cặp Port “1024 – 80” xác định ra được một HTTP session và cặp Port “1025 – 23” xác định ra được một Telnet session. Tại phía đầu cuối, TCP trên các host căn cứ vào cặp Port này để đưa dữ liệu lên đúng chính xác giao thức tương ứng của tầng Application.

Từ ví dụ trên, ta thấy, cứ mỗi một cặp source – destination port của một phương thức truyền tải sẽ xác định ra một session application nào đó, cho phép hai host đồng thời giao tiếp với nhau cùng lúc bởi nhiều application mà không bị ảnh hưởng lẫn nhau. Chức năng này còn được gọi là session multiplexing của tham số Port trong TCP và UDP header.

Nhận diện Application:

Một chức năng quan trọng khác của tham số Port là giúp các thiết bị hoạt động ở lớp Transport nhận diện được Application nào đang được truyền tải trong gói UDP hoặc TCP mà không cần phải mở gói này ra.

Hình 1.16. Nhận diện Application được truyền tải

Điều này được thực hiện bằng cách quan sát Port đang được sử dụng trong header của giao thức truyền tải. Ví dụ (hình 1.16):

• Nếu một gói TCP có trường Port (Source Port hoặc Destination Port) mang giá trị là 80 thì bên trong phần tải của nó đang chứa dữ liệu của một session HTTP.
• Tương tự, nếu một gói TCP có trường Port mang giá trị là 23 thì bên trong phần tải của nó đang chứa dữ liệu của một session Telnet.
• Nếu một gói TCP có trường Port mang giá trị là 21 thì nó đang truyền tải dữ liệu FTP.
• Nếu một gói UDP hoặc TCP có trường Port mang giá trị là 53 thì nó đang truyền tải dữ liệu DNS.
• Nếu một gói UDP có trường Port mang giá trị là 69 thì nó đang truyền tải dữ liệu TFTP.
• Nếu một gói UDP có trường Port mang giá trị là 161 thì nó đang truyền tải dữ liệu SNMP.
• .v.v…

Như vây, các giao thức lớp Transport khi truyền tải các ứng dụng không sử dụng tham số Port một cách tùy ý mà phải chọn Port cho các ứng dụng theo một quy ước đã được xác định từ trước. Các giao thức application thường gặp và port tương ứng của chúng được quy định và chuẩn hóa bởi tổ chức IANA – Internet Assigned Numbers Authority. Đây là một tổ chức toàn cầu có nhiệm vụ quản lý và phân phối các tài nguyên của mạng Internet như địa chỉ IP, giá trị port truyền tải cho các application, số hiệu mạng (autonomous system number) cho định tuyến BGP,.v.v…. Chúng ta có thể xem danh sách các giao thức application và các giá trị port tương ứng đã được đăng ký và phê chuẩn bởi IANA theo danh sách nằm tại đường link https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Lưu ý rằng, các port gán cho các ứng dụng phổ biến vừa nêu ở trên thường được gọi là dải wellknown port hay system port, thường lấy giá trị trong dải từ 0 đến 1023 và được mở tại phía Server của ứng dụng. Tại phía Client, Port của application thường được các chương trình Client chọn ngẫu nhiên lớn hơn hoặc bằng 1024.

Kiểm tra port trên máy tính :

Trong quản trị server, người quản trị thường hay sử dụng lệnh “netstat” trên giao diện dòng lệnh của các hệ điều hành nổi tiếng như Windows hoặc Linux để xác định xem server đã mở port nào, từ đó xác định được Application nào đã được cài đặt và chạy trên server. Ví dụ:

[root@localhost ~]# netstat -nlutp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/systemd       
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      7028/dnsmasq       
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6540/sshd          
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      6538/cupsd         
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      6939/master        
tcp6       0      0 :::111                  :::*                    LISTEN      1/systemd          
tcp6       0      0 :::80                   :::*                    LISTEN      16277/httpd        
tcp6       0      0 :::22                   :::*                    LISTEN      6540/sshd          
tcp6       0      0 ::1:631                 :::*                    LISTEN      6538/cupsd         
tcp6       0      0 ::1:25                  :::*                    LISTEN      6939/master        
udp        0      0 192.168.122.1:53        0.0.0.0:*                           7028/dnsmasq       
udp        0      0 0.0.0.0:67              0.0.0.0:*                           7028/dnsmasq       
udp        0      0 0.0.0.0:111             0.0.0.0:*                           1/systemd          
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           6183/avahi-daemon: 
udp        0      0 0.0.0.0:40199           0.0.0.0:*                           6183/avahi-daemon: 
udp        0      0 0.0.0.0:828             0.0.0.0:*                           6173/rpcbind       
udp6       0      0 :::111                  :::*                                1/systemd          
udp6       0      0 :::828                  :::*                                6173/rpcbind

Trong ví dụ này, ta có thể thấy, trên server chạy hệ điều hành CentOS, các port 22, 80 của TCP đã được mở, cho thấy hai ứng dụng SSH và HTTP đã được bật trên server này. Thật vậy:

[root@localhost ~]# systemctl status sshd
  sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-11-02 07:07:47 +07; 12min ago
(…)

[root@localhost ~]# systemctl status httpd
  httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Mon 2020-11-02 07:13:03 +07; 7min ago

(…)