Giao tiếp Socket

1. Tổng quan

A. Định nghĩa

Socket là điểm cuối (Endpoint) dùng cho giao tiếp giữa các tiến trình qua mạng, được định danh bằng tổ hợp địa chỉ IP và số cổng. Giao tiếp socket là cách một ứng dụng gửi và nhận dữ liệu thông qua socket này; đó là phần mở rộng ra mạng của giao tiếp giữa các tiến trình (IPC), do hệ điều hành cung cấp bằng cách bọc ngăn xếp TCP/IP trong một API chuẩn.

Điểm cốt lõi để hiểu socket là "một cửa sổ trừu tượng để ứng dụng xử lý một mạng phức tạp". Hoạt động bên trong của TCP/IP (phân mảnh và ghép lại gói tin, định tuyến, bảo đảm thứ tự, truyền lại, điều khiển luồng, điều khiển tắc nghẽn) cực kỳ phức tạp, nhưng nhà phát triển có thể giao tiếp mà không cần biết sự phức tạp này miễn là biết giao diện chuẩn gồm socket(), bind(), connect(), send() và recv(). Đây là sức mạnh của trừu tượng hóa, giống như dùng điện thoại mà không cần biết mạng chuyển mạch hoạt động bên trong ra sao.

Socket định danh đối tác giao tiếp bằng hai tọa độ. Địa chỉ IP chỉ định "máy tính (host) nào trên Internet", còn số cổng chỉ định "chương trình (tiến trình) nào trên máy tính đó". Ví dụ, máy chủ Web thường mở socket trên cổng 80 (HTTP) và 443 (HTTPS) để chờ kết nối của client. IP:cổng thường được ví như "địa chỉ tòa nhà:số phòng", và trong giao tiếp TCP, một kết nối được định danh duy nhất bằng bộ 5 phần tử (5-tuple) gồm (IP nguồn, cổng nguồn, IP đích, cổng đích, giao thức). Nhờ khái niệm 5-tuple này, một máy chủ có thể phân biệt và xử lý đồng thời hàng chục nghìn kết nối client ngay cả trên cùng cổng 80.

B. Bối cảnh ra đời và sự cần thiết

Nguồn gốc của socket nằm ở việc BSD Unix đưa ra API Berkeley Socket cho lập trình mạng vào đầu thập niên 1980. Trước đó, mã giao tiếp phải viết lại cho từng phần cứng và giao thức mạng, nhưng bằng cách trừu tượng hóa giao tiếp mạng theo mô hình mô tả (descriptor) thống nhất tương tự nhập/xuất tệp (read/write), socket đã giúp phát triển ứng dụng mạng có tính khả chuyển. Để các chương trình trên những thiết bị khác nhau giao tiếp, cần một phương pháp chuẩn để ① định danh đối tác, ② trao đổi dữ liệu ổn định, và ③ hoạt động bất kể hệ điều hành hay ngôn ngữ; socket đã trở thành tiêu chuẩn trên thực tế (de facto standard) đáp ứng cả ba yêu cầu này. Ngày nay gần như mọi ứng dụng mạng—Web, phần mềm nhắn tin, trò chơi, IoT, phát trực tuyến—đều chạy trên socket.

C. Đặc điểm

Giao tiếp socket là hai chiều (bidirectional), và với socket hướng kết nối, một khi kết nối được thiết lập thì nó giữ trạng thái (stateful) cho đến khi được đóng một cách tường minh. Ngoài ra, vì nhân hệ điều hành đảm nhận việc đệm, truyền lại và điều khiển luồng, nên tầng ứng dụng có thể chỉ tập trung vào ý nghĩa của dữ liệu. Mặt khác, dưới lớp trừu tượng này, đặc tính của giao thức tầng vận chuyển (TCP/UDP) vẫn lộ ra nguyên vẹn, nên nhà phát triển phải tự chịu trách nhiệm về đánh đổi giữa độ tin cậy và hiệu năng tùy theo loại socket được chọn.

2. Cấu trúc socket và hệ thống định danh

flowchart TB
  subgraph APP["Tầng ứng dụng (Application)"]
    A1["Ứng dụng"]
  end
  subgraph OS["Nhân hệ điều hành (OS Kernel)"]
    S["Socket (Socket Descriptor)"]
    SB["Bộ đệm gửi / Bộ đệm nhận"]
    TCP["Tầng vận chuyển (TCP / UDP)"]
    IP["Tầng mạng (IP)"]
  end
  NIC["NIC (Tầng vật lý)"]
  A1 -->|"socket() / send() / recv()"| S
  S --> SB --> TCP --> IP --> NIC
  NIC -->|"mạng"| NET(("Internet"))
  style S fill:#e8f0fe,stroke:#2f6fed

Socket là mặt ranh giới nằm giữa ứng dụng và ngăn xếp mạng của nhân hệ điều hành. Khi ứng dụng gọi socket(), nhân tạo ra các cấu trúc dữ liệu cần thiết cho giao tiếp và trả về một số nguyên gọi là bộ mô tả socket (một loại bộ mô tả tệp). Từ đó chương trình xử lý giao tiếp mạng như một tệp bằng số nguyên duy nhất này. Đây là kết quả của việc mở rộng triết lý "mọi thứ đều là tệp" của họ Unix ra tới mạng, và nhờ sự thống nhất này, các hàm ghép kênh như select/poll có thể đối xử với tệp và socket như nhau.

Việc bộ mô tả socket dùng chung một nguồn tài nguyên với bộ mô tả tệp thể hiện thành một ràng buộc cụ thể trong thực tế. Trên Linux, số bộ mô tả một tiến trình có thể mở đồng thời thường được đặt mặc định là 1024 (ulimit -n), nên nếu không nâng giá trị này, accept() sẽ thất bại với lỗi EMFILE ngay khi số kết nối đồng thời vượt 1024. Do đó, máy chủ nhiều kết nối phải nâng các giới hạn nhân như ulimit và fs.file-max lên hàng trăm nghìn và giám sát rò rỉ kết nối (socket không đóng). Điều này cho thấy socket không chỉ là một khái niệm mà là một thực thể gắn trực tiếp với quản lý tài nguyên của hệ điều hành.

Điều đặc biệt quan trọng trong hệ thống định danh socket là sự tồn tại của bộ đệm gửi và bộ đệm nhận. Việc send() trả về không có nghĩa dữ liệu đã tới đối tác, mà chỉ mới được sao chép vào bộ đệm gửi của nhân, còn việc truyền, truyền lại và bảo đảm thứ tự thực tế do phần cài đặt TCP của nhân thực hiện bất đồng bộ. Vì vậy, lập trình socket phải luôn tính đến "ghi một phần (partial write)" và "đọc một phần (partial read)". Ví dụ, dù bạn send() 10KB thì tùy tình trạng bộ đệm có thể chỉ 4KB được xử lý, nên ứng dụng phải viết một vòng lặp kiểm tra giá trị trả về và lặp lại việc gửi. Bỏ qua điểm này sẽ gây ra lỗi trông giống như mất dữ liệu trong truyền dung lượng lớn.

Thành phần	Vai trò	Hàm ý thực tiễn
Bộ mô tả socket	Số nguyên trỏ tới một điểm cuối giao tiếp	Số có thể mở mỗi tiến trình (ulimit -n) quyết định trần kết nối đồng thời
Địa chỉ IP	Định danh host (máy tính)	Cần chọn địa chỉ ràng buộc trong môi trường NAT/nhiều giao diện
Số cổng (0~65535)	Định danh tiến trình (dịch vụ)	0~1023 là cổng well-known (cần đặc quyền)
Bộ đệm gửi/nhận	Vùng lưu tạm dữ liệu của nhân	Kích thước bộ đệm (SO_RCVBUF v.v.) ảnh hưởng thông lượng
5-tuple	Định danh duy nhất của một kết nối	Cơ sở để xử lý đồng thời nhiều kết nối trên một cổng

3. Quy trình và các loại giao tiếp socket

sequenceDiagram
  participant C as Client
  participant S as Máy chủ
  Note over S: socket() → bind() → listen()
  S->>S: chờ kết nối tại accept() (blocking)
  C->>C: socket()
  C->>S: connect() (TCP 3-way handshake)
  S-->>C: accept() trả về (tạo socket kết nối)
  loop Trao đổi dữ liệu
    C->>S: send() / recv()
    S->>C: send() / recv()
  end
  C->>S: close() (4-way handshake)
  S->>S: close()

Quy trình giao tiếp socket TCP gồm bốn giai đoạn: chuẩn bị máy chủ → thiết lập kết nối → trao đổi dữ liệu → kết thúc. Máy chủ trước tiên tạo socket bằng socket(), ràng buộc IP và cổng của mình bằng bind(), chuyển sang trạng thái có thể nhận yêu cầu kết nối (tạo hàng đợi chờ) bằng listen(), và chờ kết nối của client tại accept(). Một điểm thiết kế quan trọng ở đây là accept() trả về một socket kết nối mới, riêng biệt. Nghĩa là socket listen vẫn là "cửa tiếp nhận" các kết nối, còn việc giao tiếp dữ liệu thực tế do một socket kết nối được tạo mới cho từng client đảm nhận. Cấu trúc này là cơ sở để một máy chủ phục vụ đồng thời nhiều client.

Client yêu cầu kết nối tới máy chủ bằng connect() sau socket(), và trong quá trình này diễn ra 3-way handshake (SYN → SYN/ACK → ACK) của TCP. Khi kết nối được thiết lập, hai bên trao đổi dữ liệu bằng send()/recv(), và khi giao tiếp kết thúc, close() dọn dẹp kết nối qua 4-way handshake (trao đổi FIN/ACK). Lúc này ở phía máy chủ còn lại trạng thái TIME_WAIT trong một khoảng thời gian (thường 2*MSL), đây là cơ chế an toàn để xử lý gói tin đến trễ; tuy nhiên, ở máy chủ tạo một lượng lớn kết nối ngắn, các socket TIME_WAIT có thể tích tụ và gây cạn kiệt cổng. Trong thực tế điều này được giảm nhẹ bằng tùy chọn SO_REUSEADDR hoặc tái sử dụng kết nối (keep-alive).

Socket được chia thành hai loại tùy theo giao thức vận chuyển sử dụng. Socket luồng (TCP) thiết lập kết nối, bảo đảm thứ tự và độ tin cậy của dữ liệu, và cung cấp một luồng byte không có ranh giới. Vì tính luồng này, ranh giới thông điệp mà ứng dụng gửi không được bảo toàn, nên nhiều thông điệp có thể đến dính liền nhau (hoặc bị tách ra). Để xử lý điều này, cần một quy ước tự đóng khung (framing) riêng như tiền tố độ dài hoặc ký tự phân tách. Socket datagram (UDP) gửi từng thông điệp một cách nhanh chóng mà không có kết nối và không bảo đảm thứ tự hay việc đến nơi, nhưng ranh giới thông điệp thì được bảo toàn.

Cách hoạt động của socket còn có một trục quan trọng khác: sự phân biệt giữa socket chặn (blocking), dừng luồng cho đến khi dữ liệu tới (như recv()), và socket không chặn (non-blocking), trả về ngay và chỉ báo tình trạng sẵn sàng. Cách chặn cho mã trực quan nhưng chiếm một luồng cho mỗi kết nối nên khả năng mở rộng kém; cách không chặn có thể xử lý một lượng lớn kết nối bằng ít luồng khi kết hợp với vòng lặp sự kiện, nhưng quản lý trạng thái trở nên phức tạp. Lựa chọn này gắn trực tiếp với mô hình I/O của các máy chủ quy mô lớn bàn ở phần sau. Ngoài ra, các tùy chọn socket như SO_KEEPALIVE (kiểm tra sự tồn tại của kết nối nhàn rỗi), TCP_NODELAY (tắt thuật toán Nagle để loại bỏ độ trễ với dữ liệu nhỏ) và SO_REUSEADDR (tái sử dụng địa chỉ) cho phép tinh chỉnh độ trễ, thông lượng và mức dùng tài nguyên ngay trên cùng một API socket. Ví dụ, máy chủ trò chơi thời gian thực bật TCP_NODELAY để ngăn các gói nhỏ bị gom trong bộ đệm rồi gửi trễ.

