thảo luận Câu hỏi phỏng vấn - làm sao nodejs chạy với 1 thread?

[jiiren]

Khách hàng của tôi thường non-tech, hoặc là sếp không muốn đọc chi tiết, của bạn chắc vì làm low level thì khách hàng là đám tech ở trên.

Cái hại là bị rối dẫn đến nản chí vào hiểu sai đấy. Còn hiểu hết thì ngon rồi, nhưng quên bớt đi để nhìn ở tầm cao hơn, nếu không phải làm việc hàng ngày với nó.
Ví dụ về redux là ngược của ông hoctrokhoa khi đứng ở low level đơn giản hóa quá mức lớp trừu tượng phía trên đấy. Nói redux là vùng nhớ global kèm cơ chế bảo vệ đúng giọng mấy ông low level mà không ai hiểu redux nó làm gì.
Nếu dùng 1 từ để mô tả bản chất của Redux thì tôi sẽ chọn Mealy state machine, cái này cũng học trong trường như OS nhé

Chuẩn, Redux đúng ra là Mealy state machine, chứ đừng xem nó chỉ là global store
respect thím

 

[lekhoa3287]

năm vừa rồi tôi phỏng vấn khá nhiều, thậm chí là tuyển cả người cho team mà tôi không lead.

Phase 1 chào hỏi nhau xong thì tôi hỏi về các dự án của các ứng viên đã làm:

• Kể qua về một vài dự án mà bạn đã làm?
• Hãy mô tả sâu hơn về dự án A, chỗ này dùng công nghệ gì-Why? chỗ kia thiết kế ra sao-Why? cái this ở chỗ that có hiệu quả không? đã gặp vấn đề abc chưa? quan điểm của bạn về cái abc là gì?... tiếp tục follow-up bằng chính câu trả lời của ứng viên + Why, Why và Why?

Sang phase 2 thì tôi hỏi problem solving, tôi sẽ đưa ra vấn đề trong dự án thực tế rồi yêu cầu ứng viên confirm khi đã hiểu rõ câu hỏi và đưa ra giải pháp, discuss với tôi như một team dev đang làm technical planning. Ứng viên đưa ra solution xong thì tôi sẽ cùng ứng viên phân tích và mổ xẻ, sau đó tôi sẽ đưa ra solution của tôi, ứng viên có thể xanh chín cãi lại/đưa ra quan điểm.

Tựu chung, tôi gần như không bao giờ hỏi lý thuyết nhưng sau buổi phỏng vấn tôi vẫn có đủ dữ liệu và bằng chứng để đánh giá ứng viên có nắm vững kiến thức nền hay không. cũng ít bị rơi vào lỗi hay gặp là hỏi tùm lum kiến thức nhưng cái đel bao giờ dùng tới.

kết quả:

• sếp tôi feedback là happy về mindset và năng lực làm việc của nhân sự mới, không chỉ là chuyên môn mà còn phải đủ cả kĩ năng mềm để đạt được autonomous
• xin feedback từ các member khác thì họ cũng an tâm làm việc chung với đồng nghiệm mới
• bản thân ứng viên cũng vui vẻ khi kết thúc buổi phỏng vấn, dù thậm chí đôi khi họ biết rõ đã trượt. HR cũng thường xuyên forward lại feedback của ứng viên cho tôi.

dĩ nhiên data của tôi là quả nhỏ để đưa ra bất cứ kết luận nào để hay khẳng định nó sẽ work với người khác.

---
Còn về yếu tố rèn luyện kiến thức thì dĩ nhiên biết càng nhiều là càng tốt (về mặt tích lũy kiến thức). Nhưng đừng nhầm lẫn rằng mọi kiến thức sẽ được đóng góp vào value stream khi làm việc. Reflected Glory/IKEA effect/Dunning-Kruger Effect là những cái rất hay gặp và nó tạo ra một ảo tưởng và hưng phấn phê pha từ dopamine peak kịch trần.

Bỏ thời gian ra học nó cũng như bỏ tiền mua bảo hiểm, nếu anh không bao giờ ra đường thì chỉ có đần mới mua bảo hiểm đâm đụng, cái anh cần là biết rằm trên đời này có tồn tại một thứ là bảo điểm đâm đụng là đủ rồi (unknown-unknown). cuộc sống còn quá nhiều chi phí khác đang đợi các anh trả. khi nào anh ra đường nhiều, thấy có nhu cầu thì mua.

Cách làm của bạn này hay, kết hợp được cả hai.
Respect!

 

[gintaku123123]

trước mình cũng nghiện tìm tòi low level mặc dù là chỉ code app
và đúng là nó có khiến mình vượt trội hơn các bạn chỉ biết high level

có 1 lần bị 1 vấn đề là cái batch nó cứ chạy 5 lần là bị treo 1l
đọc log thì thấy nó bị treo ở chỗ gọi sang yahoo shopping API (giống shopee nhưng của đám nhật lùn)
cái mình check lại thấy có set time out rùi mà ta, nếu nó ko rep hoặc ko connect đc thì nó sẽ quăng lỗi và end batch, nhưng nó lại ko, cứ treo ở đúng cái dòng log
"Waiting yahoo API response...."
mình tái hiện các kiểu ko ra. Thế rồi sẵn kiến thức low level network ít ỏi của bản thân, mình dùng tcpdump để theo dõi packet
và rồi nhận ra là thằng yahoo này rất mất dạy và cái library request mình dùng cũng ko "thông minh" lắm .
thông thường khi bên server nó ko muốn nch với mình (client) nữa thì nó sẽ gửi mình 1 packet tcp để báo là tình ta chấm dứt (graceful shutdown?), nhưng thg yahoo này mất nết nó chả nói năng gì thế là cái app mình cứ đứng chờ nó trong vô vọng
thế là để fix nóng thì phi vào cái library đó trick lỏ lại để nó handle case này.

chuyện cũng lâu và kiến thức cũng lỏ đi nhiều rồi, các fen đọc cho vui

 

[Esquie]

trước mình cũng nghiện tìm tòi low level mặc dù là chỉ code app
và đúng là nó có khiến mình vượt trội hơn các bạn chỉ biết high level

có 1 lần bị 1 vấn đề là cái batch nó cứ chạy 5 lần là bị treo 1l
đọc log thì thấy nó bị treo ở chỗ gọi sang yahoo shopping API (giống shopee nhưng của đám nhật lùn)
cái mình check lại thấy có set time out rùi mà ta, nếu nó ko rep hoặc ko connect đc thì nó sẽ quăng lỗi và end batch, nhưng nó lại ko, cứ treo ở đúng cái dòng log
"Waiting yahoo API response...."
mình tái hiện các kiểu ko ra. Thế rồi sẵn kiến thức low level network ít ỏi của bản thân, mình dùng tcpdump để theo dõi packet
và rồi nhận ra là thằng yahoo này rất mất dạy và cái library request mình dùng cũng ko "thông minh" lắm .
thông thường khi bên server nó ko muốn nch với mình (client) nữa thì nó sẽ gửi mình 1 packet tcp để báo là tình ta chấm dứt (graceful shutdown?), nhưng thg yahoo này mất nết nó chả nói năng gì thế là cái app mình cứ đứng chờ nó trong vô vọng
thế là để fix nóng thì phi vào cái library đó trick lỏ lại để nó handle case này.

chuyện cũng lâu và kiến thức cũng lỏ đi nhiều rồi, các fen đọc cho vui

HTTP request hả bác? vậy vậy timeout là client chủ động kill chứ đâu có chờ gì từ server đâu nhỉ? vậy câu hỏi đặt ra là HTTP client đã thực sự xử lý timeout chưa?

 

[jiiren]

HTTP request hả bác? vậy vậy timeout là client chủ động kill chứ đâu có chờ gì từ server đâu nhỉ? vậy câu hỏi đặt ra là HTTP client đã thực sự xử lý timeout chưa?

Cũng thắc mắc giống bác, đa phần nếu trong HTTP request có timeout header thì client sẽ tự động terminate

 

[lekhoa3287]

HTTP request hả bác? vậy vậy timeout là client chủ động kill chứ đâu có chờ gì từ server đâu nhỉ? vậy câu hỏi đặt ra là HTTP client đã thực sự xử lý timeout chưa?

Chắc là lúc đầu bác này nghĩ là cái lib nó sẽ cover hết các case cho mình.

 

[gintaku123123]

sorry mấy bác chứ chuyện lâu quá r cũng ko nhớ chính xác cái gì đã xảy ra nữa.

mình cũng debug quanh cái timeout thôi, nhưng có vẻ cái thư viện mình xài nó chỉ set timeout connection , chứ ko có timeout read
Phía server nó established connection xong nó ngủm đi đâu luôn nên cái socket mình cứ treo đấy đợi data từ nó

 

[Esquie]

sorry mấy bác chứ chuyện lâu quá r cũng ko nhớ chính xác cái gì đã xảy ra nữa.

mình cũng debug quanh cái timeout thôi, nhưng có vẻ cái thư viện mình xài nó chỉ set timeout connection , chứ ko có timeout read
Phía server nó established connection xong nó ngủm đi đâu luôn nên cái socket mình cứ treo đấy đợi data từ nó

Thế mình mới hỏi nó là HTTP phải không. hay là web socket. vì cơ chế xử lý của 2 cái này khác nhau.

Nhưng HTTP hay WS thì nó đều chỉ ra là phần xử lý "batch" của bác đang có một vấn đề khác

Best practice khi xây dựng hệ thống background jobs/sheduling là cần:

• Phải tính tới việc kill process nếu nó chạy lâu bất thường nếu không thì nó sẽ gây nghẽn (timeout/lease expiration/heartbeat/monitoring).
• Khi implement code cũng cần tính tới việc process đang chạy thì bị kill giữa chừng, cần design/implement theo hướng có thể retry dễ dàng mà không lo làm hỏng data/tạo ra side effect (idempotency - tuy nhiên không phải lúc nào cũng cần).

Đây là những criteria must have của background jobs/sheduling system để đạt resilience.

nếu chỉ thiết kế theo hướng đặt niềm tin mọi "moving part" sẽ luôn hoạt động đúng thì hệ thống đó có quá nhiều break/weak point để fail

 

[condao]

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.


Xem tệp đính kèm 3653639
Xem tệp đính kèm 3653711

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.

Core Dumped

Hello and welcome to Core Dumped. I'm a CS Engineer and I love teaching others about complex concepts I've learn over the years, but in a simple and easy to understand format.

www.youtube.com

dev go mà nhìn vô cười khẩy quá ahihi

 

[blacksnow2919311]

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

 

[Nhà Cấp 4]

Mấy cái ông nói thì chả base trên low level.

SE thì gặp bug hay edge case khó cũng phải tính toán và cân nhắc cả tầng đó, vả lại cũng chỉ là kiến thức đã được dạy ở đại học chứ có xa rời thực tế đếch đâu, tôi thắc mắc ông anh làm swe ở công ty nào đấy.

Vì bigtech từ tây đến tàu thì cũng sẽ có những issue chạm đến layer này, và nó không hiếm, lúc ấy nếu không có gì trong đầu thì ông xử lý làm sao?

thím có thể chia sẻ cho e 1 vài ví dụ thử được không, em muốn tìm hiểu thử các big problem cần tới low level như này, để có keyword tìm hiểu thử thôi - đọc qa thớt này khá cuốn và e cũng muốn tìm hiểu thử
---

 

[Trình Hà Lân]

nhưng thím có thể chia sẻ cho e 1 vài ví dụ thử được không, em muốn tìm hiểu thử các big problem cần tới low level như này, để có keyword tìm hiểu thử thôi - đọc qa thớt này khá cuốn và e cũng muốn tìm hiểu thử
---

thím cứ lên engineering blog mấy big tech mà đọc

 

[picolami]

thím có thể chia sẻ cho e 1 vài ví dụ thử được không, em muốn tìm hiểu thử các big problem cần tới low level như này, để có keyword tìm hiểu thử thôi - đọc qa thớt này khá cuốn và e cũng muốn tìm hiểu thử
---

Tìm cách làm sao kết nối VPN mà dùng hết được đường truyền card mạng 1Gbps ? rồi 10 Gbps ?

 

[blacksnow2919311]

Cần đọc sách cơ bản về OS nếu chưa đọc, đọc rồi thì cần hiểu kỹ và đúng hơn. Trong sách có hết đấy, thế nào là process, os level thread, user level thread, cấp phát bộ nhớ trên heap và stack như thế nào, đặc tính gì

Nhắc lại là đọc kỹ giáo trình về OS, để biết khái niệm cơ bả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

 

[1457040007]

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

Đang đọc cuốn này nè fence.
Có vẻ là hiểu được concept, trong cuốn này cũng có nhắc tới nodeJS và concept event loop

 

[bribnt]

Card mạng nào báo cho CPU cha
Kernel OS mới là thằng xử lý nhé.

Cái gì vậy trời

Ở đây tôi không phải chê trách gì, dev thì có nhiều dev, nhiều ngành nghề. Ai làm "tầng trên" thì làm, biết fundamental là được. Tôi làm "tầng dưới" cũng không rõ mấy cách "tầng trên" làm ra sao. Đôi khi viết C# để viết mấy tool linh tinh test với hardware thôi.

NHƯNG bớt xàm lol, hiểu chưa rõ đi hỏi ứng viên rồi xàm lol lần nữa trên mạng. Thay vì nội dung trao đổi thì lại đi dạy khôn, kiến thức "low level" thiếu hụt trầm trọng mà nói chuyện trịch thượng quá.

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:

Monitoring and Tuning the Linux Networking Stack: Receiving Data | Packagecloud Blog

This post guides you through monitoring and tuning the Linux network stack with the focus on receiving data.

blog.packagecloud.io

 

[bribnt]

Thường tôi không có hứng viết nhiều nhưng đang chờ WC nên rảnh tay viết nhanh tí.

Nhắc lại là đọc kỹ giáo trình về OS, để biết khái niệm cơ bản, để biết 1 trong những nhiệm vụ quan trọng nhất của OS là Lập lịch (Scheduling) cho các cpu core, tại mỗi thời điểm thực thi code tại 1 vị trí xác định trong virtual memory của 1 tiến trình nào đó.
Thế ngồi đợi nghĩa là gì? Hiểu được thì đỡ phát biểu kiểu O/S có phải bỏ ra 1 thread ngồi đợi phần việc đó chạy xong không
Về networking thì fen cũng cần đọc lại giáo trình mạng máy tính, mô hình mấy lớp, tại sao phân lớp như thế, card mạng ở lớp nào. Để đỡ nói mấy câu gây ngứa như OS giao phần việc ngồi đợi cho card mạng.
Công việc của card mạng là rất xác định, không cần nhận thêm, không cần ai chỉ bảo giao việc. Thông thường trừ bọn card mạng khôn lỏi ra thì địa chỉ IP trong packet còn không biết, định bảo nó chờ đợi cái gì? Packet đến tràn không xử lý thì drop, làm gì phải xoắn. Lắm khi OS còn phải chủ động đi mà poll xem có packet nào đến. Hoặc bọn user space app còn tự poll packet.

Có vẻ là fen đã để rớt sách trong trường không thèm đọc, rồi tổng hợp kiến thức bằng youtube và AI nên nó mới lỗ chỗ như này.

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.

 

[picolami]

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.

 

[khanhduy8]

Với low level thì mình đọc lí thuyết xong chắc phải debug qua gdb hay bất kỳ công cụ debug nào đó thì mới hiểu rõ được, xong thấy lùng bùng lại quay lại đọc lý thuyết. Giờ có AI thì ngồi cãi nhau với nó. Thực ra nhờ cãi nhau với AI mà thấy được lỗ hổng trong tư duy của mình. Mà chắc cũng nên quen với việc bị người khác đặt dấu hỏi chấm. Càng đọc đủ nhiều, gặp càng nhiều cao nhân thì càng thấy mình học k bao giờ là đủ. Đọc thread này mình lại nhớ hồi đó dùng proxychains cho nginx thì k thấy nó chạy qua proxy, thử haproxt bản cũ thì ổn, đoán là do epoll hay cái gì đó mà chưa có thời gian debug thử :v

 

[Có Ai Xúi Giục Em Không]

Với low level thì mình đọc lí thuyết xong chắc phải debug qua gdb hay bất kỳ công cụ debug nào đó thì mới hiểu rõ được, xong thấy lùng bùng lại quay lại đọc lý thuyết. Giờ có AI thì ngồi cãi nhau với nó. Thực ra nhờ cãi nhau với AI mà thấy được lỗ hổng trong tư duy của mình. Mà chắc cũng nên quen với việc bị người khác đặt dấu hỏi chấm. Càng đọc đủ nhiều, gặp càng nhiều cao nhân thì càng thấy mình học k bao giờ là đủ. Đọc thread này mình lại nhớ hồi đó dùng proxychains cho nginx thì k thấy nó chạy qua proxy, thử haproxt bản cũ thì ổn, đoán là do epoll hay cái gì đó mà chưa có thời gian debug thử :v

nodejs chắc chỉ debug bằng console.log thôi, muốn đào sâu cũng khó