20 trang 39 lượt tải

Bài thực hành môn Thiết kế và triển khai mạng IP | Trường Đại học Bách Khoa Hà Nội

77

Sử dụng các kiến thức của bài trước, dựng môi trường mạng ảo với các kết nối mặc định có tốc độ cao (500Mbps) và 1 kết nối tốc độ thấp (10Mbps). Các luồng dữ liệu cạnh tranh trên kết nối tốc độ thấp này. Tài liệu được sưu tầm gồm 31 trang, giúp các bạn nắm vững kiến thức, rèn luyện kỹ năng và đạt được kết quả tốt trong học tập. Mời các bạn đón xem!

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

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

Tác giả:

Profile

My Lữ

1 tuần trước
Danh sách Quiz
/20
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
Internet).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.
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.
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).
Slide 3: V
ị
trí trong ki
ế
n trúc phân t
ầ
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:
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).
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.
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).
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:
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
Githứải thích chi tic ở tầng giao vết:ậ 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. Email
(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.
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ì.
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ề.
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.
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:
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.
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.
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 tiQUESTION SECTION:ết: Câu hỏi là tìm bản ghi A (địa chỉ IP) cho linux.com.
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:
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):
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ó.
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.
Gi
ả
i thích chi ti
ế
t:
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).
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.
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.
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.
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.
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Đây là mộết thông đit: ệ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.
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 tiGETế: Yêu ct: ầ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 HTTP/1.0:(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.
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).
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íchCác mã trchi iếạng thái đưt: ợ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ề.
Gi
ả
i thích chi ti
ế
t:
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.
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).
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ỳ).
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
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.
Gi
ả
i thích chi ti
ế
t:
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ì.
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.
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.
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.
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.
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.
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.
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:
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?
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ử.
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ư):
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:
Đâ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.
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.
Giải thích chi tiSơ đồ minh hết: ọ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.
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ị.
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.
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.
Giải thích chi tiMột email đưết: ợ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.
Phần đBao gầu (Header):ồ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...).
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):
Được thiết lập trên cổng 20 của server (ở chế độ active, hoặc một cổng ngẫu nhiên
ở chế độ passive).
Kết nối này được tạo ra một cách tạm thời mỗi khi có một file cần được truyền
hoặc khi cần gửi danh sách file.
Nhiệm vụ: Chỉ dùng để truyền nội dung thực sự của file hoặc kết quả của lệnh
LIST. Sau khi truyền xong, kết nối này sẽ được đóng lại.
"Out-of-band" có nghĩa là thông tin điều khiển và dữ liệu thực tế được gửi trên hai kênh
riêng biệt (hai "băng tần" khác nhau).
Yêu cầu đăng nhập:
Để sử dụng FTP, người dùng thường phải đăng nhập (authenticate) bằng tên người
dùng và mật khẩu trước khi có thể thực hiện các thao tác trên file.
Anonymous FTP:
Một số FTP server công cộng cho phép người dùng đăng nhập mà không cần có tài khoản
từ trước. Người dùng có thể đăng nhập với tên là anonymous và mật khẩu thường là địa
chỉ email của họ (hoặc một chuỗi bất kỳ).
Chế độ này thường được dùng để chia sẻ các phần mềm miễn phí, tài liệu công khai.
Tổng kết toàn bộ bài giảng
Như vậy, chúng ta đã đi qua toàn bộ nội dung của bài giảng "Internet Services". Chúng ta đã tìm hiểu:
1. Kiến trúc phân tầng của mạng: Giúp hiểu vị trí và vai trò của các dịch vụ ứng dụng.
2. Tầng Giao vận: Với hai giao thức cốt lõi là TCP (tin cậy) và UDP (nhanh, không tin cậy) làm nền tảng
cho mọi dịch vụ.
3. DNS (Domain Name System): Dịch vụ "danh bạ của Internet", chuyển đổi từ tên miền dễ nhớ sang địa
chỉ IP mà máy tính sử dụng. Chúng ta đã học về cấu trúc phân cấp, các loại truy vấn (đệ quy, tương
tác), và cách đọc một thông điệp DNS.
4. Web và HTTP/HTTPS: Dịch vụ phổ biến nhất. Chúng ta đã khám phá cách Web ra đời, cấu trúc của
một URL, cách HTTP hoạt động với các phương thức GET/POST, các chế độ duy trì/không duy trì, và
tầm quan trọng của Cookie để quản lý phiên làm việc. Chúng ta cũng đã thấy HTTPS bổ sung lớp bảo
mật SSL/TLS để xác thực, mã hóa và đảm bảo toàn vẹn dữ liệu.
5. Dịch vụ Email: Tìm hiểu về các thành phần MUA, MTA, các giao thức SMTP (để gửi), POP/IMAP (để
nhận), và vai trò của MIME trong việc cho phép gửi các nội dung đa phương tiện.
6. FTP (File Transfer Protocol): Một giao thức chuyên dụng cho việc truyền file, với cơ chế độc đáo sử
dụng hai kết nối riêng biệt cho việc điều khiển và truyền dữ liệu.
Phần cuối cùng (FTP) và phần tổng kết đã hoàn tất. Bạn có câu hỏi nào khác hoặc có muốn làm rõ thêm bất
kỳ phần nào trong toàn bộ bài giảng này không? Tôi hy vọng phần giải thích chi tiết này hữu ích cho bạn.

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

Preview text:

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
Internet).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.
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.
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
Githứải thích chi tic ở tầng giao vết:ậ 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. Email
(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.
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ì.
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.
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:
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 tiQUESTION SECTION:ết: 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ó.
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.
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.
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Đây là mộết thông đit: ệ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.
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 tiGETế: Yêu ct: ầ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 HTTP/1.0:(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íc C h ũn chi g l ti ế à m t:
ộ 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).
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íchCác mã trchi iếạng thái đưt: ợ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: