THẢO LUẬN

thanks e đã theo dõi 🥰

0
thg 10 29, 4:10 SA

♥️♥️♥️

+1

Bài viết thực sự rất tâm huyết ạ! Cảm ơn anh đã share những kiến thức bổ ích này.

+1

Trước giờ mình xem các bài viết của page nhưng không đăng nhập và tương tác. Đến khi đọc được bài viết này, nó thực sự rất hay và chi tiết. Vì vậy mình đã login và comment những dòng này. Cảm ơn tác giả.

+1

bạn check thử xem bạn dụng amazon linux 2 hay là bản 2023.

0

ngạingạingại

0
thg 10 28, 10:47 SA

Theo mình, Scrum là framework hiện thực tư tưởng Agile, nên nếu bạn làm đúng Scrum thì chắc chắn bạn đã follow Agile. Quá thích cái đoạn giải thích cool ngầu. 👍️

0
thg 10 28, 7:30 SA

@refacore Mình muốn làm rõ hơn một chút về vấn đề dùng cookies để khặc phục vấn đề nhiều người dùng chung một giải địa chỉ IP

Bạn có thể làm rõ hơn một chút chỗ này giúp mình được không?

Mong được nhận câu trả lời từ bạn!

0

Không thích code gen 😃) Chí ít là cho đến khi không cần dùng build runner nữa

0

hay day minh Nhac den websocket da phan dev deu nghi den socketio, ma trong tai lieu socketio dua ra cach su dung nhu vay!

0

@DuongThanhPhu áp dụng cho nhiều loại sản phẩm và có trên 2 attribute vẫn ok chứ ạ

0

Mình php -v nó cứ "-bash: php: command not found". Đã làm đủ các bước trước đó. Chạy sudo amazon-linux-extras | grep php thấy nó in ra php 8.1 enabled rồi. Không hiểu nổi.

0
Avatar
đã bình luận cho bài viết
thg 10 27, 7:44 SA

dạ cho em hỏi tại sao phải chia ra 2 loại authorization code và accesstoken, mà không gửi accesstoken ngay từ đầu ạ?

0
thg 10 26, 3:56 SA

Cho mình hỏi trường hợp từ webview nếu muốn gọi về màn hình thanh toán của ứng dụng thanh toán thì mình có những cách nào để thực hiện ạ?

0
thg 10 26, 3:45 SA

Bao giờ a viết tiếp ạ

0

hay quá ạ. Cảm ơn tác giả bài viết

0

@tuana9a đầu tiên là cảm ơn bạn đã có phần comment rất tâm huyết, trình bày băn khoăn 1 cách rõ ràng. Mình xin trả lời câu hỏi của bạn như sau:

  • "Kiến thức network rất phức tạp", đó chính là lý do tại sao chúng ta nên học kỹ lại mô hình OSI, đặc biệt là cách hoạt động của TCP ở layer 4 và HTTP ở layer 7. Như mình đã nhắc đến trong phần kiến thức cần có trước khi đọc bài viết này.
  • Cụ thể hơn, TCP là 1 stateful protocol, tức là trong định nghĩa về cách hoạt động của TCP đã yêu cầu trong 1 connection TCP thì packet sẽ có thứ tự, packet sau phụ thuộc packet trước. HAProxy, khi tự định nghĩa mình hoạt động với mode TCP, tức là hoạt động ở layer 4, sẽ chỉ quan tâm tới IP + Port, còn mọi thông tin data phía trong sẽ được passthrough nguyên vẹn (bao gồm cả thông tin về thứ tự, offset của packet đó). Khi hoạt động với mode tcp, HAProxy sẽ mở 1 connection tới client, 1 connection tới server và map chúng lại với nhau 1-1, tức là sẽ không có chuyện n connection client - m connection server. Cái này là cách hoạt động của L4 Proxy nói chung rồi chứ ko phải chỉ mỗi HAProxy. Đọc thêm: https://www.haproxy.com/blog/layer-4-and-layer-7-proxy-mode.

TCP.drawio.png

Như bạn thấy trong hình, bản chất 1 bản tin HTTP là tập hợp của nhiều gói tin TCP. Các gói tin TCP thì có quan hệ thứ tự với nhau (stateful), nhưng các bản tin HTTP thì không có quan hệ thứ tự như vậy (stateless).

  • Tiếp theo, khi chạy ở layer 7 thì mới xuất hiện protocol là HTTP/websocket, ở layer này thì HAProxy có thể tạo ra n connection client - m connection server tùy thuộc vào config connection mode (keep alive / close / tunnel... Thế nhưng như mình đã giải thích trong bài về cách hoạt động của websocket, sau khi có 1 HTTP request upgrade và nhận dc response 101 switching protocol thì HAProxy sẽ tự động chuyển trạng thái từ HTTP (layer 7) sang TCP tunnel (layer 4). Lúc này mọi gói tin TCP của websocket frame đều được truyền nguyên vẹn qua 2 connection với client và backend đang mở mà không bị sửa đổi gì. Điều này nghĩa là nó thuần túy là các gói tin TCP có thứ tự và chỉ được chuyển tới đúng cái backend đang mở connection đó thôi. Đọc thêm: https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy

Hy vọng là câu trả lời này sẽ giúp bạn hiểu rõ hơn.

0
Avatar
đã bình luận câu trả lời trong câu hỏi
thg 10 25, 4:38 CH

Đoạn npm em có fix đc rồi ạ, nhưng bây giờ k biết ssh vào như vậy liệu bảo mật có ổn k, do em cũng đọc được vài bài nói k nên để ssh vào prod, liệu cài git runner trên vps rồi cấp quyền cho user git runner liệu có tốt hơn k ạ?

0

Kiến thức network rất phức tạp, mình có câu hỏi là bạn đã test thực tế mà không sử dụng thư viện mà dùng thuần thư viện standard của nodejs chưa. Nếu được thì show cả quá trình haproxy xử lý packet khi nó nhận được thì mới hiểu được chính xác nó xử lý như nào.

Ngay như đoạn giải thích cơ chế proxies của Haproxy https://docs.haproxy.org/3.0/intro.html#3.3.1, họ viết như này

image.png

Ý là họ dùng 2 connection "độc lập", tức có thể n client connection tới haproxy nhưng chỉ m connection tới các server phía sau, cụ thể implement như nào thì chắc phải đọc code hoặc có blog chi tiết từ Haproxy. Mình cũng hiểu là dù protocol nào đi nữa websocket hay http thì nó cũng sẽ thành các gói tin có source (ip + port) và destination (ip+port). Do vậy cũng không dám khẳng định là Haproxy "mặc định" có "khôn" để điều hướng các gói tin liên quan tới websocket của một client về chung một backend không hay nó coi như một http request bình thường và bắn tùm lum (round-robin, least-conn, ...) sang các backend khá?

Khẳng định không cần dùng ip_hash hay sticky session cho websocket mình thấy vẫn chưa thuyết phục.

Bản thân TCP connection thì nó cũng chỉ là các gói tin độc lập: có source (ip + port), dest (ip +port).

image.png

Nguồn ảnh: https://www.geeksforgeeks.org/tcp-ip-packet-format/

Ý kiến của bạn ntn? @monmen

0
Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí