Mời bạn thưởng thức Newsletter #76.

TCP vs. UDP vs. gRPC: Chọn giao thức phù hợp cho kiến trúc của bạn

Khi viết một hàm, dữ liệu chỉ di chuyển bên trong bộ nhớ của một máy; nhưng phần mềm hiện đại luôn phải giao tiếp với cơ sở dữ liệu, API hay trình duyệt ở nửa kia thế giới. Giao thức mạng chính là bộ quy tắc quy định định dạng dữ liệu, cách mở và đóng một cuộc hội thoại, cũng như cách xử lý khi có sự cố. Bài viết bắt đầu từ tầng vận chuyển với hai nền móng là TCP và UDP. TCP ưu tiên độ tin cậy: trước khi truyền dữ liệu, hai bên thực hiện bắt tay ba bước (SYN, SYN-ACK, ACK); sau đó giao thức đảm bảo mọi byte đến đủ, đúng thứ tự, tự động gửi lại gói bị mất, đồng thời dùng kiểm soát luồng và kiểm soát tắc nghẽn để không làm quá tải bên nhận. Vì vậy TCP phù hợp khi độ chính xác quan trọng hơn tốc độ, như truy vấn cơ sở dữ liệu, email hay trang web. UDP thì ngược lại: không kết nối, không bắt tay, không đánh số gói tin, gói nào rơi giữa đường là mất luôn; đổi lại độ trễ rất thấp, rất hợp với phát video trực tiếp hay trò chơi trực tuyến, nơi bỏ qua một khung hình còn tốt hơn dừng lại chờ khung cũ.

Ở tầng ứng dụng, HTTP hoạt động theo mô hình yêu cầu – phản hồi, với các phương thức GET, POST, PUT, DELETE, phần header chứa siêu dữ liệu và mã trạng thái như 200 OK hay 404 Not Found. Phiên bản HTTP cũng rất quan trọng: HTTP/1.1 xử lý từng yêu cầu một trên mỗi kết nối nên dễ gặp tắc nghẽn đầu hàng, khi một tài nguyên chậm kéo cả trang chậm theo; HTTP/2 thêm cơ chế ghép kênh để nhiều yêu cầu và phản hồi chạy song song trên cùng một kết nối TCP; còn HTTP/3 bỏ hẳn TCP, chạy trên QUIC (xây dựng trên UDP) để nhanh hơn trên mạng kém ổn định. Cuối cùng, WebSocket khắc phục nhược điểm một chiều của HTTP: kết nối bắt đầu bằng một yêu cầu HTTP xin “nâng cấp”, sau đó được giữ mở để cả máy khách lẫn máy chủ gửi dữ liệu bất cứ lúc nào mà không phải kèm header cho từng tin nhắn. Đây là lựa chọn phù hợp cho ứng dụng chat hay bảng giá chứng khoán cần độ trễ thấp và giao tiếp hai chiều.

Kỹ thuật phần mềm năm 2026

Ben Congdon nhận định tác động lớn nhất của công cụ LLM đến nay là chi phí biên, cả về thời gian lẫn tiền bạc, để tạo ra mã nguồn chất lượng cao đã giảm mạnh. Nhưng viết mã chỉ là một phần của kỹ thuật phần mềm, nên nút thắt sẽ dịch chuyển sang chỗ khác. Theo ông, công việc của kỹ sư gồm xây dựng, phát triển tiếp và vận hành hệ thống phân tán: hai phần đầu đã rẻ và dễ hơn nhờ LLM, còn vận hành gần như chưa bị ảnh hưởng. Thị trường sẽ kỳ vọng kỹ sư khai thác được năng suất từ LLM, và nghề này sẽ trở nên “cơ khí hóa” hơn nhưng cũng năng suất hơn. Từ đó, đầu tư vào hạ tầng tốt càng sinh lời nhanh: chỉ số, ghi nhật ký, cờ tính năng, phát hành, tự động mở rộng, cấu hình… nên dễ tự phục vụ cho cả người lẫn LLM, với giao diện dòng lệnh thân thiện hoặc API sẵn sàng cho MCP. Hạ tầng CI cũng quan trọng hơn khi tác nhân AI viết nhiều mã: có thể cần đầu tư vào kiểm thử thuộc tính và xác minh hình thức, và vì LLM không ngại viết kiểm thử nên không còn lý do để thiếu độ phủ.

Tác giả nhấn mạnh các lớp trừu tượng do con người định hướng: thiếu hướng dẫn rõ ràng, LLM sẽ lấp đầy bằng những giải pháp tham lam chỉ để vượt qua CI, khiến mã ngày càng rối. Ranh giới mô-đun, giao diện thư viện và hợp đồng giữa tầng hạ tầng với tầng sản phẩm trở thành đòn bẩy giữ chất lượng dài hạn. Việc con người rà soát mã cũng thành nút thắt mới: vấn đề phong cách nên giao cho kiểm tra tự động, còn người rà soát tập trung vào những quyết định khó sửa về sau như thay đổi giao diện, mã lưu trữ dữ liệu hay mã quan trọng về hiệu năng. Điều này tạo nghịch lý cho kỹ sư trẻ: phải có “gu rà soát” sớm hơn trong khi ít tự viết mã để rèn trực giác. Độ dao động của ước lượng thời gian dự án cũng tăng, vì chi phí phụ thuộc vào mức độ tác vụ có thể giao cho LLM. Với bài toán tự xây hay mua, SaaS kiểu giao diện mỏng trên CRUD sẽ nghiêng về tự xây ở công ty vừa và lớn, còn hạ tầng hay tuân thủ dạng dịch vụ ít thay đổi vì chi phí vận hành không giảm như chi phí phát triển.

