Phần lý thuyết có thể tóm gọn trong tầm 30 giây. phần thực hành thì xem cho biết thôi chứ không nên áp dụng vào dự án thực tế. Về cơ bản vấn đề này đã được các framework hay các bộ thư viện khác xử lý rồi, chúng ta chỉ cần sử dụng thôi.
Chủ đề của bác chủ Video rất hay. Có vẻ bác biết rộng và sâu, nhưng mà bác trình bày không tốt lắm. Bác nói chậm hơn, có ngắt dừng, bỏ bớt các thông tin thừa đi thì sẽ rất cuốn hút hơn. Một chút góp ý, mong sẽ có nhiều Video có chất lượng
bác góp ý lịch sự đấy, chứ em nói thẳng thắn hơn với chủ thớt là : nói dài dòng những thứ không cần thiết và không liên quan, nói không tập trung vào vấn đề chính.
A ơi vậy nếu hacker biết được hệ thống đang có Rate Limit và tấn công DoS. Lúc đó request của người dùng bình thường cũng bị chặn thì nên xử lý thế nào ạ
em xin góp ý, đây mới chỉ là giải pháp bề nổi , chặn request , còn bề chìm vẫn có cách check dc time request kế tiếp, hoặc kiên trì đợi hết time, nếu như vẫn đi sâu vào lấy SMS, OTP, Mail tính phí hết thì làm thế nào giảm bớt chi phí a
Áp dụng rate limiting cho SMS/email, xác thực hai yếu tổ, lưu cái mã vào để gửi tiếp nếu mã chưa hết hạn, và thực hiện các biện pháp xác thực khác đối với user
Em thường dùng throttle và để nó rất thoải mái, 1 người dùng trong 30s họ không bao h có thể dùng hết giới hạn đó, và nếu ai có spam khi dính throttle thì họ bị khoá tường lửa ngay và luôn, còn về vấn đề 100 r/s thì vì muốn mượt nhất em không có hạn chế, thay vì đó em cố gắng tăng khả năng xử lý r/s nhiều hơn nữa, có tốt không anh?
Nó còn tùy vào là api nào đang bị tăng request đột biến, dựa vào ngữ cảnh của từng api riêng mà xác định request đó có bị spam hay không. Ở ví dụ trên, 1 user không thể nào gửi 100 requests forgot password cùng 1 lúc được => đang bị spam => áp dụng rate limit cho nó. Sẽ có 1 câu hỏi triển khai thêm là 1 user chưa đăng nhập thì làm sao biết các request 1 2 3 ... 100 là của user đó ?
@@jackiedo7370 ở trên là em dùng cho trường hợp chưa đang nhập thành công tức là họ nhập mật khẩu để spam api tìm mật khẩu thì có vẻ cách của em cũng khá ổn rồi anh nhỉ
ở câu làm sao biết user này của ai thì em có test 1 lần là đối với api công cộng tức là không cần xác thực thì throttle nó sẽ áp dụng giới hạn theo ip người gọi, và nếu ip người gọi đó dính giới hạn thì lập tức bị chặn ip đó luôn, em chỉ biết được ngang đó
@@ey3474 đó là cách xử lý phổ biến nhưng có nhược điểm. 1 công ty 100 máy tính, khi request tới server thì tuy rằng mỗi máy có 1 internal IP riêng nhưng khi ra internet thì 100 máy này chung 1 IP, khi em rate limit 1 máy sẽ ảnh hưởng 99 máy khác
em nghĩ cái này dùng ở internal thôi chứ ngoài thì nên thêm capcha hay hệ thống check api nào đang nhiều do ip r chặn ip có vấn đề chứ chặn từ phía be e thấy kh hợp lý lắm
Nguyên tắc phải đi từ BE rồi đến FE. Trường hợp DDOS thì người ta đã cố phá thì sẽ tìm cách lách qua FE, chưa kể cung cấp các bên khác. Thế mới có câu phòng bệnh còn hơn chữa bệnh
Em vừa phỏng vấn vị trí backend developer, ở vòng technical interview thì em lại làm việc với bạn HR, và được yêu cầu giải 2 bài toán sử dụng ngôn ngữ JavaScript trong 60 phút, như trên hacker rank vậy, nhưng đề bài không rõ ràng và không có nhiều lưu ý. Anh cho em hỏi cách phỏng vấn này cần lưu ý gì không ạ
@@orangesixtyseven test thuật toán thì nhiều cty test mà b. pvan Nab EH đều có vòng đó. làm trên codility như leetcode hay hackerank thui. Còn vụ đề bài không rõ ràng thì mình k rõ lắm, ngta đưa 1 site của họ cho mình làm hay bắt mình làm trên đâu b.
@@orangesixtysevengiờ phỏng vấn fresher nó hay đòi giải ba cái giải thuật toán đánh đố kiểu này, nếu bạn nhắm mình làm k nổi thì luyện giải thuật toán , k thì như bác trên nói là đổi cty khác thôi, phỏng vấn mà giải hacker rank nhìn nó khá vớ vẩn cho fresher theo ý kiến cá nhân, jobs IT giờ ít nên phải chấp nhận thôi
![How to Get a Developer Job - Even in This Economy [Full Course]](http://i.ytimg.com/vi/6nz8GXjxiHg/mqdefault.jpg)
nội dung quá hay mong chú làm thêm nhiều video
Phần lý thuyết có thể tóm gọn trong tầm 30 giây. phần thực hành thì xem cho biết thôi chứ không nên áp dụng vào dự án thực tế. Về cơ bản vấn đề này đã được các framework hay các bộ thư viện khác xử lý rồi, chúng ta chỉ cần sử dụng thôi.
Vâng ạ!
Video hay quá anh. Em các keyword về cách anh test benchmark và về các tầng RateLimiter để nghiên cứu tiếp ạ.
với câu hỏi ở đầu video, có thể xử lý như Rate Limiting, Queueing cho các yêu cầu, Asynchronous ...
Chủ đề của bác chủ Video rất hay. Có vẻ bác biết rộng và sâu, nhưng mà bác trình bày không tốt lắm.
Bác nói chậm hơn, có ngắt dừng, bỏ bớt các thông tin thừa đi thì sẽ rất cuốn hút hơn.
Một chút góp ý, mong sẽ có nhiều Video có chất lượng
Cảm ơn sự góp ý của Bác!
bác góp ý lịch sự đấy, chứ em nói thẳng thắn hơn với chủ thớt là :
nói dài dòng những thứ không cần thiết và không liên quan, nói không tập trung vào vấn đề chính.
Cảm ơn anh
A ơi vậy nếu hacker biết được hệ thống đang có Rate Limit và tấn công DoS. Lúc đó request của người dùng bình thường cũng bị chặn thì nên xử lý thế nào ạ
cho e xin link nội dung vấn đề này nâng cao với ạ!
tks u a .
cho em xin link discord học hỏi với ạ
em xin góp ý, đây mới chỉ là giải pháp bề nổi , chặn request , còn bề chìm vẫn có cách check dc time request kế tiếp, hoặc kiên trì đợi hết time, nếu như vẫn đi sâu vào lấy SMS, OTP, Mail tính phí hết thì làm thế nào giảm bớt chi phí a
Fresher BE em... Anh nói trong video nâng cao thì 3 tier bren Go
@@anonystick video đó có chưa anh
Áp dụng rate limiting cho SMS/email, xác thực hai yếu tổ, lưu cái mã vào để gửi tiếp nếu mã chưa hết hạn, và thực hiện các biện pháp xác thực khác đối với user
Em thường dùng throttle và để nó rất thoải mái, 1 người dùng trong 30s họ không bao h có thể dùng hết giới hạn đó, và nếu ai có spam khi dính throttle thì họ bị khoá tường lửa ngay và luôn, còn về vấn đề 100 r/s thì vì muốn mượt nhất em không có hạn chế, thay vì đó em cố gắng tăng khả năng xử lý r/s nhiều hơn nữa, có tốt không anh?
Nó còn tùy vào là api nào đang bị tăng request đột biến, dựa vào ngữ cảnh của từng api riêng mà xác định request đó có bị spam hay không.
Ở ví dụ trên, 1 user không thể nào gửi 100 requests forgot password cùng 1 lúc được => đang bị spam => áp dụng rate limit cho nó.
Sẽ có 1 câu hỏi triển khai thêm là 1 user chưa đăng nhập thì làm sao biết các request 1 2 3 ... 100 là của user đó ?
@@jackiedo7370 Tại sao phải theo user mà không theo địa chỉ IP nhỉ ?
@@jackiedo7370 ở trên là em dùng cho trường hợp chưa đang nhập thành công tức là họ nhập mật khẩu để spam api tìm mật khẩu thì có vẻ cách của em cũng khá ổn rồi anh nhỉ
ở câu làm sao biết user này của ai thì em có test 1 lần là đối với api công cộng tức là không cần xác thực thì throttle nó sẽ áp dụng giới hạn theo ip người gọi, và nếu ip người gọi đó dính giới hạn thì lập tức bị chặn ip đó luôn, em chỉ biết được ngang đó
@@ey3474 đó là cách xử lý phổ biến nhưng có nhược điểm. 1 công ty 100 máy tính, khi request tới server thì tuy rằng mỗi máy có 1 internal IP riêng nhưng khi ra internet thì 100 máy này chung 1 IP, khi em rate limit 1 máy sẽ ảnh hưởng 99 máy khác
em nghĩ cái này dùng ở internal thôi chứ ngoài thì nên thêm capcha hay hệ thống check api nào đang nhiều do ip r chặn ip có vấn đề chứ chặn từ phía be e thấy kh hợp lý lắm
Uhm. Họ đang interview BE em... chứ còn nhiều mà. Nginx...
Nguyên tắc phải đi từ BE rồi đến FE. Trường hợp DDOS thì người ta đã cố phá thì sẽ tìm cách lách qua FE, chưa kể cung cấp các bên khác. Thế mới có câu phòng bệnh còn hơn chữa bệnh
Giữa hàm increase với set expire của a nó có delay nên hàm này chạy nó k đúng 100% đc
rate limit, backlog
Em vừa phỏng vấn vị trí backend developer, ở vòng technical interview thì em lại làm việc với bạn HR, và được yêu cầu giải 2 bài toán sử dụng ngôn ngữ JavaScript trong 60 phút, như trên hacker rank vậy, nhưng đề bài không rõ ràng và không có nhiều lưu ý. Anh cho em hỏi cách phỏng vấn này cần lưu ý gì không ạ
Đổi cty khác
@@otis4ex do cách phỏng vấn của bên cty không ổn hay sao anh
@@orangesixtyseven test thuật toán thì nhiều cty test mà b. pvan Nab EH đều có vòng đó. làm trên codility như leetcode hay hackerank thui. Còn vụ đề bài không rõ ràng thì mình k rõ lắm, ngta đưa 1 site của họ cho mình làm hay bắt mình làm trên đâu b.
@@orangesixtysevengiờ phỏng vấn fresher nó hay đòi giải ba cái giải thuật toán đánh đố kiểu này, nếu bạn nhắm mình làm k nổi thì luyện giải thuật toán , k thì như bác trên nói là đổi cty khác thôi, phỏng vấn mà giải hacker rank nhìn nó khá vớ vẩn cho fresher theo ý kiến cá nhân, jobs IT giờ ít nên phải chấp nhận thôi
@@ducchuy2467 em PV cho vị trí Junior, tham gia PV cũng vài lần nhưng lần đầu gặp phải kiểu PV này =(
Cảm ơn anh