Loại	Giao thức	Đặc điểm	Ứng dụng tiêu biểu
Socket luồng	TCP	Hướng kết nối, bảo đảm độ tin cậy/thứ tự, luồng byte	Web/truyền tệp/DB/nhắn tin
Socket datagram	UDP	Không kết nối, nhanh nhưng không tin cậy, bảo toàn ranh giới thông điệp	Video thời gian thực/trò chơi/DNS/VoIP
Socket RAW	IP/ICMP v.v.	Truy cập trực tiếp các tầng thấp hơn	ping/traceroute/công cụ bảo mật

4. Socket TCP/UDP và WebSocket — So sánh và trường hợp

Nếu socket TCP là giao tiếp mức thấp xử lý trực tiếp tầng vận chuyển, thì WebSocket là công nghệ tầng cao hơn cho môi trường trình duyệt Web. Vì trình duyệt không thể mở socket TCP tùy ý do lý do bảo mật và chính sách, WebSocket (RFC 6455) ra đời như tiêu chuẩn cho giao tiếp hai chiều thời gian thực. WebSocket bắt đầu bằng một yêu cầu HTTP GET thông thường, rồi chuyển giao thức (bắt tay) bằng header Upgrade: websocket, sau đó máy chủ và client tự do trao đổi thông điệp theo khung (full-duplex) trên một kết nối bền vững duy nhất (cùng kết nối TCP). Nhờ vậy, "server push", trong đó máy chủ gửi dữ liệu tới client trước, trở nên khả thi, hiện thực hóa các dịch vụ Web thời gian thực như trò chuyện, thông báo thời gian thực, giá cổ phiếu và biên tập cộng tác (kiểu Google Docs).

So sánh bằng các trường hợp cụ thể: trò chơi trực tuyến cảm nhận được cả độ trễ vài chục ms nên thường dùng cấu trúc lai gửi dữ liệu vị trí/chuyển động qua UDP (bù một phần mất mát bằng gói tiếp theo) và xử lý dữ liệu quan trọng về độ chính xác như thanh toán và giao dịch vật phẩm qua TCP. Hội nghị truyền hình (WebRTC) cũng tách media trên nền UDP (SRTP) và tín hiệu (signaling) trên TCP/WebSocket vì tín hiệu cần độ tin cậy. Bảng điều khiển giá chứng khoán cần máy chủ đẩy hàng nghìn cập nhật giá mỗi giây, nên WebSocket giảm mạnh độ trễ và tải máy chủ so với polling. Như vậy, độ nhạy trễ và yêu cầu độ chính xác của dữ liệu chi phối việc chọn giao thức.

Phân loại	Socket TCP	WebSocket
Tầng	Trực tiếp tầng vận chuyển (TCP)	Tầng ứng dụng (nâng cấp trên HTTP)
Kết nối	socket→connect→3-way handshake	Upgrade sau bắt tay HTTP
Giao tiếp	Luồng byte hai chiều	Hai chiều full-duplex (theo khung)
Môi trường	Máy chủ/ứng dụng gốc	Mọi lĩnh vực kể cả trình duyệt Web
Đóng khung	Ứng dụng tự cài đặt	Giao thức cung cấp khung
Công dụng	Ứng dụng mạng nói chung	Web thời gian thực (trò chuyện/thông báo/giá)

5. So sánh giao tiếp socket và giao tiếp HTTP

