Vâng, em nhầm, em cứ nghĩ là cứ port 80 thì đc xử lí bởi HTTP server trên server. Hìhì, server có thể quy định cổng 80 là do process nào xử lý cũng đc nhỉ.
Cái gói TCP này source port là 2506 và Destination Port là 80. Có phải phần data kia đã được Y!M client mã hóa ko ạ, và có thể dùng công cụ nào để giải mã nó ra dạng text bình thường ạ 

Theo tôi packet trên ko phải được mã hoá mà chẳng qua đây là "ngôn ngữ" của protocol YM nói chuyện với nhau thôi, để hiểu được ngữ nghĩa của chúng thì bạn phải đọc thật kỹ RFC của các giao thức YM  

Theo tôi packet trên ko phải được mã hoá mà chẳng qua đây là "ngôn ngữ" của protocol YM nói chuyện với nhau thôi, để hiểu được ngữ nghĩa của chúng thì bạn phải đọc thật kỹ RFC của các giao thức YM  

==> mã hexa lù lù thế kia, ngôn ngữ nào ở đây

 

Ặc, ý gì đâu. nokia1100 đưa ra nội dung của một packet thì cái nội dung đó dĩ nhiên phải ở dưới dạng hexa chứ còn cái gì nữa mà phải bàn 

Theo tôi packet trên ko phải được mã hoá mà chẳng qua đây là "ngôn ngữ" của protocol YM nói chuyện với nhau thôi, để hiểu được ngữ nghĩa của chúng thì bạn phải đọc thật kỹ RFC của các giao thức YM  

==> mã hexa lù lù thế kia, ngôn ngữ nào ở đây

 

Bạn ko thấy 2 dấu trong ngoặc hay là giả vờ ko thấy vậy ? Ngôn ngữ ở đây chính là protocol (đừng nói với tôi protocol ko phải ngôn ngữ nhá :lol ). Mã hex lù lù thì sao ? Bộ có packet nào ko phải là mã hexa à ? Cho dù là SSL hay VPN hay SSH mã hoá hay có qua cả chục protocol khác thì sniff lên đều ra mã hexa thôi, nếu bạn tìm được cái packet nào sniff lên mà ko phải là mã hexa thì xin up lên đây, tôi xin bái bạn làm sư phụ

Lần sau tìm hiểu kỹ TCP/IP rồi hãy nói nhé  

bạn tìm hiểu tcp/ip kỹ chưa mà khuyên người ta ?
1. Theo ngữ cảnh của bạn, "ngôn ngữ" là gì ?
2. packet chẳng mắc mớ gì tới hex hay cái gì gì hết. packet PAYLOAD được hiển thị ở dạng hex thì khả dĩ (bởi vì packet không chỉ gồm nội dung, vậy những thứ liên quan tới header có được ethreal hiển thị dạng hex không ?, rõ ràng là không!). Khái niệm packet được define ở OSI Network layer, hex/bin/dec là cách application interpret cái view của mình tùy theo packet content. Ethereal display packet payload ở dạng hex, không có nghĩa là không có ai có quyền code cái packet sniffer hiển thị thông tin sniff được ở dạng bin, octal hay cái gì khác.
 

to vietwow: đúng là tớ chả biết gì về TCP/IP cả, mong bạn chỉ dạy ).  

Còn hexa ở trên là do các chương tình sniffer & analyer Ethereal hiển thị. Như vậy thì việc hiển thị hexa hay decinmal hay ASCII là do chương trình sniff sử dụng quy định chứ ko phải là do "packet content" như bạn nói
 

1. Tui không rõ bạn nghĩ chữ ngôn ngữ như thế nào nên mới hỏi lại. Tui không make any statement rằng bạn không hiểu chữ ngôn ngữ. Protocol thiếu nhiều đặc tính của 1 ngôn ngữ nếu nói về khía cạnh linguistic, chính xác hơn nó được định nghĩa là tập hợp những "quy ước" về giao tiếp.

2. Ở khái niệm "đường dây mạng" KHÔNG tồn tại khái niệm packet. OSI make clear separation giữa các layer mới nhau, layer này hoàn toàn không biết và không cần thiết phải biết tới những gì định nghĩa ở layer khác. Khái niệm "đường dây mạng" của bạn nằm ở tầng mấy của OSI ? Khái niệm packet nằm ở tầng mấy của OSI ? Nên nói "packet đi trên đường dây mạng là tín hiệu điện" liệu có chính xác ? Nếu bạn đã không phân biệt rõ ở chỗ này, dĩ nhiên bạn sẽ không phân biệt rõ giữa cái gì khái niệm 1 packet và khái niệm 1 "view" của nó, bởi vì 2 khái niệm này nằm ở 2 tầng khác biệt nhau của OSI.

Do vậy, ý tui muốn phản bác với bạn nằm ở câu này trong bài post trên của bạn: "Bộ có packet nào ko phải là mã hexa à". Bởi vì ở đây, bạn cho rằng 1 packet (khái niệm ở Network layer) và cái nội dung in vào mắt mình (Application layer) làm một. Và do đó tui make 1 statement là "Hoàn toàn có thể code 1 sniffer để hiển thị NỘI DUNG của packet dưới dạng khác hex".

Và ý cuối cùng của bạn cũng có cái đáng để nói:
- Có vẻ bạn cho rằng TCP/IP là bộ network protocol duy nhất. Điều này bạn xem lại nhé, tui đưa thêm vài thứ cho bạn tham khảo: APPLETALK, DECNET, thậm chí là NETBEUI, tất cả đều là network protocol suite.
- OSI chứa TCP/IP, TCP/IP là 1 phần của OSI, nói cái này là "hoạt động thực sự", cái kia là "chuẩn" để tham khảo là sai, cả 2 đều là chuẩn.

edited: tui vừa post xong thì hình như bạn edit lại post của mình, nên tui quote tiếp phần này

vietwow wrote:

Còn hexa ở trên là do các chương tình sniffer & analyer Ethereal hiển thị. Như vậy thì việc hiển thị hexa hay decinmal hay ASCII là do chương trình sniff sử dụng quy định chứ ko phải là do "packet content" như bạn nói
 

- Phần tô đậm là bạn lặp lại ý của mình ở trên, vui lòng xem lại
- Vui lòng xem lại luôn là tui nói ở đâu trong bài post trước là "packet content là hex" ? Người nói ý đó là bạn, khi cho rằng "Bộ có packet nào ko phải là mã hexa à " và tui phản bác lại chính ý đó. 

Thứ 2 bạn nói "layer này hoàn toàn không biết và không cần thiết phải biết tới những gì định nghĩa ở layer khác" là hoàn toàn sai, cái layer vẫn có 1 số cái phụ thuộc nhau. Cụ thể là dưa vào trường Ethernet type trong Ethernet header thì TCP/IP Stack mới biết header tiếp theo nó phải xử lý là gì (IP hay ARP/RARP ...), tương tự dựa vào trường Protocol trong IP header thì TCP/IP Stack mới biết header tiếp theo nó phải xử lý là gì (là ICMP hay UDP hay TCP), và cuối cùng dựa vào trường port trong TCP/UDP header thì TCP/IP Stack mới biết header tiếp theo nó phải xử lý là gì (là DNS hay HTTP ...). Tất cả chúng đều có 1 mắc xích liên quan đến nhau
 

2. Bạn nhầm lẫn: 1 protocol có thể trải dài nhiều layer, nhưng 1 layer không thể hiểu những quy định của layer khác. ARP/RARP có thể có những specification nằm ở 2 layer, nhưng nếu nói vậy rồi cho rằng datalink layer hiểu về những thứ defined ở network layer là trật lất. Nói thẳng ra luôn, trong 1 OS, phần IP trong TCP/IP kernel stack làm gì ? một là logical addressing, 2 là packet routing. Trong những thứ đó, datalink hiểu gì ? Chẳng hiểu gì hết.

- Ví dụ của bạn về sự tồn tại của field 'Protocol' trong IP header không chứng minh được là Network layer HIỂU về những thứ xác định ở Transport layer, nó ở đó chỉ với mục đích là để TCP/IP stack biết đường mà forward cái datagram đó lên đúng cái protocol handler tương ứng. Việc interpret và process data không thuộc về chức năng của nó nữa, nên tui nói nó không hiểu về các định nghĩa của lớp trên là không sai.

- Riêng về ví dụ port của bạn, cũng nói luôn với bạn rằng trong chức năng của TCP/IP stack, TCP không biết/không cần biết những app nào sẽ handle cái data này, những gì nó làm khi nhân được data là tách header ra, notify kernel là data available for reading trong cái socket receive buffer của cái socket descriptor nào đang associate với port đó, ngay bản thân việc read cái data từ cái socket buffer cũng chẳng còn thuộc về phần chức năng của TCP nữa, mà thuộc về IO và virtual file subsystem, chứ đừng nói tới việc TCP biết app nào đã request để open cái descriptor đó, và expect data kiểu gì. Bạn đừng gom luôn chức năng nhiều kernel subsytems lại với nhau và cho rằng đó là chức năng riêng của TCP chứ. Bạn sai khi cho rằng TCP/IP stack xử lý cái header "tiếp theo" sau TCP header. Nó chẳng xử lý gì cả vì chẳng biết gì để xử lý.

3. Tui đồng ý ở điểm này, sở dĩ có sự tranh luận ở bài trên vì tui nghĩ bạn đang refer tới 2 layer thuộc OSI model. my bad ! btw, có lẽ bạn không cần phải mở mang cho tui về các mailling list, tui frequent những maillist như vậy từ lâu lắm rồi.

4. Những giao thức vừa kể không phải là hỗ trợ thêm, mà chúng predate OSI, chúng không còn được sử dụng nhiều vì thiếu những đặc điểm của OSI, đặc điểm quan trọng nhất có lẽ là không phân biệt rõ ràng giới hạn chức năng của 1 layer, dẫn đến khó khăn cho 3rd-party vendor khi develop 1 product để interoperate với 1 product trước đó. Nếu bạn vẫn cho rằng OSI không make clear separation giữa các layer, chứng tỏ bạn vẫn chưa nắm được nguyên nhân ra đời của OSI. Bạn nghiên cứu về networking bao lâu để nói như vậy ?

1. Còn riêng về việc bạn muốn biết tui học networking ở đâu thì xin trả lời sơ sơ, tui self-trained, chả có cisco ciskiet nào cả, và cũng self-employed luôn. Cũng nhân tiện xin bạn rút lại những lời cho rằng dân học cisco thì lặm OSI, bởi vì theo tui biết, cisco là biggest vendor về networking hardwares, và nó nếu cisco không hỗ trợ nhiều networking model thì chắc cũng chẳng ai hỗ trợ nhiều cả. Đừng nên claim cái gì mà mình không biết, kẻo dân học cisco chính gốc lại vào gây chuyện đấy. 

như tôi đã nói tôi khẳng định 100% như đã nói ở trên là nếu TCP/IP ko dựa vào trường Protocol, ehternet type hay port thì nó ko tài nào xử lý được gói tin nữa 

"Bạn bảo TCP/IP Stack chẳng xử lý gì cả vì chẳng biết gì để xử lý ? Nope, HTTP Protocol là gì ? Nó là giao thức nằm trong bộ TCP/IP ở tầng App, nó chính cái cái biêt cách xử lý như thế nào với 1 gói tin có Dst port là 80" 

....HTTP có thể sử dụng TCP như là underlying transport protocol, nhưng chẳng có ai cấm việc bạn thay thế TCP/IP bằng IPX/SPX để carry HTTP traffic, HTTP KHÔNG THỂ nhìn thấy cái gì thực sự carry traffic của nó ở lớp dưới. Need proofs ? google thử xem có tồn tại IPX web server không thì biết.
Một điều nữa là việc "xử lý gói tin có DST port 80" không thuộc thẩm quyền của HTTP. HTTP quy ước là quy ước các quy tắc xử lý "nội dung" của gói tin, không phải xử lý TCP info liên quan tới cái gói tin đó. Nói thẳng ra: HTTP biết gì về SYN, ACK, FIN flag, port của gói tin ? Nó có cơ hội nhìn thấy đâu mà xử lý ? Xử lý ở đây là xử lý data nhận được từ kernel IO subsystem hoàn thành tác vụ của nó và notify kernel để copy data từ kernel-space lên user-space.  

chào bạn,
1. nói tiếp về số 1 ở trên. Tui vẫn cho câu phát biểu của mình không sai. Có thể rephrase lại nó như thế này: "1 layer không biết những thứ được xác định ở layer khác và function ở layer khác". Như tui đã nói ở trên, việc IP header có 1 field là Protocol chỉ giúp cho nó biết chính xác cái PROTOCOL HANDLER để tiếp tục forward những gì còn lại, sau khi nó đã làm xong nhiệm vụ là decapsulate cái ip header. Đó là ý của tui, còn tui nghĩ nếu bạn interpret ý của tui như bài vừa post thì bạn cần đọc lại bài trên của tui.
Mà nói thiệt, không cần refer tui tới 1 tool như hping, nếu muốn tui có khả năng viết 1 tool để craft 1 raw packet như hping. Còn việc protocol ID nào được kernel process, cũng nói với bạn luôn, khỏi test mất công: hầu hết kernel chỉ auto process normal packet có Protocol field value là 1 (ICMP), 2 (IGMP), 6 (TCP), và 17 (UDP) và drop mọi packet khác, trừ phi bạn obtain thẳng raw data từ datalink layer rồi tự process nó, xây dựng custom procol handler để process mấy cái datagram có Protocol field value khác. Đây là điều mà mấy route processor trong mỗi router làm để process routing packets.

Tui quote lại câu mà bạn cho là bạn hiểu đúng ý tui:

như tôi đã nói tôi khẳng định 100% như đã nói ở trên là nếu TCP/IP ko dựa vào trường Protocol, ehternet type hay port thì nó ko tài nào xử lý được gói tin nữa 

Tui không hề tuyên bố như thế trong bất cứ post nào của tui trong thread này, bạn có thể dẫn chứng ra nếu tìm thấy. Tui nói là 1 layer chỉ làm đúng chức năng của nó, không cần biết chức năng của layer khác là như thế nào. Network layer sử dụng Protocol field để tiếp tục forward cái decapsulated payload sang cho đúng cái protocol handler, không có nghĩa là nó CÓ KHẢ NĂNG hiểu và làm được những gì cái protocol handler đó sẽ làm.
Bạn có lẽ nhầm lẫn ở chỗ này, việc bạn biết được số điện thoại của nhà mình không làm cho bạn biết được phương thức đánh số của nhà cung cấp (xin lỗi, poor example).

2.

"Bạn bảo TCP/IP Stack chẳng xử lý gì cả vì chẳng biết gì để xử lý ? Nope, HTTP Protocol là gì ? Nó là giao thức nằm trong bộ TCP/IP ở tầng App, nó chính cái cái biêt cách xử lý như thế nào với 1 gói tin có Dst port là 80" 

Câu này thì tui để mọi người đánh giá. Bạn đi từ sai lầm này đến sai lầm khác. HTTP có thể sử dụng TCP như là underlying transport protocol, nhưng chẳng có ai cấm việc bạn thay thế TCP/IP bằng IPX/SPX để carry HTTP traffic, HTTP KHÔNG THỂ nhìn thấy cái gì thực sự carry traffic của nó ở lớp dưới. Need proofs ? google thử xem có tồn tại IPX web server không thì biết.
Một điều nữa là việc "xử lý gói tin có DST port 80" không thuộc thẩm quyền của HTTP. HTTP quy ước là quy ước các quy tắc xử lý "nội dung" của gói tin, không phải xử lý TCP info liên quan tới cái gói tin đó. Nói thẳng ra: HTTP biết gì về SYN, ACK, FIN flag, port của gói tin ? Nó có cơ hội nhìn thấy đâu mà xử lý ? Xử lý ở đây là xử lý data nhận được từ kernel IO subsystem hoàn thành tác vụ của nó và notify kernel để copy data từ kernel-space lên user-space.

Bạn đọc hết cái HTTP rfc xem nó có chữ nào là chữ port không ?
http://www.w3.org/Protocols/rfc2616/rfc2616.html

Không tin nữa thì bạn kiếm quách 1 web server code mà nhìn cái core function của nó xem chỗ nào nó hiểu và xử lý Transport layer info. Thứ duy nhất có số 80 chắc chỉ là lúc nó declare server socket. Còn việc thực sự xử lý các network IO liên quan tới socket này không còn thuộc chức năng của web server nữa.

4. Tui cũng đã xác nhận là tui misread bạn vì bạn refer tới TCP/IP MODEL, tui lại hiểu là bạn refer tới TCP/IP layer thuộc về OSI MODEL. Hy vọng bạn cũng do some favor và đọc lại ý của tui. Việc bạn refer tui tới những tài liệu, website "nổi tiếng" thì tui cám ơn bạn, mặc dù thực sự không helpful lắm với tui vì tui đã đọc 3 cái đó từ đời tám hoánh nào rồi.

Liên quan tới Cisco, do bạn đề cập nó trước, và make 1 assumption là tui đã từng học CCNA nên lậm OSI. Sorry bạn, nhưng cá nhân tui, dù dốt, nhưng cũng đã có cơ hội thảo luận với không ít người tài giỏi khác, nhưng tui không quan tâm tới cái background của họ, tui cũng không bao giờ hỏi, hoặc giả định rằng kiến thức của họ từ cái nguồn nào ra. Việc bạn đã tiếp xúc với bao nhiêu người có CCIE tui cũng chẳng quan tâm, tui quan tâm duy nhất tới cái khía cạnh bạn đưa ra ở topic này, còn bạn học ở đâu để đưa ra thì tui mackeno. Mà nói thiệt với bạn nhé, tui chẳng cần phải nhờ tới 1 "chuyên gia" Cisco để thảo luận với bạn, nếu bạn cứ tiếp tục diễn đạt mức hiểu của bạn về networking như vậy.

Về thái độ thảo luận, hy vọng bạn có thể làm được điều này
- Nếu cho rằng tui đã nói cái gì, vui lòng quote chính xác lại, và diễn dịch lời nói của tui theo cách hiểu của bạn. Điều này giúp tui biết được tui và bạn không đồng ý ở điểm nào trong lời nói của tui, tui sẽ sửa nếu quan điểm của bạn đúng.
- Không nên cho rằng người nào tham gia thảo luận đều là "thắc mắc chỗ nào chứ nói".
- Không nên assume bất cứ điều gì về technical background của người ta.
- Không nên bảo người ta phải nhờ tới "chuyên gia" để tiếp tục thảo luận với mình, bạn hơi tự cao đấy.

Cuối cùng là tui refer bạn đọc về OS concept, về kernel subsystems, để xem bao nhiêu thứ được dùng trong khi implement OSI 7 layers, để biết tới lớp nào thì kernel perform context switch từ userspace sang kernelspace khi handle data to/from network. Bạn học OSI mà không hiểu lớp nào đang được phần nào của kernel handle thì cũng như học vẹt, chả tác dụng gì đâu.

Tui bắt đầu cảm thấy đủ với việc tiếp tục thảo luận trong topic này. 

Em dùng Wireshark để bắt gói tin, và theo dõi thì thấy có những thông điệp HTTP rất lạ (nghĩa là ko giống khi duyệt web), ở phần info của Wireshark có ghi là Continuation or non-HTTP traffic, phần trong của thông điệp này chỉ có trường Data với nội dung như sau

Em để ý thấy những thông điệp này đc gửi đi khi dùng Yahoo! Messenger sau khi update từ Y!M 8.1.0.412 lên 8.1.0.413. Mặc dù trước đó (phiên bản 8.1.0.412) thì rõ ràng là Y!M dùng Port 5050. Vậy có phải là Y!M đã chuyển từ dùng giao thức YMSG (port 5050) sang dùng giao thức HTTP (port 80) ko nhỉ (giờ tuyệt nhiên ko filter đc cái YMSG nào). Em nghĩ là tất cả các thông điệp HTTP phải có chung khuôn dạng là

Và có cách nào giải mã được đoạn ký tự loằng ngà loằng ngoằng kia ra dạng Text đc ko ạ 

À, các bác ơi cho em hỏi là dùng Etheral có thể bắt đc cái gói tin đi trong mạng LAN từ máy tính của nhà hàng xóm đc ko ạ 

Thế bạn có đọc đc mật khẩu đăng nhập ko )