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 ạ?

Bao giờ a viết tiếp ạ

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

@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.

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.

Đ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 ạ?

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

Ý 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).

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

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

@levinhtuyen210 mình cảm ơn bạn

Update: Nếu ai gặp lỗi về AuthorizationHeaderMalformed thì hãy set lại bucket về cùng region của lambda nhé. Hoặc có thể đổi lai region của function origin-request về region của bucket hiện tại.

Comment này để cho biết rằng sau 3 năm 5 tháng 18 ngày thì đã có người thấy cái này lần nữa.

@cuongnh28 mình dùng cloud Digital Ocean. bạn có thể cùng FileZilla để upsource lên hoặc CI/CD để auto deploy lên từ github. Vì dùng Server side render nên hơi tốn resource 1 chút. chỉ dùng cá nhân và ít user vào cùng 1 lúc (dưới 15) có thể dùng cấu hình này là đc rồi

@CVThien912 kiểm tra đường dẫn npm có đúng không, kiểm tra npm đã cài hay chưa, kiểm tra PATH của npm

@levinhtuyen210 mình cảm ơn bạn. Với lại cho mình hỏi về phần resource bạn dùng để deploy với ạ. Hosting tầm bao nhiêu là đủ nhỉ?

Vì không phụ thuộc vào BE nên sẽ không có API, việc quản lý nội dung sẽ là các file Markdown. bạn tìm trong thư mục project/app/content/blog -> các file tương ứng với slug của bài viết

Cho mình hỏi, muốn đăng bài vào mục blog thì vào mục nào để đăng ạ? Đối với web site ở trên

đọc xong mình ko biết mục đích của tool là gì và kết quả là gì luôn 😁 có vẻ do bạn dùng tiếng Nhật nên mình ko hiểu.

Khi làm vậy, webpack sẽ thực hiện code-splitting, tức bỏ mã nguồn của package vào file riêng chứ không cho cùng vào file script của component hay ở vendor nữa. Có article hướng dẫn thêm về cái này ở https://vueschool.io/articles/vuejs-tutorials/lazy-loading-and-code-splitting-in-vue-js/Bàn ghế tiệc cưới

Nhiều đồ cổ ở đây quá @@

@hungpvph36223 🧐vậy à e? cái này a phải thử thêm để confirm, thanks e nhé

Đồng ý.