Giao tiếp socket và HTTP khác nhau về cơ bản trong cách duy trì kết nối. HTTP là cách tiếp cận thiên về phi trạng thái (Stateless) hoàn tất xử lý sau một yêu cầu-phản hồi, nên về nguyên tắc máy chủ không thể nói với client trước. Khi cần thời gian thực, nó dựa vào polling hoặc long polling, trong đó client lặp lại yêu cầu, điều này kém hiệu quả vì gây ra yêu cầu thừa, phụ phí header và độ trễ. Dù vậy, HTTP cũng chạy trên socket TCP ở bên trong, và keep-alive của HTTP/1.1 cùng ghép kênh của HTTP/2 đã giảm phụ phí này bằng cách tái sử dụng kết nối. Khác biệt cốt lõi là giao tiếp socket (đặc biệt WebSocket) hỗ trợ tự nhiên giao tiếp hai chiều, thời gian thực bằng cách giữ chính kết nối luôn sống.

Trong thực tế, các giải pháp trung gian giữa ba lựa chọn cũng được dùng tích cực. Nếu máy chủ chỉ cần đẩy một chiều tới client, SSE (Server-Sent Events) hoạt động tiết kiệm trên HTTP; nếu cần hai chiều thực sự, độ trễ thấp thì chọn WebSocket; còn yêu cầu-phản hồi đơn giản thì chọn REST (HTTP). Phán đoán này phải cân nhắc không chỉ hiệu năng mà cả khả năng đi qua tường lửa/proxy và độ phức tạp của xử lý tái kết nối và xác thực.

Về mặt định lượng, khác biệt là rõ ràng. Ví dụ, cung cấp dữ liệu cập nhật mỗi giây cho 10.000 người bằng polling sẽ sinh ra 10.000 yêu cầu HTTP mỗi giây, với vài trăm byte header lặp lại mỗi yêu cầu; ngược lại, WebSocket chỉ đẩy một khung vài byte khi cần sau một lần bắt tay ban đầu, cắt giảm tải mạng và máy chủ hàng chục lần trở lên. Ngược lại, với thông tin đơn giản chỉ được truy vấn vài lần một ngày, chi phí duy trì kết nối bền vững lại là lãng phí, nên yêu cầu-phản hồi HTTP mới là đáp án đúng. Nói cách khác, điều cốt lõi không phải "cái nào ưu việt hơn" mà là khớp với đặc tính khối lượng công việc gồm "tần suất cập nhật, tính hai chiều và số kết nối".

Phân loại	Giao tiếp socket (WebSocket)	Giao tiếp HTTP
Kết nối	Kết nối bền vững (giữ trạng thái)	Kết thúc sau yêu cầu-phản hồi (phi trạng thái)
Hướng	Hai chiều (có thể server push)	Một chiều (client khởi tạo)
Tính thời gian thực	Cao	Thấp (cần polling)
Phụ phí	Khung tối thiểu sau bắt tay ban đầu	Header lặp lại ở mọi yêu cầu
Công dụng	Thời gian thực/hai chiều	Tài liệu Web/REST API

6. Chuyên sâu: Dịch vụ thời gian thực quy mô lớn và xử lý socket hiệu năng cao

Ở các dịch vụ thời gian thực quy mô lớn, thách thức thực sự của socket là làm sao duy trì và xử lý một lượng lớn kết nối đồng thời một cách hiệu quả. Điều này được hình thức hóa thành bài toán C10K kinh điển (bài toán một máy chủ gánh 10.000 kết nối đồng thời), và ngày nay được bàn tới tận mức C10M (mười triệu). Mô hình "một luồng/tiến trình cho mỗi kết nối" ban đầu có giới hạn về mở rộng vì bộ nhớ và chi phí chuyển ngữ cảnh tăng tuyến tính theo số kết nối. Cái giải quyết điều này là ghép kênh I/O hướng sự kiện (I/O multiplexing). epoll của Linux, kqueue của BSD/macOS, và IOCP của Windows cho phép một luồng được nhân thông báo hiệu quả về thay đổi trạng thái trên hàng chục nghìn socket và xử lý chúng. Chính mô hình vòng lặp sự kiện này là bí quyết để Nginx, Node.js và Redis gánh lượng kết nối lớn bằng ít luồng. Gần đây, io_uring (5.1+) của Linux là giao diện I/O bất đồng bộ giảm cả phụ phí lời gọi hệ thống, và được áp dụng ngày càng nhiều ở các máy chủ, proxy hiệu năng cao.

