รูปแบบการสื่อสารและความน่าเชื่อถือ (Reliability)

1Logical Channel และรูปแบบการสื่อสาร

เมื่อโปรแกรมเรียกใช้เครือข่าย มันไม่อยากควบคุมแรงดันไฟฟ้า จังหวะสัญญาณ หรือเลือก router ทีละตัว โปรแกรมต้องการช่องทางที่มีพฤติกรรมชัดเจน เช่น ส่งข้อมูลให้ปลายทาง รับคำตอบ หรืออ่านข้อมูลต่อเนื่อง ช่องทางที่โปรแกรมมองเห็นนี้เรียกว่า logical channel

ช่องทางเชิงตรรกะซ้อนอยู่บนเส้นทางทางกายภาพ

Logical channel คือภาพนามธรรมของการสื่อสารระหว่างปลายทาง แม้ข้างใต้ข้อมูลอาจผ่าน switch, router และ link หลายสิบช่วง แต่ application มองเห็นเหมือนมีช่องทางเชื่อมจากโปรแกรมหนึ่งไปยังอีกโปรแกรมหนึ่งโดยตรง

คำว่า “logical” ไม่ได้แปลว่าช่องทางนั้นไม่มีอยู่จริง แต่หมายถึงเราเลือกมองเฉพาะพฤติกรรมที่ระดับนี้สนใจ แล้วซ่อนรายละเอียดด้านล่างไว้ก่อน คล้ายการโทรหาเพื่อน เรามองเห็นเป็นการสนทนาระหว่างคนสองคน แม้สัญญาณจะผ่านสถานีฐาน โครงข่ายหลัก และระบบของผู้ให้บริการหลายส่วน

Client/Server เป็นบทบาท ไม่ใช่ชนิดของเครื่อง

ในการสื่อสารแบบ Client/Server client เป็นฝ่ายเริ่มขอบริการ ส่วน server รอรับและตอบสนอง คำเหล่านี้บอกบทบาทในการสื่อสารหนึ่งครั้ง ไม่ได้บอกว่าเครื่องหนึ่งต้องเป็น client หรือ server ไปตลอด เครื่องเดียวกันอาจเป็น server ต่อผู้ใช้ แต่เป็น client เมื่อเรียกฐานข้อมูลหรือบริการอีกตัวหนึ่ง

ตัวอย่างเช่น Order Service รับ request จากหน้าเว็บในบทบาท server แต่เมื่อมันเรียก Payment Service มันกลับอยู่ในบทบาท client ทันที การแยกบทบาทออกจากตัวเครื่องจะสำคัญมากเมื่อเข้าสู่ network service และ microservices

รูปแบบการสื่อสารไม่ได้มีเพียงสองแบบ

Request/Reply กับ Message Stream เป็นรูปแบบที่พบได้บ่อย แต่ไม่ใช่การแบ่งช่องทางทั้งหมด เราสามารถมองการสื่อสารได้หลายมิติ และแต่ละมิติตอบคนละคำถาม

Request/Reply: ขอหนึ่งครั้ง ตอบหนึ่งครั้ง

ใน Request/Reply ฝั่งหนึ่งส่งคำขอ แล้วอีกฝั่งส่งคำตอบกลับมา HTTP เป็นตัวอย่างที่คุ้นเคย รูปแบบนี้ตรงกับงานจำนวนมาก เช่น ขอหน้าเว็บ ตรวจยอดเงิน หรือบันทึกข้อมูลหนึ่งรายการ เพราะ application สามารถผูกคำตอบเข้ากับคำขอที่เป็นต้นเหตุได้

แต่ความง่ายนี้มีเงื่อนไข หากคำตอบมาช้า client จะรอนานแค่ไหน หาก timeout แล้ว request อาจทำงานสำเร็จไปแล้วหรือไม่ และหากส่งใหม่ server จะทำงานซ้ำหรือเปล่า Request/Reply จึงดูคล้ายการเรียกฟังก์ชัน แต่ remote call มีความไม่แน่นอนที่ local function ไม่มี

Message กับ Byte Stream: ซองจดหมายกับสายน้ำ

ช่องทางแบบ message-oriented รักษาขอบเขตของแต่ละข้อความไว้ หากส่งสามข้อความ ฝั่งรับก็มองเห็นเป็นสามหน่วย แม้รายละเอียดเรื่องการแตก packet ภายในอาจต่างออกไป ส่วน byte stream มองข้อมูลเป็นลำดับ byte ต่อเนื่องโดยไม่รักษาขอบเขตที่ application ส่งแต่ละครั้ง

จุดนี้สำคัญต่อการเขียนโปรแกรมมาก หาก sender เรียกส่งข้อมูลหนึ่งครั้ง ไม่ได้แปลว่า receiver จะอ่านได้ครบในครั้งเดียวเสมอไป โดยเฉพาะ TCP ซึ่งให้บริการแบบ byte stream Application ต้องสร้าง message framing เอง เช่น ระบุความยาวไว้ข้างหน้า ใช้ตัวคั่น หรือกำหนดรูปแบบข้อมูลที่บอกจุดสิ้นสุดได้

Streaming ไม่ได้แปลว่าต้องเป็นวิดีโอ

Streaming หมายถึงการรับส่งข้อมูลต่อเนื่องโดยไม่ต้องรอให้ข้อมูลทั้งหมดเสร็จก่อนจึงเริ่มใช้ ปลายทางอาจประมวลผลไปพร้อมกับที่ข้อมูลใหม่มาถึง ตัวอย่างมีทั้งเสียง วิดีโอ log แบบต่อเนื่อง ผลลัพธ์จาก AI model หรือข้อมูล sensor

Stream บางชนิดต้องการ byte ครบถ้วนและเรียงลำดับ เช่น การส่งไฟล์ต่อเนื่อง ขณะที่ live media อาจให้ความสำคัญกับข้อมูลที่มาทันเวลามากกว่าการรอ packet เก่า การบอกว่า “เป็น stream” จึงยังไม่อธิบายความต้องการด้าน reliability ได้ทั้งหมด

Synchronous กับ Asynchronous: รอหรือไปทำอย่างอื่นก่อน

การสื่อสารแบบ synchronous ทำให้ผู้เรียกผูกการทำงานไว้กับคำตอบในช่วงนั้น รูปแบบนี้เข้าใจง่าย แต่หากปลายทางช้า ทรัพยากรของผู้เรียกอาจถูกใช้ไปกับการรอ ส่วน asynchronous communication เปิดให้ผู้ส่งส่งงานแล้วไปทำอย่างอื่นต่อ จากนั้นจึงรับผลหรือ event ในภายหลัง

Asynchronous ไม่ได้แปลว่าเร็วกว่าเสมอ มันเปลี่ยนวิธีจัดการเวลาและความล้มเหลว ผู้ส่งต้องติดตามว่างานใดเสร็จแล้ว ผลลัพธ์เป็นของคำขอใด และถ้าระบบหยุดกลางทางจะกลับมาทำต่ออย่างไร ความเร็วที่ผู้ใช้รู้สึกดีขึ้น อาจแลกมาด้วย state ที่ระบบต้องจำมากขึ้น

2ความไม่แน่นอนที่ระบบสื่อสารต้องรับมือ

เครือข่ายจริงมีสัญญาณรบกวน link ที่เสีย คิวที่เต็ม และ packet ที่เดินทางคนละเส้นทาง Protocol แต่ละชั้นอาจตรวจพบ แก้ไข หรือรายงานปัญหาบางส่วน แต่ไม่ได้หมายความว่าทุกปัญหาจะถูกซ่อนจน application มองไม่เห็น

Reliability ไม่ได้แปลเพียงว่า “ส่งถึง”

เวลาพูดว่าช่องทางหนึ่งน่าเชื่อถือ เราต้องระบุว่าหมายถึงคุณสมบัติใด ข้อมูลอาจไปถึงแต่ผิดเพี้ยน ไปถึงครบแต่มาซ้ำ หรือไปถึงทุกชิ้นแต่เรียงผิดลำดับก็ได้ นอกจากนั้น ข้อมูลที่มาถึงช้าเกินกำหนดอาจไร้ประโยชน์ แม้ในทางเทคนิคจะถือว่าส่งสำเร็จแล้ว

ไม่มีช่องทางใดควรถูกเรียกว่า reliable แบบลอย ๆ โดยไม่บอกขอบเขต TCP ให้ byte stream ที่ส่งครบ ไม่ซ้ำ และเรียงลำดับภายใน connection ตราบใดที่ connection ยังดำเนินต่อได้ แต่ไม่ได้รับประกันว่า application ปลายทางนำคำสั่งไปทำเสร็จแล้ว และไม่ได้รับประกันว่าจะเสร็จภายในเวลาที่กำหนด

ปัญหาเกิดได้หลายระดับ

การจัดกลุ่มตามระดับช่วยให้เราไม่แก้ผิดที่ แต่ต้องระวังว่าอาการระดับบนอาจเกิดจากสาเหตุระดับล่างได้ เช่น application เห็น timeout เพราะ packet หาย, server ช้า หรือเส้นทางขาดก็ได้ อาการเดียวไม่ได้ชี้สาเหตุเดียว

ตรวจพบ แก้ไข หรือเพียงรายงาน

เมื่อพบความผิดปกติ ระบบมีทางเลือกหลายแบบ เช่น ตรวจพบแล้วทิ้งข้อมูลที่เสีย ขอให้ส่งใหม่ แก้ข้อผิดพลาดด้วยข้อมูลส่วนเกิน เลือกเส้นทางใหม่ หรือส่งสัญญาณบอกชั้นบนว่าทำต่อไม่ได้ การเลือกวิธีขึ้นอยู่กับต้นทุนและลักษณะงาน

ตัวอย่างเช่น link ไร้สายอาจมี error สูง จึงแก้บางส่วนใกล้จุดเกิดเหตุเพื่อลดการส่งใหม่ตลอดเส้นทาง ขณะที่ end-to-end protocol ยังต้องตรวจความครบถ้วนอีกครั้ง เพราะแม้ทุก link จะทำงานถูกต้อง อุปกรณ์ระหว่างทางหรือปลายทางก็ยังอาจเกิดปัญหาได้

Checksum และ CRC: รู้ว่าผิด ไม่ได้แปลว่าแก้ได้

ระบบสามารถเพิ่มข้อมูลตรวจสอบเพื่อช่วยตรวจว่าข้อมูลเปลี่ยนระหว่างทางหรือไม่ เช่น checksum หรือ CRC หากค่าที่คำนวณได้ไม่ตรงกัน ผู้รับรู้ว่าข้อมูลน่าสงสัย แต่การตรวจพบไม่ได้บอกข้อมูลเดิมที่ถูกต้องเสมอไป ผู้รับอาจต้องทิ้ง frame แล้วรอการส่งใหม่

การตรวจข้อผิดพลาดจึงต่างจากการแก้ข้อผิดพลาด Error detection บอกว่ามีบางอย่างผิด ส่วน error correction ใช้ข้อมูลส่วนเกินมากพอที่จะกู้ค่าบางส่วนกลับมาได้ ทั้งสองแบบแลก reliability กับ overhead คนละระดับ

ACK, timeout และ retransmission

ผู้รับอาจส่ง ACK เพื่อยืนยันว่าได้รับข้อมูลแล้ว หากผู้ส่งรอนานเกินช่วง timeout โดยไม่เห็น ACK ก็อาจส่งข้อมูลเดิมซ้ำ วิธีนี้ฟังดูตรงไปตรงมา แต่มีความคลุมเครือสำคัญ: ข้อมูลเดิมอาจหาย หรือข้อมูลถึงแล้วแต่ ACK ต่างหากที่หาย

ดังนั้นผู้รับต้องแยกข้อมูลใหม่ออกจากข้อมูลซ้ำได้ มิเช่นนั้น retransmission ที่ตั้งใจเพิ่ม reliability อาจทำให้คำสั่งเกิดผลสองครั้ง สิ่งที่ช่วยได้คือ sequence number ในระดับ protocol และ idempotency key ในระดับ application

ลำดับข้อมูล: ส่งก่อน ไม่ได้รับประกันว่าจะถึงก่อน

Packet อาจผ่านคนละเส้นทาง เจอคิวไม่เท่ากัน หรือบาง packet ต้องส่งใหม่ Packet ที่ส่งทีหลังจึงอาจมาถึงก่อน หาก application ต้องการลำดับเดิม protocol ต้องใส่ sequence number และเก็บข้อมูลที่มาผิดลำดับไว้จนกว่าส่วนที่ขาดจะมาถึง

แต่การรักษาลำดับก็มีราคา หาก packet หนึ่งหาย ข้อมูลที่มาถึงทีหลังอาจต้องรอทั้งที่ตัวเองไม่เสีย ปรากฏการณ์นี้เรียกได้ว่าเกิดการขวางกันด้วยข้อมูลด้านหน้า หรือ head-of-line blocking สำหรับ live application บางชนิด การรอ packet เก่าอาจแย่กว่าปล่อยข้ามแล้วเล่นข้อมูลใหม่ต่อ

