บทนำร่วม 7/8

Performance — ตัวชี้วัดที่ใช้ประเมินทุกชั้น

คำว่า “เครือข่ายเร็ว” กว้างเกินกว่าจะวัดได้ เราต้องแยกก่อนว่าเร็วในแง่ส่งข้อมูลได้มาก ตอบสนองไว เวลาสม่ำเสมอ หรือส่งข้อมูลของ application ได้สำเร็จจริง ตัวชี้วัดเหล่านี้จะกลับมาตลอดทุก layer

1Bandwidth และ Latency

Bandwidth กับ latency ถูกเรียกรวม ๆ ว่า “ความเร็ว” บ่อยที่สุด ทั้งที่ตอบคนละคำถาม Bandwidth บอกว่าช่องทางรองรับข้อมูลได้มากแค่ไหนต่อเวลา ส่วน latency บอกว่าข้อมูลหนึ่งหน่วยต้องรอนานแค่ไหนกว่าจะเดินทางหรือได้ผลตอบกลับ

Bandwidth: ความสามารถในการขนข้อมูลต่อหน่วยเวลา

Bandwidth (แบนด์วิดท์)

Bandwidth = อัตราสูงสุดเชิงทฤษฎีหรืออัตราที่กำหนดของช่องทาง หน่วยเป็น bit per second (bps)

1 Mbps → 1 bit ใช้เวลา 1 μs; 2 Mbps → 1 bit ใช้เวลาเพียง 0.5 μs

ตัวอย่างด้านบนพูดถึงเวลาในการผลัก bit ลง link หรือ bit time เมื่ออัตราการส่งสูงขึ้น เวลาที่ใช้ต่อ bit ลดลง แต่ไม่ได้แปลว่า bit เคลื่อนที่ผ่านสายเร็วขึ้นตามสัดส่วน สัญญาณยังแพร่ผ่าน medium ด้วยความเร็วที่ขึ้นกับคุณสมบัติทางกายภาพของ medium

ลองนึกภาพ — ถนนกว้างกับรถที่วิ่งเร็ว

Bandwidth คล้ายจำนวนช่องจราจร ถนนสิบช่องรับรถผ่านจุดหนึ่งต่อเวลาได้มากกว่าถนนหนึ่งช่อง แต่รถคันแรกไม่ได้จำเป็นต้องถึงปลายทางเร็วขึ้นสิบเท่า หากระยะทางและความเร็วรถเท่าเดิม

ดังนั้นการเพิ่ม bandwidth คล้ายขยายถนนให้รองรับรถพร้อมกันมากขึ้น ส่วนการลด propagation delay คล้ายย่นระยะทางหรือทำให้รถเดินทางเร็วขึ้น ทั้งคู่ช่วย performance แต่ช่วยคนละด้าน

Latency: เวลาที่ข้อมูลใช้ตั้งแต่จุดหนึ่งไปอีกจุดหนึ่ง

Latency ต้องระบุขอบเขตเสมอว่าเป็น one-way delay, round-trip time หรือ response time ของ application หากพูดเพียง “latency 50 ms” โดยไม่บอกจุดเริ่มและจุดจบ ตัวเลขยังตีความได้ไม่ครบ

องค์ประกอบของ Latency

One-way delay ≈ Processing + Queueing + Transmission + Propagation

Propagation delay = Distance / Propagation speed

Transmission delay = Packet size (bits) / Link rate (bps)

องค์ประกอบ	เกิดจากอะไร	ขึ้นกับอะไร
Processing delay	อุปกรณ์ตรวจ header, checksum และตัดสินใจส่งต่อ	กำลังประมวลผล งานที่ทำ และภาระของอุปกรณ์
Queueing delay	Packet รอ link หรือทรัพยากรที่กำลังถูกใช้งาน	Traffic ที่มาถึงพร้อมกัน ความยาวคิว และนโยบาย scheduling
Transmission delay	เวลาผลัก bit ทั้ง packet ลง link	ขนาด packet และอัตราการส่งของ link
Propagation delay	เวลาที่สัญญาณเดินทางผ่าน medium	ระยะทางและความเร็วการแพร่ของสัญญาณ

Processing และ queueing เปลี่ยนไปตามอุปกรณ์และภาระงาน Transmission เปลี่ยนตามขนาดข้อมูลกับ link rate ส่วน propagation ผูกกับระยะทางทางกายภาพมากกว่า จึงไม่มี “กฎหนึ่งบรรทัด” ว่าองค์ประกอบใดสำคัญที่สุดทุกกรณี

Transmission ไม่ใช่ Propagation

สองคำนี้สับสนกันบ่อย Transmission delay คือเวลาที่ sender ใช้ผลัก packet ลงสายให้ครบ ส่วน propagation delay คือเวลาที่สัญญาณเดินทางจากต้นสายไปปลายสาย Packet ใหญ่เพิ่ม transmission delay แต่ไม่ได้ทำให้ bit แรกเดินทางช้าลงเพราะระยะทางมากขึ้น

ลองนึกภาพ — ขบวนรถออกจากอุโมงค์

Transmission delay คล้ายเวลาที่รถทั้งขบวนค่อย ๆ ผ่านปากอุโมงค์เข้าไป หากขบวนยาวหรือปากทางรับรถได้น้อย ก็ใช้เวลานานกว่ารถคันสุดท้ายจะเข้าอุโมงค์

Propagation delay คล้ายเวลาที่รถคันแรกวิ่งจากปากอุโมงค์ไปถึงอีกฝั่ง ขึ้นกับความยาวอุโมงค์และความเร็วรถ การขยายปากอุโมงค์ช่วยให้รถทั้งขบวนเข้าได้เร็วขึ้น แต่ไม่ได้ย่นความยาวของอุโมงค์

ตัวอย่างคำนวณ Transmission Delay

Packet ขนาด 1,500 byte มี 12,000 bit

บน link 1 Mbps: 12,000 / 1,000,000 = 0.012 s = 12 ms
บน link 100 Mbps: 12,000 / 100,000,000 = 0.00012 s = 0.12 ms

Bandwidth ที่มากขึ้นลดเวลาผลัก packet ลง link อย่างชัดเจน แต่ถ้าปลายทางอยู่ห่างจน propagation ใช้ 100 ms การลด transmission จาก 12 ms เหลือ 0.12 ms ก็ไม่ได้ทำให้ delay รวมลดลงร้อยเท่า

วิธีพิจารณาว่าอะไรสำคัญ

ข้อมูลก้อนเล็กบนเส้นทางไกลมักถูกครอบงำด้วย propagation, processing และจำนวนรอบของ protocol ส่วนข้อมูลก้อนใหญ่หรือ link ช้าจะเห็นผลของ transmission และ throughput มากขึ้น แต่ต้องคำนวณจากค่าจริง ไม่ควรสรุปจากขนาดข้อมูลเพียงอย่างเดียว

2Delay × Bandwidth Product

Bandwidth–Delay Product (BDP) บอกปริมาณข้อมูลที่สามารถอยู่ระหว่างการเดินทางในเครือข่าย ณ ขณะหนึ่ง หาก bandwidth สูงและเส้นทางไกล เราต้องมีข้อมูลกำลังเดินทางจำนวนมากจึงจะใช้ช่องทางได้เต็ม

ลองนึกภาพ — ปริมาตรของท่อ

มองช่องสัญญาณเป็นท่อ ความยาวของท่อแทน delay และพื้นที่หน้าตัดแทน bandwidth ท่อยาวและกว้างเก็บน้ำที่กำลังเดินทางอยู่ได้มากกว่าท่อสั้นหรือแคบ

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

ต้องระบุ delay ที่นำมาใช้ให้ชัด หากต้องการจำนวน bit ที่กำลังเดินทางทางเดียว ใช้ one-way delay แต่ถ้าคำนวณข้อมูลที่ sender ต้องส่งค้างไว้ก่อนเห็น acknowledgment กลับมา มักใช้ RTT:

สูตร BDP ตามขอบเขตที่ต้องการ

One-way in-flight data = Bandwidth × One-way delay

Window สำหรับคงการส่งระหว่างรอ ACK ≈ Bottleneck bandwidth × RTT

ตัวอย่างคำนวณแบบ One-Way

One-way delay = 50 ms, Bottleneck bandwidth = 45 Mbps

BDP = 50×10⁻³ × 45×10⁶ = 2.25×10⁶ bits ≈ 281,250 bytes

ถ้า RTT เท่ากับ 100 ms บนเส้นทางเดียวกัน ข้อมูลที่ sender ต้องมีระหว่างส่งและรอ ACK เพื่อคงอัตรา 45 Mbps จะอยู่ประมาณ 4.5 ล้าน bit หรือ 562,500 byte ตัวเลขนี้เป็นจุดเริ่มต้นในการคิด window size แต่ performance จริงยังขึ้นกับ overhead, loss, congestion control และข้อจำกัดของปลายทาง

เหตุใด Stop-and-Wait จึงเสียโอกาสบนท่อยาว

ถ้าผู้ส่งส่งหนึ่ง packet แล้วหยุดรอ ACK ก่อนส่ง packet ต่อไป link จะว่างระหว่างที่ packet และ ACK กำลังเดินทาง ยิ่ง RTT สูง ช่องว่างนี้ยิ่งมาก Sliding window เปิดให้ผู้ส่งมีหลาย packet ที่ยังไม่ได้รับ ACK อยู่พร้อมกัน จึงเติมข้อมูลลงเส้นทางได้ต่อเนื่องกว่า

ตัวอย่าง Stop-and-Wait

สมมุติส่ง packet 1,500 byte ผ่าน link 100 Mbps และมี RTT 100 ms

Transmission delay = 12,000 / 100,000,000 = 0.12 ms
ถ้ารอ ACK ทุก packet รอบหนึ่งใช้ประมาณ 100.12 ms โดยยังไม่รวม delay อื่น
Throughput โดยประมาณ = 12,000 bit / 0.10012 s ≈ 120 kbps

แม้ link ระบุว่า 100 Mbps แต่ Stop-and-Wait ใช้ได้เพียงประมาณ 0.12% ในตัวอย่างนี้ ปัญหาไม่ได้อยู่ที่ link ช้า แต่อยู่ที่ protocol ปล่อยให้ link ว่างระหว่างรอ

หยุดคิดสักครู่

ถ้าเพิ่ม bandwidth จาก 100 Mbps เป็น 1 Gbps แต่ยังส่ง packet เดียวแล้วรอ ACK 100 ms ประสิทธิภาพจะดีขึ้นมากหรือไม่? Transmission delay ลดลง แต่เวลาส่วนใหญ่ยังหมดไปกับการรอ RTT การซื้อท่อกว้างขึ้นจึงไม่ช่วย หากเปิดก๊อกทีละหยดเหมือนเดิม

3Throughput และ RTT

Bandwidth คือเพดานหรือความสามารถของช่องทาง ส่วน throughput คืออัตราที่สังเกตได้จริงระหว่างการส่ง การมี link 1 Gbps ไม่ได้แปลว่า application จะได้รับข้อมูล 1 Gbps เสมอไป

Throughput, Goodput และ Bandwidth

ตัวชี้วัด	บอกอะไร	นับข้อมูลใด
Bandwidth/Capacity	ช่องทางรองรับได้สูงสุดหรือกำหนดไว้เท่าไร	เป็นคุณสมบัติหรือเพดานของ link/path ตามบริบท
Throughput	ส่งข้อมูลผ่านได้จริงต่อเวลาเท่าไร	อาจรวม header และข้อมูลที่ส่งซ้ำตามจุดที่วัด
Goodput	Application ได้ payload ที่มีประโยชน์จริงต่อเวลาเท่าไร	ไม่นับ protocol overhead และ retransmission ที่ไม่เพิ่มข้อมูลใหม่

Goodput จึงไม่เกิน throughput และ throughput บนเส้นทางไม่ควรเกิน bottleneck capacity ในช่วงยาว ๆ แต่ตัวเลขที่เครื่องมือรายงานอาจต่างกันตามขอบเขตและวิธีนับ เช่น นับหน่วยเป็น bit หรือ byte นับ header หรือไม่ และใช้ฐาน 1,000 หรือ 1,024

Bottleneck: เส้นทางเร็วเท่าช่วงที่จำกัดที่สุด

เส้นทางจาก client ถึง server ผ่านหลาย link เช่น 1 Gbps → 100 Mbps → 20 Mbps → 1 Gbps อัตราการส่งต่อเนื่องถูกจำกัดโดย link 20 Mbps เป็นหลัก ต่อให้ link ต้นทางกว้างขึ้นอีกสิบเท่า ข้อมูลก็ยังสะสมรอที่จุดแคบ

ลองนึกภาพ — คอขวดที่เป็นคอขวดจริง ๆ

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

อย่างไรก็ตาม bottleneck อาจเปลี่ยนตามเวลา ผู้ใช้อื่นเข้ามาแชร์ link, server CPU เต็ม หรือ receiver อ่านข้อมูลไม่ทัน จุดจำกัดจึงไม่จำเป็นต้องเป็นสายเส้นเดิมตลอดไป

RTT: เวลาไปและกลับ แต่ไม่ใช่ response time ทั้งหมด

Round-Trip Time (RTT) คือเวลาที่สัญญาณหรือข้อมูลเดินทางไปยังอีกฝั่งและมีสิ่งตอบกลับมาถึงจุดเดิม ขอบเขตจริงขึ้นกับวิธีวัด เช่น ping วัด ICMP echo ในเงื่อนไขหนึ่ง ขณะที่ TCP handshake หรือ HTTP request ผ่าน proxy และ server processing อาจให้ค่าต่างกัน

Application response time อาจประกอบด้วยหลาย RTT บวกเวลา DNS, handshake, TLS, queue, server processing และการถ่ายโอนข้อมูล ดังนั้น ping ต่ำไม่ได้รับประกันว่าเว็บไซต์ตอบเร็ว และเว็บไซต์ช้าไม่ได้แปลว่า network path ช้าเสมอไป

แบบจำลองง่ายสำหรับการถ่ายโอนหนึ่งก้อน

Throughput = TransferSize / TransferTime

TransferTime ≈ Protocol setup/RTT cost + TransferSize / Bottleneck throughput

สูตรนี้เป็นแบบจำลองเบื้องต้น ไม่ใช่สมการสากล จำนวน RTT ขึ้นกับ protocol, connection reuse และลำดับการทำงาน ส่วน throughput จริงอาจค่อย ๆ เพิ่มจาก congestion control และได้รับผลจาก loss จึงต้องระบุสมมุติฐานก่อนคำนวณ

ตัวอย่างไฟล์ 1 MB

ให้ไฟล์มีขนาดประมาณ 8 Mb และยังไม่รวม overhead:

บน bottleneck 1 Mbps เวลาส่งข้อมูลอย่างต่ำ ≈ 8 Mb / 1 Mbps = 8 s
บน bottleneck 1 Gbps เวลาส่งข้อมูลอย่างต่ำ ≈ 8 Mb / 1,000 Mbps = 8 ms

แต่ถ้าต้องเสียเวลา setup 100 ms ก่อนเริ่มส่ง เวลารวมโดยย่อจะเป็น 8.1 s กับ 108 ms ตามลำดับ ฝั่ง 1 Gbps จึงไม่ได้จบใน 8 ms ตามที่ bandwidth อย่างเดียวบอก เพราะ latency ของขั้นตอนก่อนส่งกลายเป็นส่วนใหญ่ของงาน

ข้อมูลเล็กไวต่อจำนวนรอบ ข้อมูลใหญ่ไวต่ออัตราการส่ง

Request ขนาดเล็กอาจใช้เวลา transmission น้อยมาก แต่ต้องผ่าน DNS, TCP handshake, TLS handshake และ request/response หลายรอบ Latency และจำนวน round trip จึงครอบงำ ส่วนไฟล์ขนาดใหญ่เมื่อเริ่มไหลต่อเนื่องแล้ว throughput ของ bottleneck มีผลมากขึ้น

นี่เป็นเหตุผลที่ protocol สมัยใหม่พยายามลดจำนวน handshake, reuse connection, ส่งหลาย request บน connection เดียว หรือรวมข้อมูลเล็กเป็น batch การ optimize ไม่ได้มีเพียงเพิ่ม Mbps แต่อาจลดจำนวนครั้งที่ต้องรออีกฝั่งตอบ

Jitter: ค่าเฉลี่ยเท่ากัน แต่ประสบการณ์ไม่เท่ากัน

Jitter คือความแปรผันของ delay ระหว่าง packet หรือระหว่างการวัด หาก packet เสียงมาถึงห่างกันไม่สม่ำเสมอ ผู้เล่นเสียงต้องมี buffer ช่วยปรับจังหวะ Buffer ใหญ่ช่วยลดเสียงสะดุด แต่เพิ่ม latency การสนทนา

ลองนึกภาพ — รถโดยสารที่มาตรงเวลากับมาเป็นกลุ่ม

เส้นทาง A มีรถมาทุก 10 นาทีตรงเวลา เส้นทาง B เฉลี่ยก็ 10 นาที แต่บางครั้งรถสามคันมาติดกันแล้วหายไปครึ่งชั่วโมง ค่าเฉลี่ยเท่ากัน แต่ผู้โดยสารรับรู้บริการต่างกันมาก

เครือข่ายก็เช่นเดียวกัน ค่า latency เฉลี่ยอาจดูดี แต่หากบาง packet ช้ามาก Video Call จะกระตุกและระบบ interactive จะรู้สึกไม่แน่นอน Jitter จึงบอกสิ่งที่ค่าเฉลี่ยซ่อนอยู่

Loss: ข้อมูลที่หายสร้างต้นทุนมากกว่าจำนวน byte ที่หาย

Packet loss อาจเกิดจาก bit error, buffer เต็ม, link ขัดข้อง หรือนโยบายของอุปกรณ์ ผลกระทบขึ้นกับ protocol และ application TCP อาจส่งใหม่และลดอัตราการส่ง ทำให้ throughput ลดและ latency เพิ่ม ส่วน real-time media อาจข้าม packet เก่าเพื่อรักษาเวลา

Loss เพียงเล็กน้อยอาจกระทบเส้นทาง RTT สูงมาก เพราะการตรวจพบและกู้คืนใช้เวลานาน จำนวนเปอร์เซ็นต์จึงยังไม่พอ ต้องดูว่า loss เกิดเป็นครั้งคราว เป็น burst อยู่จุดใด และ application รับมืออย่างไร

4วัด Performance อย่างไรไม่ให้ตัวเลขหลอกเรา

กำหนดขอบเขตก่อนวัด

ก่อนรายงานตัวเลข ต้องบอกว่าเริ่มจับเวลาตรงไหน จบตรงไหน วัดบน link, ระหว่าง host, ระหว่าง process หรือจากมุมผู้ใช้ หากวัด throughput ที่ network interface อาจรวม header แต่หากวัด goodput ใน application จะเห็นเฉพาะ payload ที่ใช้ได้จริง

สิ่งที่ต้องระบุ	ตัวอย่างคำถาม
ขอบเขต	วัด one-way, RTT, connection time หรือ response time ทั้งหมด?
หน่วย	bit/s หรือ byte/s, ms หรือ μs, ฐาน 1,000 หรือ 1,024?
ช่วงเวลา	ค่าเฉลี่ยต่อ 1 วินาที 1 นาที หรือทั้งการทดลอง?
Traffic	Packet ขนาดใด จำนวน flow เท่าไร และส่งต่อเนื่องหรือ burst?
สภาพแวดล้อม	มีผู้ใช้อื่น, Wi-Fi interference, VPN, proxy หรือ rate limit หรือไม่?

Average อย่างเดียวไม่พอ

ถ้า request 99 ครั้งตอบใน 10 ms แต่อีก 1 ครั้งใช้ 5 s ค่าเฉลี่ยอาจยังดูพอใช้ แต่ผู้ใช้ที่เจอครั้งช้าจะรู้สึกว่าระบบค้าง การรายงาน percentile เช่น median, p95, p99 และค่าสูงสุดช่วยให้เห็นส่วนปลายของการกระจายที่ค่าเฉลี่ยซ่อนอยู่

สำหรับระบบที่เรียก service หลายตัวพร้อมกัน tail latency สำคัญยิ่งขึ้น เพราะ response รวมต้องรอส่วนที่ช้าที่สุด แม้แต่ละ service ช้าเพียง 1% โอกาสที่อย่างน้อยหนึ่งตัวช้าใน fan-out ขนาดใหญ่จะเพิ่มขึ้นมาก

ตัวอย่างค่าเฉลี่ยที่หลอกตา

มี request 10 ครั้ง: 9 ครั้งใช้ 10 ms และ 1 ครั้งใช้ 1,000 ms

Median ≈ 10 ms — ผู้ใช้ส่วนใหญ่เห็นระบบเร็ว
Average = (9×10 + 1,000)/10 = 109 ms
Maximum = 1,000 ms — มีผู้ใช้หนึ่งรายรอนานกว่าคนอื่นร้อยเท่า

ตัวเลขทั้งสามถูกทั้งหมด แต่เล่าเรื่องคนละส่วน การเลือกเฉพาะตัวเลขที่ดูดีที่สุดไม่ใช่การวัด performance แต่เป็นการแต่งหน้ากราฟครับ

การทดสอบต้องแยก Capacity ออกจาก Load

Capacity บอกว่าระบบรองรับได้มากเพียงใด ส่วน load บอกว่าขณะทดสอบเราใส่งานเข้าไปเท่าไร หาก load ต่ำ ระบบหลายแบบอาจให้ latency ใกล้กัน แต่เมื่อเข้าใกล้ capacity queueing delay จะเพิ่มอย่างรวดเร็ว และหลังเกินจุดหนึ่ง throughput อาจไม่เพิ่ม ขณะที่ error กับ timeout เพิ่มแทน

ดังนั้นการทดสอบเพียงผู้ใช้หนึ่งคนไม่สามารถสรุป scalability ได้ และการยิง load สูงสุดเพียงครั้งเดียวก็ไม่บอกพฤติกรรมตลอดช่วง ควรเพิ่ม load ทีละระดับ วัด throughput, latency percentile, loss/error และการใช้ทรัพยากรพร้อมกัน

ลองวิเคราะห์

หลังอัปเกรด link จาก 100 Mbps เป็น 1 Gbps หน้าเว็บยังใช้เวลาเปิด 800 ms เท่าเดิม เป็นไปได้หรือไม่? เป็นไปได้มาก หากข้อมูลมีขนาดเล็กและเวลาอยู่ที่ DNS, RTT, TLS, server processing หรือ database การเพิ่ม bandwidth แก้เฉพาะส่วน transmission ที่อาจเล็กอยู่แล้ว

เครื่องมือหนึ่งตัววัดโลกได้ไม่ครบ