Sức mạnh của mô hình vòng lặp sự kiện bộc lộ rõ nhất ở mức dùng tài nguyên. Mô hình dùng một luồng cho mỗi kết nối tiêu tốn vài trăm KB đến vài MB mỗi kết nối chỉ riêng ngăn xếp luồng, nên 10.000 kết nối cần vài GB bộ nhớ; còn vòng lặp sự kiện quản lý một kết nối chỉ bằng một bộ mô tả socket và một đối tượng trạng thái nhỏ, gánh nhiều kết nối hơn hẳn trên cùng phần cứng. Tuy nhiên, vì vòng lặp sự kiện sẽ dừng toàn bộ nếu một callback chiếm luồng đơn quá lâu, nên phải kèm theo thiết kế tách công việc nặng CPU sang các luồng/tiến trình worker. Như vậy, việc chọn mô hình xử lý socket quyết định luôn cơ cấu chi phí và đặc tính sự cố của máy chủ.

Khi mở rộng theo chiều ngang (scale-out) một dịch vụ dựa trên WebSocket ra nhiều máy chủ, một vấn đề mới nảy sinh. Vì kết nối bền vững bị gắn cố định vào một thực thể máy chủ cụ thể (sticky session), việc truyền một thông điệp mà máy chủ B nhận được tới người dùng đang kết nối với máy chủ A đòi hỏi lan truyền thông điệp giữa các máy chủ. Trong thực tế, một message broker như Redis Pub/Sub hoặc Kafka được đặt làm mặt phẳng nền (backplane) để phát tỏa sự kiện giữa các thực thể, và các kết nối được phân bổ tại bộ cân bằng tải bằng sticky session hoặc băm nhất quán. Ngoài ra, ping/pong (heartbeat) định kỳ được gửi để kết nối nhàn rỗi không bị tường lửa/NAT ngắt, và kết nối bị ngắt được tái kết nối bằng lùi lũy thừa (exponential backoff)—việc quản lý vòng đời kết nối như vậy chi phối chất lượng dịch vụ. Các phần mềm nhắn tin quy mô lớn như KakaoTalk, Slack và Discord là những trường hợp tiêu biểu của kiến trúc này.

Về mặt bảo mật, phải áp dụng TLS cho giao tiếp socket (TLS cho TCP, wss:// cho WebSocket) để chống nghe lén và giả mạo, và phải ngăn kết nối trái phép cùng CSWSH (Cross-Site WebSocket Hijacking) qua xác thực Origin và xác thực dựa trên token (JWT, v.v.) trong lúc bắt tay WebSocket. Ngoài ra, hãy chuẩn bị cho DoS kiểu cạn kiệt tài nguyên bằng trần tài nguyên mỗi kết nối, giới hạn kích thước thông điệp và giới hạn tốc độ (rate limiting).

Gần đây, chính địa hình của giao tiếp socket đang thay đổi. QUIC (nền tảng vận chuyển của HTTP/3) cài đặt lại kết nối, độ tin cậy và mã hóa (tích hợp sẵn TLS 1.3) trên nền socket UDP, gộp 3-way handshake của TCP và bắt tay TLS thành một, và hỗ trợ di trú kết nối (giữ kết nối sống ngay cả khi mạng chuyển đổi). Điều này phá vỡ tiền đề lâu đời rằng "độ tin cậy nhất định phải là TCP" và dịch chuyển trọng tâm phát triển ứng dụng sang việc dùng socket UDP cho cả thời gian thực lẫn độ tin cậy. Đồng thời, khi môi trường serverless và edge lan rộng, một mẫu hình đang gia tăng, trong đó thay vì WebSocket truyền thống vốn giả định kết nối bền vững kéo dài, phía máy chủ giảm thiểu trạng thái và giao việc quản lý kết nối cho một cổng WebSocket được quản lý (ví dụ: hỗ trợ WebSocket của API Gateway).

7. Điểm cần cân nhắc và hàm ý

Chọn phương thức giao tiếp phù hợp với yêu cầu là điểm khởi đầu của kiến trúc. Yêu cầu-phản hồi đơn giản thì HTTP/REST gọn gàng, hai chiều thời gian thực hợp với WebSocket, đẩy một chiều từ máy chủ hợp với SSE, và trường hợp nhạy trễ nhưng chấp nhận mất mát nhỏ thì hợp với UDP. Từ góc nhìn của Kỹ sư chuyên nghiệp, cần một phán đoán tổng hợp bao gồm không chỉ hiệu năng mà cả độ phức tạp phát triển/vận hành và khả năng đi qua proxy.
Khả năng mở rộng kết nối đồng thời do mô hình I/O quyết định. Dịch vụ quy mô lớn phải cân nhắc vòng lặp sự kiện dựa trên epoll/kqueue/IOCP thay vì một luồng cho mỗi kết nối, và xa hơn là io_uring; dịch vụ giữ kết nối phải kèm theo thiết kế message broker, sticky session và backplane.
Áp dụng riêng đánh đổi giữa độ tin cậy và tốc độ theo từng đơn vị dữ liệu là thực tế. Như trong trò chơi và hội nghị truyền hình, thiết kế lai tách media qua UDP và điều khiển/giao dịch qua TCP ngay trong một dịch vụ là phổ biến, và điều này gắn với xu hướng mới nhất cài đặt lại độ tin cậy trên nền UDP, như QUIC (HTTP/3).
Vòng đời kết nối và khả năng phục hồi khi sự cố phải được phản ánh trong thiết kế. TIME_WAIT/cạn kiệt cổng, kết nối zombie, hết thời chờ NAT, và ghi một phần không lộ ra ở quy mô nhỏ nhưng lan thành sự cố khi lưu lượng tăng, nên phải chuẩn hóa các chính sách heartbeat, tái kết nối, backpressure và timeout.
Nội tại hóa bảo mật (security by design) là bắt buộc. Tránh socket dạng văn bản thuần và mặc định dùng TLS/wss, đồng thời nhúng xác thực, xác thực Origin và giới hạn tốc độ vào tầng giao tiếp để kênh thời gian thực không trở thành bề mặt tấn công.
Bảo đảm khả năng quan sát (observability) là tiền đề của vận hành. Vì kết nối bền vững, khác với yêu cầu-phản hồi, tích tụ vấn đề một cách âm thầm, nên phải liên tục đo các chỉ số như số kết nối đang hoạt động, tuổi thọ kết nối, tỷ lệ tái kết nối, độ trễ thông điệp và mức chiếm bộ đệm, và đặt cảnh báo ngưỡng để phát hiện bất thường sớm. Điều này gắn tự nhiên với quản lý SLO theo góc nhìn SRE.

Tài liệu tham khảo

IETF RFC 6455, "The WebSocket Protocol" — https://datatracker.ietf.org/doc/html/rfc6455
Dan Kegel, "The C10K problem" — http://www.kegel.com/c10k.html
Linux man-pages, socket(2)/epoll(7) — https://man7.org/linux/man-pages/man2/socket.2.html
MDN Web Docs, "The WebSocket API" — https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

Tóm tắt một câu: Socket là điểm cuối giao tiếp được định danh bằng IP và cổng, gồm socket TCP (tin cậy) và UDP (tốc độ) cùng WebSocket hai chiều thời gian thực; giao tiếp socket bền vững, hai chiều tương phản với HTTP phi trạng thái, yêu cầu-phản hồi và phù hợp cho dịch vụ thời gian thực, còn mở rộng quy mô lớn phụ thuộc vào I/O hướng sự kiện như epoll và io_uring cùng thiết kế message broker và bảo mật.