21 trang 6 lượt tải

Giới thiệu về Kiến trúc Phân tầng và Dịch vụ Internet | Môn Thiết kế và triển khai mạng IP - Đại học Bách Khoa Hà Nội

12

Kết nối tầng giao vận (Transport Layer): Giới thiệu về tầng chịu trách nhiệm truyền dữ liệu giữa các ứng dụng trên các máy tính khác nhau. Tài liệu được sưu tầm gồm 21 trang, giúp bạn ôn tập tốt hơn. Mời các bạn đón xem. 

Môn: Thiết kế và triển khai mạng IP 24 tài liệu

Trường: Đại học Bách Khoa Hà Nội 4.3 K tài liệu

Tác giả:

Profile

Linh Giang

1 tuần trước
Tải xuống Chia sẻ Báo cáo
Danh sách Quiz
Tải xuống
/21
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Internet).
Chào bạn, tôi rất sẵn lòng trình bày và giải thích chi tiết bài giảng này cho bạn. Chúng ta sẽ đi qua từng phần
một. Sau mỗi phần, tôi sẽ dừng lại và hỏi để đảm bảo bạn đã nắm rõ nội dung trước khi chúng ta tiếp tục.
Bây giờ, chúng ta hãy bắt đầu với phần đầu tiên: Giới thiệu tổng quan và Kiến trúc phân tầng.
Phần 1: Giới thiệu tổng quan và Kiến trúc phân tầng (Slides 1-3)
Slide 1: Trang bìa - Internet Services
Nội dung: Đây là slide mở đầu, giới thiệu chủ đề của bài giảng là "Internet Services" (Các Dịch vụ
Giải thích chi tiết:
Slide này cho chúng ta biết bài giảng được biên soạn bởi giảng viên Phạm Huy Hoàng, thuộc
Viện Công nghệ Thông tin và Truyền thông (SoICT) của Đại học Bách Khoa Hà Nội (HUST).
Logo "25 năm SoICT" cho thấy bối cảnh bài giảng nằm trong chuỗi sự kiện hoặc tài liệu kỷ niệm
của viện.
Chủ đề "Internet Services" ám chỉ rằng chúng ta sẽ học về các dịch vụ nền tảng và phổ biến nhất
mà mạng Internet cung cấp, chẳng hạn như duyệt web, gửi email, phân giải tên miền, v.v. Đây là
những dịch vụ mà người dùng cuối tương tác hàng ngày.
Slide 2: Nội dung
Nội dung: Slide này trình bày bố cục, hay mục lục, của toàn bộ bài giảng.
Giải thích chi tiết:
Kết nối tầng giao vận (Transport Layer): Giới thiệu về tầng chịu trách nhiệm truyền dữ liệu giữa
các ứng dụng trên các máy tính khác nhau.
Kết nối tầng ứng dụng (Application Layer): Tập trung vào tầng cao nhất, nơi các ứng dụng
mạng như trình duyệt web, email client hoạt động.
Dịch vụ IP cơ bản: DNS, Mail, Web: Đây là phần trọng tâm của bài giảng, đi sâu vào ba dịch vụ
cốt lõi:
DNS (Domain Name System): Hệ thống phân giải tên miền, dịch từ tên web (ví dụ:
google.com) sang địa chỉ IP.
Mail: Dịch vụ thư điện tử (email).
Web: Dịch vụ duyệt web qua giao thức HTTP/HTTPS.
Kết nối dịch vụ mạng riêng và mạng public Internet: Đề cập đến cách các mạng nội bộ
(như mạng công ty, gia đình) kết nối và tương tác với mạng Internet toàn cầu.
Slide 3: Vị trí trong kiến trúc phân tầng
Nội dung: Slide này trực quan hóa vị trí và vai trò của các tầng trong mô hình mạng máy tính (cụ thể là
mô hình TCP/IP).
Giải thích chi tiết:
Mô hình này chia nhỏ quá trình giao tiếp mạng thành các "tầng" (layers), mỗi tầng có một chức
năng chuyên biệt. Dữ liệu đi từ trên xuống ở máy gửi và từ dưới lên ở máy nhận.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Application (Tầng Ứng dụng): Tầng cao nhất, gần với người dùng nhất. Nó hỗ trợ các ứng
dụng trên mạng như trình duyệt web (HTTP), email (SMTP), v.v. Các dịch vụ chúng ta sẽ học (Web,
Mail, DNS) đều nằm ở tầng này.
Transport (Tầng Giao vận): Nhiệm vụ của nó là truyền dữ liệu giữa các ứng dụng (processes)
đang chạy trên các máy tính khác nhau. Nó cung cấp hai giao thức chính là TCP (tin cậy) và UDP
(không tin cậy).
Network (Tầng Mạng): Chịu trách nhiệm chọn đường và chuyển tiếp các gói tin (packets)
giữa các mạng khác nhau. Giao thức chính ở đây là IP (Internet Protocol).
Datalink (Tầng Liên kết dữ liệu): Hỗ trợ việc truyền thông cho các thiết bị trên cùng một mạng
vật lý (ví dụ: trong cùng một mạng LAN).
Physical (Tầng Vật lý): Tầng cuối cùng, chịu trách nhiệm truyền và nhận dòng bit (0 và 1) trên
đường truyền vật lý (cáp đồng, cáp quang, sóng vô tuyến).
Slide này rất quan trọng vì nó đặt nền móng kiến thức, giúp chúng ta hiểu các dịch vụ như Web, DNS không
hoạt động một mình mà dựa trên sự hỗ trợ của các tầng bên dưới.
Phần 1 (Giới thiệu tổng quan và Kiến trúc phân tầng) đã kết thúc. Bạn đã hiểu rõ và hài lòng với phần giải thích
này chưa? Chúng ta có thể tiếp tục với phần tiếp theo không?
Phần 2: Kết nối Tầng Giao vận (Slides 4-6)
Khi bạn đã sẵn sàng, chúng ta sẽ tiếp tục với phần giải thích về vai trò và đặc điểm của Tầng Giao vận (Transport
Layer).
Slide 4: Kết nối tầng giao vận (1)
Nội dung: Slide này đi sâu vào chức năng chính và cách hoạt động của tầng giao vận.
Giải thích chi tiết:
Chức năng cốt lõi: Tầng giao vận cung cấp một phương tiện truyền thông logic giữa các ứng
dụng cuối (end applications). "Logic" có nghĩa là các ứng dụng trên hai máy tính khác nhau có
thể gửi dữ liệu cho nhau như thể có một đường ống kết nối trực tiếp, mặc dù trên thực tế dữ liệu
phải đi qua nhiều thiết bị mạng trung gian (routers) như trong hình.
Ứng dụng là các tiến trình: Điều quan trọng cần nhớ là tầng giao vận không kết nối máy tính với
máy tính, mà là tiến trình (process) với tiến trình. Ví dụ, trên máy tính của bạn có thể đang chạy
cả trình duyệt Chrome và ứng dụng Skype. Tầng giao vận đảm bảo dữ liệu từ máy chủ web sẽ đến
đúng trình duyệt Chrome, và dữ liệu cuộc gọi sẽ đến đúng ứng dụng Skype.
Hoạt động ở Bên gửi (Sender):
1. Nhận dữ liệu từ một ứng dụng (ví dụ: trình duyệt web gửi yêu cầu HTTP).
2. "Đóng gói" dữ liệu này vào các đơn vị gọi là đoạn tin (segments).
3. Nếu dữ liệu từ ứng dụng quá lớn, nó sẽ được chia nhỏ (segmentation) thành nhiều đoạn
tin.
4. Chuyển các đoạn tin này xuống cho tầng mạng (Network Layer) để gửi đi.
Hoạt động ở Bên nhận (Receiver):
1. Nhận các đoạn tin từ tầng mạng.
2. Tập hợp (reassembly) lại dữ liệu từ các đoạn tin này.
3. Chuyển dữ liệu đã hoàn chỉnh lên cho ứng dụng tương ứng.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
Slide 5: Kết nối tầng giao vận (2)
Nội dung: Slide này làm rõ hơn về phạm vi hoạt động và các loại dịch vụ của tầng giao vận.
Giải thích chi tiết:
Cài đặt trên các hệ thống cuối (End Systems): Như hình minh họa, tầng giao vận (màu cam) chỉ
tồn tại trên các thiết bị đầu cuối như máy tính của người dùng và máy chủ. Các thiết bị trung gian
như routers và switches không có tầng này. Chúng chỉ cần xử lý đến tầng mạng (Network Layer) để
quyết định đường đi cho gói tin. Đây là lý do nó được gọi là "end-to-end transport". Hai
dạng dịch vụ giao vận: Tầng giao vận cung cấp hai loại dịch vụ chính, tương ứng với hai giao thức
phổ biến:
1. TCP (Transmission Control Protocol): Dịch vụ tin cậy, hướng liên kết
(connectionoriented).
Tin cậy: Đảm bảo mọi dữ liệu gửi đi sẽ đến nơi một cách nguyên vẹn và đúng thứ
tự. Nếu có mất mát, nó sẽ tự động gửi lại.
Hướng liên kết: Trước khi truyền dữ liệu, hai bên phải thiết lập một kết nối (giống
như một cuộc gọi điện thoại, bạn phải "bắt tay" trước khi nói chuyện).
Ví dụ sử dụng: duyệt web (HTTP), tải file (FTP), gửi email (SMTP).
2. UDP (User Datagram Protocol): Dịch vụ không tin cậy, không liên kết (connectionless).
Không tin cậy: Gửi dữ liệu đi mà không đảm bảo nó có đến nơi hay không, và cũng
không đảm bảo thứ tự. Nó hoạt động theo kiểu "gửi và quên". Không liên kết: Không
cần thiết lập kết nối trước, cứ có dữ liệu là gửi.
Ví dụ sử dụng: Streaming video/audio, game online, DNS (thường là vậy). Các ứng
dụng này ưu tiên tốc độ và chấp nhận mất mát một vài gói tin nhỏ.
Slide 6: Ứng dụng IP cơ bản và dịch vụ giao vận
Nội dung: Slide này là một bảng tổng kết, liên kết các ứng dụng phổ biến ở tầng ứng dụng với giao
thức ở tầng giao vận mà chúng sử dụng.
Domain Name (DNS): Dùng UDP. Lý do: Các truy vấn và phản hồi DNS thường rất nhỏ, chỉ gồm
một gói tin. Dùng UDP nhanh hơn vì không cần chi phí thiết lập và duy trì kết nối như TCP. E-mail
(SMTP): Dùng TCP. Lý do: Việc gửi email đòi hỏi độ tin cậy tuyệt đối. Chúng ta không thể chấp
nhận việc email bị mất hoặc sai thứ tự nội dung.
Remote terminal access (Telnet): Dùng TCP. Lý do: Khi bạn điều khiển một máy tính từ xa, mỗi
ký tự bạn gõ đều phải được gửi đi một cách tin cậy.
Web (HTTP): Dùng TCP. Lý do: Để một trang web hiển thị chính xác, toàn bộ mã HTML, CSS, ảnh...
phải được tải về đầy đủ và đúng đắn.
File transfer (FTP): Dùng TCP. Lý do: Tương tự như Web, việc truyền file cần đảm bảo file ở đích
giống hệt file ở nguồn.
Streaming multimedia: Dùng TCP hoặc UDP. Lý do:
Một số dịch vụ streaming (như YouTube) ngày nay dùng TCP để đảm bảo chất lượng và
tránh giật lag do phải chờ gói tin gửi lại.
Các dịch vụ yêu cầu thời gian thực cao (live streaming, video call) thường dùng UDP (hoặc
các giao thức xây dựng trên nó như RTP) vì việc chờ đợi một gói tin bị mất sẽ gây ra độ trễ
lớn, thà bỏ qua gói tin đó còn hơn.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Internet telephony (VoIP): Thường dùng UDP. Lý do: Tương tự streaming thời gian thực, trong
một cuộc gọi thoại, tốc độ là tối quan trọng. Trễ một vài mili giây có thể chấp nhận được, nhưng
dừng cả cuộc hội thoại để chờ một gói tin bị mất thì không.
Phần 2 (Kết nối Tầng Giao vận) đã kết thúc. Phần này đã giải thích vai trò, đặc điểm và các giao thức chính của
tầng giao vận. Bạn đã hiểu rõ và hài lòng chưa? Chúng ta có thể tiếp tục với phần "DNS" không?
Phần 3: Hệ thống phân giải tên miền (DNS) (Slides 7-20)
Khi bạn sẵn sàng, chúng ta sẽ đi sâu vào một trong những dịch vụ nền tảng quan trọng nhất của Internet:
DNS.
Slide 7 & 8: Giới thiệu chung
(Slide 7 chỉ là slide trống, nội dung chính nằm ở slide 8)
Nội dung: Slide này giới thiệu các khái niệm cơ bản về tên miền và DNS.
Giải thích chi tiết:
Tên miền (Domain Name):
Đây là một định danh (tên) trên tầng ứng dụng, giúp con người dễ dàng ghi nhớ và truy
cập các máy chủ (nút mạng) trên Internet. Thay vì phải nhớ một dãy số khó nhớ như
142.250.204.78, chúng ta chỉ cần nhớ google.com.
Việc quản lý tên miền được tổ chức tập trung theo một hệ thống phân cấp.
Quốc tế: ICANN (Internet Corporation for Assigned Names and Numbers) là tổ chức
quản lý cao nhất.
Việt Nam: VNNIC (Vietnam Internet Network Information Center) là cơ quan quản
lý tên miền cấp quốc gia .vn.
DNS (Domain Name System):
Là một hệ thống phân tán toàn cầu, bao gồm các máy chủ DNS có nhiệm vụ quản lý thông
tin tên miền và cung cấp dịch vụ phân giải tên miền, tức là dịch từ tên miền sang địa chỉ
IP.
Vấn đề cần giải quyết:
Người dùng sử dụng tên miền để truy cập dịch vụ.
Máy tính và thiết bị mạng lại giao tiếp với nhau bằng địa chỉ IP.
Câu hỏi cốt lõi là: Làm thế nào để chuyển đổi (ánh xạ) từ một tên miền sang địa chỉ IP
tương ứng? DNS chính là câu trả lời.
Slide 9: Chuyển đổi địa chỉ và ví dụ
Nội dung: Slide này minh họa một cách trực quan quá trình phân giải tên miền cơ bản.
Giải thích chi tiết:
1. Người dùng (NSD - Người sử dụng): Gõ tên miền www.soict.hust.edu.vn vào trình duyệt và
nhấn Enter.
2. Máy tính của người dùng: Nhận ra rằng nó cần địa chỉ IP của web server này để kết nối. Nó
không biết địa chỉ IP là gì.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
3. Hành động: Máy tính gửi một truy vấn đến "Máy chủ tên miền" (DNS Server). Truy vấn có nội
dung: "Xin cho biết địa chỉ IP của www.soict.hust.edu.vn là gì?"
4. Máy chủ tên miền: Tra cứu trong cơ sở dữ liệu của nó và tìm thấy bản ghi tương ứng.
5. Phản hồi: Máy chủ tên miền trả lời lại cho máy tính của người dùng: "Địa chỉ IP của
www.soict.hust.edu.vn là 202.191.56.65".
6. Kết nối: Bây giờ máy tính của người dùng đã có địa chỉ IP, nó có thể gửi yêu cầu trực tiếp đến
"Máy chủ web" tại địa chỉ 202.191.56.65 để tải trang web về.
Slide 10: Không gian tên miền (Domain Name Space)
Nội dung: Mô tả kiến trúc của hệ thống tên miền.
Giải thích chi tiết:
Kiến trúc hình cây (Tree Structure): Không gian tên miền được tổ chức theo một cấu trúc phân
cấp hình cây.
Root (Nút gốc): Là đỉnh của cây, được biểu diễn bằng một dấu chấm (.). Ví dụ,
google.com. thực chất là tên miền đầy đủ.
Bên dưới gốc là các tên miền cấp cao nhất (Top-Level Domains - TLDs) như .com, .org,
.net, và các tên miền quốc gia như .vn, .jp.
Bên dưới TLDs là các tên miền cấp hai (ví dụ hust.edu.vn), và cứ thế tiếp tục.
Zone (Vùng): Một "zone" là một phần của cây tên miền được một máy chủ DNS cụ thể
quản lý. Ví dụ, VNNIC quản lý zone .vn, còn HUST quản lý zone hust.edu.vn. Việc này cho phép
quản lý phân tán.
Bản ghi (Resource Records - RRs): Mỗi nút trên cây (tương ứng với một tên miền) được mô tả
bởi một tập hợp các bản ghi. Các loại bản ghi quan trọng bao gồm:
A (Address): Ánh xạ một tên miền sang một địa chỉ IPv4. Đây là bản ghi phổ biến nhất. (Ví
dụ: soict.hust.edu.vn -> 202.191.56.65).
NS (Name Server): Cho biết máy chủ DNS nào chịu trách nhiệm (authoritative) cho một
zone.
SOA (Start of Authority): Chứa thông tin quản trị về một zone, như máy chủ DNS chính,
email của người quản trị, v.v.
Slide 11 & 12: Hệ thống máy chủ DNS
Nội dung: Các slide này mô tả hệ thống phân cấp của các máy chủ DNS trên toàn thế giới.
Giải thích chi tiết: Hệ thống DNS được chia thành nhiều cấp bậc:
1. Máy chủ tên miền gốc (Root DNS Server):
Có 13 hệ thống máy chủ gốc trên toàn thế giới (được đặt tên từ A đến M). Tuy nhiên,
mỗi hệ thống này thực chất là một cụm gồm rất nhiều máy chủ vật lý được đặt ở nhiều vị trí
địa lý khác nhau (sử dụng công nghệ Anycast) để đảm bảo tính sẵn sàng và giảm độ trễ.
Nhiệm vụ: Chúng không biết địa chỉ IP của google.com, nhưng chúng biết máy chủ
nào quản lý tên miền .com. Chúng sẽ chỉ cho người hỏi đến đúng nơi để hỏi tiếp.
2. Máy chủ tên miền cấp 1 (Top Level Domain - TLD Server):
Quản lý các tên miền cấp cao nhất như .com, .org, .vn.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Nhiệm vụ: Ví dụ, máy chủ TLD của .com không biết địa chỉ IP của google.com, nhưng nó biết
máy chủ DNS nào của Google chịu trách nhiệm cho google.com. Nó sẽ chỉ đường đến đó.
3. Máy chủ được ủy quyền (Authoritative DNS Server):
Đây là máy chủ cuối cùng trong chuỗi truy vấn, chứa thông tin chính xác và cuối cùng về
một tên miền. Ví dụ, máy chủ DNS của HUST là authoritative cho tên miền hust.edu.vn.
Nhiệm vụ: Khi được hỏi, nó sẽ trả về câu trả lời chính xác (ví dụ: địa chỉ IP trong bản ghi A).
4. Máy chủ cục bộ (Local DNS Server):
Đây là máy chủ không thuộc hệ thống phân cấp chính thức trên. Thường là máy chủ DNS
của nhà cung cấp dịch vụ Internet (ISP) của bạn (VNPT, FPT, Viettel) hoặc các dịch vụ công
cộng như 8.8.8.8 (Google DNS), 1.1.1.1 (Cloudflare).
Nhiệm vụ: Khi máy tính của bạn cần phân giải một tên miền, nó sẽ hỏi máy chủ này đầu
tiên. Máy chủ cục bộ sẽ thay mặt bạn thực hiện toàn bộ quá trình truy vấn đến các máy chủ
Root, TLD, và Authoritative để tìm ra câu trả lời, sau đó trả về cho bạn và lưu vào bộ nhớ
đệm (cache) để tăng tốc cho các lần hỏi sau.
Slide 13: Phân giải tên miền
Nội dung: Liệt kê các phương pháp và cơ chế để phân giải tên miền.
Tự phân giải (trên máy local):
File HOSTS: Một file văn bản đơn giản trên máy tính để ánh xạ thủ công IP với tên
miền.
Windows: C:\WINDOWS\system32\drivers\etc\hosts
Linux: /etc/hosts
Hệ điều hành sẽ kiểm tra file này trước khi gửi truy vấn DNS ra ngoài.
Bộ đệm của ứng dụng/hệ điều hành (Cache): Cả trình duyệt và hệ điều hành đều lưu lại
kết quả của các lần phân giải gần đây để không phải hỏi lại, giúp tăng tốc độ.
Dịch vụ phân giải tên miền (Client/Server):
Đây là phương pháp chính, sử dụng giao thức DNS.
Giao thức: DNS là một giao thức tầng ứng dụng.
Cổng dịch vụ: Hoạt động trên cổng 53. Thường dùng UDP cho các truy vấn nhanh, nhưng
có thể dùng TCP cho các tác vụ cần độ tin cậy cao hơn như truyền dữ liệu zone (zone
transfer) giữa các máy chủ.
Các loại truy vấn:
Phân giải đệ quy (Recursive Query): Máy tính của bạn "ủy thác" hoàn toàn cho máy
chủ DNS cục bộ. Nó chỉ hỏi: "Tìm cho tôi IP của X", và chờ câu trả lời cuối cùng.
Phân giải tương tác (Iterative Query): Máy chủ DNS cục bộ sẽ hỏi "từng bước".
Nó hỏi Root, Root chỉ đến TLD. Nó hỏi TLD, TLD chỉ đến Authoritative. Nó hỏi
Authoritative và nhận được câu trả lời. Đây là cách các máy chủ DNS "nói chuyện" với
nhau.
Slide 14 & 15: Thông điệp DNS
Nội dung: Mô tả cấu trúc của một gói tin DNS.
Giải thích chi tiết:
Giải thích chi tiết:
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
Cả truy vấn (Query) và phản hồi (Reply) đều có chung một khuôn dạng (format). Khuôn dạng này
được chia thành các phần:
Header (Phần đầu):
Identification: Một số ngẫu nhiên để khớp một phản hồi với truy vấn của nó.
Flags: Các cờ điều khiển cho biết đây là truy vấn hay phản hồi, có phải là phản hồi từ máy
chủ authoritative không, có hỗ trợ đệ quy không, v.v.
Question (Phần câu hỏi):
#Question: Số lượng câu hỏi (thường là 1).
QUESTION: Nội dung câu hỏi, bao gồm tên miền cần truy vấn và loại bản ghi (ví dụ: A, NS,
MX).
Answer (Phần trả lời):
#Answer RRs: Số lượng bản ghi trong phần trả lời.
ANSWER: Chứa các bản ghi (Resource Records - RRs) trả lời trực tiếp cho câu hỏi. Ví dụ: bản
ghi A chứa địa chỉ IP.
Authority (Phần ủy quyền):
#Authority RRs: Số lượng bản ghi.
AUTHORITY: Chứa các bản ghi NS trỏ đến các máy chủ DNS authoritative cho tên miền đó.
Phần này hữu ích khi câu trả lời không có trong phần Answer.
Additional (Phần bổ sung):
#Additional RRs: Số lượng bản ghi.
ADDITIONAL: Chứa các thông tin bổ sung hữu ích. Ví dụ, nếu phần Authority trả về tên của
một máy chủ NS, phần Additional thường sẽ chứa luôn địa chỉ IP (bản ghi A) của máy chủ
NS đó, giúp client không phải thực hiện thêm một truy vấn DNS nữa.
Slide 16, 17, 18: Ví dụ: dig linux.com
Nội dung: Phân tích kết quả trả về từ lệnh dig, một công cụ dòng lệnh mạnh mẽ để truy vấn DNS.
QUESTION SECTION: Câu hỏi là tìm bản ghi A (địa chỉ IP) cho linux.com.
ANSWER SECTION:
Phần này trả lời trực tiếp câu hỏi. Ta thấy linux.com có 2 địa chỉ IP là 140.211.167.51 và
140.211.167.50.
1786 là TTL (Time-to-Live), tính bằng giây. Nó cho biết máy chủ DNS cục bộ có thể lưu kết
quả này trong cache trong 1786 giây. Trong khoảng thời gian này, nếu có ai hỏi lại, nó sẽ
trả lời từ cache mà không cần truy vấn lại từ đầu.
AUTHORITY SECTION:
Phần này cho biết các máy chủ DNS được ủy quyền (authoritative) cho tên miền linux.com
là ns1.linux-foundation.org. và ns2.linux-foundation.org..
Như slide 17 giải thích, nếu phần ANSWER rỗng (tức là máy chủ hiện tại không biết câu trả
lời), thì client sẽ phải gửi truy vấn tới các máy chủ được liệt kê trong phần AUTHORITY này.
ADDITIONAL SECTION:
Phần này cung cấp thông tin "giúp sức". Nó cung cấp luôn địa chỉ IP (bản ghi A) của
ns1.linux-foundation.org. và ns2.linux-foundation.org..
Như slide 18 giải thích, đây là địa chỉ IP của các máy chủ trả lời truy vấn. Việc cung cấp sẵn
thông tin này giúp client không phải tốn thêm một vòng lặp DNS để tìm IP của ns1.linux-
foundation.org. trước khi có thể hỏi nó.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Slide 19: Phân giải tương tác (Iterative Query)
Nội dung: Minh họa cơ chế phân giải mà các máy chủ DNS sử dụng để nói chuyện với nhau.
Giải thích chi tiết:
Đây là cơ chế mặc định giữa các máy chủ DNS. "Tương tác" có nghĩa là hỏi từng bước một.
Giả sử máy chủ Default server (máy chủ cục bộ của ISP) cần tìm soict.hust.edu.vn.
1. Nó không biết, nên nó hỏi Root server.
2. Root server trả lời: "Tôi không biết, nhưng tôi biết máy chủ quản lý .vn. Cậu hãy đi hỏi dns.vn
(TLD server)".
3. Default server hỏi máy chủ dns.vn.
4. dns.vn trả lời: "Tôi không biết, nhưng tôi biết máy chủ quản lý hust.edu.vn. Cậu hãy đi hỏi
dns.hust.edu.vn (Authoritative server)".
5. Default server hỏi máy chủ dns.hust.edu.vn.
6. dns.hust.edu.vn là máy chủ authoritative, nó biết câu trả lời và trả về địa chỉ IP 202.191.56.65.
7. Default server nhận được IP cuối cùng và trả về cho client.
Slide 20: Phân giải đệ quy (Recursive Query)
Nội dung: Minh họa cơ chế truy vấn mà máy tính người dùng thường sử dụng.
Giải thích chi tiết:
"Đệ quy" có nghĩa là "ủy thác". Client chỉ hỏi một lần và chờ câu trả lời cuối cùng.
1. Máy tính người dùng (202.191.56.65) hỏi Default server: "Hãy tìm cho tôi địa chỉ IP của
soict.hust.edu.vn." Đây là một yêu cầu đệ quy.
2. Default server chấp nhận yêu cầu này và có trách nhiệm tìm ra câu trả lời cuối cùng. Nó bắt đầu
quá trình phân giải tương tác như đã mô tả ở slide 19 (hỏi Root -> hỏi TLD -> hỏi Authoritative).
3. Sau khi nhận được câu trả lời cuối cùng từ Authoritative DNS server, Default server sẽ trả kết
quả này về cho máy tính người dùng.
Sự kết hợp giữa truy vấn đệ quy (client -> local server) và truy vấn tương tác (local server -> các server
khác) tạo nên hiệu quả cho toàn bộ hệ thống DNS.
Phần 3 (Hệ thống phân giải tên miền - DNS) đã kết thúc. Đây là một phần khá dài và chi tiết về một dịch vụ
nền tảng rất quan trọng. Bạn đã hiểu rõ và hài lòng với phần giải thích này chưa? Chúng ta có thể tiếp tục với
phần "HTTP và Web" không?
Tuyệt vời! Chúng ta sẽ tiếp tục với phần tiếp theo, một dịch vụ mà chúng ta sử dụng hàng ngày: HTTP và Web.
Phần 4: HTTP và Web (Slides 21-36)
Phần này sẽ giải thích cách World Wide Web ra đời, giao thức HTTP hoạt động như thế nào, và các khái niệm
liên quan như URL, cookie, và các chế độ của HTTP.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Slide 21 & 22: HTTP và Web
(Slide 21 chỉ là slide trống, nội dung chính nằm ở slide 22)
Nội dung: Slide này cung cấp bối cảnh lịch sử về sự ra đời của World Wide Web (WWW).
Giải thích chi tiết:
Internet trước thập kỷ 1990s:
Internet lúc này chủ yếu được sử dụng trong môi trường học thuật, chính phủ và nghiên
cứu. Nó không thân thiện với người dùng phổ thông.
Các dịch vụ chính là email và truyền file (FTP). Tuy nhiên, các dịch vụ này không có cách nào
hiệu quả để liên kết các tài liệu với nhau một cách dễ dàng. Nếu bạn đọc một tài liệu và
muốn tham khảo một tài liệu khác, bạn phải tự tìm và mở nó.
Năm 1990, Tim Berners-Lee giới thiệu World Wide Web: Đây là một cuộc cách mạng. WWW
đề xuất một hệ thống mới dựa trên các khái niệm:
1. Siêu văn bản (Hypertext): Các tài liệu không còn là những văn bản tĩnh. Chúng có thể
chứa các liên kết (hyperlinks), cho phép người dùng nhảy từ tài liệu này sang tài liệu khác
chỉ bằng một cú click chuột.
2. HTML (Hypertext Markup Language): Là ngôn ngữ được sử dụng để tạo ra các trang siêu
văn bản này. Nó định nghĩa cấu trúc và nội dung của một trang web (tiêu đề, đoạn văn,
hình ảnh, liên kết...).
3. URL (Uniform Resource Locator): Là một cơ chế để định vị (địa chỉ) cho mỗi tài nguyên
(trang web, hình ảnh, video) trên Internet, giúp các liên kết biết phải trỏ đến đâu.
Ý tưởng cốt lõi là các đối tượng (hình ảnh, văn bản) không cần phải đóng gói "tất cả trong một" nữa.
Một trang web có thể được tạo thành từ nhiều tài nguyên nằm ở nhiều nơi khác nhau trên thế giới, được
liên kết với nhau bằng URL và hiển thị trên trình duyệt của người dùng.
Slide 23: Uniform Resource Locator (URL)
Slide 24: HTTP và Web - Mô hình Client/Server
Nội dung:
Phân tích cấu trúc của một URL.
Giải thích chi tiết:
URL là địa chỉ duy nhất của một tài nguyên trên mạng. Nó cho trình duyệt biết
tài nguyên đó là
gì
cách để lấy nó về
.
Cấu trúc chung:
protocol://hostname[:port]/directory-path/resource
protocol
:
Giao thức sẽ được sử dụng để truy cập tài nguyên. Ví dụ
:
http
,
https
(để truy cập web)
ftp
(để truyền file)
smtp
(để gửi mail)
hostname
:
Tên miền (ví dụ:
www.google.com
)
hoặc địa chỉ IP của máy chủ chứa tài
nguyên.
port
(tùy chọn): Cổng dịch vụ trên máy chủ. Mỗi giao thức có một cổng mặc định (HTTP
là 80, HTTPS là 443). Nếu URL không chỉ định cổng, trình duyệt sẽ sử dụng cổng mặc định.
directory-path
:
Đường dẫn đến tài nguyên trên máy chủ, giống như cấu trúc thư mục
trên máy tính của bạn.
resource
:
Tên của tài nguyên cụ thể (ví dụ:
index.html
,
logo.png
).
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
Giải thích chi tiết:
Nội dung: Mô tả kiến trúc cơ bản của Web và vai trò của giao thức HTTP.
WWW (World Wide Web): Là một hệ thống thông tin toàn cầu nơi người dùng có thể truy cập
các tài nguyên siêu văn bản (HTML).
HTTP (HyperText Transfer Protocol): Là giao thức ở tầng ứng dụng, định ra các quy tắc để trình
duyệt web và máy chủ web "nói chuyện" với nhau. Nó là "ngôn ngữ" của Web.
Mô hình Client/Server:
Client (Khách): Là trình duyệt web (Firefox, Chrome, Safari) chạy trên máy tính hoặc điện
thoại của người dùng.
Nhiệm vụ: Gửi yêu cầu (HTTP Request) đến máy chủ để xin một tài nguyên (ví dụ:
một trang web). Sau khi nhận được tài nguyên, nó sẽ hiển thị (render) nội dung đó
cho người dùng.
Server (Chủ): Là phần mềm máy chủ web (Apache, Nginx, IIS) chạy trên một máy tính mạnh
mẽ.
Nhiệm vụ: Lắng nghe các yêu cầu từ client, tìm tài nguyên được yêu cầu và gửi phản
hồi (HTTP Response) chứa tài nguyên đó trở lại cho client.
Slide 25: Hoạt động của HTTP
Nội dung: Tóm tắt các bước trong một phiên giao dịch HTTP điển hình.
Giải thích chi tiết:
1. Thiết lập liên kết TCP: Trước khi có thể trao đổi bất cứ điều gì, client và server phải thiết lập một
kết nối tin cậy.
Server mở một TCP socket và lắng nghe các yêu cầu kết nối trên cổng 80 (cổng mặc định
cho HTTP).
Client (trình duyệt) khởi tạo một kết nối TCP đến địa chỉ IP và cổng 80 của server.
Server chấp nhận yêu cầu, và một kết nối TCP được thiết lập.
2. Trao đổi thông điệp HTTP: Bây giờ, client và server có thể gửi dữ liệu cho nhau qua kết nối TCP
vừa tạo.
Client gửi một thông điệp HTTP Request (ví dụ: "GET /index.html HTTP/1.1").
Server xử lý yêu cầu và gửi lại một thông điệp HTTP Response (chứa nội dung của file
index.html và mã trạng thái, ví dụ: "200 OK").
3. Đóng liên kết TCP: Sau khi giao dịch hoàn tất, kết nối TCP có thể được đóng lại. (Điều này đúng
với HTTP/1.0, còn HTTP/1.1 có thể giữ kết nối mở để dùng lại).
Slide 26: Khuôn dạng HTTP Request
Nội dung: Phân tích cấu trúc chi tiết của một thông điệp yêu cầu HTTP.
Đây là một thông điệp văn bản (ASCII), con người có thể đọc hiểu được.
Dòng yêu cầu (Request Line): Dòng đầu tiên, quan trọng nhất.
GET: Phương thức yêu cầu (sẽ nói ở slide sau).
/~tungbt/index.htm: Đường dẫn tới tài nguyên trên server.
HTTP/1.1: Phiên bản HTTP đang sử dụng.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
HTTP/1.0:
Giải thích chi tiết:
Các dòng tiêu đề (Header Lines): Cung cấp thêm thông tin cho server.
Host: soict.hust.edu.vn: Tên miền của server. Đây là tiêu đề bắt buộc trong HTTP/1.1,
cho phép một server vật lý có thể host nhiều website khác nhau.
User-Agent: Thông tin về trình duyệt và hệ điều hành của client.
Accept: Các loại nội dung mà client có thể chấp nhận (ví dụ: text/html, ảnh...).
Connection: keep-alive: Yêu cầu server giữ kết nối TCP mở sau khi gửi xong response
để có thể dùng lại cho các request tiếp theo.
Dòng trống (Báo kết thúc tiêu đề): Một dòng trống (\r\n) để phân tách phần header và phần
thân (body).
Phần thân (Entity Body - không có trong ví dụ này): Chứa dữ liệu gửi lên server. Phần này chỉ
có với các request như POST.
Slide 27: Các phương thức yêu cầu (Request Methods)
Nội dung: Liệt kê các phương thức chính trong HTTP.
GET: Yêu cầu lấy về một tài nguyên. Dữ liệu (tham số) được gửi đi như một phần của URL (ví
dụ: ...search?q=computer+network).
POST: Yêu cầu gửi dữ liệu lên server để xử lý (ví dụ: điền form đăng nhập, đăng bài viết).
Dữ liệu được gửi trong phần thân (body) của request, không hiển thị trên URL.
HEAD: Giống hệt GET, nhưng server chỉ trả về phần header của response, không trả về nội
dung. Hữu ích để kiểm tra xem tài nguyên có tồn tại hay không, hoặc lấy thông tin về tài
nguyên (ngày cập nhật cuối, kích thước...) mà không cần tải nó về.
HTTP/1.1 (bổ sung thêm):
PUT: Tải một file lên server tại một đường dẫn URL cụ thể. Nếu tài nguyên đã tồn tại, nó sẽ
bị ghi đè.
DELETE: Xóa một tài nguyên trên server tại một URL cụ thể.
Lưu ý: Sự khác biệt chính giữa GET và POST là GET gửi tham số qua URL, còn POST gửi qua
body. Do đó, POST an toàn hơn cho việc gửi thông tin nhạy cảm (như mật khẩu) vì nó không bị
lưu lại trong lịch sử trình duyệt hay log của server một cách rõ ràng như URL.
Slide 28: Khuôn dạng HTTP Response
Nội dung: Phân tích cấu trúc của một thông điệp phản hồi từ server.
Cũng là một thông điệp văn bản.
Dòng trạng thái (Status Line):
HTTP/1.1: Phiên bản HTTP.
200: Mã trạng thái (status code). 200 có nghĩa là "OK" (thành công).
OK: Mô tả ngắn gọn về mã trạng thái.
Các dòng tiêu đề (Header Lines): Cung cấp thông tin về response và server.
Date: Thời gian server gửi response.
Server: Thông tin về phần mềm web server (ví dụ: Apache/2.2.15 trên CentOS).
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
Last-Modified: Thời gian tài nguyên được sửa đổi lần cuối.
Content-Length: Kích thước của nội dung (dữ liệu) trả về, tính bằng byte.
Content-Type: Loại của dữ liệu trả về (ví dụ: text/html). Điều này giúp trình duyệt biết
phải xử lý dữ liệu như thế nào (hiển thị như HTML, mở như ảnh, v.v.).
Dòng trống: Phân tách header và body.
Phần thân (Dữ liệu đáp ứng yêu cầu): Đây là nội dung thực sự của tài nguyên mà client yêu cầu
(ví dụ: mã HTML của trang web).
Slide 29: Mã trạng thái trả lời (Status Codes)
Nội dung: Giới thiệu một số mã trạng thái HTTP phổ biến.
Các mã trạng thái được nhóm theo chữ số đầu tiên:
2xx (Success): Yêu cầu đã được xử lý thành công.
200 OK: Thành công. Tài nguyên được trả về trong body.
3xx (Redirection): Cần hành động thêm để hoàn thành yêu cầu (thường là chuyển hướng).
301 Moved Permanently: Tài nguyên đã được chuyển vĩnh viễn đến một URL mới.
URL mới được chỉ định trong header Location:. Trình duyệt sẽ tự động truy cập URL
mới.
4xx (Client Error): Yêu cầu có lỗi từ phía client.
400 Bad Request: Server không hiểu được cú pháp của request.
404 Not Found: Server không tìm thấy tài nguyên được yêu cầu. Đây là một trong
những lỗi phổ biến nhất.
5xx (Server Error): Server gặp lỗi khi xử lý một yêu cầu hợp lệ.
505 HTTP Version Not Supported: Server không hỗ trợ phiên bản HTTP mà client
yêu cầu.
Slide 30: Hiển thị (rendering) nội dung trang web
Nội dung: Mô tả quy trình cơ bản mà trình duyệt thực hiện sau khi nhận được HTTP Response.
Giải thích chi tiết:
1. Nhận thông điệp HTTP Response.
2. Phân tích và hiển thị (Parse & Render):
Trình duyệt đọc mã HTML để xây dựng cấu trúc của trang (DOM Tree).
Khi gặp các thẻ tham chiếu đến các tài nguyên khác (như ảnh <img src="...">, file CSS
<link href="...">, file Javascript <script src="...">), trình duyệt sẽ gửi tiếp các
HTTP Request để tải các tài nguyên này về.
Nó áp dụng các quy tắc trong CSS để định dạng giao diện và thực thi mã Javascript để thêm
các chức năng tương tác.
3. Xử lý sự kiện (Event Handling): Trang web không phải là một thực thể tĩnh. Trình duyệt liên tục
lắng nghe các sự kiện để phản ứng lại.
Sự kiện của người dùng: OnClick (khi người dùng click chuột), OnMouseOver (khi di chuột
qua một phần tử).
Sự kiện của trình duyệt: OnLoad (khi trang đã tải xong hoàn toàn), OnBeforeUnload (khi
người dùng chuẩn bị rời khỏi trang).
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
Giải thích chi tiết:
Sự kiện theo thời gian: setTimeout() (thực thi một hành động sau một khoảng thời
gian), setInterval() (lặp lại một hành động theo chu kỳ).
Slide 31: Các chế độ của HTTP
Nội dung: So sánh hai chế độ hoạt động chính của HTTP: không duy trì và có duy trì.
HTTP không duy trì (Non-persistent HTTP):
Đây là cơ chế mặc định của HTTP/1.0.
Mỗi đối tượng trên trang web (file HTML, mỗi file ảnh, file CSS...) đòi hỏi một kết nối TCP
riêng biệt.
Quy trình: Mở kết nối TCP -> Gửi request -> Nhận response -> Đóng kết nối TCP. Lặp lại
cho mọi đối tượng.
Nhược điểm: Rất tốn kém về thời gian và tài nguyên vì phải thực hiện quá trình "bắt tay 3
Slide 32: Hoạt động của HTTP/1.0 (Không duy trì)
Nội dung: Minh họa bằng biểu đồ thời gian cho chế độ không duy trì.
Giải thích chi tiết:
Giả sử trang index.html có tham chiếu đến 10 ảnh.
1. Kết nối 1 (tải HTML):
Client mất 1 RTT (Round-Trip Time - thời gian để một gói tin đi và về) để thiết lập kết nối
TCP.
Client gửi request, server nhận và gửi lại response. Quá trình này mất thêm 1 RTT cộng
với thời gian truyền file. 2. Kết nối 2-11 (tải 10 ảnh):
Quá trình trên được lặp lại 10 lần nữa cho 10 file ảnh.
Tổng cộng: Cần 11 kết nối TCP riêng biệt và ít nhất 22 RTT (2 RTT cho mỗi đối tượng) để tải
xong toàn bộ trang. 11xRTT trên slide là cách tính đơn giản hóa, thực tế là 2*11 RTT.
Slide 33 & 34: Hoạt động của HTTP/1.1 (Có duy trì)
Nội dung: Minh họa cho chế độ có duy trì, bao gồm cả Pipelining.
HTTP/1.1 (Không Pipelining - Slide 33):
Chỉ cần 1 kết nối TCP.
Client gửi request cho index.html, nhận response.
Sau đó, vẫn trên kết nối đó, nó gửi request cho ảnh 1, chờ nhận response.
bước" của TCP cho mỗi đối tượng.
HTTP có duy trì (Persistent HTTP):
Đây là cơ chế mặc định của
HTTP/1.1
.
Client và server thiết lập một kết nối TCP và
giữ nó mở
để gửi/nhận nhiều
request/response qua cùng một kết nối đó.
Ưu điểm:
Hiệu quả hơn nhiều, giảm độ trễ và tải cho server.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Rồi gửi request cho ảnh 2, chờ nhận response...
Cơ chế này được gọi là Stop-and-wait: gửi một yêu cầu và phải đợi phản hồi trước khi gửi
yêu cầu tiếp theo. Nó vẫn tốn nhiều RTT.
Slide 35: HTTP là giao thức stateless
Nội dung: Giải thích một đặc tính quan trọng của HTTP: tính không trạng thái.
Giải thích chi tiết:
Stateless (Không trạng thái): Có nghĩa là Web server không ghi nhớ bất cứ thông tin gì về
các request trước đó của một client. Mỗi request được xử lý một cách hoàn toàn độc lập, như
thể nó là lần đầu tiên server thấy client đó.
Ví dụ: Bạn thêm một món hàng vào giỏ hàng online (request 1). Khi bạn đi đến trang thanh toán
(request 2), nếu không có cơ chế nào khác, server sẽ không biết bạn là ai và giỏ hàng của bạn có
gì.
Vấn đề: Rất nhiều ứng dụng web (ngân hàng, thương mại điện tử, mạng xã hội) lại cần duy trì
trạng thái để nhận diện người dùng và cung cấp trải nghiệm cá nhân hóa.
Giải pháp: Các cơ chế như Cookie được tạo ra để giải quyết vấn đề này.
Slide 36: HTTP Cookie
Nội dung: Giới thiệu cơ chế Cookie để giúp HTTP "có trạng thái".
Giải thích chi tiết: Cookie là một mẩu dữ liệu nhỏ mà server gửi cho trình duyệt để lưu lại.
Quy trình hoạt động:
1. Lần đầu truy cập: Client gửi request đến server.
2. Server tạo Cookie: Server xử lý request và khi gửi lại HTTP Response, nó đính kèm một
header Set-Cookie: với một giá trị duy nhất (ví dụ: Set-Cookie: userID=12345).
3. Trình duyệt lưu Cookie: Trình duyệt nhận response và lưu lại mẩu cookie này, gắn nó với
tên miền của server.
4. Các lần truy cập sau: Với mọi request tiếp theo đến cùng một server đó, trình duyệt sẽ tự
động đính kèm cookie đã lưu vào trong một header Cookie:. (ví dụ: Cookie:
userID=12345).
5. Server nhận diện: Server đọc header Cookie: và biết được "À, đây là người dùng số
12345". Nó có thể truy xuất giỏ hàng, thông tin đăng nhập... của người dùng này và trả về
một trang web được cá nhân hóa.
HTTP/1.1 với Pipelining (Slide 34):
Đây là một sự tối ưu hóa.
Vẫn trên
1
kết nối TCP
.
Client gửi
liên tiếp nhiều request
(cho ảnh 1, 2, ..., 10) mà
không cần chờ response
của
request trước đó.
Server nhận các request và gửi lại các response theo đúng thứ tự.
Ưu điểm:
Giảm đáng kể thời gian chờ đợi, gần như chỉ tốn vài RTT để tải toàn bộ trang.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Bằng cách này, Cookie giúp server "ghi nhớ" được client qua nhiều request khác nhau, tạo ra một phiên
(session) làm việc.
Phần 4 (HTTP và Web) đã kết thúc. Chúng ta đã đi qua lịch sử, các khái niệm cốt lõi, hoạt động và các chế độ
của HTTP. Bạn đã hiểu rõ và hài lòng với phần giải thích này chưa? Chúng ta có thể tiếp tục với phần "HTTPS"
không?
Tuyệt vời! Chúng ta sẽ tiếp tục với phần tiếp theo, một sự nâng cấp quan trọng của HTTP để đảm bảo an toàn
và bảo mật: HTTPS.
Phần 5: HTTPS (Slides 37-40)
Phần này sẽ giải thích những hạn chế của HTTP, tại sao HTTPS lại cần thiết và cách nó hoạt động để bảo vệ
người dùng.
Slide 37: HTTPS
Nội dung: Slide này nêu lên các vấn đề bảo mật của HTTP và giới thiệu HTTPS như một giải pháp.
Giải thích chi tiết:
Hạn chế của HTTP: HTTP là một giao thức "trần" (plain text). Dữ liệu được truyền đi mà không
được bảo vệ, dẫn đến hai lỗ hổng nghiêm trọng:
1. Không có cơ chế xác thực (Authentication): Người dùng không có cách nào chắc chắn
rằng máy chủ mà họ đang kết nối đến thực sự là vietcombank.com.vn chứ không phải là
một trang web giả mạo do kẻ tấn công dựng lên. Kẻ tấn công có thể giả mạo dịch vụ hoặc
chèn mã độc vào nội dung trang web (ví dụ: Man-in-the-Middle attack).
2. Không có cơ chế mã hóa (Encryption): Toàn bộ dữ liệu trao đổi giữa trình duyệt và máy
chủ (bao gồm tên đăng nhập, mật khẩu, số thẻ tín dụng) đều ở dạng văn bản thuần. Kẻ tấn
công có thể "nghe lén" (eavesdropping) trên đường truyền và đánh cắp các thông tin nhạy
cảm này một cách dễ dàng.
Secure HTTP (HTTPS): Là giải pháp cho những vấn đề trên.
Về bản chất, HTTPS không phải là một giao thức mới hoàn toàn. Nó chính là HTTP chạy
trên một lớp bảo mật bổ sung là SSL/TLS.
SSL (Secure Sockets Layer) và phiên bản kế nhiệm của nó là TLS (Transport Layer
Security) là các giao thức mật mã tạo ra một kênh truyền an toàn giữa hai bên. Nó nằm
giữa Tầng Ứng dụng (HTTP) và Tầng Giao vận (TCP).
HTTPS cung cấp 3 lớp bảo vệ chính:
1. Xác thực (Authentication): Đảm bảo người dùng đang truy cập vào đúng website mà họ
muốn. Điều này được thực hiện thông qua Chứng chỉ số (SSL/TLS Certificate). Trình duyệt
sẽ kiểm tra chứng chỉ của website để xác minh danh tính của nó.
2. Toàn vẹn dữ liệu (Data Integrity): Đảm bảo dữ liệu trong quá trình truyền không bị thay
đổi hoặc chỉnh sửa bởi kẻ thứ ba.
3. Bảo mật/Mã hóa (Confidentiality/Encryption): Dữ liệu được giữ bí mật trong suốt quá
trình truyền bằng cách mã hóa nó. Kể cả khi kẻ tấn công nghe lén được, họ cũng chỉ thấy
một chuỗi ký tự vô nghĩa.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Số hiệu cổng ứng dụng: HTTPS sử dụng cổng 443 thay vì cổng 80 của HTTP.
Slide 38: HTTP trên trình duyệt Web
Nội dung: Minh họa giao diện của một trang web sử dụng HTTP.
Giải thích chi tiết:
Slide này cho thấy màn hình trang chủ của Vietcombank tại thời điểm bài giảng được soạn.
Quan trọng nhất là nhìn vào thanh địa chỉ: http://www.vietcombank.com.vn.
Sử dụng http:// có nghĩa là kết nối này không được bảo mật. Nhiều trình duyệt hiện đại sẽ
hiển thị một biểu tượng cảnh báo (như hình ổ khóa bị gạch chéo hoặc chữ "Not Secure") để cảnh
báo người dùng.
Mũi tên chỉ vào nút "Đăng nhập / Login" và chú thích "Khi click vào liên kết..." là một cách để
dẫn dắt đến slide tiếp theo. Hành động quan trọng như đăng nhập chắc chắn không thể thực hiện
qua một kết nối không an toàn.
Slide 39: HTTPS trên trình duyệt Web
Nội dung: Minh họa giao diện khi người dùng chuyển sang sử dụng HTTPS, đặc biệt là cho các tác vụ
nhạy cảm.
Giải thích chi tiết:
Sau khi người dùng click vào nút đăng nhập, họ được chuyển hướng đến một trang mới.
Hãy nhìn vào thanh địa chỉ: https://.... Chữ "s" là viết tắt của "Secure".
Trình duyệt hiển thị một biểu tượng ổ khóa màu xanh lá cây (hoặc màu xám trên các trình
duyệt hiện đại). Đây là dấu hiệu trực quan cho người dùng biết rằng họ đang ở trên một kết nối
an toàn.
Giải thích các lợi ích của HTTPS trong bối cảnh này:
1. "Toàn bộ nội dung website (bao gồm hình ảnh, CSS, Flash, scripts...) đã được trình
duyệt thẩm tra tính toàn vẹn và nguồn gốc tin cậy."
Điều này có nghĩa là trình duyệt đã kiểm tra chứng chỉ SSL/TLS của trang web và xác
nhận rằng nó thực sự thuộc về Vietcombank, không phải là trang giả mạo. Nó cũng
đảm bảo rằng không có thành phần nào của trang web bị kẻ tấn công thay đổi trên
đường truyền.
2. "Mọi thông tin trao đổi giữa trình duyệt và Vietcombank được giữ bí mật."
Điều này có nghĩa là tên đăng nhập, mật khẩu và mã xác thực mà người dùng nhập
vào sẽ được mã hóa trước khi gửi đi. Kẻ tấn công không thể đọc được những thông
tin này.
Slide 40: Slide trống
Slide này là một slide trống, có thể dùng để kết thúc phần HTTPS hoặc làm bước đệm chuyển sang chủ
đề tiếp theo.
Phần 5 (HTTPS) đã kết thúc. Phần này đã làm rõ sự khác biệt giữa HTTP và HTTPS cũng như tầm quan trọng
của việc sử dụng kết nối bảo mật. Bạn đã hiểu rõ và hài lòng với phần giải thích này chưa? Chúng ta có thể tiếp
tục với dịch vụ quan trọng tiếp theo là "Email" không?
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Rất tốt! Giờ chúng ta sẽ chuyển sang một dịch vụ Internet nền tảng khác cũng rất quen thuộc: Dịch vụ Email.
Phần 6: Dịch vụ Email (Slides 41-46)
Phần này sẽ giới thiệu các thành phần, giao thức và kiến trúc hoạt động của hệ thống thư điện tử.
Slide 41: Dịch vụ email
Nội dung: Giới thiệu các thành phần và giao thức chính trong hệ thống email.
Giải thích chi tiết:
Hệ thống email bao gồm ba thành phần chính:
1. MUA (Mail User Agent - Tác nhân người dùng thư):
Đây là phần mềm mà người dùng cuối tương tác trực tiếp. Nó là chương trình để
soạn, gửi, đọc và quản lý email.
Ví dụ: Microsoft Outlook, Mozilla Thunderbird, ứng dụng Mail trên điện thoại.
Nhiệm vụ:
Giúp người dùng gửi thư đến máy chủ mail của họ.
Giúp người dùng lấy thư từ máy chủ mail của họ về để đọc.
2. MTA (Mail Transfer Agent - Tác nhân chuyển thư):
Đây là các máy chủ mail (mail server). Chúng hoạt động ở phía sau, người dùng
không tương tác trực tiếp với chúng.
Ví dụ: Sendmail, Postfix, Microsoft Exchange Server.
Nhiệm vụ:
Nhận thư từ MUA của người gửi.
Chuyển tiếp (relay) thư qua Internet đến máy chủ mail của người nhận.
Lưu trữ thư đến trong hộp thư (mailbox) của người dùng.
Duy trì một hàng đợi (message queue) để lưu các thư chưa gửi đi được (ví
dụ, do máy chủ của người nhận đang offline) và sẽ thử gửi lại sau.
Các giao thức liên quan:
Để Gửi thư:
SMTP (Simple Mail Transfer Protocol): Là giao thức chuẩn để "đẩy" (push) thư đi.
Nó được sử dụng trong hai giai đoạn:
1. Từ MUA của người gửi đến máy chủ mail của người gửi.
2. Từ máy chủ mail của người gửi đến máy chủ mail của người nhận.
Để Nhận thư (Lấy thư về): Người dùng cần một giao thức để "kéo" (pull) thư từ hộp thư
trên máy chủ mail về MUA của mình. Có hai giao thức phổ biến:
POP (Post Office Protocol), cụ thể là POP3:
Hoạt động theo cơ chế "tải về và xóa". Khi MUA kết nối, nó sẽ tải toàn bộ thư
mới về máy tính của người dùng và (thường) xóa chúng khỏi máy chủ.
Đơn giản, phù hợp nếu bạn chỉ dùng một thiết bị để kiểm tra mail.
IMAP (Internet Mail Access Protocol):
Phức tạp và mạnh mẽ hơn. Nó cho phép người dùng xem và quản lý thư trực
tiếp trên máy chủ.
Thư vẫn được lưu trên máy chủ. Bạn có thể tạo thư mục, xóa thư, đánh dấu thư
đã đọc... và các thay đổi này sẽ được đồng bộ hóa trên tất cả các thiết bị (điện thoại,
laptop, PC) mà bạn dùng để truy cập email. Đây là giao thức phổ biến hiện nay.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
Slide 42: Giao thức SMTP
Nội dung: Đi sâu hơn vào các đặc điểm của giao thức SMTP.
Giải thích chi tiết:
Tài liệu mô tả: Được định nghĩa trong RFC 2821 (và các bản cập nhật sau này).
Giao thức nền: SMTP sử dụng TCP làm giao thức tầng giao vận để đảm bảo việc truyền thư được
tin cậy. Không thể chấp nhận việc email bị mất hoặc lỗi trên đường truyền.
Cổng dịch vụ: Hoạt động trên cổng 25.
Chức năng: Như đã nói, SMTP là giao thức để chuyển thư từ client đến server và giữa các
server với nhau. Nó là một giao thức "push". Bạn không thể dùng SMTP để đọc mail.
Tương tác yêu cầu/trả lời:
Giao tiếp giữa client và server SMTP diễn ra dưới dạng các dòng lệnh và mã trạng thái,
tương tự như HTTP nhưng đơn giản hơn.
Yêu cầu (Commands): Là các lệnh văn bản (ASCII) như HELO, MAIL FROM, RCPT TO, DATA.
Trả lời (Replies): Là các mã trạng thái (ví dụ: 250 OK) và một dòng mô tả ngắn.
Slide 43: Các giao thức nhận thư
Nội dung: So sánh hai giao thức nhận thư là POP và IMAP.
Sơ đồ minh họa rõ ràng vai trò của các giao thức:
Người gửi (sender's user agent) dùng SMTP để đẩy mail đến server của mình.
Server người gửi dùng SMTP để đẩy mail đến server người nhận.
Người nhận (receiver's user agent) dùng một giao thức truy cập (access protocol) như
POP hoặc IMAP để lấy mail về từ server của mình.
Slide 44: Web Mail
Nội dung: Giới thiệu một hình thức truy cập email rất phổ biến ngày nay: qua trình duyệt web.
Giải thích chi tiết:
Với Web Mail (như Gmail, Hotmail/Outlook.com, Yahoo! Mail), trình duyệt web của bạn đóng
vai trò như một MUA (Mail User Agent).
Thay vì dùng một phần mềm riêng như Outlook, bạn dùng Chrome hay Firefox để đọc/gửi mail.
POP (Post Office Protocol) [RFC 1939]:
Thường được gọi là POP3.
Quy trình cơ bản:
Đăng nhập, lấy hết thư về, đăng xuất.
Thường là "download-and-delete", không giữ lại trạng thái trên server.
Nhược điểm:
Khó quản lý email từ nhiều thiết bị khác nhau.
IMAP (Internet Mail Access Protocol) [RFC 1730]:
Phức tạp hơn POP.
Cho phép lưu trữ và xử lý thư ngay trên máy chủ.
Người dùng có thể xem tiêu đề thư,
xóa, tạo thư mục... mà không cần tải toàn bộ nội dung về.
Trạng thái (thư đã đọc/chưa đọc) được duy trì trên server và đồng bộ hóa qua tất cả các
thiết bị.
Rất phù hợp cho người dùng di động và sử dụng nhiều thiết bị.
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Giải thích chi tiết:
Phần đầu (Header):
Giao tiếp MUA và MTA: Việc giao tiếp giữa trình duyệt của bạn (MUA) và máy chủ mail (MTA, ví
dụ server của Google) được thực hiện thông qua giao thức HTTP/HTTPS.
Lưu trữ: Tất cả các email được lưu trữ và quản lý hoàn toàn trên máy chủ của nhà cung cấp dịch
vụ.
Lợi ích: Cực kỳ tiện lợi. Bạn có thể truy cập email của mình từ bất kỳ máy tính nào có kết nối
Internet và trình duyệt web mà không cần cài đặt gì.
Ngày nay: Nhiều MTA (máy chủ mail) của các tổ chức (như mail.hust.edu.vn) cũng cung cấp
một giao diện web để người dùng có thể truy cập mail một cách tiện lợi bên cạnh việc hỗ trợ
POP/IMAP.
Slide 45: Khuôn dạng thông điệp thư điện tử
Nội dung: Mô tả cấu trúc cơ bản của một email theo chuẩn RFC 822.
Một email được chia thành hai phần chính, ngăn cách bởi một dòng trắng:
Chứa các thông tin "siêu dữ liệu" (metadata) về email.
Bao gồm các trường như:
To:: Địa chỉ email của người nhận.
From:: Địa chỉ email của người gửi.
Subject:: Tiêu đề của email.
Và nhiều trường khác như Date:, CC:, BCC:.
Phần thân (Body):
Chứa nội dung thực sự của bức thư.
Theo chuẩn RFC 822 gốc, phần thân chỉ được chứa văn bản dạng mã ASCII. Điều này là
một hạn chế lớn vì nó không cho phép gửi kèm hình ảnh, file tài liệu, hoặc văn bản có định
dạng (chữ đậm, chữ nghiêng).
Slide 46: Tiêu chuẩn MIME
Nội dung: Giới thiệu MIME, một phần mở rộng để khắc phục hạn chế của định dạng email gốc.
Giải thích chi tiết:
Vấn đề: Làm thế nào để gửi các nội dung không phải là văn bản ASCII (ví dụ: ảnh, video, file Word,
PDF) qua email?
Giải pháp: MIME (Multipurpose Internet Mail Extensions) [RFC 2045, 2046].
MIME không thay đổi cấu trúc email gốc. Thay vào đó, nó thêm một số dòng header để mô tả
nội dung phức tạp trong phần thân.
Các header chính của MIME:
MIME-Version: 1.0: Cho biết email này tuân thủ chuẩn MIME.
Content-Type:: Mô tả loại dữ liệu trong phần thân.
Cú pháp: type/subtype (ví dụ: image/jpeg, application/pdf).
Điều này cho MUA của người nhận biết phải xử lý nội dung này như thế nào (hiển thị
như một ảnh, mở bằng Adobe Reader...).
lOMoARcPSD| 61601435
slide3.md 2025-06-28
Content-Transfer-Encoding:: Mô tả cách dữ liệu nhị phân (như file ảnh) được mã hóa
thành dạng văn bản ASCII để có thể gửi đi an toàn qua hệ thống email.
base64 là một phương pháp mã hóa phổ biến. Nó biến đổi dữ liệu nhị phân thành
một chuỗi các ký tự ASCII an toàn.
Nhờ có MIME, email ngày nay có thể chứa gần như mọi loại dữ liệu, làm cho nó trở thành một công cụ
giao tiếp cực kỳ mạnh mẽ.
Phần 6 (Dịch vụ Email) đã kết thúc. Chúng ta đã tìm hiểu về các thành phần, các giao thức gửi/nhận, và cách
email xử lý các loại dữ liệu đa dạng. Bạn đã hiểu rõ và hài lòng với phần giải thích này chưa? Chúng ta có thể
tiếp tục với phần cuối cùng về "FTP" không?
Tuyệt vời! Chúng ta sẽ đi đến phần cuối cùng của bài giảng, tìm hiểu về một trong những giao thức lâu đời và
vẫn còn hữu ích của Internet: FTP (File Transfer Protocol).
Phần 7: FTP - Giao thức truyền tập tin (Slides 47-48)
Phần này sẽ giải thích cách FTP hoạt động để trao đổi file giữa các máy tính.
Slide 47: Slide trống
Đây là một slide trống, đóng vai trò làm tiêu đề cho phần FTP. Nội dung chính nằm ở slide tiếp theo.
Slide 48: FTP: File Transfer Protocol
Nội dung: Slide này cung cấp một cái nhìn tổng quan về kiến trúc và cơ chế hoạt động của FTP.
Giải thích chi tiết:
Mô hình Client-Server: FTP hoạt động theo mô hình client-server.
FTP client: Là chương trình mà người dùng sử dụng để kết nối đến một FTP server. Nó cung
cấp một giao diện (user interface) để người dùng thực hiện các lệnh như tải file lên (upload),
tải file xuống (download), liệt kê thư mục, v.v.
FTP server: Là phần mềm chạy trên một máy tính từ xa, quản lý các file và thư mục, và chờ
đợi kết nối từ các client.
Sử dụng TCP: FTP sử dụng TCP để đảm bảo việc truyền file được tin cậy, không bị lỗi hay mất mát
dữ liệu.
Cơ chế "Out-of-band control" (Điều khiển ngoài băng): Đây là đặc điểm độc đáo và quan trọng
nhất của FTP. Không giống như HTTP chỉ dùng một kết nối, FTP sử dụng hai kết nối TCP song song:
1. Kết nối điều khiển (Control Connection):
Được thiết lập trên cổng 21 của server.
Kết nối này được duy trì trong suốt toàn bộ phiên làm việc của người dùng. Nhiệm
vụ: Dùng để gửi các lệnh từ client (ví dụ: USER, PASS để đăng nhập; LIST để xem
danh sách file; RETR để tải file về; STOR để tải file lên) và nhận các phản hồi từ server.
Dữ liệu trên kênh này là các thông tin điều khiển, không phải là nội dung của file.
2. Kết nối dữ liệu (Data Connection):

Tài liệu khác của Đại học Bách Khoa Hà Nội

Preview text:

lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Chào bạn, tôi rất sẵn lòng trình bày và giải thích chi tiết bài giảng này cho bạn. Chúng ta sẽ đi qua từng phần
một. Sau mỗi phần, tôi sẽ dừng lại và hỏi để đảm bảo bạn đã nắm rõ nội dung trước khi chúng ta tiếp tục.
Bây giờ, chúng ta hãy bắt đầu với phần đầu tiên: Giới thiệu tổng quan và Kiến trúc phân tầng.
Phần 1: Giới thiệu tổng quan và Kiến trúc phân tầng (Slides 1-3)
Slide 1: Trang bìa - Internet Services
Nội dung: Đây là slide mở đầu, giới thiệu chủ đề của bài giảng là "Internet Services" (Các Dịch vụ Internet).
Giải thích chi tiết:
Slide này cho chúng ta biết bài giảng được biên soạn bởi giảng viên Phạm Huy Hoàng, thuộc
Viện Công nghệ Thông tin và Truyền thông (SoICT) của Đại học Bách Khoa Hà Nội (HUST).
Logo "25 năm SoICT" cho thấy bối cảnh bài giảng nằm trong chuỗi sự kiện hoặc tài liệu kỷ niệm của viện.
Chủ đề "Internet Services" ám chỉ rằng chúng ta sẽ học về các dịch vụ nền tảng và phổ biến nhất
mà mạng Internet cung cấp, chẳng hạn như duyệt web, gửi email, phân giải tên miền, v.v. Đây là
những dịch vụ mà người dùng cuối tương tác hàng ngày. Slide 2: Nội dung
Nội dung: Slide này trình bày bố cục, hay mục lục, của toàn bộ bài giảng.
Giải thích chi tiết:
Kết nối tầng giao vận (Transport Layer): Giới thiệu về tầng chịu trách nhiệm truyền dữ liệu giữa
các ứng dụng trên các máy tính khác nhau.
Kết nối tầng ứng dụng (Application Layer): Tập trung vào tầng cao nhất, nơi các ứng dụng
mạng như trình duyệt web, email client hoạt động.
Dịch vụ IP cơ bản: DNS, Mail, Web: Đây là phần trọng tâm của bài giảng, đi sâu vào ba dịch vụ cốt lõi:
DNS (Domain Name System): Hệ thống phân giải tên miền, dịch từ tên web (ví dụ:
google.com) sang địa chỉ IP.
Mail: Dịch vụ thư điện tử (email).
Web: Dịch vụ duyệt web qua giao thức HTTP/HTTPS.
Kết nối dịch vụ mạng riêng và mạng public Internet: Đề cập đến cách các mạng nội bộ
(như mạng công ty, gia đình) kết nối và tương tác với mạng Internet toàn cầu.
Slide 3: Vị trí trong kiến trúc phân tầng
Nội dung: Slide này trực quan hóa vị trí và vai trò của các tầng trong mô hình mạng máy tính (cụ thể là mô hình TCP/IP).
Giải thích chi tiết:
Mô hình này chia nhỏ quá trình giao tiếp mạng thành các "tầng" (layers), mỗi tầng có một chức
năng chuyên biệt. Dữ liệu đi từ trên xuống ở máy gửi và từ dưới lên ở máy nhận. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Application (Tầng Ứng dụng): Tầng cao nhất, gần với người dùng nhất. Nó hỗ trợ các ứng
dụng trên mạng như trình duyệt web (HTTP), email (SMTP), v.v. Các dịch vụ chúng ta sẽ học (Web,
Mail, DNS) đều nằm ở tầng này.
Transport (Tầng Giao vận): Nhiệm vụ của nó là truyền dữ liệu giữa các ứng dụng (processes)
đang chạy trên các máy tính khác nhau. Nó cung cấp hai giao thức chính là TCP (tin cậy) và UDP (không tin cậy).
Network (Tầng Mạng): Chịu trách nhiệm chọn đường và chuyển tiếp các gói tin (packets)
giữa các mạng khác nhau. Giao thức chính ở đây là IP (Internet Protocol).
Datalink (Tầng Liên kết dữ liệu): Hỗ trợ việc truyền thông cho các thiết bị trên cùng một mạng
vật lý (ví dụ: trong cùng một mạng LAN).
Physical (Tầng Vật lý): Tầng cuối cùng, chịu trách nhiệm truyền và nhận dòng bit (0 và 1) trên
đường truyền vật lý (cáp đồng, cáp quang, sóng vô tuyến).
Slide này rất quan trọng vì nó đặt nền móng kiến thức, giúp chúng ta hiểu các dịch vụ như Web, DNS không
hoạt động một mình mà dựa trên sự hỗ trợ của các tầng bên dưới.
Phần 1 (Giới thiệu tổng quan và Kiến trúc phân tầng) đã kết thúc. Bạn đã hiểu rõ và hài lòng với phần giải thích
này chưa? Chúng ta có thể tiếp tục với phần tiếp theo không?
Phần 2: Kết nối Tầng Giao vận (Slides 4-6)
Khi bạn đã sẵn sàng, chúng ta sẽ tiếp tục với phần giải thích về vai trò và đặc điểm của Tầng Giao vận (Transport Layer).
Slide 4: Kết nối tầng giao vận (1)
Nội dung: Slide này đi sâu vào chức năng chính và cách hoạt động của tầng giao vận.
Giải thích chi tiết:
Chức năng cốt lõi: Tầng giao vận cung cấp một phương tiện truyền thông logic giữa các ứng
dụng cuối (end applications). "Logic" có nghĩa là các ứng dụng trên hai máy tính khác nhau có
thể gửi dữ liệu cho nhau như thể có một đường ống kết nối trực tiếp, mặc dù trên thực tế dữ liệu
phải đi qua nhiều thiết bị mạng trung gian (routers) như trong hình.
Ứng dụng là các tiến trình: Điều quan trọng cần nhớ là tầng giao vận không kết nối máy tính với
máy tính, mà là tiến trình (process) với tiến trình. Ví dụ, trên máy tính của bạn có thể đang chạy
cả trình duyệt Chrome và ứng dụng Skype. Tầng giao vận đảm bảo dữ liệu từ máy chủ web sẽ đến
đúng trình duyệt Chrome, và dữ liệu cuộc gọi sẽ đến đúng ứng dụng Skype.
Hoạt động ở Bên gửi (Sender):
1. Nhận dữ liệu từ một ứng dụng (ví dụ: trình duyệt web gửi yêu cầu HTTP).
2. "Đóng gói" dữ liệu này vào các đơn vị gọi là đoạn tin (segments).
3. Nếu dữ liệu từ ứng dụng quá lớn, nó sẽ được chia nhỏ (segmentation) thành nhiều đoạn tin.
4. Chuyển các đoạn tin này xuống cho tầng mạng (Network Layer) để gửi đi.
Hoạt động ở Bên nhận (Receiver):
1. Nhận các đoạn tin từ tầng mạng.
2. Tập hợp (reassembly) lại dữ liệu từ các đoạn tin này.
3. Chuyển dữ liệu đã hoàn chỉnh lên cho ứng dụng tương ứng. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Slide 5: Kết nối tầng giao vận (2)
Nội dung: Slide này làm rõ hơn về phạm vi hoạt động và các loại dịch vụ của tầng giao vận.
Giải thích chi tiết:
Cài đặt trên các hệ thống cuối (End Systems): Như hình minh họa, tầng giao vận (màu cam) chỉ
tồn tại trên các thiết bị đầu cuối như máy tính của người dùng và máy chủ. Các thiết bị trung gian
như routers và switches không có tầng này. Chúng chỉ cần xử lý đến tầng mạng (Network Layer) để
quyết định đường đi cho gói tin. Đây là lý do nó được gọi là "end-to-end transport". Hai
dạng dịch vụ giao vận: Tầng giao vận cung cấp hai loại dịch vụ chính, tương ứng với hai giao thức phổ biến:
1. TCP (Transmission Control Protocol): Dịch vụ tin cậy, hướng liên kết (connectionoriented).
Tin cậy: Đảm bảo mọi dữ liệu gửi đi sẽ đến nơi một cách nguyên vẹn và đúng thứ
tự. Nếu có mất mát, nó sẽ tự động gửi lại.
Hướng liên kết: Trước khi truyền dữ liệu, hai bên phải thiết lập một kết nối (giống
như một cuộc gọi điện thoại, bạn phải "bắt tay" trước khi nói chuyện).
Ví dụ sử dụng: duyệt web (HTTP), tải file (FTP), gửi email (SMTP).
2. UDP (User Datagram Protocol): Dịch vụ không tin cậy, không liên kết (connectionless).
Không tin cậy: Gửi dữ liệu đi mà không đảm bảo nó có đến nơi hay không, và cũng
không đảm bảo thứ tự. Nó hoạt động theo kiểu "gửi và quên". Không liên kết: Không
cần thiết lập kết nối trước, cứ có dữ liệu là gửi.
Ví dụ sử dụng: Streaming video/audio, game online, DNS (thường là vậy). Các ứng
dụng này ưu tiên tốc độ và chấp nhận mất mát một vài gói tin nhỏ.
Slide 6: Ứng dụng IP cơ bản và dịch vụ giao vận
Nội dung: Slide này là một bảng tổng kết, liên kết các ứng dụng phổ biến ở tầng ứng dụng với giao
thức ở tầng giao vận mà chúng sử dụng.
Giải thích chi tiết:
Domain Name (DNS): Dùng UDP. Lý do: Các truy vấn và phản hồi DNS thường rất nhỏ, chỉ gồm
một gói tin. Dùng UDP nhanh hơn vì không cần chi phí thiết lập và duy trì kết nối như TCP. E-mail
(SMTP): Dùng TCP. Lý do: Việc gửi email đòi hỏi độ tin cậy tuyệt đối. Chúng ta không thể chấp
nhận việc email bị mất hoặc sai thứ tự nội dung.
Remote terminal access (Telnet): Dùng TCP. Lý do: Khi bạn điều khiển một máy tính từ xa, mỗi
ký tự bạn gõ đều phải được gửi đi một cách tin cậy.
Web (HTTP): Dùng TCP. Lý do: Để một trang web hiển thị chính xác, toàn bộ mã HTML, CSS, ảnh...
phải được tải về đầy đủ và đúng đắn.
File transfer (FTP): Dùng TCP. Lý do: Tương tự như Web, việc truyền file cần đảm bảo file ở đích
giống hệt file ở nguồn.
Streaming multimedia: Dùng TCP hoặc UDP. Lý do:
Một số dịch vụ streaming (như YouTube) ngày nay dùng TCP để đảm bảo chất lượng và
tránh giật lag do phải chờ gói tin gửi lại.
Các dịch vụ yêu cầu thời gian thực cao (live streaming, video call) thường dùng UDP (hoặc
các giao thức xây dựng trên nó như RTP) vì việc chờ đợi một gói tin bị mất sẽ gây ra độ trễ
lớn, thà bỏ qua gói tin đó còn hơn. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Internet telephony (VoIP): Thường dùng UDP. Lý do: Tương tự streaming thời gian thực, trong
một cuộc gọi thoại, tốc độ là tối quan trọng. Trễ một vài mili giây có thể chấp nhận được, nhưng
dừng cả cuộc hội thoại để chờ một gói tin bị mất thì không.
Phần 2 (Kết nối Tầng Giao vận) đã kết thúc. Phần này đã giải thích vai trò, đặc điểm và các giao thức chính của
tầng giao vận. Bạn đã hiểu rõ và hài lòng chưa? Chúng ta có thể tiếp tục với phần "DNS" không?
Phần 3: Hệ thống phân giải tên miền (DNS) (Slides 7-20)
Khi bạn sẵn sàng, chúng ta sẽ đi sâu vào một trong những dịch vụ nền tảng quan trọng nhất của Internet: DNS.
Slide 7 & 8: Giới thiệu chung
(Slide 7 chỉ là slide trống, nội dung chính nằm ở slide 8)
Nội dung: Slide này giới thiệu các khái niệm cơ bản về tên miền và DNS.
Giải thích chi tiết:
Tên miền (Domain Name):
Đây là một định danh (tên) trên tầng ứng dụng, giúp con người dễ dàng ghi nhớ và truy
cập các máy chủ (nút mạng) trên Internet. Thay vì phải nhớ một dãy số khó nhớ như
142.250.204.78, chúng ta chỉ cần nhớ google.com.
Việc quản lý tên miền được tổ chức tập trung theo một hệ thống phân cấp.
Quốc tế: ICANN (Internet Corporation for Assigned Names and Numbers) là tổ chức quản lý cao nhất.
Việt Nam: VNNIC (Vietnam Internet Network Information Center) là cơ quan quản
lý tên miền cấp quốc gia .vn.
DNS (Domain Name System):
Là một hệ thống phân tán toàn cầu, bao gồm các máy chủ DNS có nhiệm vụ quản lý thông
tin tên miền và cung cấp dịch vụ phân giải tên miền, tức là dịch từ tên miền sang địa chỉ IP.
Vấn đề cần giải quyết:
Người dùng sử dụng tên miền để truy cập dịch vụ.
Máy tính và thiết bị mạng lại giao tiếp với nhau bằng địa chỉ IP.
Câu hỏi cốt lõi là: Làm thế nào để chuyển đổi (ánh xạ) từ một tên miền sang địa chỉ IP
tương ứng? DNS chính là câu trả lời.
Slide 9: Chuyển đổi địa chỉ và ví dụ
Nội dung: Slide này minh họa một cách trực quan quá trình phân giải tên miền cơ bản.
Giải thích chi tiết:
1. Người dùng (NSD - Người sử dụng): Gõ tên miền www.soict.hust.edu.vn vào trình duyệt và nhấn Enter.
2. Máy tính của người dùng: Nhận ra rằng nó cần địa chỉ IP của web server này để kết nối. Nó
không biết địa chỉ IP là gì. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
3. Hành động: Máy tính gửi một truy vấn đến "Máy chủ tên miền" (DNS Server). Truy vấn có nội
dung: "Xin cho biết địa chỉ IP của www.soict.hust.edu.vn là gì?"
4. Máy chủ tên miền: Tra cứu trong cơ sở dữ liệu của nó và tìm thấy bản ghi tương ứng.
5. Phản hồi: Máy chủ tên miền trả lời lại cho máy tính của người dùng: "Địa chỉ IP của
www.soict.hust.edu.vn là 202.191.56.65".
6. Kết nối: Bây giờ máy tính của người dùng đã có địa chỉ IP, nó có thể gửi yêu cầu trực tiếp đến
"Máy chủ web" tại địa chỉ 202.191.56.65 để tải trang web về.
Slide 10: Không gian tên miền (Domain Name Space)
Nội dung: Mô tả kiến trúc của hệ thống tên miền.
Giải thích chi tiết:
Kiến trúc hình cây (Tree Structure): Không gian tên miền được tổ chức theo một cấu trúc phân cấp hình cây.
Root (Nút gốc): Là đỉnh của cây, được biểu diễn bằng một dấu chấm (.). Ví dụ,
google.com. thực chất là tên miền đầy đủ.
Bên dưới gốc là các tên miền cấp cao nhất (Top-Level Domains - TLDs) như .com, .org,
.net, và các tên miền quốc gia như .vn, .jp.
Bên dưới TLDs là các tên miền cấp hai (ví dụ hust.edu.vn), và cứ thế tiếp tục.
Zone (Vùng): Một "zone" là một phần của cây tên miền được một máy chủ DNS cụ thể
quản lý. Ví dụ, VNNIC quản lý zone .vn, còn HUST quản lý zone hust.edu.vn. Việc này cho phép quản lý phân tán.
Bản ghi (Resource Records - RRs): Mỗi nút trên cây (tương ứng với một tên miền) được mô tả
bởi một tập hợp các bản ghi. Các loại bản ghi quan trọng bao gồm:
A (Address): Ánh xạ một tên miền sang một địa chỉ IPv4. Đây là bản ghi phổ biến nhất. (Ví
dụ: soict.hust.edu.vn -> 202.191.56.65).
NS (Name Server): Cho biết máy chủ DNS nào chịu trách nhiệm (authoritative) cho một zone.
SOA (Start of Authority): Chứa thông tin quản trị về một zone, như máy chủ DNS chính,
email của người quản trị, v.v.
Slide 11 & 12: Hệ thống máy chủ DNS
Nội dung: Các slide này mô tả hệ thống phân cấp của các máy chủ DNS trên toàn thế giới.
Giải thích chi tiết: Hệ thống DNS được chia thành nhiều cấp bậc:
1. Máy chủ tên miền gốc (Root DNS Server):
Có 13 hệ thống máy chủ gốc trên toàn thế giới (được đặt tên từ A đến M). Tuy nhiên,
mỗi hệ thống này thực chất là một cụm gồm rất nhiều máy chủ vật lý được đặt ở nhiều vị trí
địa lý khác nhau (sử dụng công nghệ Anycast) để đảm bảo tính sẵn sàng và giảm độ trễ.
Nhiệm vụ: Chúng không biết địa chỉ IP của google.com, nhưng chúng biết máy chủ
nào quản lý tên miền .com. Chúng sẽ chỉ cho người hỏi đến đúng nơi để hỏi tiếp.
2. Máy chủ tên miền cấp 1 (Top Level Domain - TLD Server):
Quản lý các tên miền cấp cao nhất như .com, .org, .vn. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Nhiệm vụ: Ví dụ, máy chủ TLD của .com không biết địa chỉ IP của google.com, nhưng nó biết
máy chủ DNS nào của Google chịu trách nhiệm cho google.com. Nó sẽ chỉ đường đến đó.
3. Máy chủ được ủy quyền (Authoritative DNS Server):
Đây là máy chủ cuối cùng trong chuỗi truy vấn, chứa thông tin chính xác và cuối cùng về
một tên miền. Ví dụ, máy chủ DNS của HUST là authoritative cho tên miền hust.edu.vn.
Nhiệm vụ: Khi được hỏi, nó sẽ trả về câu trả lời chính xác (ví dụ: địa chỉ IP trong bản ghi A).
4. Máy chủ cục bộ (Local DNS Server):
Đây là máy chủ không thuộc hệ thống phân cấp chính thức trên. Thường là máy chủ DNS
của nhà cung cấp dịch vụ Internet (ISP) của bạn (VNPT, FPT, Viettel) hoặc các dịch vụ công
cộng như 8.8.8.8 (Google DNS), 1.1.1.1 (Cloudflare).
Nhiệm vụ: Khi máy tính của bạn cần phân giải một tên miền, nó sẽ hỏi máy chủ này đầu
tiên. Máy chủ cục bộ sẽ thay mặt bạn thực hiện toàn bộ quá trình truy vấn đến các máy chủ
Root, TLD, và Authoritative để tìm ra câu trả lời, sau đó trả về cho bạn và lưu vào bộ nhớ
đệm (cache) để tăng tốc cho các lần hỏi sau.
Slide 13: Phân giải tên miền
Nội dung: Liệt kê các phương pháp và cơ chế để phân giải tên miền.
Giải thích chi tiết:
Tự phân giải (trên máy local):
File HOSTS: Một file văn bản đơn giản trên máy tính để ánh xạ thủ công IP với tên miền.
Windows: C:\WINDOWS\system32\drivers\etc\hosts Linux: /etc/hosts
Hệ điều hành sẽ kiểm tra file này trước khi gửi truy vấn DNS ra ngoài.
Bộ đệm của ứng dụng/hệ điều hành (Cache): Cả trình duyệt và hệ điều hành đều lưu lại
kết quả của các lần phân giải gần đây để không phải hỏi lại, giúp tăng tốc độ.
Dịch vụ phân giải tên miền (Client/Server):
Đây là phương pháp chính, sử dụng giao thức DNS.
Giao thức: DNS là một giao thức tầng ứng dụng.
Cổng dịch vụ: Hoạt động trên cổng 53. Thường dùng UDP cho các truy vấn nhanh, nhưng
có thể dùng TCP cho các tác vụ cần độ tin cậy cao hơn như truyền dữ liệu zone (zone
transfer) giữa các máy chủ.
Các loại truy vấn:
Phân giải đệ quy (Recursive Query): Máy tính của bạn "ủy thác" hoàn toàn cho máy
chủ DNS cục bộ. Nó chỉ hỏi: "Tìm cho tôi IP của X", và chờ câu trả lời cuối cùng.
Phân giải tương tác (Iterative Query): Máy chủ DNS cục bộ sẽ hỏi "từng bước".
Nó hỏi Root, Root chỉ đến TLD. Nó hỏi TLD, TLD chỉ đến Authoritative. Nó hỏi
Authoritative và nhận được câu trả lời. Đây là cách các máy chủ DNS "nói chuyện" với nhau.
Slide 14 & 15: Thông điệp DNS
Nội dung: Mô tả cấu trúc của một gói tin DNS.
Giải thích chi tiết: lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Cả truy vấn (Query) và phản hồi (Reply) đều có chung một khuôn dạng (format). Khuôn dạng này
được chia thành các phần:
Header (Phần đầu):
Identification: Một số ngẫu nhiên để khớp một phản hồi với truy vấn của nó.
Flags: Các cờ điều khiển cho biết đây là truy vấn hay phản hồi, có phải là phản hồi từ máy
chủ authoritative không, có hỗ trợ đệ quy không, v.v.
Question (Phần câu hỏi):
#Question: Số lượng câu hỏi (thường là 1).
QUESTION: Nội dung câu hỏi, bao gồm tên miền cần truy vấn và loại bản ghi (ví dụ: A, NS, MX).
Answer (Phần trả lời):
#Answer RRs: Số lượng bản ghi trong phần trả lời.
ANSWER: Chứa các bản ghi (Resource Records - RRs) trả lời trực tiếp cho câu hỏi. Ví dụ: bản ghi A chứa địa chỉ IP.
Authority (Phần ủy quyền):
#Authority RRs: Số lượng bản ghi.
AUTHORITY: Chứa các bản ghi NS trỏ đến các máy chủ DNS authoritative cho tên miền đó.
Phần này hữu ích khi câu trả lời không có trong phần Answer.
Additional (Phần bổ sung):
#Additional RRs: Số lượng bản ghi.
ADDITIONAL: Chứa các thông tin bổ sung hữu ích. Ví dụ, nếu phần Authority trả về tên của
một máy chủ NS, phần Additional thường sẽ chứa luôn địa chỉ IP (bản ghi A) của máy chủ
NS đó, giúp client không phải thực hiện thêm một truy vấn DNS nữa.
Slide 16, 17, 18: Ví dụ: dig linux.com
Nội dung: Phân tích kết quả trả về từ lệnh dig, một công cụ dòng lệnh mạnh mẽ để truy vấn DNS.
Giải thích chi tiết:
QUESTION SECTION: Câu hỏi là tìm bản ghi A (địa chỉ IP) cho linux.com. ANSWER SECTION:
Phần này trả lời trực tiếp câu hỏi. Ta thấy linux.com có 2 địa chỉ IP là 140.211.167.51 và 140.211.167.50.
1786 là TTL (Time-to-Live), tính bằng giây. Nó cho biết máy chủ DNS cục bộ có thể lưu kết
quả này trong cache trong 1786 giây. Trong khoảng thời gian này, nếu có ai hỏi lại, nó sẽ
trả lời từ cache mà không cần truy vấn lại từ đầu. AUTHORITY SECTION:
Phần này cho biết các máy chủ DNS được ủy quyền (authoritative) cho tên miền linux.com
là ns1.linux-foundation.org. và ns2.linux-foundation.org..
Như slide 17 giải thích, nếu phần ANSWER rỗng (tức là máy chủ hiện tại không biết câu trả
lời), thì client sẽ phải gửi truy vấn tới các máy chủ được liệt kê trong phần AUTHORITY này. ADDITIONAL SECTION:
Phần này cung cấp thông tin "giúp sức". Nó cung cấp luôn địa chỉ IP (bản ghi A) của
ns1.linux-foundation.org. và ns2.linux-foundation.org..
Như slide 18 giải thích, đây là địa chỉ IP của các máy chủ trả lời truy vấn. Việc cung cấp sẵn
thông tin này giúp client không phải tốn thêm một vòng lặp DNS để tìm IP của ns1.linux-
foundation.org. trước khi có thể hỏi nó. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Slide 19: Phân giải tương tác (Iterative Query)
Nội dung: Minh họa cơ chế phân giải mà các máy chủ DNS sử dụng để nói chuyện với nhau.
Giải thích chi tiết:
Đây là cơ chế mặc định giữa các máy chủ DNS. "Tương tác" có nghĩa là hỏi từng bước một.
Giả sử máy chủ Default server (máy chủ cục bộ của ISP) cần tìm soict.hust.edu.vn.
1. Nó không biết, nên nó hỏi Root server.
2. Root server trả lời: "Tôi không biết, nhưng tôi biết máy chủ quản lý .vn. Cậu hãy đi hỏi dns.vn (TLD server)".
3. Default server hỏi máy chủ dns.vn.
4. dns.vn trả lời: "Tôi không biết, nhưng tôi biết máy chủ quản lý hust.edu.vn. Cậu hãy đi hỏi
dns.hust.edu.vn (Authoritative server)".
5. Default server hỏi máy chủ dns.hust.edu.vn.
6. dns.hust.edu.vn là máy chủ authoritative, nó biết câu trả lời và trả về địa chỉ IP 202.191.56.65.
7. Default server nhận được IP cuối cùng và trả về cho client.
Slide 20: Phân giải đệ quy (Recursive Query)
Nội dung: Minh họa cơ chế truy vấn mà máy tính người dùng thường sử dụng.
Giải thích chi tiết:
"Đệ quy" có nghĩa là "ủy thác". Client chỉ hỏi một lần và chờ câu trả lời cuối cùng.
1. Máy tính người dùng (202.191.56.65) hỏi Default server: "Hãy tìm cho tôi địa chỉ IP của
soict.hust.edu.vn." Đây là một yêu cầu đệ quy.
2. Default server chấp nhận yêu cầu này và có trách nhiệm tìm ra câu trả lời cuối cùng. Nó bắt đầu
quá trình phân giải tương tác như đã mô tả ở slide 19 (hỏi Root -> hỏi TLD -> hỏi Authoritative).
3. Sau khi nhận được câu trả lời cuối cùng từ Authoritative DNS server, Default server sẽ trả kết
quả này về cho máy tính người dùng.
Sự kết hợp giữa truy vấn đệ quy (client -> local server) và truy vấn tương tác (local server -> các server
khác) tạo nên hiệu quả cho toàn bộ hệ thống DNS.
Phần 3 (Hệ thống phân giải tên miền - DNS) đã kết thúc. Đây là một phần khá dài và chi tiết về một dịch vụ
nền tảng rất quan trọng. Bạn đã hiểu rõ và hài lòng với phần giải thích này chưa? Chúng ta có thể tiếp tục với phần "HTTP và Web" không?
Tuyệt vời! Chúng ta sẽ tiếp tục với phần tiếp theo, một dịch vụ mà chúng ta sử dụng hàng ngày: HTTP và Web.
Phần 4: HTTP và Web (Slides 21-36)
Phần này sẽ giải thích cách World Wide Web ra đời, giao thức HTTP hoạt động như thế nào, và các khái niệm
liên quan như URL, cookie, và các chế độ của HTTP. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Slide 21 & 22: HTTP và Web
(Slide 21 chỉ là slide trống, nội dung chính nằm ở slide 22)
Nội dung: Slide này cung cấp bối cảnh lịch sử về sự ra đời của World Wide Web (WWW).
Giải thích chi tiết:
Internet trước thập kỷ 1990s:
Internet lúc này chủ yếu được sử dụng trong môi trường học thuật, chính phủ và nghiên
cứu. Nó không thân thiện với người dùng phổ thông.
Các dịch vụ chính là email và truyền file (FTP). Tuy nhiên, các dịch vụ này không có cách nào
hiệu quả để liên kết các tài liệu với nhau một cách dễ dàng. Nếu bạn đọc một tài liệu và
muốn tham khảo một tài liệu khác, bạn phải tự tìm và mở nó.
Năm 1990, Tim Berners-Lee giới thiệu World Wide Web: Đây là một cuộc cách mạng. WWW
đề xuất một hệ thống mới dựa trên các khái niệm:
1. Siêu văn bản (Hypertext): Các tài liệu không còn là những văn bản tĩnh. Chúng có thể
chứa các liên kết (hyperlinks), cho phép người dùng nhảy từ tài liệu này sang tài liệu khác
chỉ bằng một cú click chuột.
2. HTML (Hypertext Markup Language): Là ngôn ngữ được sử dụng để tạo ra các trang siêu
văn bản này. Nó định nghĩa cấu trúc và nội dung của một trang web (tiêu đề, đoạn văn, hình ảnh, liên kết...).
3. URL (Uniform Resource Locator): Là một cơ chế để định vị (địa chỉ) cho mỗi tài nguyên
(trang web, hình ảnh, video) trên Internet, giúp các liên kết biết phải trỏ đến đâu.
Ý tưởng cốt lõi là các đối tượng (hình ảnh, văn bản) không cần phải đóng gói "tất cả trong một" nữa.
Một trang web có thể được tạo thành từ nhiều tài nguyên nằm ở nhiều nơi khác nhau trên thế giới, được
liên kết với nhau bằng URL và hiển thị trên trình duyệt của người dùng.
Slide 23: Uniform Resource Locator (URL)
Nội dung: Phân tích cấu trúc của một URL.
Giải thích chi tiết:
URL là địa chỉ duy nhất của một tài nguyên trên mạng. Nó cho trình duyệt biết tài nguyên đó là
gì và cách để lấy nó về .
Cấu trúc chung: protocol://hostname[:port]/directory-path/resource
protocol : Giao thức sẽ được sử dụng để truy cập tài nguyên. Ví dụ :
http , https (để truy cập web) ftp (để truyền file) smtp (để gửi mail)
hostname : Tên miền (ví dụ: www.google.com ) hoặc địa chỉ IP của máy chủ chứa tài nguyên.
port (tùy chọn): Cổng dịch vụ trên máy chủ. Mỗi giao thức có một cổng mặc định (HTTP
là 80, HTTPS là 443). Nếu URL không chỉ định cổng, trình duyệt sẽ sử dụng cổng mặc định.
directory-path : Đường dẫn đến tài nguyên trên máy chủ, giống như cấu trúc thư mục trên máy tính của bạn.
resource : Tên của tài nguyên cụ thể (ví dụ: index.html , logo.png ).
Slide 24: HTTP và Web - Mô hình Client/Server lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Nội dung: Mô tả kiến trúc cơ bản của Web và vai trò của giao thức HTTP.
Giải thích chi tiết:
WWW (World Wide Web): Là một hệ thống thông tin toàn cầu nơi người dùng có thể truy cập
các tài nguyên siêu văn bản (HTML).
HTTP (HyperText Transfer Protocol): Là giao thức ở tầng ứng dụng, định ra các quy tắc để trình
duyệt web và máy chủ web "nói chuyện" với nhau. Nó là "ngôn ngữ" của Web.
Mô hình Client/Server:
Client (Khách): Là trình duyệt web (Firefox, Chrome, Safari) chạy trên máy tính hoặc điện thoại của người dùng.
Nhiệm vụ: Gửi yêu cầu (HTTP Request) đến máy chủ để xin một tài nguyên (ví dụ:
một trang web). Sau khi nhận được tài nguyên, nó sẽ hiển thị (render) nội dung đó cho người dùng.
Server (Chủ): Là phần mềm máy chủ web (Apache, Nginx, IIS) chạy trên một máy tính mạnh mẽ.
Nhiệm vụ: Lắng nghe các yêu cầu từ client, tìm tài nguyên được yêu cầu và gửi phản
hồi (HTTP Response) chứa tài nguyên đó trở lại cho client.
Slide 25: Hoạt động của HTTP
Nội dung: Tóm tắt các bước trong một phiên giao dịch HTTP điển hình.
Giải thích chi tiết:
1. Thiết lập liên kết TCP: Trước khi có thể trao đổi bất cứ điều gì, client và server phải thiết lập một kết nối tin cậy.
Server mở một TCP socket và lắng nghe các yêu cầu kết nối trên cổng 80 (cổng mặc định cho HTTP).
Client (trình duyệt) khởi tạo một kết nối TCP đến địa chỉ IP và cổng 80 của server.
Server chấp nhận yêu cầu, và một kết nối TCP được thiết lập.
2. Trao đổi thông điệp HTTP: Bây giờ, client và server có thể gửi dữ liệu cho nhau qua kết nối TCP vừa tạo.
Client gửi một thông điệp HTTP Request (ví dụ: "GET /index.html HTTP/1.1").
Server xử lý yêu cầu và gửi lại một thông điệp HTTP Response (chứa nội dung của file
index.html và mã trạng thái, ví dụ: "200 OK").
3. Đóng liên kết TCP: Sau khi giao dịch hoàn tất, kết nối TCP có thể được đóng lại. (Điều này đúng
với HTTP/1.0, còn HTTP/1.1 có thể giữ kết nối mở để dùng lại).
Slide 26: Khuôn dạng HTTP Request
Nội dung: Phân tích cấu trúc chi tiết của một thông điệp yêu cầu HTTP.
Giải thích chi tiết:
Đây là một thông điệp văn bản (ASCII), con người có thể đọc hiểu được.
Dòng yêu cầu (Request Line): Dòng đầu tiên, quan trọng nhất.
GET: Phương thức yêu cầu (sẽ nói ở slide sau).
/~tungbt/index.htm: Đường dẫn tới tài nguyên trên server.
HTTP/1.1: Phiên bản HTTP đang sử dụng. lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Các dòng tiêu đề (Header Lines): Cung cấp thêm thông tin cho server.
Host: soict.hust.edu.vn: Tên miền của server. Đây là tiêu đề bắt buộc trong HTTP/1.1,
cho phép một server vật lý có thể host nhiều website khác nhau.
User-Agent: Thông tin về trình duyệt và hệ điều hành của client.
Accept: Các loại nội dung mà client có thể chấp nhận (ví dụ: text/html, ảnh...).
Connection: keep-alive: Yêu cầu server giữ kết nối TCP mở sau khi gửi xong response
để có thể dùng lại cho các request tiếp theo.
Dòng trống (Báo kết thúc tiêu đề): Một dòng trống (\r\n) để phân tách phần header và phần thân (body).
Phần thân (Entity Body - không có trong ví dụ này): Chứa dữ liệu gửi lên server. Phần này chỉ
có với các request như POST.
Slide 27: Các phương thức yêu cầu (Request Methods)
Nội dung: Liệt kê các phương thức chính trong HTTP.
Giải thích chi tiết: HTTP/1.0:
GET: Yêu cầu lấy về một tài nguyên. Dữ liệu (tham số) được gửi đi như một phần của URL (ví
dụ: ...search?q=computer+network).
POST: Yêu cầu gửi dữ liệu lên server để xử lý (ví dụ: điền form đăng nhập, đăng bài viết).
Dữ liệu được gửi trong phần thân (body) của request, không hiển thị trên URL.
HEAD: Giống hệt GET, nhưng server chỉ trả về phần header của response, không trả về nội
dung. Hữu ích để kiểm tra xem tài nguyên có tồn tại hay không, hoặc lấy thông tin về tài
nguyên (ngày cập nhật cuối, kích thước...) mà không cần tải nó về.
HTTP/1.1 (bổ sung thêm):
PUT: Tải một file lên server tại một đường dẫn URL cụ thể. Nếu tài nguyên đã tồn tại, nó sẽ bị ghi đè.
DELETE: Xóa một tài nguyên trên server tại một URL cụ thể.
Lưu ý: Sự khác biệt chính giữa GET và POST là GET gửi tham số qua URL, còn POST gửi qua
body. Do đó, POST an toàn hơn cho việc gửi thông tin nhạy cảm (như mật khẩu) vì nó không bị
lưu lại trong lịch sử trình duyệt hay log của server một cách rõ ràng như URL.
Slide 28: Khuôn dạng HTTP Response
Nội dung: Phân tích cấu trúc của một thông điệp phản hồi từ server.
Giải thích chi tiết:
Cũng là một thông điệp văn bản.
Dòng trạng thái (Status Line): HTTP/1.1: Phiên bản HTTP.
200: Mã trạng thái (status code). 200 có nghĩa là "OK" (thành công).
OK: Mô tả ngắn gọn về mã trạng thái.
Các dòng tiêu đề (Header Lines): Cung cấp thông tin về response và server.
Date: Thời gian server gửi response.
Server: Thông tin về phần mềm web server (ví dụ: Apache/2.2.15 trên CentOS). lOMoAR cPSD| 61601435 slide3.md 2025-06-28
Last-Modified: Thời gian tài nguyên được sửa đổi lần cuối.
Content-Length: Kích thước của nội dung (dữ liệu) trả về, tính bằng byte.
Content-Type: Loại của dữ liệu trả về (ví dụ: text/html). Điều này giúp trình duyệt biết
phải xử lý dữ liệu như thế nào (hiển thị như HTML, mở như ảnh, v.v.).
Dòng trống: Phân tách header và body.
Phần thân (Dữ liệu đáp ứng yêu cầu): Đây là nội dung thực sự của tài nguyên mà client yêu cầu
(ví dụ: mã HTML của trang web).
Slide 29: Mã trạng thái trả lời (Status Codes)
Nội dung: Giới thiệu một số mã trạng thái HTTP phổ biến.
Giải thích chi tiết:
Các mã trạng thái được nhóm theo chữ số đầu tiên:
2xx (Success): Yêu cầu đã được xử lý thành công.
200 OK: Thành công. Tài nguyên được trả về trong body.
3xx (Redirection): Cần hành động thêm để hoàn thành yêu cầu (thường là chuyển hướng).
301 Moved Permanently: Tài nguyên đã được chuyển vĩnh viễn đến một URL mới.
URL mới được chỉ định trong header Location:. Trình duyệt sẽ tự động truy cập URL mới.
4xx (Client Error): Yêu cầu có lỗi từ phía client.
400 Bad Request: Server không hiểu được cú pháp của request.
404 Not Found: Server không tìm thấy tài nguyên được yêu cầu. Đây là một trong
những lỗi phổ biến nhất.
5xx (Server Error): Server gặp lỗi khi xử lý một yêu cầu hợp lệ.
505 HTTP Version Not Supported: Server không hỗ trợ phiên bản HTTP mà client yêu cầu.
Slide 30: Hiển thị (rendering) nội dung trang web
Nội dung: Mô tả quy trình cơ bản mà trình duyệt thực hiện sau khi nhận được HTTP Response.
Giải thích chi tiết:
1. Nhận thông điệp HTTP Response.
2. Phân tích và hiển thị (Parse & Render):
Trình duyệt đọc mã HTML để xây dựng cấu trúc của trang (DOM Tree).
Khi gặp các thẻ tham chiếu đến các tài nguyên khác (như ảnh ..., file CSS , file Javascript

Tài liệu liên quan: