BigO là gì?

BigO là ký hiệu đánh giá độ phức tạp của thuật toán hoặc hệ thống, thường dùng để đo:

• Time complexity: thời gian thực hiện theo số lượng dữ liệu (n).

• Space / Capacity complexity: bộ nhớ hay dung lượng cần thiết theo số lượng dữ liệu.

Nói cách khác, BigO giúp chúng ta ước lượng trước cách một thuật toán hoặc hệ thống “tốn” bao nhiêu thời gian và bộ nhớ khi dữ liệu tăng lên.

BigO về thời gian

• Thể hiện số bước cần thực hiện khi dữ liệu tăng.

• Ví dụ minh họa:

  • O(1): Truy cập phần tử mảng theo index. Thời gian không đổi, bất kể dữ liệu lớn hay nhỏ.

  • O(n): Duyệt một mảng dài n phần tử. Thời gian tăng tuyến tính theo số phần tử.

  • O(log n): Tìm kiếm nhị phân trong mảng sắp xếp. Thời gian tăng chậm, giảm dữ liệu đi một nửa mỗi bước.

  • O(n²): Duyệt 2 vòng lồng nhau. Thời gian tăng nhanh, dữ liệu gấp đôi → thời gian tăng gấp 4.

BigO về dung lượng

• Đo bộ nhớ cần thiết để lưu dữ liệu khi thuật toán chạy.

• Ví dụ:

  • O(1): chỉ cần vài biến tạm, không phụ thuộc dữ liệu.

  • O(n): lưu toàn bộ dữ liệu trong bộ nhớ (như copy một mảng).

  • O(n²): dùng ma trận kích thước n×n.

Tại sao quan trọng?

• Đánh giá hiệu năng trước khi triển khai: tránh thuật toán chậm khi dữ liệu lớn.

• Quyết định cách lưu trữ dữ liệu: giảm bộ nhớ, cache hợp lý.

• So sánh thuật toán: chọn thuật toán nhanh hơn hoặc tốn ít bộ nhớ hơn.

Proxy không chỉ giúp tăng tốc, bảo mật và kiểm soát truy cập, mà còn có thể đại diện cho bạn hoặc cho server để xử lý các yêu cầu một cách thông minh.

Proxy là gì?

Proxy là một máy chủ trung gian đứng giữa client và server, giúp chuyển tiếp yêu cầu và phản hồi, đồng thời cung cấp các tính năng như bảo mật, cache, load balancing.

Forward Proxy

Định nghĩa

Forward Proxy là proxy đại diện cho client khi truy cập server bên ngoài. Client gửi request tới proxy, proxy thực hiện request thay client và trả kết quả về.

Vai trò

• Ẩn danh client: server bên ngoài không biết ai gửi request.

• Chặn / kiểm soát truy cập: quản lý website mà người dùng có thể truy cập.

• Cache dữ liệu: giảm băng thông, tăng tốc độ truy cập.

Ví dụ minh họa

• Công ty muốn nhân viên chỉ truy cập được một số website, tất cả request đi qua forward proxy để lọc nội dung.

• Người dùng muốn ẩn IP khi truy cập internet dùng forward proxy để giấu địa chỉ thật.

Use cases

Ẩn danh khi truy cập Internet

• Forward proxy giúp client giấu IP thật khi truy cập website hoặc dịch vụ bên ngoài.

• Ví dụ: người dùng cá nhân muốn truy cập các trang web quốc tế mà không để lộ địa chỉ IP thật.

Kiểm soát và lọc truy cập

• Công ty hoặc trường học dùng forward proxy để quản lý website mà nhân viên hoặc học sinh có thể truy cập.

• Có thể chặn các trang web không phù hợp hoặc giới hạn băng thông.

Cache dữ liệu

• Forward proxy có thể lưu tạm dữ liệu đã truy cập, giảm băng thông và tăng tốc độ cho các lần truy cập tiếp theo.

• Ví dụ: một trang web phổ biến được nhiều người trong công ty truy cập, dữ liệu được cache trên proxy để load nhanh hơn.

Bypass giới hạn địa lý

• Người dùng muốn truy cập nội dung bị hạn chế theo vị trí địa lý có thể dùng forward proxy để giả lập IP từ quốc gia khác.

Ghi lại và giám sát lưu lượng

• Forward proxy giúp theo dõi hoạt động Internet của người dùng để phân tích, báo cáo hoặc đảm bảo tuân thủ chính sách công ty.

Reverse Proxy

Định nghĩa

Reverse Proxy là proxy đại diện cho server khi nhận request từ client. Client không biết server thật nằm ở đâu, chỉ gửi request tới reverse proxy, proxy chuyển tiếp tới server thực và trả kết quả về client.

Vai trò

• Load balancing: phân phối request tới nhiều server để tránh quá tải.

• Bảo mật: ẩn server thật, chặn các truy cập độc hại.

• TLS/SSL termination: xử lý mã hóa để giảm tải cho server backend.

• Cache tĩnh: giảm tải server backend, tăng tốc độ phản hồi.

Ví dụ minh họa

• Website lớn có nhiều server backend, dùng reverse proxy như Nginx hoặc HAProxy để phân phối request và tăng hiệu năng.

• Cloudflare hoạt động như reverse proxy, bảo vệ server khỏi các tấn công DDoS và cache nội dung tĩnh.

Use cases

Load balancing (Cân bằng tải)

• Reverse proxy phân phối request từ client tới nhiều server backend để tránh quá tải, tăng hiệu năng và khả năng chịu lỗi.

• Ví dụ: website lớn có hàng chục server, Nginx hoặc HAProxy làm reverse proxy để phân phối đều request.

