Lịch Sử Phát Triển Networking: Từ ARPANET Đến QUIC
8 tháng 9, 2026
Mục lục
- Chương 1: Bài toán gốc — kết nối được với nhau (1960s)
- Chương 2: Thống nhất nhiều mạng — TCP/IP (1970s)
- Chương 3: Định danh dễ nhớ — DNS (1980s)
- Chương 4: Siêu văn bản — HTTP & WWW (1990s đầu)
- Chương 5: Bảo mật kênh truyền — SSL/TLS (1990s cuối)
- Chương 6: Giao tiếp hai chiều real-time — AJAX & WebSocket (2000s)
- Chương 7: Đa luồng trên một kết nối — HTTP/2 (2010s)
- Chương 8: Bỏ TCP, xây lại trên UDP — QUIC & HTTP/3 (2010s cuối – nay)
- Tổng kết: toàn cảnh 8 giai đoạn
Chương 1: Bài toán gốc — kết nối được với nhau (1960s)
Vấn đề: Trước 1969, mạng máy tính là các kết nối điểm-điểm (point-to-point) riêng lẻ — muốn 2 máy nói chuyện thì phải có một đường dây vật lý dành riêng cho chúng, giống điện thoại analog. Cách này không mở rộng được: N máy cần gần N² đường dây.
Giải pháp: ARPANET (1969) thử nghiệm chuyển mạch gói (packet switching) — chia dữ liệu thành các gói nhỏ, mỗi gói tự mang thông tin định tuyến và tự tìm đường đi qua mạng, thay vì giữ một đường dây cố định suốt phiên làm việc.
Kiểu cũ (circuit switching):
Máy A ======= [đường dây riêng] ======= Máy B
Kiểu mới (packet switching):
Máy A → [gói 1] → node → node → [gói 1] → Máy B
→ [gói 2] → node → node → [gói 2] → Máy B
Ý nghĩa: Đây là viên gạch đầu tiên. Không có packet switching thì mọi thứ sau này (IP, TCP, Internet) không có nền để đứng.
Chương 2: Thống nhất nhiều mạng — TCP/IP (1970s)
Vấn đề: Đến giữa 1970s, có nhiều mạng packet-switching độc lập (ARPANET, mạng vệ tinh, mạng radio) nhưng kiến trúc khác nhau, không nói chuyện được với nhau. Mỗi mạng là một "ốc đảo".
Giải pháp: Vint Cerf và Bob Kahn thiết kế TCP/IP (1974) làm tầng trung gian chung, tách trách nhiệm rõ ràng:
| Tầng | Trách nhiệm | Vấn đề nó giải quyết |
|---|---|---|
| IP | Định tuyến gói tin qua nhiều mạng khác nhau | Gói đi từ mạng A sang mạng B bằng cách nào |
| TCP | Đảm bảo gói đến đủ, đúng thứ tự | IP không đảm bảo gì cả — TCP vá phần đó |
Đây là chỗ hay nhầm: IP chỉ lo định tuyến, không lo độ tin cậy. Một gói IP có thể mất, trùng, hoặc đến sai thứ tự — và IP coi đó là chuyện bình thường. TCP là tầng phía trên, chịu trách nhiệm dọn dẹp mớ hỗn loạn đó.
Ý nghĩa: "Internet" đúng nghĩa đen là mạng của các mạng (inter-network) — và TCP/IP chính là thứ khâu chúng lại với nhau.
Chương 3: Định danh dễ nhớ — DNS (1980s)
Vấn đề: Mọi máy trên Internet được định danh bằng địa chỉ IP (dạng 192.168.1.1). Nhớ vài chục địa chỉ thì ổn, nhưng khi số lượng máy chủ tăng lên hàng nghìn, việc này bất khả thi với con người.
Giải pháp: DNS (Domain Name System, 1983) ánh xạ tên miền dễ nhớ (example.com) sang địa chỉ IP, hoạt động như một danh bạ phân tán — không có một máy chủ trung tâm nào giữ toàn bộ danh sách, mà là hệ thống các máy chủ ủy quyền cho nhau theo cây phân cấp.
example.com → DNS lookup → 93.184.216.34
Ý nghĩa: Cùng giai đoạn này, mô hình OSI 7 tầng cũng được đưa ra để chuẩn hóa cách các giao thức phân lớp trách nhiệm (vật lý → liên kết dữ liệu → mạng → giao vận → phiên → trình diễn → ứng dụng). TCP/IP không theo đúng 7 tầng này, nhưng OSI trở thành ngôn ngữ chung để nói về networking.
Chương 4: Siêu văn bản — HTTP & WWW (1990s đầu)
Vấn đề: FTP, Telnet, email (SMTP) đã tồn tại nhưng rời rạc — mỗi giao thức phục vụ một việc riêng, không có cách nào để liên kết thông tin từ nơi này sang nơi khác một cách trực quan.
Giải pháp: Tim Berners-Lee tạo ra HTTP + HTML (1991) tại CERN để giải quyết bài toán siêu văn bản (hypertext) — tài liệu có thể chứa link trỏ sang tài liệu khác, và trình duyệt là công cụ để "đi theo" các link đó.
Ý nghĩa: Đây là bước ngoặt lớn nhất về mặt đại chúng hóa. Internet trước đó là công cụ của giới kỹ thuật; World Wide Web biến nó thành thứ ai cũng dùng được chỉ bằng cách click chuột.
Chương 5: Bảo mật kênh truyền — SSL/TLS (1990s cuối)
Vấn đề: HTTP truyền dữ liệu dạng plain text. Bất kỳ ai đứng giữa đường truyền (ISP, mạng WiFi công cộng, kẻ tấn công man-in-the-middle) đều đọc được nội dung — bao gồm cả mật khẩu, số thẻ tín dụng.
Giải pháp: SSL (1995), sau này phát triển thành TLS, mã hóa toàn bộ kênh truyền trước khi dữ liệu ứng dụng (HTTP) đi qua. HTTPS = HTTP chạy trên TLS.
Ý nghĩa: Không có TLS thì không có thương mại điện tử, không có ngân hàng online, không có bất kỳ giao dịch nhạy cảm nào an toàn trên Internet công cộng.
Chương 6: Giao tiếp hai chiều real-time — AJAX & WebSocket (2000s)
Vấn đề: HTTP vốn là mô hình request-response một chiều — client hỏi, server trả lời, xong. Muốn có dữ liệu mới, phải load lại toàn bộ trang. Với các ứng dụng cần cập nhật liên tục (chat, dashboard, game), cách này quá nặng và chậm.
Giải pháp theo 2 bước:
- AJAX (phổ biến từ ~2005) dùng
XMLHttpRequestđể gọi ngầm lên server mà không reload trang — nhưng vẫn là request-response, chỉ là "ẩn" đi. - WebSocket (2011) mở một kết nối TCP hai chiều thật sự, giữ nguyên trong suốt phiên làm việc — server có thể chủ động đẩy dữ liệu về client bất cứ lúc nào, không cần client phải hỏi trước.
Ý nghĩa: Đây là bài toán mà mô hình request-response của HTTP không giải quyết tốt — WebSocket ra đời đúng vì giới hạn kiến trúc đó.
Chương 7: Đa luồng trên một kết nối — HTTP/2 (2010s)
Vấn đề: HTTP/1.1 mỗi request cần một kết nối TCP riêng (hoặc phải xếp hàng chờ trên cùng một kết nối). Một trang web hiện đại tải hàng chục resource (JS, CSS, ảnh, font) — mở hàng chục kết nối TCP song song vừa tốn tài nguyên vừa bị giới hạn bởi trình duyệt (thường 6 kết nối/domain).
Giải pháp: HTTP/2 (2015) dùng multiplexing — nhiều request/response chạy chung một kết nối TCP, chia nhỏ thành các "frame" và ghép lại đúng thứ tự.
| HTTP/1.1 | HTTP/2 | |
|---|---|---|
| Số kết nối cần | Nhiều (giới hạn ~6/domain) | 1 kết nối, nhiều luồng |
| Head-of-line blocking | Có, ở tầng ứng dụng | Đã giải quyết ở tầng ứng dụng |
Vấn đề còn sót lại: HTTP/2 giải quyết head-of-line blocking ở tầng ứng dụng, nhưng bản thân TCP vẫn có head-of-line blocking ở tầng giao vận — nếu một gói TCP bị mất, toàn bộ các luồng multiplexed phía trên đều phải đợi gói đó được gửi lại, dù chúng thuộc các request độc lập.
Chương 8: Bỏ TCP, xây lại trên UDP — QUIC & HTTP/3 (2010s cuối – nay)
Vấn đề: Hai giới hạn cộng dồn từ TCP:
- Bắt tay TCP (3 bước) + bắt tay TLS (thêm 1-2 vòng round-trip) = độ trễ khởi tạo kết nối khá lớn, đặc biệt rõ trên mạng di động.
- Head-of-line blocking ở tầng TCP như đã nói ở Chương 7 — không thể vá được nếu vẫn giữ nguyên TCP, vì đó là bản chất thiết kế của nó (đảm bảo thứ tự tuyệt đối).
Giải pháp: QUIC (Google phát triển, chuẩn hóa RFC 9000 năm 2021), nền tảng cho HTTP/3, xây dựng lại trên UDP thay vì TCP:
- Tự cài đặt cơ chế tin cậy + đảm bảo thứ tự ở tầng ứng dụng (thay vì dựa vào TCP), nhưng làm theo từng luồng riêng — mất gói ở luồng này không chặn luồng khác.
- Gộp luôn bắt tay mã hóa (TLS 1.3) vào bắt tay kết nối, giảm số vòng round-trip cần thiết trước khi truyền dữ liệu thật.
Đây chính là điểm khép vòng thú vị nhất: UDP từng bị coi là "giao thức tối giản, không đáng tin cậy" — giờ được dùng làm nền cho giao thức web hiện đại nhất, vì nó cho toàn quyền kiểm soát ở tầng trên thay vì bị TCP ép theo một mô hình cứng.
Tổng kết: toàn cảnh 8 giai đoạn
| Giai đoạn | Thời kỳ | Vấn đề cốt lõi | Giao thức/công nghệ | Vá giới hạn của tầng nào |
|---|---|---|---|---|
| Kết nối được | 1960s | Không mở rộng được với circuit switching | Packet switching (ARPANET) | Tầng vật lý/liên kết |
| Thống nhất mạng | 1970s | Nhiều mạng không nói chuyện được | TCP/IP | Liên mạng |
| Dễ nhớ | 1980s | Địa chỉ IP khó nhớ | DNS | Tầng ứng dụng |
| Chia sẻ thông tin | 1990s đầu | Không có cách liên kết tài liệu | HTTP/HTML (WWW) | Tầng ứng dụng |
| Bảo mật | 1990s cuối | Dữ liệu truyền dạng plain text | SSL/TLS | Tầng giao vận/ứng dụng |
| Real-time | 2000s | Request-response không đủ cho cập nhật liên tục | AJAX, WebSocket | Tầng ứng dụng |
| Hiệu năng | 2010s | Quá nhiều kết nối TCP song song | HTTP/2 (multiplexing) | Tầng ứng dụng |
| Bỏ giới hạn TCP | 2010s cuối–nay | TCP head-of-line blocking không vá được | QUIC/HTTP/3 (trên UDP) | Tầng giao vận |
Cách hình dung toàn bộ dòng chảy: mỗi giao thức mới không thay thế hoàn toàn cái cũ, mà vá đúng một giới hạn cụ thể của tầng ngay bên dưới nó. Khi giới hạn đó nằm sâu trong bản chất thiết kế (như TCP head-of-line blocking), cách duy nhất để vá triệt để là bỏ hẳn tầng đó và xây lại — đó là lý do QUIC quay về dùng UDP thay vì tiếp tục vá trên TCP.