Flow Control กับ Congestion Control ไม่ใช่เรื่องเดียวกัน

Flow control ป้องกันไม่ให้ผู้ส่งส่งเร็วเกินกว่าที่ผู้รับจะรับหรือประมวลผลไหว ส่วน congestion control ป้องกันไม่ให้การส่งข้อมูลรวมกันเร็วเกินกว่าที่เครือข่ายระหว่างทางรองรับได้ แบบแรกมองกำลังของปลายทาง แบบหลังมองภาระในเครือข่าย

เปรียบเหมือนร้านค้ามีที่เก็บของรับได้วันละ 100 กล่อง นี่เป็นข้อจำกัดของผู้รับ แต่ถนนเข้าร้านรถติดจนขนได้เพียงวันละ 50 กล่อง นี่เป็นข้อจำกัดของเครือข่าย การแก้ด้วยการขยายโกดังอย่างเดียวไม่ทำให้ถนนหายติด และการขยายถนนก็ไม่ช่วยถ้าโกดังเต็มอยู่แล้ว

Failure ไม่ได้มีหน้าตาเดียว

Link ขาดหรือ node ปิดเป็นความเสียหายที่เห็นชัด แต่ระบบเครือข่ายยังมี partial failure คือบางส่วนทำงานและบางส่วนไม่ทำงาน เช่น client ส่ง request ออกไปได้ แต่ reply กลับมาไม่ได้ หรือ server ทำงานอยู่แต่ฐานข้อมูลที่มันต้องใช้ติดต่อไม่ได้

สิ่งที่ยากคือผู้สังเกตแต่ละจุดเห็นข้อมูลไม่เท่ากัน Client ที่ timeout ไม่รู้ว่า server ล่ม งานยังทำอยู่ หรือเพียง network ช้า ความไม่รู้สถานะของอีกฝั่งคือหัวใจของ distributed systems และเริ่มต้นให้เห็นได้ตั้งแต่ network communication

Security เป็นอีกแกนหนึ่ง ไม่ใช่ส่วนย่อยของ Reliability

การดักฟัง (eavesdropping), การแก้ไขข้อมูลโดยผู้ไม่หวังดี, การปลอมตัว และการปฏิเสธบริการเป็นปัญหาด้าน security แม้บางแนวคิดอย่าง integrity จะมีชื่อคล้ายกัน แต่ reliability มักสนใจความเสียหายหรือความผิดปกติของการส่ง ส่วน security เพิ่มสมมุติฐานว่ามีผู้โจมตีที่ตั้งใจทำให้ระบบผิดพลาดหรือขโมยข้อมูล

ระบบอาจ reliable มากแต่ไม่ confidential เช่น ส่งข้อมูลถึงครบทุกครั้งแต่ใครก็อ่านได้ หรือ secure แต่ไม่ available เช่น ข้อมูลถูกเข้ารหัสดีมากแต่ service ล่มตลอด การประเมินระบบจึงต้องแยกคุณสมบัติเหล่านี้ก่อน แล้วค่อยดูว่ากลไกหนึ่งช่วยหรือกระทบหลายด้านอย่างไร

3สรุปและขั้นตอนถัดไป

จากปัญหาการสื่อสาร ไปสู่ Protocol และ Layering

บทนี้กล่าวถึง checksum, ACK, sequence number, timeout และ retransmission แต่กลไกเหล่านี้จะทำงานร่วมกันได้ก็ต่อเมื่อทั้งสองฝั่งตีความข้อมูลตรงกัน ต้องรู้ว่า field ใดหมายถึงลำดับ ค่าใดหมายถึงการยืนยัน และเมื่อหมดเวลาควรทำอะไร ข้อตกลงนี้คือ protocol

เมื่อกลไกมีหลายหน้าที่ เราจึงแบ่งงานออกเป็นชั้น เพื่อไม่ให้ application ทุกตัวต้องสร้างการส่งสัญญาณ การตรวจ frame การหาเส้นทาง และการส่งใหม่เองทั้งหมด บทถัดไปจะอธิบายว่า protocol คืออะไร layer ช่วยจัดระบบอย่างไร และเหตุใดการแบ่งชั้นจึงทั้งแก้ปัญหาและสร้างข้อจำกัดใหม่พร้อมกัน