Bảo mật và ẩn server thật

• Reverse proxy giúp giấu IP và thông tin của server backend, bảo vệ khỏi các tấn công trực tiếp (DDoS, probing).

• Ví dụ: Cloudflare hoạt động như reverse proxy, lọc các request độc hại trước khi tới server thật.

TLS/SSL Termination

• Reverse proxy có thể xử lý mã hóa SSL/TLS, giảm tải cho server backend.

• Ví dụ: Nginx nhận request HTTPS, giải mã và chuyển tiếp request nội bộ qua HTTP.

Caching nội dung tĩnh

• Reverse proxy có thể lưu tạm các file tĩnh như ảnh, CSS, JS, giúp giảm tải cho server backend và tăng tốc độ phản hồi.

• Ví dụ: Nginx cache trang web phổ biến, khách truy cập lấy nội dung trực tiếp từ proxy.

Compression / Optimization

• Reverse proxy có thể nén dữ liệu, tối ưu hóa hình ảnh trước khi gửi tới client, giúp tiết kiệm băng thông.

Câu trả lời thường nằm ở một thành phần tưởng chừng đơn giản nhưng cực kỳ quan trọng: Message Queue – nơi các tin nhắn được xếp hàng chờ xử lý, giúp các ứng dụng hoạt động trơn tru và đáng tin cậy hơn.

Message Queue là gì?

Message Queue là một hệ thống trung gian cho phép gửi và nhận dữ liệu (message) giữa các ứng dụng hoặc dịch vụ một cách bất đồng bộ.

Nếu các service là người, message queue là bưu điện, nơi gửi thư để người nhận đọc khi rảnh, thay vì phải gặp trực tiếp và trao đổi ngay lập tức.

Tại sao cần Message Queue?

Trong các hệ thống hiện đại, nhiều service cần trao đổi dữ liệu liên tục:

• Nếu gọi trực tiếp (synchronous), service A phải chờ service B trả lời → chậm, dễ bị nghẽn.

• MQ cho phép gửi message và tiếp tục làm việc, service nhận có thể xử lý khi rảnh.

Các vấn đề MQ giải quyết:

• Giảm tải cho hệ thống: không bị “nghẽn” khi nhiều yêu cầu cùng lúc.

• Tăng độ tin cậy: message được lưu lại, nếu service nhận tạm thời down vẫn có thể xử lý sau.

• Tách rời các service: A không cần biết B xử lý ra sao, chỉ cần gửi message.

Cách hoạt động cơ bản

1. Producer (người gửi): Gửi message vào queue.

2. Queue (hàng đợi): Giữ message theo thứ tự, đợi consumer xử lý.

3. Consumer (người nhận): Lấy message từ queue và xử lý.

Ví dụ:

Một website đặt hàng:

• Producer: service xử lý đơn hàng gửi message “đơn hàng mới”.

• Queue: giữ đơn hàng chờ xử lý.

• Consumer: service kho nhận message, cập nhật tồn kho, gửi email xác nhận.

Các loại Message Queue phổ biến

• RabbitMQ: Hỗ trợ nhiều kiểu routing, queue bền vững.

• Kafka: Thường dùng cho streaming, xử lý lượng lớn message, hỗ trợ replay message.

• SQS (AWS): MQ trên cloud, đơn giản, dễ scale.

Lợi ích của Message Queue

• Bất đồng bộ: Producer không cần chờ Consumer.

• Tăng khả năng chịu lỗi: Message được lưu lại nếu Consumer gặp sự cố.

• Dễ mở rộng: Thêm Consumer để tăng throughput.

• Tách rời hệ thống: Service không phụ thuộc trực tiếp vào nhau.

Nhưng caching không phải lúc nào cũng đơn giản—nó đặt ra câu hỏi về dữ liệu luôn tươi mới, làm thế nào để không tải lại database mỗi lần, và cách cân bằng giữa tốc độ và độ chính xác của thông tin.

Caching là gì?

Caching là kỹ thuật lưu trữ tạm thời dữ liệu hoặc kết quả tính toán ở nơi dễ truy cập hơn, để truy xuất nhanh hơn khi cần dùng lại.

Thay vì đi tìm dữ liệu từ nguồn gốc mỗi lần, hệ thống lấy trực tiếp từ “bản sao nhanh” trong cache.

Tại sao cần caching?

• Giảm thời gian truy xuất dữ liệu → ứng dụng phản hồi nhanh hơn.

• Giảm tải cho database hoặc hệ thống backend, đặc biệt khi có nhiều người dùng cùng truy cập dữ liệu giống nhau.

• Giúp cải thiện trải nghiệm người dùng, đặc biệt với dữ liệu đọc nhiều, thay đổi ít.

Các loại caching phổ biến

1. In-memory cache: Lưu trong bộ nhớ RAM của server, truy xuất cực nhanh.

   • Ví dụ: Redis, Memcached

2. Browser cache: Trình duyệt lưu file tĩnh (CSS, JS, hình ảnh) để không phải tải lại từ server.

3. CDN cache: Lưu bản sao dữ liệu tĩnh ở nhiều địa điểm gần người dùng, giảm độ trễ.

Ví dụ minh họa

• Một trang web hiển thị bảng giá sản phẩm từ database. Thay vì truy vấn database mỗi lần người dùng mở trang, hệ thống lưu kết quả truy vấn trong cache 5 phút.

• Khi người dùng khác mở trang trong 5 phút đó, dữ liệu được lấy trực tiếp từ cache → phản hồi ngay lập tức, giảm tải database.

Lưu ý khi dùng cache

• Dữ liệu thay đổi → cần cơ chế hết hạn (TTL) hoặc invalidate cache.

• Không phải dữ liệu nào cũng nên cache, đặc biệt dữ liệu cực kỳ nhạy cảm hoặc thay đổi liên tục.

Cơ sở dữ liệu (Database) là nền móng của mọi hệ thống phần mềm. Nhưng “database” không chỉ là MySQL hay MongoDB — mà là một hệ sinh thái lớn, với nhiều loại kiến trúc khác nhau, tối ưu cho những nhu cầu khác nhau.

Database dùng để làm gì?

• Lưu trữ dữ liệu có cấu trúc hoặc không cấu trúc.

• Cho phép truy vấn nhanh và đáng tin cậy.

• Đảm bảo dữ liệu không mất khi tắt máy.

→ Nó là bộ nhớ dài hạn của hệ thống, khác với RAM.

Phân loại

Có 2 cách phân loại chính: về cấu trúc tổ chức mô hình dữ liệu và về tác vụ hệ thống phải xử lý.

SQL và NoSQL

Đây là cách phân loại dựa trên cấu trúc dữ liệu và cách tổ chức lưu trữ.

• SQL → quan hệ, dạng bảng (relational model)

• NoSQL → phi quan hệ, dạng document/kv/column/graph

SQL

• Cấu trúc: Dữ liệu lưu trong bảng (table), gồm hàng (row) và cột (column).

• Schema: Cứng, phải định nghĩa trước các cột, kiểu dữ liệu.

• Quan hệ: Bảng có thể liên kết nhau bằng khóa chính/khóa ngoại.

• Tính năng nổi bật:

  • ACID (giao dịch an toàn, dữ liệu chính xác)

  • Dễ truy vấn phức tạp bằng SQL

• Ví dụ: MySQL, PostgreSQL, Oracle

• Minh họa:

  • Một bảng SinhVien có cột id, ten, tuoi.

  • Một bảng Diem có cột sinhvien_id, mon, diem.

  • Dùng join để biết sinh viên nào có điểm môn nào.

NoSQL

• Cấu trúc: Không nhất thiết theo bảng, có thể là document, key-value, cột, hoặc graph.

• Schema: Linh hoạt, thêm trường mới không ảnh hưởng dữ liệu cũ.

• Quan hệ: Ít hoặc không dùng join.

• Tính năng nổi bật:

  • Dễ mở rộng ngang (dùng nhiều máy)

  • Hiệu năng cao cho dữ liệu lớn hoặc phi cấu trúc

  • Một số trade-off về tính nhất quán (không ACID 100%)

• Ví dụ: MongoDB (document), Redis (key-value), Cassandra (column)

• Minh họa:

  • Trong MongoDB, một document SinhVien có thể chứa luôn danh sách điểm:

{ “id”: 1, “ten”: “An”, “tuoi”: 20, “diem”: [{”mon”: “Toan”, “diem”: 9}, {”mon”: “Ly”, “diem”: 8}] }

So sánh nhanh

Cấu trúc dữ liệu:

• SQL: Dữ liệu lưu trong bảng cố định, gồm hàng và cột.

• NoSQL: Dữ liệu có thể là document, key-value, cột hoặc graph, không cố định.

Schema:

• SQL: Cứng, phải định nghĩa trước các cột và kiểu dữ liệu.

• NoSQL: Linh hoạt, có thể thêm trường mới dễ dàng mà không ảnh hưởng dữ liệu cũ.

Quan hệ giữa dữ liệu:

• SQL: Có, sử dụng join để liên kết các bảng.

• NoSQL: Ít hoặc không dùng join.

ACID (tính toàn vẹn dữ liệu):

• SQL: Đảm bảo ACID đầy đủ (an toàn, chính xác).

• NoSQL: Không hoàn toàn ACID, một số trade-off để tăng hiệu năng.

Ví dụ hệ quản trị:

• SQL: MySQL, PostgreSQL, Oracle.

• NoSQL: MongoDB, Redis, Cassandra.

Khi nào dùng:

• SQL: Hệ thống giao dịch, dữ liệu quan trọng, cần tính toàn vẹn cao.

• NoSQL: Dữ liệu lớn, web, realtime, dữ liệu phi cấu trúc hoặc semi-structured.

OLTP và OLAP

Đây là cách phân loại dựa trên mục đích sử dụng, tính chất truy vấn, và pattern vận hành.

• OLTP → giao dịch nhỏ, độ trễ thấp

• OLAP → phân tích dữ liệu lớn, throughput cao

OLTP (Online Transaction Processing)

• Mục đích: Xử lý giao dịch hàng ngày, dữ liệu thay đổi liên tục.

• Đặc điểm:

  • Nhiều ghi/đọc nhỏ (insert/update/delete nhanh)

  • Dữ liệu chi tiết, tươi mới

  • Yêu cầu ACID (an toàn, chính xác)

  • Thường là bảng chuẩn hóa (normalized) để tránh dư thừa

• Ví dụ:

  • MySQL lưu đơn hàng, khách hàng, giao dịch ngân hàng

  • Một bảng Orders với OrderID, CustomerID, Amount, Status

• Truy vấn: Nhanh, đơn giản, truy vấn theo hàng, số lượng bản ghi ít mỗi lần

OLAP (Online Analytical Processing)

• Mục đích: Phân tích dữ liệu lớn, tổng hợp thông tin để ra quyết định.

• Đặc điểm:

  • Nhiều đọc lớn, ít ghi (bulk insert)

  • Dữ liệu thường tóm tắt, gộp, không cần tươi mới ngay lập tức

  • Thường dùng bảng dạng cột (columnar) để tính toán nhanh

  • Thiết kế denormalized (dữ liệu lặp để tăng tốc phân tích)

• Ví dụ:

  • ClickHouse lưu dữ liệu bán hàng theo tháng, theo sản phẩm, tổng doanh thu

  • Một bảng SalesSummary với Month, ProductID, TotalAmount

• Truy vấn: Phức tạp, tính tổng, trung bình, group by, trend, báo cáo

So sánh nhanh

Mục đích:

• OLTP: Xử lý giao dịch hàng ngày.

• OLAP: Phân tích dữ liệu, làm báo cáo.

Dữ liệu:

• OLTP: Chi tiết, luôn mới.

• OLAP: Tóm tắt, dữ liệu lịch sử.

Ghi/đọc:

• OLTP: Nhiều ghi/đọc nhỏ, thao tác nhanh.

• OLAP: Ít ghi, nhiều đọc lớn, xử lý nhiều bản ghi cùng lúc.

ACID:

• OLTP: Quan trọng, đảm bảo giao dịch an toàn.

• OLAP: Không bắt buộc 100%, một số trade-off để tăng tốc phân tích.

Thiết kế dữ liệu:

• OLTP: Chuẩn hóa (normalized) để tránh dư thừa.

• OLAP: Denormalized hoặc dạng cột (columnar) để truy vấn nhanh.

Ví dụ cơ sở dữ liệu:

• OLTP: MySQL, PostgreSQL.

• OLAP: ClickHouse, Amazon Redshift.

Truy vấn:

• OLTP: Nhanh, đơn giản, thao tác trên vài bản ghi.

• OLAP: Phức tạp, chậm hơn nhưng tính toán nhanh trên lượng lớn dữ liệu.

Khi nói đến hệ thống phân tán (distributed system), nhiều người dễ hình dung ngay đến các cụm máy chủ lớn, microservices, Kubernetes, sharding, replication… Nhưng để hiểu đúng bản chất, trước tiên ta phải bắt đầu từ điều đơn giản nhất: Single-Node System. Vì distributed system sinh ra để giải quyết những giới hạn của single-node.

Single-Node System – Một máy làm tất cả

Single-node system là mô hình mà toàn bộ ứng dụng của bạn chạy trên một máy duy nhất:
– App backend
– Database
– Storage
– Cronjob
– Cache (có thể là memory)

Tất cả tài nguyên CPU, RAM, Disk của hệ thống đều nằm trên cùng một node.

✔ Ưu điểm

• Đơn giản: triển khai dễ, debug dễ, chi phí thấp.

• Không có distributed complexity: không phải lo network partition, replication lag, consensus, clock drift…

• Phù hợp cho MVP: hầu hết startup bắt đầu bằng single-node.

✔ Hạn chế

• Single Point of Failure: máy chết → hệ thống chết.

• Không scale theo chiều ngang: muốn mạnh hơn chỉ có cách tăng CPU/RAM (vertical scaling).

• Giới hạn tài nguyên: dù nâng cấp đến đâu cũng có ngưỡng (thường là vài trăm GB RAM và vài chục cores).

Single-node giống như một nhà hàng chỉ có một đầu bếp. Nếu khách quá đông → bếp quá tải → phục vụ chậm → bữa ăn bị delay.

Distributed System – Khi một máy không còn đủ nữa

Distributed system là hệ thống chạy trên nhiều node độc lập, giao tiếp qua mạng nhưng phối hợp để hoạt động như một hệ thống duy nhất.

Một distributed system có thể gồm:

• Nhiều backend service

• Nhiều database instance (primary/replica, sharding)

• Caching cluster

• Storage distributed (S3, Ceph…)

• Message queue cluster (Kafka, NATS)

✔ Ưu điểm

• Horizontal scaling: cần thêm sức mạnh → thêm node.

• High availability: một máy chết hệ thống vẫn chạy.

• Throughput lớn: chia tải qua nhiều máy.

• Đáp ứng nhu cầu lớn: hàng triệu user cùng lúc.

Distributed system giống như nhà hàng có nhiều đầu bếp, mỗi người làm một phần → phục vụ được nhiều khách cùng lúc.

✔ Hạn chế

• Phức tạp: phải đối mặt với distributed consensus, network latency, partition, replication consistency…

• Khó debug: lỗi có thể nằm ở bất kỳ node nào.

• Chi phí cao hơn: cả phần cứng lẫn công sức vận hành.

• Không phải bài toán nào cũng cần distributed.

Khi nào Single-Node là đủ?

• MVP, proof-of-concept

• Hệ thống dưới 5–10k users/day

• Workload nhẹ, không cần realtime

• Dữ liệu không quá lớn (<100GB)

• Team nhỏ, không có DevOps chuyên sâu

👉 Thực tế đại đa số các dự án nội bộ doanh nghiệp vẫn chạy single-node rất ổn định.

Khi nào cần chuyển sang Distributed?

Khi single-node chạm ngưỡng:

• CPU/RAM không thể tăng thêm

• Database bị quá tải

• Một node không còn đáng tin cậy

• Cần multi-region

• Cần high availability

• Cần hơn 1 instance để scale

• Delay tăng do tải cao

Hoặc khi sản phẩm phát triển đến mức cần:

• caching cluster

• sharding database

• load balancing

• event-driven architecture

SSL/TLS là “ổ khóa an toàn” giúp dữ liệu trên Internet không bị đọc trộm hoặc sửa đổi.

Giống như:

• Bạn nói chuyện qua điện thoại nhưng đường dây đã được mã hóa, người nghe lén không hiểu được.

• Bạn gửi thư nhưng thư đã được niêm phong, người khác mở ra sẽ bị phát hiện.

👉 SSL/TLS = công nghệ mã hóa giúp thông tin khi truyền qua Internet được an toàn.

Khi truy cập trang web có https:// và biểu tượng ổ khóa, bạn đang dùng SSL/TLS.

Certificate

Certificate (chứng chỉ số) giống như “thẻ căn cước của website”.

Nó dùng để chứng minh:

1. Website đúng là website thật, không phải giả mạo

2. Website sở hữu đúng domain, ví dụ: https://bank.com

3. Website có chìa khóa để mã hóa dữ liệu an toàn

Certificate được cấp bởi tổ chức uy tín (CA – Certificate Authority), tương tự như:

• Thẻ căn cước được cấp bởi Nhà nước

• Bằng lái xe được cấp bởi cơ quan giao thông

👉 Trình duyệt chỉ tin những certificate được “nhà phát hành uy tín” cấp.

SSL/TLS kết hợp Certificate

1. Certificate giúp trình duyệt kiểm tra: “Đây có đúng là website thật không?”

2. sau khi xác minh, trình duyệt và website dùng SSL/TLS để: mã hóa toàn bộ dữ liệu gửi/nhận

👉 Certificate = chứng minh danh tính
👉 SSL/TLS = bảo mật dữ liệu

Chúng giống như:

• Certificate = “thẻ căn cước” để chứng minh bạn là ai

• SSL/TLS = “mã hóa cuộc trò chuyện” để bảo vệ thông tin

Các mô hình xác thực

One-Way TLS (phổ biến nhất)

• Client kiểm tra certificate của server

• Server không kiểm tra client

• Browser → Server: HTTPS

• API Gateway → Backend Service

👉 Dùng cho 99% website.

Mutual TLS (mTLS) — 2 chiều

• Server có certificate

• Client cũng phải có certificate

• Hai bên đều authenticate nhau

Ứng dụng:

• Kết nối microservice trong nội bộ

• Banking, Payment Gateway

• IoT device authenticate (không dùng password)

👉 Bảo mật rất cao, yêu cầu quản lý cert phức tạp.

Qúa trình TLS Handshake

Establish TCP Connection (3-way handshake)

Trong hình:

• Client → SYN

• Server → SYN + ACK

• Client → ACK

SSL/TLS Handshake (TLS 1.2)

ClientHello

Client gửi:

• version TLS hỗ trợ

• các cipher suites hỗ trợ

• random bytes

• SNI (domain truy cập)

ServerHello + Certificate

Server gửi:

• version TLS chọn

• cipher suite chọn

• certificate (public key)

Certificate Verification (Client → Server)

Client kiểm tra:

• CA có hợp lệ không

• domain trong cert có khớp không

• cert còn hạn không

ClientKeyExchange

Client gửi pre-master secret hoặc public key (nếu ECDHE).

Server Finished

Cả hai bên:

• tạo master secret

• sinh symmetric key để mã hóa data

• báo “Finished”

Encrypted Application Data

Sau khi handshake xong, toàn bộ HTTP sẽ được mã hóa:

Client → HTTP GET
Server → HTTP Response

Ví dụ về setup HTTPS cho server

Chuẩn bị domain

HTTPS bắt buộc cần 1 domain hợp lệ.

Bạn cần:

• Một domain: ví dụ myservice.com

• Trỏ DNS về server (A record → IP server)

👉 Nếu chưa trỏ DNS, thì cert không thể verify.

Lấy SSL/TLS certificate

Có 2 loại phổ biến:

Lựa chọn A – Free (Let’s Encrypt)

Dùng certbot, zero-downtime, tự gia hạn.
Dùng cho hầu hết hệ thống.

On Ubuntu:

sudo apt install certbot
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d myservice.com

Lựa chọn B – Certificate trả phí

Bạn mua từ:

• DigiCert

• GlobalSign

• Sectigo

Quy trình:

• Tạo CSR

• Gửi cho CA

• Nhận file .crt + .key + chain file

Cấu hình server chạy HTTPS

Case 1 — Nginx

File cấu hình ví dụ:

server {
    listen 443 ssl;
    server_name myservice.com;

    ssl_certificate /etc/letsencrypt/live/myservice.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myservice.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

Thêm redirect HTTP → HTTPS:

server {
    listen 80;
    server_name myservice.com;
    return 301 https://$host$request_uri;
}

Reload:

sudo nginx -t
sudo systemctl reload nginx

Case 2 — Golang HTTPS native

Golang cho phép chạy HTTPS rất dễ:

File main.go:

package main

import (
    “log”
    “net/http”
)

func main() {
    http.HandleFunc(”/”, func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte(”Hello HTTPS”))
    })

    log.Println(”Listening on :443...”)
    err := http.ListenAndServeTLS(”:443”,
        “server.crt”, // public cert
        “server.key”, // private key
        nil,
    )
    log.Fatal(err)
}

Chạy:

go run main.go

Kiểm tra HTTPS

• Truy cập https://myservice.com

• Kiểm tra padlock (ổ khóa) trong browser

• Kiểm tra certificate với:

openssl s_client -connect myservice.com:443 -servername myservice.com

Gia hạn certificate

Nếu dùng Let’s Encrypt:

sudo certbot renew --dry-run

Let’s Encrypt tự gia hạn qua cron.

Tóm tắt 5 bước đơn giản

1. Có domain → trỏ DNS về server

2. Sinh certificate (Let’s Encrypt / trả phí)

3. Cấu hình HTTPS (Nginx, Golang, Node, v.v.)

4. Redirect HTTP → HTTPS

5. Gia hạn cert (Let’s Encrypt auto)

