AnoraLee/voz-controversial-dataset huggingface dataset:
Công ty: Ninjavan Thời điểm phỏng vấn: 2022 Nơi nộp CV: Itviec Round 1: HR liên hệ để hỏi sơ qua về kinh nghiệm và những thứ được viết trong CV, sau đó sẽ gửi 1 bài test online gồm 3 câu thuật toán trên hackerrank. Round 2: Phỏng vấn online gồm thuật toán và system design. Tham gia phỏng 2 gồm 2 anh 1 lead 1 senior. Interviewer khá thân thiện và giỏi, kiến thức tốt. Phỏng vấn gồm 2 phần Thuật toán: hỏi câu Next Permutation trên leetcode. Câu này tuy medium nhưng muốn giải cách tốt nhất thì khá khó nên mình chỉ làm được cách brute force. Cái này cũng do mình ko tốt thuật toán với code trên file word nên ko làm được cách tối ưu. Nhưng có vẻ 2 anh cũng ko yêu cầu mình phải giải cách tốt nhất, chủ yếu mình giao tiếp với 2 anh để cùng nhau code là ổn. System Design: Design Feature Flags. Thiết kế các flags để tắt bật các feature trên 1 tập users nhất định. Khúc này các anh hỏi xoáy sâu làm sao để design đươc feature flags trên 1 tập users và phải tối ưu được performance. Các câu hỏi chủ yếu là thiết kế DB ra sao, chọn SQL hay noSQL, tại sao..... Sau khi kết thúc 2 phần này sẽ tiếp tục hỏi về kiến thức CS như Isolation levels, Threading, Microservices, Docker, K8s, Kafka,.... Kết thúc buổi này mấy anh sẽ trả lời đầy đủ những gì mình còn thắc mắc và giới thiệu team đang làm gì. Đánh gía chung mình thấy 2 anh giỏi và thân thiện, team cũng đang giải quyết những vấn đề khá hay. Round 3: Round này mình gặp 1 anh CTO người nước ngoài. Ảnh cho 1 đoạn code và hỏi mình cách để refactor và optimize đoạn code này. Vòng này cũng khá đơn giản do anh CTO cũng như đang pair làm việc chung với mình. Sau đó, anh sẽ hỏi thêm một số câu về CS như DB indexing, Networking, về Microservices như RPC vs Message Queue,... Nói chung vòng này ko sâu như vòng trước và anh CTO cũng khá thân thiện. Sau vòng này thì HR contact và đánh giá mình chưa được mức Senior nên ko process tiếp. Mình cũng khá tiếc vì mình nghĩ đây là một công ty tốt để improve technical skills. Kinh nghiệm sau lần phỏng vấn: Leetcode chưa giải được tốt. Vẫn chưa nắm vững Microservices + System Design nên mình nghĩ do vậy mà chưa đạt mức Senior. Với bên đây Senior cũng yêu cầu phải nắm vững nhiều ngôn ngữ (Golang, Java, Javascript...) cũng nhưng nắm cái lib/tools (Docker, Kafka, ElasticSearch, K8s, RabbitMQ...), làm được luôn FE (ReactJS) sẽ được đánh giá cao.
Cty: Go1 platform Thời điểm: 2/2022 Vị trí: SSE Hr contact qua Linkedin. Chuẩn bị: không Ngôn ngữ: tiếng anh Expect: 3k5 Vòng 1: Hr gửi email và link github https://github.com/go1com/go1-coding-challenge cho chuẩn bị, đọc sơ qua thì cũng bình thường nên ko có luyện gì, tới ngày thì gặp 2 người để pv, làm live coding và trả lời câu hỏi xoay quanh phần đó, họ có yêu cầu làm thêm dựa trên yêu cầu đó. Làm có bug, xong mình debug đặt breakpoint rồi fix luôn. Xong sớm trước giờ quy định Kết quả: pass. Khá dễ dàng nếu như bạn có thể làm dc bài giải thuật mức độ easy. Không hỏi bất kỳ câu nào khác ngoài cái này. Vòng 2: vòng kể chuyện Gặp anh manager, và ảnh kêu kể về trường hợp bạn leading để resolve 1 problem nào đó... Mình bảo em không có, nói chung là mình không nhớ ngay dc với lại tiếng anh kém, nên mình chọn trả lời không có. Kết quả: không có offer. Bài học rút ra: Nên chuẩn bị về các câu chuyện kiểu resolve conflict, leading project này kia, không chỉ ở đây mà các công ty khác cũng sẽ có câu dạng này khi bạn vào vòng gặp boss bự. Improve tiếng anh. Gửi từ Galaxy Z Fold 4 bằng vozFApp
Cty: Epam Anywhere Tháng 2/2022 HR liên hệ qua Linkedin. Vị trí: sse fullstack JS Chuẩn bị: không Vòng 1: technical. Gặp 2 người, 1 VN 1 Trung Quốc. Hỏi lý thuyết khá nhiều ví dụ như: bind/apply/call arrow function scope binding this css/html với dạng nào thì dùng Nodejs định nghĩa như thế nào là API tốt Live coding 1 2 câu gì đó kiểu rất dễ Vòng 2: technical manager Hỏi chuyện định hướng này kia. Không có gì đặc biệt xong nghe mình bảo muốn làm remote hoàn toàn nên giới thiệu qua remote anywhere Vòng 3: pv lại technical vì nói là với kết quả technical vòng 1 thì không offer được mức mình expected. Gặp 1 người Ấn Độ, hỏi technical rất đơn giản. Live coding 1 câu siêu dễ. Vòng 4: gặp hiring manner người belarus hay gì đó. Không có hỏi gì đánh đố hay gì đặc biệt, chủ yếu để thông báo mức offer. Offer 3,xk Chốt: đây là công ty phỏng vấn rất dễ để lụm lương to. Ai đang muốn nhảy lên range 3k có thể thử Nhưng mình từ chối offer vì tìm được công ty hợp phong cách và thấy mình có thể có impact lớn hơn. Gửi từ Galaxy Z Fold 4 bằng vozFApp
Cái đống của Ninja kia gặp mình cũng ko chắc trả lời dc 80% đâu Mà nó hỏi kiến thức thì phụ thuộc vào việc hiểu sâu tới mức nào. Khá là khoai, để sang năm tui sẽ thử apply đi pv thử xem sao nhé Mà hỏi sâu vậy ko dc 4k thì hơi chán
Vòng 2 mà thím trả lời thế là dở rồi Cái đó phải tập luyện thím ạ. Đợt mình ôn Amazon, ngồi chuẩn bị script rồi nói cho trơn tru mấy câu như vậy cũng tốn công không khác gì luyện code hết. Với ở level Senior trở lên thì họ sẽ đòi hỏi nhiều hơn ko chỉ mỗi kỹ thuật. Mà còn về giao tiếp, behavior, communication, leadership v.v...
Công ty: Shopback Thời điểm: 5/2022 (Sau khi bị Wolffun chơi một vố, giờ vẫn còn cay ) FYI Vị trí: Frontend Engineer Chuẩn bị: Đã dành khoảng 1 tháng để giải Leetcode và cũng có 1 lần PV khởi động ở Zalo Hr contact qua Linkedin sau đó là trao đổi qua zalo Vòng 1: sau khi Screen CV và nch sơ với HR thì sẽ có một buổi tech interview với 2 người trong Shopback (Lúc đó mình nhớ là một chị và một anh). Ấn tượng thì họ khá là nice, về câu hỏi cho vị trí mình pv là FE engineer thì sẽ có 3 câu Algo (khoảng Easy tới Medium Leetcode), những thứ bên phía Frontend (cả cơ bản lẫn nâng cao). Sau vòng đó là sẽ có một vòng nch với anh Head of Engineering bên VN (chủ blog Codeaholicguy) chủ yếu là về những thứ đã làm ở cty cũ, về công nghệ, blah blah => buổi nch này thì thoải mái nhẹ nhàng. Vòng 2: Sẽ có một buổi nch với Head of Engineering bên phía Sin, một anh người Sin ốm ốm và nch rất thân thiện mặc dù accent hơi khó nghe. Về buổi nch thì sẽ là cách giải quyết những conflict với đồng nghiệp, soft skill, bài học ở công ty cũ, etc (Không có hỏi về tech) Vòng 3: Deal lương với HR Kết quả: Sau khi deal lương xong xuôi hết và nhận đc Offer, mình quyết định cancel hết tất cả những buổi interview với một bên mình đang pv là Trusting Social (Chỉ còn 1 round cuối là tới vòng deal lương) thì được HR báo là bên Shopback nhận được thông báo là freeze tuyển dụng nên case của mình bị Pending Lại bơ vơ một lần nữa sau khi bị Wolffun chơi một vố ( Wolffun đã chơi tôi như thế nào? ) Kinh nghiệm rút ra: 30 chưa phải là Tết, không nên cancel những bên khác => Nên pv hết để chọn offer tốt nhất.
Cty: Google Role: Software Engineer for Chrome Tôi nộp trên trang careers của Google, sau 1 ngày thì nhận mail được process. Vòng đầu tiên là online assessment. Được làm trong vòng 4 ngày kể từ khi nhận mail Đề sẽ là 30 câu trắc nghiệm behavior trong 30p. Trả lời xong không được phép back về câu cũ. Câu hỏi sẽ bị lặp lại hoặc đảo cách hỏi để xem hành vi có nhất quán và cách làm việc với hợp với cty không. Tôi tạch nên không thể review thêm
( Cảnh báo - bần đạo bị lỗi chính tả hơi nặng ) Chẳng là dạo này đang tính làm vài cái có liên quan tới concurrent nhiều. Cá nhân thì vẫn thích C++ hơn tuy nhiên có ứng cử viên ko thể ko quan tâm tới là Rust. Thống kê vài năm gần đây , Stack Overflow's cho biết có tới 86% dev "like" ngôn ngữ này. Dù có người chưa từng học - dùng nó làm việc. Vậy nó có gì hay , theo mình đọc thấy có nhiều nhiều cải tiến so với C++. Toàn hay ho cả ( chưa thấy thối nhiều ) , trên các site diễn đàn về lập trình tây lông. Có một bộ phận không nhỏ cuồng Rust tới mức được gọi là "truyền giáo". Trên "Hacker News" với từ khóa Rust vs C++ , có vô số topic của những người bảo thủ đấu vs mấy anh em truyền giáo. Chắc chẳng bao giờ có hồi kết. Tựu chung lại mình muốn nghe lời các thánh ở voz cho ý kiến về Rust , ở vài luận điểm. + Rust có thay thế C/C++ ( hai thằng riêng ) như C đã từng thay thế vài ngôn ngữ trước đó. + Rust có thực sự mạnh mẽ và an toàn như quảng cáo ? + Rust và tương lai của nó , 5 , 10 năm 40 năm có được như C và C++ hiện nay ? Vì Rust hiện tại chưa có một tổ chức tiêu chuẩn như C vs C++. + Phát triển một phần mềm , hay hệ thống dựa trên Rust có hẳn ok hơn C or C++ ? Cá nhân mình thừa nhận luôn là người khá bảo thủ ( có vẻ hơi ác cảm vs mấy cái mới kiểu scrip ). Vì thế cũng thiên về ý kiến RUst ko bao giờ "kill" được C,C++. Hiện tại cá nhân thấy Rust còn thiếu và thiếu rất nhiều t hư viện , chưa kể những lib cốt lõi của thế giới này. Gần như ko thể thay thế... Còn Go tuy của gg , đọc bài Discord phát triển một loạt dịch vụ trên GO thì ăn hành mạnh bởi cái GC của nó. Quay sang Rust thấy rất ok , đã thay thế gần hết sang Rust. Thành ra mình vẫn coi th ường Rust nhưng buộc phải có cái nhìn và suy nghxi khác về nó. Tuy bảo thủ nhưng ko có nghĩa cố chết với lối mòn. trích ý kiến một ông Tiến nhưng sĩ ở bên trời tây: https://www.quora.com/Why-is-the-Ru...-getting-popular/answer/Mario-Galindo-Queralt Phong cách thừa thời gian hiện tại của mình , nhiều lúc mình hay dùng asm kèm vs c. Nếu thích tối ưu một cái gì đó , cho dù trình dịch thực sự rất thông minh rồi. Tuy nhiên có nhiều lúc vẫn thấy có thể tối ưu hơn nữa bằng "tay". Or có vài hàm nào đó ko thích sử dụng có sẵn trong lib. Thường mình sẽ viết lại bằng ams bỏ đi một số thứ ko cần thiết so với nhu cầu. Thành ra việc quen vs c call asm như một thói quen. Ngại thay đổi hoài nghi những đứa khác , trong đó có Rust. Mời các thánh thần , các chiên da. Các nhà học sĩ voz có chung quan tâm tới chủ đề nầy. Vào tung chưởng phong cho bần mỗ mở mang tầm mắt. Bần mỗ chỉ là kẻ ko chuyên trong ngành này- từ trước tới giờ ko qua trường lớp thành ra thiển cận rồi. Có điều nói ko phải mong các hạ "hạ khẩu mà lưu tình ". Kính bút...
Độc lập gì bạn. Đa phần các ngôn ngữ khác nhau ở cú pháp. C C++ ở 1 thế giới khác. Bởi vì nó đảm bảo hiệu năng. Rust là 1 phiên bản nâng cấp về hiệu năng của C++. Chạy nhanh như C++ và không có lỗi.
Thím đã thử nó chưa mình cần xác thực của người đã thử. Chạy nhanh gần = hay hơn ? Thực sự an toàn thật ? Tại nó bảo tránh được các bug về bộ nhớ của c vs c++. Tuy nhiên vẫn call list vẫn dùng raw point. Rồi đặt trong Unsafe... Vậy cũng đâu hẳn an toàn.
Chạy nhanh bằng. Bởi vì C++ nó chạy nhanh nhất rồi. Nó tránh bug cho mình bằng cách tự động sửa bug cho mình. Chỉ thế thôi. Nó giống bộ sưu tập rác của Java nhưng nhanh hơn. Bình thường dev C++ phải tự sửa lỗi. Nên nó hay bị lỗi.
1. Ko có ngôn ngữ nào thay được ngôn ngữ nào cả, kể cả ko phải Rust/C++. 2. Ai quảng cáo vậy, mạnh hay an toàn phải nói rõ ra là chỗ nào chứ nói chung chung thì cũng như câu trên, ko có ngôn ngữ nào mạnh hơn ngôn ngữ nào hết. 3. Ý bạn tiêu chuẩn là ntnao? Cái này à: https://github.com/rust-lang/rfcs . Còn tương lai thì t cũng ko đủ tự tin để nói. 4. Ok hơn là oke gì nhỉ? Performance? Productivity? Maintainable? Chủ đề của bạn ko hợp lý lắm vì nếu ko phải Rust, mà là ngôn ngữ khác với các câu hỏi như trên thì cũng chẳng có điểm nào mà thảo luận hết
Cái hay của ngôn ngữ này là dev k cần thu hồi bộ nhớ thủ công như C++, cũng k dùng GC để collect định kì như mấy nngu khác. Nhưng code cũng rườm rà phết. Mới coi sơ. chưa biết gì nhiều. Code phải để ý cái vụ owner của vùng nhớ, code ko quen làm mãi mới build dc. Công nhận cách tiếp cận mới lạ thật.
Mà anh em cho tôi hỏi là trong 5 năm gần đây thằng RUST có ra product nào ngon ko nhỉ ? Thằng C++ nó ảnh hưởng cả nghành công nghiệp phần mềm từ trước rồi, có những thứ gọi là legacy rất khó mà thay đổi . Với tôi thì ko có C++ thường nhưng thấy C++ cũng trưởng thành và thay đổi từng ngày rồi.
Theo mình biết thì có alacritty với Discord cũng có dùng. Lần đầu biết đến Rust là qua bài này https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f Chính bài blog này làm mình thắc mắc về cách quản lí bộ nhớ của Rust nênhọc thử. Thấy cách tiếp cận hay thật.
bởi vì cái scope mà discord dùng rust trong trường hợp này thì nó có rất nhiều lựa chọn khác, không bắt buộc phải dùng rust. việc dùng rust chỉ như là việc thí nghiệm dùng cái mới (cái này rất bình thường) chứ có phải là bắt buộc phải dùng rust mới ra được kết quả như vậy đâu? muốn có kết luận thì phải so sánh mấy thằng to như servo hay redox xem nó có ra trò trống gì cơ.
star của github có thể có giá trị với ngôn ngữ khác nhưng hoàn toàn vô nghĩa với mấy cái liên quan tới javascript (mấy cái repo 1 dòng code cũng có thể có cả nghìn stars) cơ mà anh deno đang muốn viết lại typescript bằng rust, tôi ngồi hóng xem có làm được không, nếu làm được thì giỏi :> à mà rust còn có một thằng được hype khá kinh nữa là xi-editor, không biết sau này có ra cơm cháo gì không :/
Rust + WebAssembly (Wasm) sẽ còn phát triển vì combo này gia tăng hiệu năng của trang web. Không phải ngẫu nhiên mà tháng 12 năm ngoái W3C công bố Wasm là ngôn ngữ web chuẩn thứ 4 (3 ngôn ngữ trước đó là HTML, CSS, Javascript).
Biết lập trình thì học được thôi chứ cần gì ai hướng dẫn Trước coi ở đây nói dễ hiểu, không dài dòng, chọn tốc độ x2 xem nhanh lẹ hiểu concept rồi thì bắt tay vào gõ thôi Chứ bảo chưa có kinh nghiệm gì về lập trình thì có mà học dài dài
Mình đã phỏng vấn khá nhiều ứng viên về cả backend lẫn frontend trong nhiều năm, chỉ có 1 câu hỏi mà gần như không có bạn nào trả lời đúng cả, đó là: Nếu nodejs là single threaded, vậy tại sao nó có thể gọi 1 http api bằng await, đợi http api đó trả lời rồi tiếp tục chạy code phía sau dòng await. Tại khi await thì thread sẽ chạy đi làm việc khác, vậy cái gì ngồi đó đợi cái http request đó? Câu trả lời mình thường nhận được là: cái event loop nó, nó loop đi loop lại để check xem cái http request đó xong chưa. Ok, nhưng nếu cái event loop đó cứ loop đi loop lại để check cái request đó xong chưa, vậy thì phải có cái gì đó khác chạy ở bên dưới để đợi các network request rồi báo cho event loop là network request đó xong rồi chứ đúng không? Ứng viên thường trả lời: Ừ chắc đúng vậy, nodejs bên trên là JS nên dùng event loop, bên dưới runtime của nodejs phải có multitask/multi thread mới xử lý được. Câu trả lời này sai, JS runtime ko có dùng thêm thread nào cả. Kể cả bạn có hỏi AI thì câu trả lời chắc chắn vẫn quá nông và không nói được bản chất vấn đề, bởi OS cũng là phần mềm, nó vẫn phải dùng CPU thôi. Lý do mình post câu hỏi này lên đây bởi đây không chỉ là vấn đề của nodejs, mà là cách máy tính vận hành nói chung. Dev viết code nhưng không hiểu code bên dưới chạy như nào. Câu hỏi này cũng áp dụng cho mọi ngôn ngữ khác, bởi nó là bản chất cách máy tính hoạt động. Tuy nhiên, mình cũng không mong đợi dev trả lời đúng, đây chỉ là 1 câu hỏi xem dev có kiến thức về low level software hay ko thôi, trả lời được thì mình đánh giá rất cao, còn k trả lời được thì mình coi như chưa hỏi, ko sao cả. Câu trả lời đúng là: Không có cái gì từ phía CPU ngồi đợi cái http request đó cả. Việc xử lý và thông báo kết qủa http request được xử lý ở mức phần cứng, cái card mạng báo cho CPU là việc CPU giao cho nó đã xong, nó bắn một message cho CPU để báo rằng nó đã xong việc, cpu báo với OS, OS báo lại với nodejs. Nói chung là vậy, câu trả lời trên hơi sơ sài, nhưng để hiểu và trả lời được vậy thì phải hiểu được một nùi thứ từ phía phần cứng + hệ điều hành. Mình post câu hỏi này lên đây để cho mọi người suy nghĩ, bởi không sớm thì muộn, bạn sẽ đụng phải các khái niệm low level như stack, heap, context switch ... Có chút kiến thức về low level software sẽ rất tốt cho mọi người. Cháu mình chắc năm sau vào đại học, có lẽ cái đầu tiên mình dạy nó sẽ là mấy cái cơ bản này. Tiện đây share với các bạn 1 kênh youtube rất hay mình kiếm được, ông này giải thích rất tốt về các khái niệm bên trên, hy vọng sẽ giúp ích cho mọi người.
Cái này mới sai nè, JS runtime dùng hơn 1 thread nhé thím Node là 1 runtime của JS, và Node có 1 thứ gọi là libuv, chính thằng này sẽ đảm nhận việc offload các I/O intensive tasks. Vì JS là single-threaded non-blocking nên JS sẽ chỉ có 1 main thread để xử lý thôi nhưng không có nghĩa là Node nó không xài thêm thread nào khác. FYI: Thread pool work scheduling - libuv documentation (https://docs.libuv.org/en/stable/threadpool.html)
Chỗ này là do thím không đọc kĩ docs của nó th. Trong lúc đang execute task trong task queue của NodeJS, nếu có bất cứ thứ gì dính tới I/O thằng node sẽ offload nó qua libuv - đi kèm với một callback khi cái I/O đó đã xong. Và một khi I/O đó xong, callback sẽ được enqueue vào trong poll queue, NodeJS event loop nếu chạy tới poll phase sẽ dequeue từng callback ra và ném vô lại trong task queue để xử lý (no-blocking là ở đoạn này), cho tới khi nào poll queue rỗng hoàn toàn. còn vấn đề await thì thím nên nhớ nó chỉ là một sugar syntatix của JS, bản chất nó vẫn là callback. Ví dụ:
Ý mình k có nói JS runtime là single threaded. Ý mình nói là khi 1 network request được gọi, runtime nó k có spaw ra 1 thread để đợi cái request đó. Nodejs xử lý 1000 db call, không có nghĩa nó cần 1000 thread ngồi đợi. Với disk I/O thì khác, libuv sẽ lấy 1 thread từ pool để đợi, nhưng nhìn chung là một trong các edge case mà nodejs dùng thread để optimize. Nói cách khác, không có chuyện nodejs có 1 thread ngồi đợi network request của bạn, cái network card sẽ phải wake up ngược lên nodejs. Disk I/O thì hoạt động khác nên mới cần đến 4 cái thread của libuv.
thảo luận Javascript có thực sự là single thread ? Aug 22, 2020 Hi mấy thím, Chả là trên công ty em có ông anh cho rằng JS không phải là single thread bởi vì có các thread khác như là webworker,.. Nhưng theo em hiểu thì các WebAPI này được cung cấp bởi browser và dùng để chạy các đoạn code JS chứ không phải là bản thân JS đã support multithread mà ông kia thì đang mentor cho em nên không dám cãi Theo các fen thì có ý kiến thế nào ? teeeeeeeee Replies: 199 Forum: Lập trình / CNTT nhớ xưa voz cũng có 1 thớt
Hmm, 2 câu hỏi này khác nhau mà b. Câu hỏi kia là liệu nodejs có phải single thread hay ko? Còn câu hỏi này là làm sao có 1 thread mà nodejs có thể handle hàng ngàn network activity cùng 1 lúc? Câu hỏi này không chỉ giới hạn ở nodejs, nó apply cho tất cả các phần mềm chạy trên các loại máy tính phổ thông nói chung.
Mình đâu phải AI đâu mà giải thích cho b từng cái một. Mình cho b câu hỏi, bạn tự tìm câu trả lời, có j ko hiểu thì hỏi t giải thích. Kernel cũng là phần mềm thôi chứ có phải phần cứng đâu mà đòi xử lý. Cuối cùng nó cũng về tầng network thôi, k về card mạng thì đi đâu? Yeah, nó weird bởi t nói tóm tắt quá, nhưng bạn có thể hiểu là request http hay gì đi nữa thì cuối cùng nó cũng chạy ra card mạng để xử lý thôi. Hay thật, bạn ko biết gì, nhưng đọc comment lại nghĩ t hiểu sai vấn đề? Bạn tin 1 phía trong khi họ k có evidence, bạn cũng k muốn đi verify/tìm hiểu và tin họ luôn? Nếu bây giờ họ bảo nodejs nói chuyện trực tiếp với card mạng để gửi request chắc bạn cũng tin luôn nhỉ?
Đang làm nhúng, mấy cái low level, multicore, multi task/thread mà đọc câu trả lời mà mắc ói Làm trên Linux hay Win x86 thì liên quan đầy đến userpsace, rồi nào system call, interrupt, nested interupt, message queue bla bla. Ông nội thớt chắc éo biết http/https được handle ra sao trong mô hình OSI, rồi cái "card mạng" làm cái gì để transfer từ ethernet packet, ip packet, network packet tới applicatio packet (trong trường hợp này là http). Tóm lại sai bét.
Bữa nay mở ra đọc comment thì thấy các bạn hỏi những câu rất khó hiểu, một phần vì mình nói tóm tắt quá. Nhưng cũng không ngờ đc các bạn ko hiểu nếu như t nói tóm tắt như vậy. Các comment thường là: "NIC ko xử lý request, kernel mới là chỗ xử lý". Ờ thì cũng đúng, nhưng nếu nói theo cách bắt bẻ từng chữ thì kernel cũng đâu có xử lý http request, nó xử lý tcp/ip connection mà. Rồi ba bữa nữa nếu một O/S nào đó cho http vào kernel của nó luôn thì các bạn lại đi cãi nhau xem thằng nào xử lý "request" à? Túm lại, bọn này là software, ko phải hardware, thằng nào xử lý cái gì cũng vậy thôi. Bắt buộc phải có cái gì đó bên dưới thông báo cho nó rằng network package đã gửi/nhận xong. Http hay gì thì cuối cùng nó cũng sẽ quay về việc gửi và nhận các network package, và việc làm sao O/S của bạn biết được 1 network package đã được nhận/gửi nó phải đến từ NIC. NIC phải thông báo cho CPU biết rằng nó xong việc bằng cách báo cho CPU biết thông qua PCIE, qua đó mới có thể tiếp tục xử lý ở các tầng cao hơn.
Tóm tắt đến trang 6: 1. Thớt văn nghe khó chịu nhưng kiểu văn này lại khiến topic nó xôm 2. Ngôn từ của thớt hơi lộn xộn nhưng đọc kỹ thì cũng có cái có giá trị 3. Vì ngôn từ hơi lộn xộn nên có cảm giác thớt chưa hoàn toàn nắm kiến thức này, rất lắm khi thớt đi xa nội dung của topic. 4. Vì ngôn từ hơi lộn xộn và thớt dùng ngôn từ này để phỏng vấn ứng viên nên khá bất công với ứng viên
Tiện topic đang xôm, các fen già đời có thể list vài cuốn OS nền tảng mà dev app cần biết ko. Cuốn này Operating Systems: Three Easy Pieces Operating Systems: Three Easy Pieces (https://pages.cs.wisc.edu/~remzi/OSTEP/) học xong có đủ trình hiểu mấy cái low level của NodeJS ko các fen
Không biết 2 fen đã làm đến phần nào rồi. Nhưng card mạng báo cho CPU là có thật. Người ta gọi cái đó là interrupt (ngắt). Với đa số card mạng hiện nay cơ chế chung là như sau: NIC nhận được packet NIC write nội dung vào ring buffer, đây là một cái queue có giới hạn kích thước trong RAM. Việc write này là thông qua DMA (direct memory access), write trực tiếp vào RAM không thông qua CPU, NIC "thông báo" cho CPU bằng cách gọi interrupt. Với một CPU có nhiều nhân, hoặc máy nhiều CPU thì trước đó đã có sẵn cấu hình xem queue nào, card nào sẽ thông báo cho core nào, CPU sau khi thực thi instruction hiện tại sẽ kiểm tra xem có bị ngắt không, Nếu có thì CPU sẽ chuyển sang thực thi thu tục tương ứng với ngắt của card mạng thay vì lệnh tiếp theo. Ở đây có người đã do vào đống source code của kernel để xem một packet từ lúc NIC nhận được cho đến khi đến userspace nó đã đi qua bước nào:
T thấy quan điểm kiểu đó ngày nay cũng không còn đúng lắm nữa. Cái mô hình nhiều lớp mạng chỉ là mô hình logic, không nhất nhất thiết nó ánh xạ 1 - 1 phân việc rõ ràng giữa các thành phần phần cứng / phần mềm. Như cái card mạng hiện giờ, tiêu biểu như là mấy cái card multi-queue (bọn này thì chắc chưa thể gọi là card khôn lỏi được) thì nó hoàn toàn nhận thức được các layer cao hơn như layer 3 - 4. Tức là có thể có nhiều thành phần (card, kernel) cùng xử lý công việc liên quan đến một layer nào đó. Để quyết định xem một packet nên đi vào queue nào, nó sẽ dựa vào hash của tổ hợp các thông số như IPv4, IPv6, TCP port, UDP port. Hàm hash cụ thể mà NIC sử dụng có thể cấu hình được: RSS Hashing Types - Windows drivers (https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types) . Nhờ việc này mà các packet sẽ vừa được chia đều (về mặt trung bình) vào các queue, vừa đảm bảo tính sticky: cùng một connection sẽ luôn đi vào một queue duy nhất. Nhiều NIC còn cho phép cấu hình trực tiếp nên cho tổ hợp IP/Port nào đi vào queue nào luôn, không cần phải hash: Intel Flow Director (ntuple) Basics (https://wiki.gbe0.com/linux/firewalling-and-filtering/intel-flow-director/basics) . Một ứng dụng của cái này là cho phép bên vận hành có thể dành riêng một queue cho việc quản lý (vd như SSH hoặc một web management riêng) có thể truy cập được ngay cả khi server bị DDOS.
Ý nghĩa phân lớp logic là để chuyên môn hóa, thông thường tránh giẫm chân vào nhau nếu có thể. Khôn hay ngu không phải lựa chọn nhị nguyên nên nó có nhiều mức độ. "Không biết/Không quan tâm" không nhất thiết là không đọc được, mà là không vượt phạm vi trách nhiệm. Bạn cũng thấy với tính năng (configurable) multi queue như mô tả thì cũng là nó cố gắng làm tốt việc của nó ở layer 2, nó có thể parse IP nhưng nó sẽ không tham gia vào việc xử lý gói tin IP. Kể cả khôn hơn nữa như có thể export netflow thì cũng là giám sát thụ động, chứ không ai thực sự muốn làm cái card mạng có khả năng, ví dụ firewall IP đơn giản. Ở mấy trang trước tôi lấy 1 ví dụ rất dễ hiểu về ngành giao nhận logistics giống y như các lớp mạng, technically xét trường hợp có tunnel layer 3 như GRE, và bỏ qua phân mảnh. Thì có thể coi như card mạng xe tải/tàu container không biết về từng gói hàng IP bên trong bao tải/kiện hàng GRE. Thấy rõ việc phân lớp logic có ý nghĩa gì, không thể coi việc chờ đợi giao nhận xe tải với kho (lớp trung chuyển middle mile) có dính dáng trực tiếp với giao nhận đầu cuối (lớp last mile) được. Ở mỗi lớp, giao thức và đối tượng chuyển giao hoàn toàn khác, thường là bao chứa nhau.