Suy ngẫm về năm 2025

Samuel Albanie nhìn lại năm 2025 qua ba chủ đề với giọng văn hài hước đặc trưng. Đầu tiên là “Thuyết tính toán của mọi thứ”: năm 2021, những thiên kiến kiến trúc thủ công ông dày công thiết kế cho thị giác máy tính tại VGG (Oxford) bị một hệ thống đơn giản nhưng dùng nhiều tính toán huấn luyện trước vượt mặt. Ông tìm lại luận điểm của Hans Moravec từ năm 1976: trí thông minh không phải phép màu của thao tác ký hiệu mà là câu chuyện về sức mạnh xử lý, “với đủ sức mạnh, thứ gì cũng bay được”. Moravec từng viết rằng hiệu năng máy AI cải thiện cùng nhịp với việc nhà nghiên cứu tiếp cận phần cứng nhanh hơn; vì phần cứng sắp ra mắt sẽ khiến các cụm máy năm 2025 trông như máy tính bỏ túi, tác giả tin chúng ta còn xa mới chạm trần. Chủ đề thứ hai là đánh giá mô hình: hệ thống ngày càng tổng quát nhưng công cụ đo vẫn hẹp. Cách tiếp cận của METR đo theo thời lượng tác vụ so với người có kỹ năng, tăng từ khoảng 5 phút đầu năm 2024 lên khoảng 4 giờ 49 phút với Claude Opus 4.5 cuối năm 2025, trong khi phạm vi cần đánh giá đã bùng nổ từ nhận dạng chữ số MNIST sang gần như toàn bộ nền kinh tế.

Chủ đề cuối, “Floreat Britannia”, bàn về nước Anh: lương thực tế tăng 33% mỗi thập kỷ giai đoạn 1970–2007 rồi gần như đứng yên, giá điện công nghiệp cao nhất châu Âu, nhà máy hạt nhân Hinkley Point C tốn 46 tỷ bảng, riêng hệ thống xua cá bằng âm thanh trị giá khoảng 700 triệu bảng chỉ dự kiến cứu 0,083 con cá hồi mỗi năm. Theo tác giả, điểm nghẽn là khả năng phối hợp và ra quyết định; ông lạc quan rằng AI sẽ khiến dự báo xác suất chất lượng cao trở nên rẻ và phổ biến. Tuy vậy, dự báo tốt vô ích nếu văn hóa e ngại sự quyết liệt; lấy hình ảnh Ben Franklin thả diều trong bão và phát minh cột thu lôi, ông kết luận nước Anh cần cả sự táo bạo lẫn thận trọng, cả “cánh diều” và “cột thu lôi”.

8 dự đoán cho năm 2026. Điều gì tiếp theo trong AI?

Philipp Schmid vốn ít khi đưa ra dự đoán, nhưng sau một năm 2025 mang tính bước ngoặt, ông liệt kê tám xu hướng cho năm 2026. Generative UI sẽ cất cánh khi độ trễ và hiệu năng sinh mã đủ tốt để ứng dụng tạo giao diện theo thời gian thực cho từng tác vụ và sở thích của người dùng. Tác nhân cá nhân sẽ chuyển sang chạy trên thiết bị biên, nhờ các mô hình ngôn ngữ nhỏ (SLM) chạy cục bộ trên thiết bị chuyên dụng. Nhà thông minh cuối cùng cũng giữ được lời hứa khi trợ lý hiểu ngữ cảnh và ý định thay vì chỉ lệnh trực tiếp, đồng thời hòa vào các trợ lý như ứng dụng Gemini hay ChatGPT. Khi các bộ benchmark dần bão hòa, phòng thí nghiệm AI chuyển sang cạnh tranh bằng “harness”, tức môi trường phức tạp chứng minh tác nhân thực hiện đáng tin cậy những luồng công việc kéo dài nhiều ngày. Vibe coding sẽ trưởng thành thành kỹ thuật thực thụ: kỹ sư dành 99% thời gian để rà soát, đánh giá, định hình ý tưởng và suy nghĩ, với năng lực cốt lõi là kết nối chi tiết triển khai, chất lượng mã, tốc độ và mục tiêu kinh doanh; biết lập trình trở thành lợi thế riêng.

Ba dự đoán còn lại xoay quanh mạng xã hội: “AI rác” biến nội dung do con người tạo ra thành thị trường cao cấp; mọi bài đăng trên X, Instagram hay LinkedIn sẽ mặc định bị coi là do AI tạo, trừ khi mang chữ ký mật mã theo chuẩn siêu dữ liệu “Human-Signed” (như C2PA cho máy ảnh), nếu không thuật toán sẽ hạ thứ hạng như “nhiễu tổng hợp”; và để chống thư rác từ tác nhân, các nền tảng sẽ tách ra một “web người thật đã xác minh” đòi hỏi xác thực sinh trắc học. Khép lại, tác giả không lo cho vai trò kỹ sư và cho rằng học lập trình vẫn đáng giá, vì hiểu biết kỹ thuật sâu càng quan trọng để điều khiển các hệ thống này. Lời khuyên của ông: xây dựng và học hỏi, tức quan sát kỹ những gì người khác làm, mổ xẻ để hiểu “tại sao” và “như thế nào”, rồi tự làm phiên bản của mình. Tác nhân vẫn sẽ là tâm điểm, với các mẫu thiết kế thành công từ tác nhân lập trình lan sang tác nhân đa dụng, chủ động dự đoán nhu cầu thay vì chỉ chờ lời nhắc.

Bài viết đã được viết lại bởi Claude Code với Opus 5.5 vào ngày 27/09/2026.