Beej's Guide to Network Programming part 1

Mở đầu

Beej’s Guide to Network Programming

Giới thiệu

Hey! Có phải Socket programming đã làm bạn thất vọng? Bạn thấy quá khó để hiểu được các hướng dẫn từ man? Bạn muốn lập trình mạng thật cool, nhưng bạn không có thời gian để tìm hiểu structs nếu bạn đã từng gọi hàm bind() trước khi connect(), vân vân và mây mây, … Đoán xem, tôi đã từng làm những thứ không tốt đẹp, và đang qua thời chia sẻ thông tin với tất cả mọi người! Bạn đã đến đúng nơi. Tài liệu này dành cho các lập trình viên C trung bình và bạn cần nắm chắc về networking noise. Và cuối cùng tôi cũn gbawst kịp tương lai (vào phút chót!) đã cập nhật hướng dẫn về IPv6! Enjoy!

Vài lời với đọc giả

Tài liệu này được viết như một tutorial, không phải là một tài liệu tham khảo hoàn chỉnh. Nó có lẽ là tốt cho cá nhân những người mà chỉ mới bắt đầu với lập trình socket và đang tìm kiếm một nền tảng. Nó chắc chắn không phải là hoàn chỉnh hay tất cả các hướng dẫn về lập trình socket, bởi nghĩa nào đi nữa. Hi vọng rằng, thông qua nó sẽ đủ để *man pages *bắt đầu có ý nghĩa… :-D

Nền tảng và trình biên dịch (Platform and Compiler)

Mã nguồn được sử dụng trong tài liệu đã được biên dịch trên các máy tính linux sử dụng Gnu’s GCC compiler. Tuy nhiên, nó có thể build trên bất kì nền tảng nào sử dụng gcc. Điều này không áp dụng nếu bạn đang lập trình trên windows. (Hãy xem mục dành cho lập trình Windows).

Trang chủ và sách bán

Địa chỉ chính thức của tài liệu này là http://beej.us/guide/bgnet/. Tại đây bạn sẽ tìm được các code mẫu và được dịch thành nhiều ngôn ngữ khác nhau. Để mua bản copy, hãy vào http://beej.us/guide/url/bgbuy. Nó sẽ duy trì việc viết tài liệu của tôi.

Ghi chú cho người dịch

Nếu bạn muốn dịch hướng dẫn này ra các ngôn ngữ khác, hãy viết cho tôi và tôi sẽ dẫn bạn bản dịch của bạn tới trang chính. Hãy tự do thêm tên của bạn và địa chỉ liên hệ trong bản dịch. Vui lòng ghi chú giấy phép hạn chế trong mục Copy right và Distribution, bên dưới. Nếu bạn muốn tôi làm chủ bản dịch, hãy hỏi. Tôi cũng sẽ dẫn nó nếu bạn muốn làm chủ nó, cách nào cũng được.

Socket là gì?

Bạn đã nghe về “sockets” nhiều lần, và có lẽ bạn đang tự hỏi chính xác chúng là gì. Well, Chúng là đây: 1 cách để nói với các chương trình khác sử dụng chuẩn Unix file descriptors. What? Ok - bạn đã nghe vài lần về Unix hacker state, “Jeez, mọi thứ trong Unix đều là file!”. Bất kì ai đã lập trình Unix về I/O đều làm nó bằng cách đọc và viết các file descriptor. Một file descriptor đơn giản là một liên kết tới một file. Nhưng file này có thể là một kết nối mạng, một FIFO, một pipe, một terminal, một file thực trên đĩa, hoặc chỉ là bất cứ thứ gì khác. Mọi thứ trong Unix là tập tin. Vì thế khi bạn viết để giao tiếp với một chương trình khác thông qua mạng internet thứ bạn đang làm là thông qua một file descriptor, bạn nên tin nó thì tốt hơn. Vậy nơi nào để tôi lấy được file descriptor này để giao tiếp mạng, Mr Smarty Pantfs? có lẽ là câu hỏi cuối cùng trong đầu của bạn ngay lúc này, nhưng tôi không định trả lời nó bất kỳ lúc nào. Bạn đã gọi tới một socket(). Nó sẽ trả về socket descriptor, và bạn giao tiếp thông qua nó sử dụng chỉ định send() và recv() socket. “But hey!”. “Nếu nó là một file descriptor, tại sao trong tên của Neptune không thể. Tôi chỉ sử dụng lệnh read() và write() để giao tiếp thông qua socket?”. Câu trả lời là “Bạn có thể! Cụ thể là Bạn có thể, nhưng send() và recv() điều khiển tốt hơn việc truyền tải dữ liệu.” Các gì tiếp theo? Có những loại sockets nào? Có DARPA Internet addresses (Internet Sockets), path names on a local node (Unix Sockets), CCITT X.25 addresses (X.25 Sockets), và rất nhiều phụ thuộc vào hệ thống Unix mà bạn đang chạy. Tài liệu này chỉ đề cập tới cái đầu tiên: Internet Socket.

Hai loại Internet Sockets.

Nó là loại nào. Có 2 loại Internet sockets? Đúng, à không tôi đang nói dối đấy, Có nhiều hơn thế, nhưng tôi chỉ dọa bạn thôi. Tôi chỉ nói về 2 loại ở đây. Ngoài câu này, tôi chỉ muốn nói với bạn rằng “Raw Sockets”, cũng rất mạnh mẽ và bạn nên tìm hiểu chúng. Đúng rồi, 2 loại sockets? Một là “Stream sockets” và cái kia là “Datagram Sockets”, cũng tương ứng với “SOCK_STREAM” và “SOCK_DGRAM”. Datagram socket thường được gọi là “connectionless sockets”. Chúng có thể connect() nếu bạn thực sự muốn. Stream sockets là kết nối 2 chiều. Nếu bạn output 2 items tới socket theo thứ tự “1, 2” chúng sẽ đến đích đúng thứ tự “1, 2”. Chúng cũng thoải mái lỗi, Tôi chắc chắn chúng sẽ thoải mái lỗi, Tôi chỉ dự định đặt tay vào tai tôi và hát la la la nếu bất kì ai thử nói khác. Cái gì sử dụng stream sockets? Bạn đã nghe đến ứng dụng telnet, Nó sử dụng stream socket. Tất cả các kí tự bạn gõ cần được đến đúng thứ tự bạn gõ chúng phải không? Cũng như thế, trình duyệt web sử dụng giao thức HTTP, cũng sử dụng sockets để lấy các trang. Sâu hơn, nếu bạn telnet tới một website trên cổng 80 bạn gõ “GET /HTTP/1.0” và nhấn enter 2 lần, nó sẽ hiện ra HTML. Tuy nhiên stream socket này là high level? Chúng sử dụng một giao thức gọi là “The Transmission Control Protocol”, nói cách khác là “TCP”. TCP giúp chắc chắn dữ liệu của bạn được gửi theo trình tự và không có lỗi. Bạn đã nghe về “TCP” trước khi bạn nghe cả “TCP/IP”, IP là viết tắt cho “Internet Protocol”. IP giúp định tuyết và chịu trách nhiệm chính cho việc toàn vẹn dữ liệu. Cool, Thế còn về Datagram sockets? Như vừa nói chúng còn được gọi là connectionless? Chúng làm gì ở đây và tại sao chúng lại không đáng tin cậy? Sự thật là: nếu bạn gửi một datagram, nó có thể tới, Nó có thể tới không theo thứ tự. Và nếu tới dữ liệu sẽ không có lỗi. Datagram socket cũng sử dụng IP cho việc định tuyết, nhưng bạn sẽ không sử dụng TCP, chúng sử dụng “User Datagram Protocol” hay “UDP” Tài sao lại connectionless? Well, về cơ bản, bạn không phải duy trì kết nối như bạn làm với stream sockets. Bạn chỉ tạo một packet, đóng theeo một IP Header trên nó cũng với thông tin địa chỉ nhận và gửi nó. Không cần kết nối. Chúng được sử dụng khi TCP không có sẵn hoặc khi một vài gói tin bị hủy bỏ. Ví dụng ứng dụng tftp (trivial file transfer protocol, em trai của FTP), dhcpcd( DHCP client), multiplayer games, streaming audio, video hội nghị, v.v… Chời một phúc. tftp và dhcpcd được sử dụng để chuyển binary applications từ một host tới những cái khác! Dữ liệu có thể mất nếu bạn mong muốn ứng dụng hoạt động khi nó tới. Đây là một loại tà thuật của nó? Well my human friend, tftp và một chương trình đơn giản có giao thức của nó trên UDP. Ví dụ giao thức tftp nói với mỗi packet gửi đi, người nhận sẽ gửi trả các packet này và nói “Tôi đã lấy nó” (một ACK packet). Nếu người nhận được gói tin chính không trả lời, 5 giây sau, anh ta sẽ gửi lại packet cho tới khi anh ấy nhận lại ACK. Thủ tục ackowledgment là tối quan trọng khi implement ứng dụng SOCK_DGRAM. Với ứng dụng không tin cậy như games, audio hay video, bạn chỉ việc bỏ qua các gói tin, hoặc có lẽ khéo léo bù lại chúng (Người chơi quake sẽ biết tới accursed lag). Từ accursed (bị nguyền rủa) ở đây là việc cực kì báng bổ thần linh. Tại sao bạn sử dụng giao thức không tin cậy. Có 2 lý do, tốc độ và tốc độ. Nó là nhanh nhất để gửi và quên hơn là giữ. cái mà việc nhận antoafn và chắc chắn thứ tự và tất cả. Nếu bạn gửi một tin nhắn. TCP là greate, nhưng nếu bạn gửi 40 vị trí cập nhật trên giây của các người chơi trên toàn thế giới, có lẽ sẽ nó sẽ không là vấn đề gì nhiều nếu có một 2 cái không nhận được và UDP là sự lựa chọn tốt.

Low level Nonsendse (vô lý) và Network theory (Lý thuyết mạng).

Kể từ khi, tôi nhắc tới việc phân lớp các giao thức, là thời điểm để nói về việc mạng thực sự làm việc như nào, Trong thực tế bạn có thể bỏ qua phần này. Nó là một nền tảng tốt dù gì đi nữa. Bỏ qua tạm đi, hiểu rồi mình sẽ quay lại sau //TODO

Kết thúc