Ping ช่วยสำรวจ RTT และ loss ของ ICMP ในเงื่อนไขหนึ่ง แต่ไม่ได้วัด HTTP response time หรือ throughput โดยตรง Traceroute ช่วยเห็นเส้นทางบางส่วน แต่ router อาจตอบต่างจาก traffic จริง เครื่องมือวัด throughput ช่วยดูอัตราส่งระหว่างปลายสองฝั่ง แต่ไม่ได้บอกว่า application ช้าเพราะฐานข้อมูลหรือไม่

วิธีที่แข็งแรงกว่าคือเริ่มจากสมมุติฐาน เลือกเครื่องมือที่วัดหลักฐานซึ่งแยกสมมุติฐานได้ และเชื่อมค่าจากหลายระดับเข้าด้วยกัน การมี dashboard เยอะไม่เท่ากับรู้สาเหตุ หากทุกกราฟวัดสิ่งที่ไม่เกี่ยวกับคำถาม

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

Bandwidth บอกความสามารถในการขนข้อมูลต่อเวลา ส่วน latency บอกเวลาที่ข้อมูลหรือผลตอบกลับใช้เดินทาง
Latency ประกอบด้วย processing, queueing, transmission และ propagation ตามขอบเขตที่วัด
Transmission delay ขึ้นกับขนาดข้อมูลกับ link rate ส่วน propagation delay ขึ้นกับระยะทางกับความเร็วสัญญาณ
Bandwidth–Delay Product บอกปริมาณข้อมูลที่อยู่ระหว่างเดินทาง และช่วยประมาณ window ที่ต้องใช้เพื่อไม่ปล่อย link ว่างระหว่างรอ ACK
Throughput คืออัตราที่วัดได้จริง ส่วน goodput นับเฉพาะ payload ที่มีประโยชน์ต่อ application
Performance แบบ end-to-end ถูกจำกัดได้ทั้งจาก bottleneck link, protocol, receiver, server และระบบที่ application พึ่งพา
Jitter บอกความแปรผันของ delay ส่วน loss อาจเพิ่มทั้ง retransmission, latency และการลดอัตราส่ง
ควรรายงาน percentile และขอบเขตการวัด ไม่ใช้ average หรือเลข bandwidth เพียงค่าเดียวสรุปประสบการณ์ทั้งหมด

เปลี่ยนมุมมอง

Performance ไม่ใช่คุณสมบัติของสายเส้นหนึ่ง แต่เป็นผลของข้อมูล เส้นทาง protocol ภาระระบบ และสิ่งที่ application ต้องการในเวลานั้น เครือข่ายเดียวกันอาจเร็วมากสำหรับการสำรองไฟล์ แต่ช้าเกินไปสำหรับการควบคุมแบบ real-time เพราะสองงานอ่านคำว่า “เร็ว” จากคนละตัวชี้วัด

จากตัวชี้วัด ไปสู่โปรแกรมที่ใช้งานเครือข่าย

เมื่อรู้ว่า bandwidth, latency, RTT และ loss มีผลอย่างไร คำถามสุดท้ายของบทนำคือ application จะขอใช้บริการเครือข่ายผ่านอะไร Socket API เป็นจุดที่แนวคิดเรื่อง address, port, connection, stream, timeout และ buffer กลายเป็น operation ที่ programmer เรียกใช้จริง

บทถัดไปจึงจะย้ายมุมมองจากการวัดเครือข่าย ไปสู่การสร้างโปรแกรม client และ server พร้อมชี้ให้เห็นว่าค่าที่วัดในบทนี้ปรากฏเป็นพฤติกรรมของ connect, send, receive และ timeout อย่างไร

คำถามก่อนเข้าสู่บทถัดไป

ถ้าโปรแกรมเรียก send() สำเร็จ แปลว่าผู้รับได้รับและประมวลผลข้อมูลแล้วหรือไม่? ยังครับ การส่งข้อมูลเข้า buffer ของระบบปฏิบัติการสำเร็จ กับผลลัพธ์ end-to-end ของ application เป็นคนละขอบเขต Socket API จะทำให้เส้นแบ่งนี้เห็นชัดขึ้น