HTTP/1.1 giống như một người chạy bàn chỉ bưng được một món mỗi lần, nên phải đi tới đi lui rất nhiều.

HTTP/2 giống như một xe đẩy có thể chở nhiều món cùng lúc, nên phục vụ nhanh và ít phải di chuyển hơn.

Vì sao cần hiểu HTTP/1.1 và HTTP/2?

Đa số developer dùng HTTP mỗi ngày nhưng ít khi thật sự nhìn thấy “cách nó chạy bên dưới”. Khi viết API, gọi API, dùng trình duyệt… ta chỉ thấy request và response—nhưng không thấy dòng dữ liệu thực sự di chuyển như thế nào.

Để hiểu vì sao HTTP/2 nhanh hơn HTTP/1.1, vì sao có chuyện Head-of-Line Blocking, vì sao phải có stream, frame, multiplexing…, ta phải đặt chúng vào đúng tầng trong stack mạng: HTTP ở Application Layer, TCP ở Transport Layer.

Tầng HTTP và tầng TCP

HTTP → Application Layer
Đây là nơi bạn viết API, define header, body, method GET/POST…
HTTP chỉ quan tâm tới request là gì và response là gì.

TCP → Transport Layer
Đây là nơi dữ liệu được chia nhỏ, đánh số, gửi từng packet, đảm bảo không mất dữ liệu, đúng thứ tự.

Điểm quan trọng:

HTTP không tự vận chuyển dữ liệu. TCP mới là thứ thực sự “chở” dữ liệu đi.

Hãy tưởng tượng:

• HTTP = hàng hóa

• TCP = xe tải vận chuyển

• Một request/response = một kiện hàng

• TCP chia kiện hàng thành nhiều thùng nhỏ (packet) rồi gửi đi.

HTTP/1.1 hoạt động như thế nào và HOL xảy ra ở đâu?

HTTP/1.1 quy định “1 request tại 1 thời điểm trên 1 TCP connection”

Dù có keep-alive, pipelining thì bản chất là:

• Dữ liệu của request phải đi theo thứ tự.

• Response cũng phải trả về theo thứ tự.

• Nếu request đứng đầu bị chậm → mọi request phía sau đều chờ.

Đây gọi là:

Head-of-Line Blocking (HOL) ở tầng HTTP.

Ví dụ hình tượng:
Bạn đi qua 1 trạm thu phí có 1 làn. Xe đầu tiên bị kẹt → tất cả xe phía sau phải đứng chờ. Đó chính là HTTP/1.1.

HTTP/2 thay đổi điều gì? Multiplexing là gì?

HTTP/2 không thay TCP. HTTP/2 chỉ thay cách tổ chức dữ liệu ở tầng HTTP trước khi đưa xuống TCP.

Cơ chế mới của HTTP/2: Multiplexing qua Stream → Frame

• Một TCP connection duy nhất

• Trong đó có nhiều stream (như nhiều làn đường ảo)

• Mỗi stream gửi nhiều frame nhỏ (gói con)

• Các frame thuộc các stream được trộn lẫn khi gửi, không phải chờ nhau

• Tại phía nhận, HTTP/2 ghép lại frame thành đúng request/response tương ứng.

Tầng TCP vẫn đi tuần tự, nhưng không còn chuyện chờ nhau ở tầng HTTP, vì các request được “trượt qua nhau” ở dạng frame.

Hình dung:
Một làn đường thật (TCP). Trên đó vẽ ra hàng chục “làn ảo” (stream). Xe của mỗi người được chia thành nhiều thùng hàng nhỏ (frame). Các thùng hàng lẫn nhau, đi chung làn nhưng đều có gắn ID → tới nơi lắp lại thành từng kiện riêng.
=> HOL ở tầng HTTP biến mất.

Các tối ưu quan trọng khác của HTTP/2

Ngoài multiplexing, HTTP/2 còn có:

Stream prioritization (ưu tiên luồng)

Bạn có thể nói với server:

• “Luồng này quan trọng, gửi trước.”

• “Luồng kia gửi sau.”

Điều này giúp:

• Tải CSS trước hình ảnh

• Tải thumbnail trước ảnh full HD

• React hydration trước tải analytics

Header Compression (HPACK)

Giảm dung lượng header bằng dictionary + incremental encoding.
Tiết kiệm cực mạnh vì header HTTP thường lặp rất nhiều.

Server Push

Đã bị bỏ ở HTTP/3 nhưng là điểm hay của HTTP/2

Server có thể gửi trước tài nguyên mà client sắp cần, không chờ client request.

Tham khảo

https://viblo.asia/p/http11-va-http2-dau-la-su-khac-biet-YWOZrj27ZQ0

Khi bạn gõ một URL hoặc khi backend gọi một API nội bộ, mọi thứ có vẻ đơn giản: gửi request – nhận response. Nhưng thực tế, đằng sau đó là một chuỗi xử lý phức tạp đi qua hàng loạt lớp mạng, proxy, middleware và logic ứng dụng.

Hiểu rõ HTTP Request Lifecycle không chỉ là kiến thức nền tảng — mà còn giúp bạn:

• Debug chính xác request đang kẹt ở đâu

• Giảm latency và tối ưu hiệu năng

• Xác định đúng lớp chịu trách nhiệm khi xảy ra lỗi hoặc timeout

• Thiết kế hệ thống và microservices chắc chắn hơn

Bài viết này sẽ đi qua toàn bộ vòng đời đó, theo đúng hành trình mà một request thực sự trải qua.

1. Toàn Bộ Hành Trình

Client → DNS → TCP/TLS → Reverse Proxy → HTTP Server → Middleware → Routing → Handler → Business Logic → Response

