Tìm hiểu cách Tim Berners-Lee kết hợp URL, HTTP và HTML để tạo ra World Wide Web — và tại sao những ý tưởng đơn giản này vẫn là nền tảng cho ứng dụng và API hiện đại.
World Wide Web (thường gọi là “Web”) là một cách để xuất bản và truy cập thông tin bằng các liên kết. Đó là hệ thống cho phép bạn nhấp từ trang này sang trang khác, mở trang sản phẩm từ kết quả tìm kiếm, hoặc chia sẻ một đường dẫn hoạt động trên hầu hết máy tính và điện thoại.
Ở cốt lõi, Web được vận hành bởi một bộ ba rất thực tế:
Bạn không cần là lập trình viên để cảm nhận tác động của chúng: mỗi lần bạn dán một liên kết, tải một trang, hay nhấp một nút dẫn bạn tới nơi khác, bạn đang dựa vào URL + HTTP + HTML.
Mọi người thường dùng “Web” và “Internet” thay thế cho nhau, nhưng chúng khác nhau:
Email, trò chơi trực tuyến, và nhiều ứng dụng chat sử dụng Internet mà không phải là “Web” theo nghĩa chặt chẽ.
Ngay cả các trải nghiệm hiện đại—ứng dụng một trang, ứng dụng di động, và API—vẫn phụ thuộc nhiều vào những nền tảng này. Chúng có thể che giấu chi tiết, nhưng tiếp tục dùng URL để định danh tài nguyên, HTTP để trao đổi yêu cầu và phản hồi, và thường HTML để khởi tạo những gì bạn thấy trong trình duyệt.
Tim Berners-Lee không cố gắng phát minh “internet.” Năm 1989, khi làm việc tại CERN, ông tập trung vào một khó chịu thực tế: thông tin quan trọng tồn tại nhưng bị phân tán trên các hệ thống không tương thích, lưu ở các định dạng khác nhau, và khó tìm lại.
Các nhà nghiên cứu, nhóm và phòng ban dùng các máy tính và phần mềm khác nhau. Ngay cả khi hai nhóm có “cùng” loại tài liệu, họ có thể lưu ở nơi khác nhau, đặt tên khác nhau, hoặc cần phần mềm đặc biệt để mở. Việc chia sẻ thường có nghĩa là gửi các tệp đi, sao chép, và mất dấu phiên bản hiện hành.
Ý tưởng cốt lõi của Berners-Lee là cho phép bất kỳ ai xuất bản một tài liệu trên chính máy tính của họ, rồi người khác truy cập nó bằng một phương pháp nhất quán—mà không cần biết loại máy, hệ điều hành, hay cấu trúc thư mục nội bộ.
Điều đó đòi hỏi vài thứ cùng hoạt động:
Đột phá không phải là một tính năng đơn lẻ—mà là quyết định giữ hệ thống nhỏ và phổ quát. Nếu các quy tắc đủ đơn giản, các máy khác nhau và các tổ chức độc lập có thể triển khai chúng và vẫn giao tiếp được.
Đây cũng là lý do tiêu chuẩn mở quan trọng ngay từ đầu: web cần các quy tắc công khai, chia sẻ để nhiều hệ thống độc lập có thể tham gia. Tập trung vào tiêu chuẩn chung—thay vì một chuỗi công cụ của một nhà cung cấp—làm cho web lan nhanh và cho phép trình duyệt và máy chủ mới làm việc với nội dung hiện có.
Nếu bạn từng cố “chia sẻ tệp” trên một ổ đĩa văn phòng lộn xộn, bạn đã thấy vấn đề cốt lõi của mạng: đặt tên nhất quán cho mọi thứ là khó. Máy khác nhau lưu thông tin ở nơi khác nhau, thư mục bị sắp xếp lại, và hai tài liệu có thể trùng tên. Không có hệ thống đặt tên chung, bạn không thể nói một cách đáng tin cậy “lấy cái đó ở chỗ kia.”
URL giải quyết điều này cho World Wide Web bằng cách cung cấp một địa chỉ toàn cầu, có thể sao chép-dán cho một tài nguyên.
Dưới đây là một ví dụ bạn có thể nhận ra:
https://www.example.com:443/products/shoes?color=black\u0026size=42#reviews
Mỗi phần có nghĩa gì (bằng tiếng thường):
Một URL có thể nhận diện gần như bất cứ thứ gì máy chủ có thể trả về: một trang HTML, một hình ảnh, một PDF, một tệp tải xuống, hoặc thậm chí một endpoint API dùng bởi ứng dụng.
Ví dụ:
/images/logo.png (một hình ảnh)/docs/terms.pdf (một tài liệu)/api/orders/123 (dữ liệu cho một ứng dụng)Mọi người thường dùng các từ này hoán đổi cho nhau:
Về mặt thực tế, nghĩ “URL = địa chỉ” sẽ giúp bạn hiểu được 95% trường hợp.
HTTP là phong cách giao tiếp cơ bản của web. Nó là một thỏa thuận đơn giản: trình duyệt của bạn hỏi một thứ, và máy chủ trả lại cái nó có (hoặc giải thích vì sao không thể).
Khi bạn gõ một URL hoặc nhấp một liên kết, trình duyệt gửi một request HTTP tới máy chủ. Yêu cầu giống như một mảnh ghi chú: “Tôi muốn tài nguyên cụ thể này.”
Máy chủ sau đó gửi lại một response HTTP. Phần trả lời là gói chứa kết quả: nội dung bạn yêu cầu (như một trang), hoặc một thông báo rằng chuyện khác đã xảy ra.
Yêu cầu HTTP bao gồm một method, chỉ loại hành động bạn đang thực hiện.
Một GET thường không thay đổi gì trên máy chủ; nó chủ yếu để đọc. Một POST thường dùng khi bạn gửi thông tin để xử lý.
Mỗi phản hồi bao gồm một mã trạng thái—hãy nghĩ nó như kết quả giao hàng.
Yêu cầu và phản hồi cũng bao gồm headers, giống như nhãn: “Đây là ai của tôi,” “Tôi chấp nhận gì,” hoặc “Nội dung này nên được xử lý thế nào.”
Một trong những nhãn hữu ích nhất là Content-Type, như text/html cho một trang web hoặc application/json cho dữ liệu. Nó cho biết trình duyệt bên trong có gì để hiển thị đúng cách.
HTML (HyperText Markup Language) là định dạng dùng để mô tả cấu trúc của một trang web—nội dung là gì và được tổ chức thế nào. Hãy nghĩ nó như một tài liệu có nhãn: “đây là tiêu đề,” “đây là đoạn văn,” “đây là liên kết,” “đây là trường biểu mẫu.”
HTML dùng thẻ để gắn nhãn nội dung. Thẻ thường có phiên bản mở và đóng, bao quanh phần nội dung mà nó mô tả.
Tiêu đề và đoạn văn tạo hình cho trang. Tiêu đề nói với cả người đọc và trình duyệt: “đây là tiêu đề quan trọng.” Đoạn văn nói: “đây là văn bản thân bài.”
Liên kết và hình ảnh cũng được mô tả trong HTML. Thẻ hình ảnh trỏ tới tệp hình ảnh (một tài nguyên), trong khi thẻ liên kết trỏ tới một URL khác.
“HT” trong HTML—hypertext—là ý tưởng lớn khiến web khác biệt so với các hệ thống trước. Thay vì điều hướng chỉ bằng menu, thư mục, hoặc lệnh đặc biệt, bạn có thể nhảy trực tiếp từ tài liệu này sang tài liệu khác bằng các liên kết có thể nhấp được đặt trong văn bản.
Sự chuyển đổi này nghe có vẻ đơn giản, nhưng rất mạnh: kiến thức trở nên kết nối. Một trang có thể tham chiếu nguồn, chủ đề liên quan, định nghĩa, và bước tiếp theo ngay lập tức—không cần “quay lại” một chỉ mục trung tâm mỗi lần.
Đây là cách một liên kết cơ bản trông như thế nào:
\u003ca href=\"/blog/how-http-works\"\u003eRead more about HTTP\u003c/a\u003e
Nói bằng tiếng thường: “Hiển thị chữ Read more about HTTP và, khi nhấp, đưa đọc giả tới trang ở /blog/how-http-works.”
HTML không chỉ để xuất bản tài liệu. Nó cũng mô tả các trường nhập như hộp văn bản, checkbox và nút bấm. Những thành phần đó cho phép một trang thu thập thông tin (như đăng nhập, tìm kiếm, hoặc thanh toán) và gửi nó tới máy chủ.
Rất dễ nhầm lẫn, nhưng chúng có nhiệm vụ khác nhau:
Ngay cả khi ứng dụng web trở nên phức tạp hơn, HTML vẫn là điểm bắt đầu: đó là cách chung, dễ đọc để mô tả nội dung một trang—và nơi nó có thể dẫn tới tiếp theo.
Khi bạn truy cập một website, trình duyệt cơ bản thực hiện hai nhiệm vụ: tìm đúng máy tính để nói chuyện, và yêu cầu đúng tệp.
Một URL (như https://example.com/page) là địa chỉ của trang. Nó bao gồm tên host (example.com) và thường là một path (/page).
Máy tính trên internet nói chuyện bằng địa chỉ số gọi là IP address. DNS (Domain Name System) giống như danh bạ điện thoại, ánh xạ example.com sang một địa chỉ IP.
Tra cứu này thường nhanh—và đôi khi được bỏ qua vì câu trả lời đã lưu từ lần truy cập gần đây.
Trình duyệt mở kết nối tới máy chủ ở địa chỉ IP đó. Nếu URL bắt đầu bằng https://, trình duyệt cũng thiết lập kết nối mã hóa để người khác không dễ đọc nội dung đang truyền.
HTTP là ngôn ngữ “yêu cầu và phản hồi” của web. Trình duyệt gửi một yêu cầu HTTP như: “Vui lòng cho tôi /page.”
Máy chủ trả lời bằng phản hồi HTTP chứa trạng thái (như “OK” hoặc “Not Found”) và nội dung.
Nội dung đó thường là HTML. HTML mô tả cấu trúc một trang—tiêu đề, đoạn văn, liên kết, v.v.
Khi trình duyệt đọc HTML, nó có thể phát hiện cần thêm các tệp khác (CSS để style, JavaScript để tương tác, hình ảnh, font). Nó lặp lại mẫu yêu cầu/phản hồi HTTP cho từng tệp đó.
Để tăng tốc, trình duyệt giữ một cache—bản sao đã tải trước đó. Nếu không có gì thay đổi, trình duyệt có thể dùng lại bản sao đó thay vì tải lại.
Danh sách kiểm tra nhanh (luồng):
Khi người ta nói “web,” họ thường nghĩ về trải nghiệm mượt mà: bạn chạm một liên kết và trang hiện ra. Bên dưới, đó là mối quan hệ đơn giản giữa ba ý tưởng: server, browser, và resource.
Một server là một máy tính (hoặc một cụm máy) kết nối internet và lưu trữ tài nguyên tại các URL. Nếu một URL là địa chỉ, server là nơi nhận khách đến địa chỉ đó và quyết định gửi gì lại.
Thứ máy chủ gửi có thể là một trang web, một tệp, hoặc dữ liệu. Điểm quan trọng là server được cấu hình để phản hồi các yêu cầu cho các URL cụ thể.
Một browser là chương trình (như Chrome, Safari, hoặc Firefox) lấy tài nguyên từ server và hiển thị chúng theo cách dễ hiểu cho con người.
Khi bạn nhập URL hoặc nhấp liên kết, trình duyệt:
Một resource là bất cứ thứ gì web có thể định danh và chuyển giao tại một URL. Ví dụ phổ biến:
Mô hình này không chỉ giới hạn cho trình duyệt. Ứng dụng di động cũng có thể yêu cầu một URL—thường là một endpoint API—và nhận dữ liệu để hiển thị trong giao diện riêng của ứng dụng. Vai trò vẫn giữ nguyên: app là “client,” server là “host,” và phản hồi API là resource.
Các trang web ban đầu chủ yếu hiển thị thông tin. Biểu mẫu là thứ cho phép web thu thập thông tin—biến một trang trở thành cuộc trao đổi hai chiều.
Một biểu mẫu HTML là một tập các trường (như hộp văn bản, checkbox, và nút) cùng hai hướng dẫn chính:
action)method, thường là GET hoặc POST)Khi bạn nhấp “Submit,” trình duyệt đóng gói những gì bạn đã nhập và gửi nó bằng HTTP tới server tại URL đó. Đó là cầu nối giữa “một tài liệu có trường” và “một ứng dụng xử lý input.”
Tóm tắt:
Vì vậy một tìm kiếm có thể trông như /search?q=shoes (GET), trong khi một thanh toán có thể POST chi tiết đơn hàng tới /checkout.
Bên server, một chương trình nhận yêu cầu HTTP, đọc các giá trị gửi lên, và quyết định bước tiếp theo:
Máy chủ sau đó trả về—thường là một trang HTML mới (“Cảm ơn!”), một thông báo lỗi, hoặc chuyển hướng tới một URL khác.
Nếu một biểu mẫu có thông tin nhạy cảm—mật khẩu, địa chỉ, chi tiết thanh toán—HTTPS là cần thiết. Nó ngăn người khác trên mạng đọc hoặc thay đổi dữ liệu gửi giữa trình duyệt và trang. Nếu không có HTTPS, ngay cả một biểu mẫu đăng nhập đơn giản cũng có thể làm lộ người dùng.
Các “ứng dụng” hiện đại trên Web không chỉ là trang web. Phần lớn là web cộng thêm mã: một trang HTML tải JavaScript và CSS, rồi dùng mã đó để cập nhật giao diện mà không tải lại toàn bộ trang.
Ngay cả khi một app cho cảm giác như ứng dụng gốc (cuộn vô hạn, cập nhật theo thời gian thực, kéo thả), nó vẫn dựa trên ba khối xây dựng Tim Berners-Lee giới thiệu.
URL không chỉ dành cho “một trang.” Nó là địa chỉ cho bất kỳ tài nguyên: một sản phẩm, một hồ sơ người dùng, một truy vấn tìm kiếm, một ảnh, hoặc một endpoint “gửi tin”. Ứng dụng tốt dùng URL để làm nội dung có thể chia sẻ, bookmark, và liên kết—hành vi cốt lõi của Web.
Phía sau, ứng dụng gửi yêu cầu HTTP và nhận phản hồi HTTP, giống như các website cổ điển. Quy tắc giống nhau dù bạn lấy một trang HTML hay tải dữ liệu cho một phần của màn hình:
Phần lớn ứng dụng hiện đại nói chuyện với APIs: URL trả dữ liệu—thường là JSON—qua HTTP.
Ví dụ:
HTML vẫn quan trọng vì thường là điểm bắt đầu (và đôi khi là phương án dự phòng). Rộng hơn, Web là nền tảng tích hợp: nếu hệ thống đồng ý về URL và HTTP, chúng có thể kết nối—bất kể ai xây dựng chúng.
Một cách thực tế để thấy các khối này hoạt động là xây một thứ nhỏ—ví dụ, front end React nói chuyện với API JSON và có URL chia sẻ cho các màn hình chính. Công cụ như Koder.ai đi theo cùng mô hình: bạn mô tả ứng dụng trong chat, và nó tạo ra stack web tiêu chuẩn (React phía frontend, Go + PostgreSQL phía backend), vậy nên bạn vẫn làm việc với URL thực, endpoint HTTP, và HTML được trình duyệt cung cấp—chỉ với ít công thiết lập thủ công hơn.
Web hoạt động ở quy mô toàn cầu vì nó dựa trên các tiêu chuẩn chung—những “luật giao thông” công khai cho phép hệ thống khác nhau giao tiếp đáng tin cậy. Một trình duyệt của công ty này có thể yêu cầu một trang từ máy chủ của công ty khác, được host ở bất cứ đâu, viết bằng bất kỳ ngôn ngữ lập trình nào, vì họ đồng ý về cơ bản như URL, HTTP, và HTML.
Nếu không có tiêu chuẩn, mỗi trang sẽ cần một ứng dụng tùy chỉnh để xem nó, và mỗi mạng sẽ có cách gửi yêu cầu riêng. Chuẩn hóa giải quyết các câu hỏi đơn giản nhưng then chốt:
Khi những quy tắc đó nhất quán, Web trở nên “mix and match”: bất kỳ trình duyệt tuân thủ + bất kỳ máy chủ tuân thủ = hoạt động.
Ấn tượng là các tiêu chuẩn có thể cải tiến trong khi cơ bản vẫn nhận dạng được. HTTP đã tiến từ phiên bản đầu sang HTTP/1.1, rồi HTTP/2 và HTTP/3, thêm hiệu suất và hiệu quả. Nhưng ý tưởng cốt lõi vẫn thế: client yêu cầu một URL, server phản hồi với mã trạng thái, headers, và body.
HTML cũng phát triển—từ tài liệu đơn giản tới ngữ nghĩa phong phú và media nhúng—nhưng vẫn giữ khái niệm cơ bản về trang và siêu liên kết.
Phần lớn sức bền của Web đến từ ưu tiên mạnh mẽ cho tương thích ngược. Trình duyệt mới vẫn cố gắng hiển thị trang cũ; máy chủ mới vẫn hiểu yêu cầu HTTP cũ. Điều đó có nghĩa là nội dung và liên kết có thể tồn tại nhiều năm—thậm chí vài thập kỷ.
Nếu bạn muốn site hoặc app của mình bền lâu, hãy dựa vào thiết kế theo tiêu chuẩn: dùng URL thực cho trạng thái có thể chia sẻ, tuân thủ quy ước HTTP cho caching và mã trạng thái, và viết HTML hợp lệ trước khi thêm lớp khác. Tiêu chuẩn không bó buộc—chúng giữ công việc của bạn di động, đáng tin cậy và thân thiện với tương lai.
Dù bạn dùng web hàng ngày, vài thuật ngữ vẫn bị lẫn lộn đến mức có thể làm sai hướng khắc phục, lập kế hoạch, hoặc thậm chí các cuộc trò chuyện đơn giản. Đây là vài nhầm lẫn phổ biến—và cách sửa nhanh.
Hiểu lầm: Internet và World Wide Web là một.
Sửa nhanh: Internet là mạng lưới toàn cầu (cáp, bộ định tuyến, kết nối). Web là một dịch vụ chạy trên đó, được xây từ URLs, HTTP, và HTML.
Hiểu lầm: “URL của tôi là example.com.”
Sửa nhanh: example.com là một domain. Một URL là một địa chỉ đầy đủ có thể bao gồm path, query, và nhiều hơn nữa, như:
https://example.com/pricing (một route cụ thể)https://example.com/search?q=shoes (route cộng query)Các phần thêm đó có thể thay đổi phản hồi từ máy chủ.
Hiểu lầm: HTML và HTTP giống nhau.
Sửa nhanh: HTTP là “cuộc trò chuyện giao vận” (yêu cầu và phản hồi). HTML là một trong các “gói” được giao—thường là thứ mô tả một trang và liên kết của nó. HTTP cũng có thể chuyển JSON, hình ảnh, PDF, hoặc video.
Hiểu lầm: Bất kỳ lỗi nào cũng nghĩa là “trang web sập,” và chuyển hướng luôn xấu.
Sửa nhanh: Mã trạng thái là tín hiệu:
Hiểu lầm: Mọi URL đều phải mở trang đọc được.
Sửa nhanh: Một URL có thể trỏ tới dữ liệu (/api/orders), một tệp (/report.pdf), hoặc một endpoint hành động cho biểu mẫu.
Hiểu lầm: Nếu có HTTPS thì site an toàn và đáng tin.
Sửa nhanh: HTTPS mã hóa kết nối và giúp xác nhận bạn đang nói chuyện với đúng domain—bảo vệ đăng nhập, biểu mẫu và dữ liệu nhạy cảm khi truyền. Nhưng nó không đảm bảo doanh nghiệp hay nội dung là uy tín. Bạn vẫn cần đánh giá nguồn, nội dung và ngữ cảnh.
Ý tưởng cốt lõi của Tim Berners-Lee thật sự nhỏ: kết nối tài liệu (và sau này là ứng dụng) bằng một phương thức địa chỉ chung, một cách yêu cầu dữ liệu chung, và một định dạng chung để hiển thị và liên kết.
URL là địa chỉ. Nó cho biết bạn muốn gì và nó nằm ở đâu (và thường cách truy cập nó).
HTTP là cuộc trò chuyện. Là tập quy tắc trình duyệt và máy chủ dùng để yêu cầu thứ gì đó và trả lời nó (mã trạng thái, headers, caching, và hơn thế).
HTML là định dạng trang. Trình duyệt có thể đọc nó để dựng nội dung—và, quan trọng, nơi các liên kết kết nối tài nguyên này với tài nguyên khác.
Hãy nghĩ về web như một vòng lặp ba bước đơn giản:
Khi bạn nắm vòng lặp đó, các chi tiết hiện đại (cookies, APIs, single-page apps, CDN) trở nên dễ lý giải hơn: chúng thường là những tinh chỉnh cho việc đặt tên, yêu cầu, hoặc hiển thị.
Nếu bạn muốn tìm hiểu sâu hơn mà không quá kỹ thuật:
Hiểu những khái niệm cơ bản này mang lại lợi ích nhanh chóng: bạn sẽ giỏi hơn trong việc đánh giá công cụ web (“Điều này có dựa trên URL và HTTP chuẩn không?”), giao tiếp với lập trình viên, và khắc phục các vấn đề hàng ngày như liên kết hỏng, cache, hoặc phân biệt “404 vs 500”.
The Internet is the global network (routers, cables, IP routing) that connects computers. The Web is a service that runs on top of it: resources identified by URLs, transferred with HTTP, and often displayed as HTML.
Many things use the Internet without being “the Web,” like email, some multiplayer games, and many chat systems.
Think of a URL as a precise address for a resource. It can point to an HTML page, an image, a PDF, or an API endpoint.
A typical URL includes:
A domain (like example.com) is just the name of a host. A URL can include much more detail—like the path and query—that changes what you actually get back.
For example:
https://example.com/pricinghttps://example.com/search?q=shoesThe fragment (the part after #) is handled by the browser, not sent to the server in the HTTP request.
Common uses:
#reviews)If you change only the fragment, you often won’t trigger a full page reload.
HTTP is the rules for the request-and-response conversation between a client (browser/app) and a server.
In practice:
Use GET when you’re retrieving something (read-only in intent), like loading a page or fetching data.
Use POST when you’re submitting data to be processed, like creating an account, posting a comment, or starting a checkout.
A practical tip: if the action should be bookmarkable/shareable (like a search), GET is usually the better fit; if it changes server state, is typical.
Status codes summarize the outcome of a request:
When troubleshooting, a often points to a wrong URL or deleted page; a usually means a server-side bug or outage.
A browser needs an IP address to connect to a server. DNS is the system that translates a human name (like example.com) into an IP address.
If a site sometimes “doesn’t resolve,” DNS is a common suspect—especially if it fails on one network/device but works on another.
Caching is when your browser saves copies of previously downloaded resources so repeat visits load faster.
Practical implications:
Servers control a lot of caching behavior via HTTP headers (like cache lifetime and revalidation).
HTTPS encrypts traffic and helps ensure you’re connected to the intended domain, which protects logins, forms, and sensitive data in transit.
It does not guarantee the site is honest or safe. You still need to evaluate:
https) — how to access itexample.com) — which server/products/shoes) — which resource?color=black) — extra parameters#reviews) — a location within a page (browser-side)