Dưới đây là mô tả chi tiết từng bước:

Client

Trình duyệt hoặc ứng dụng gửi yêu cầu HTTP bao gồm: method (GET/POST/…), URL, headers, body (nếu có).

DNS

Chuyển hostname (ví dụ: api.example.com) thành địa chỉ IP. Nếu DNS chậm → request bị delay ngay từ bước đầu.

TCP / TLS Handshake

• TCP: Thiết lập kết nối (SYN → SYN/ACK → ACK).

• TLS: Nếu HTTPS, diễn ra thêm handshake để tạo kênh mã hoá.

Reverse Proxy (Nginx / Envoy / HAProxy)

Điểm vào đầu tiên của backend. Proxy có thể xử lý:

• SSL termination (giải mã HTTPS)

• Rate limit

• Load balancing

• Routing cơ bản theo path/host

• Caching

• Logging

Sau đó, request được forward vào service backend thực sự.

HTTP Server (bên trong ứng dụng)

Ví dụ: Go net/http, Node.js Express, Java Spring, Python FastAPI.
Nhiệm vụ:

• Parse request

• Tạo request object

• Điều phối middleware và routing

Middleware

Các lớp chạy trước hoặc sau handler:

• Logging

• Authentication / Authorization

• CORS

• Panic recovery

• Body limit

• Rate limit cấp ứng dụng

Middleware quá nhiều → tăng thời gian xử lý và memory footprint.

Routing

So khớp method + path để chọn đúng handler.
Các framework hiện đại dùng trie-based router để tăng tốc.

Handler (Controller)

Nhận request, validate input, ánh xạ về business logic.

Business Logic

Phần xử lý chính của ứng dụng:

• Query database

• Gọi cache (Redis, Memcached)

• Gọi API nội bộ hoặc bên thứ ba

• Xử lý nghiệp vụ

• Mapping dữ liệu

Đây là nơi quyết định phần lớn performance của hệ thống.

Response

Kết quả được serialize (JSON, protobuf…)
và gửi ngược lại qua cùng kết nối TCP/TLS về client.

2. Các loại Timeout – Request có thể chết ở đâu?

Một trong những lợi ích lớn nhất của việc hiểu lifecycle là biết timeout nằm ở lớp nào.

DNS timeout

Không resolve được hostname.

TCP connect timeout

Không thiết lập được kết nối (server down, firewall chặn).

TLS handshake timeout

Không bắt tay TLS xong.

Reverse proxy timeout

• upstream timeout

• idle timeout

• read/write timeout

(Ví dụ: upstream timed out trong Nginx)

Application timeout

Framework HTTP server giới hạn thời gian xử lý.

Context timeout trong handler

Backend tự cancel xử lý: context deadline exceeded

Database timeout

Query quá lâu → ảnh hưởng cả request.

Một request có thể chết ở rất nhiều điểm — hiểu đúng lớp là chìa khóa để debug.

3. Các điểm tối ưu trong toàn bộ lifecycle

DNS

• Bật DNS caching

• Sử dụng DNS resolver nhanh (Cloudflare 1.1.1.1)

TCP/TLS

• Giữ kết nối lâu hơn bằng Keep-alive

• Bật HTTP/2 hoặc HTTP/3

• TLS session resumption để giảm handshake

Reverse Proxy

• Tối ưu buffer

• Bật gzip/brotli

• Tinh chỉnh timeout hợp lý

• Cache response tĩnh

Middleware

• Chỉ giữ những middleware cần thiết

• Không làm DB/API call bên trong middleware

Routing

• Dùng router hiệu quả (Gin, Fiber, FastAPI…)

• Tránh dynamic regex routing nặng

Business Logic

• Tối ưu query DB (index, limit, tránh N+1)

• Cache thông minh

• Giảm external call hoặc dùng bulk request

• Hạn chế serialize object khổng lồ

Response

• Tránh response quá nặng

• Dùng json encoder hiệu quả (ví dụ: jsoniter cho Go)

4. Sơ đồ tổng quan

Client
  ↓
DNS
  ↓
TCP Handshake
  ↓
TLS Handshake (HTTPS)
  ↓
Reverse Proxy (Nginx/Envoy)
  ↓
Application HTTP Server
  ↓
Middleware Chain
  ↓
Router
  ↓
Handler / Controller
  ↓
Business Logic
  ↓
Response → Client

5. Kết luận

Một request HTTP không đơn giản chỉ là “gọi API”. Nó đi qua rất nhiều lớp — từ DNS, TCP, TLS đến proxy, middleware và business logic.
Hiểu rõ từng lớp giúp bạn:

• Debug nhanh hơn

• Thiết kế hệ thống chắc chắn hơn

• Tối ưu hiệu năng đúng chỗ

• Tránh timeout và bottleneck khó đoán

TCP cung cấp:

• Connection-oriented – phải bắt tay (3-way handshake) trước khi gửi.

• Reliable – bảo đảm dữ liệu đến đủ, đúng thứ tự.

• Flow control / Congestion control – tự điều chỉnh tốc độ gửi để tránh nghẽn mạng.

• Retransmission – gói mất sẽ được gửi lại.

👉 Thích hợp cho: web, API, database, file transfer, email—nơi dữ liệu phải chính xác tuyệt đối.

UDP (User Datagram Protocol)

UDP có:

• Connectionless – gửi thẳng, không cần handshake.

• Không đảm bảo – mất gói, trùng gói, sai thứ tự đều có thể xảy ra.

• Không kiểm soát dòng / tắc nghẽn – tốc độ gửi tuỳ ứng dụng.

• Độ trễ rất thấp – vì không tốn chi phí kiểm tra trạng thái.

👉 Thích hợp cho: video call, live stream, game real-time, DNS, IoT—nơi quan trọng tốc độ hơn độ chính xác.

Kiến trúc máy tính là gì?

Kiến trúc máy tính là cách mà một máy tính được tổ chức để:

• Nhận lệnh

• Xử lý

• Lưu trữ

• Giao tiếp với thiết bị bên ngoài

4 thành phần cốt lõi

CPU (Bộ xử lý trung tâm)

• Thực thi câu lệnh

• Gồm:

  • ALU: xử lý tính toán

  • Control Unit: điều khiển

  • Registers: bộ nhớ siêu nhanh trong CPU

CPU là bộ não

Memory (Bộ nhớ)

Thứ tự từ nhanh → chậm:

1. Register

2. Cache (L1, L2, L3)

3. RAM

4. SSD / HDD

Càng nhanh thì càng nhỏ & đắt

Storage (Lưu trữ)

• HDD, SSD

• Lưu dữ liệu lâu dài

• Chậm hơn RAM rất nhiều

I/O (Input / Output)

• Bàn phím, chuột, mạng, ổ đĩa

• Giao tiếp giữa máy và thế giới bên ngoài

Chu trình CPU xử lý 1 lệnh

Fetch → Decode → Execute

1. Fetch: lấy lệnh từ RAM

2. Decode: giải mã lệnh

3. Execute: thực thi

Chu trình này lặp lại hàng tỷ lần mỗi giây.

Process & Thread trong kiến trúc

• Process:

  • Có bộ nhớ riêng

  • Chạy độc lập

• Thread:

  • Nằm trong process

  • Dùng chung bộ nhớ

Backend server thường:

• 1 service = 1 process

• Mỗi request = 1 thread / goroutine

Một chương trình hoạt động như thế nào?

Giả sử chúng ta đã xây dựng xong một chương trình viết bằng Golang, vậy để chương trình này chạy, chúng sẽ trải qua những bước gì? Hãy cùng tìm hiểu.

Từ chương trình Go → CPU thực thi: toàn bộ quá trình

Giả sử bạn có file: main.go, và bạn đã build xong binary với: go build

Bây giờ, để chương trình Go chạy, máy tính sẽ trải qua 5 giai đoạn tương ứng với các thành phần trong kiến trúc máy tính.

Ổ đĩa (SSD/HDD) → Lưu binary

Sau khi build, bạn có file: ./myapp

Nó nằm trong ổ đĩa, giống như tài liệu đang nằm trong kho. Lúc này chương trình chưa được chạy, chưa ở RAM, chưa dùng CPU.

OS nhận lệnh chạy chương trình → Tạo Process mới

Khi bạn chạy: ./myapp. OS (Linux/Windows) vào cuộc.

OS thực hiện:

1. Tạo một Process

2. Cấp cho process này:

   • vùng RAM riêng

   • stack và heap

   • danh sách file descriptor

   • quyền truy cập hệ thống

Đây là lúc chương trình “được sinh ra” trong hệ thống.

OS tải binary từ ổ đĩa → RAM

OS đọc file ./myapp từ SSD/HDD và copy vào RAM.

• RAM nhanh hơn ổ đĩa hàng ngàn lần

• CPU chỉ có thể lấy lệnh từ RAM, không thể đọc trực tiếp từ ổ đĩa

➡️ Đây là bước: Load → Decode → Prepare

CPU bắt đầu thực thi → Go Runtime khởi động trước

Khi chương trình đã nằm trong RAM, CPU bắt đầu chạy. Nhưng CPU không chạy main() ngay. Nó chạy Go Runtime trước, vì Go binary luôn mang theo runtime nhẹ.

Go runtime sẽ:

• khởi tạo garbage collector

• tạo scheduler cho goroutine (M:N)

• set số lượng OS threads (GOMAXPROCS)

• khởi tạo bộ cấp phát bộ nhớ (allocator)

• chuẩn bị network poller

➡️ Sau khi runtime đủ điều kiện → gọi vào hàm main.main()

Chương trình Go chạy → Tương tác với OS, CPU, RAM

Từ đây chương trình hoạt động như sau:

Khi chạy logic trong Go: CPU thực thi từng instruction trong RAM.

Khi bạn tạo goroutine: Go scheduler sẽ:

• gom hàng nghìn goroutine

• phân phối lên một vài OS thread

• chuyển đổi cực nhanh mà không cần OS can thiệp

Khi bạn đọc file, gọi API, sleep…: Go runtime dùng system call để nhờ OS làm giúp.

Ví dụ: fmt.Println(”Hello”)

Flow: Go fmt → Go runtime → syscall write → OS → stdout

Góc nhìn tổng thể – liên kết với kiến trúc máy tính

Dưới đây là sơ đồ chính xác quá trình:

(1) Go Code (.go files)
        ↓
go build → compiler → binary (machine code)
        ↓
(2) Binary nằm trong ổ đĩa (SSD/HDD)
        ↓
(3) OS tạo Process → cấp RAM/Thread
        ↓
(4) OS load binary vào RAM
        ↓
(5) CPU bắt đầu chạy → Go runtime khởi động
        ↓
(6) main() chạy
        ↓
(7) Chương trình tương tác:
      - CPU: chạy lệnh
      - RAM: lưu dữ liệu
      - OS: syscall (file, network, socket)
      - hardware: network card, disk, GPU

Tóm lại

Golang build thành binary, OS nạp binary vào RAM, CPU chạy binary với sự hỗ trợ của Go runtime, và mọi I/O đều qua OS.