0Pricing
Azure Fundamentals · บทเรียน

เพิ่มประสิทธิภาพด้วยกฎ CDN

ใช้กลไกกฎเพื่อเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS เพิ่มส่วนหัวความปลอดภัย และใช้การกรองตามภูมิศาสตร์เพื่อจำกัดการเข้าถึงเนื้อหาจากบางประเทศ

เพิ่มประสิทธิภาพด้วยกฎ CDN เป็นบทเรียน Azure Fundamentals ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Azure Fundamentals และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดกลไกกฎจึงมีความสำคัญ

กลไกกฎของ Azure Front Door ซึ่งเรียกว่า Rule sets ใน Standard/Premium ช่วยให้คุณดักจับและแก้ไขคำขอและการตอบสนอง HTTP ที่โหนด PoP ขอบเครือข่าย ก่อนที่ข้อมูลเหล่านั้นจะถูกแคชหรือส่งต่อไปยังต้นทาง หากไม่มีกลไกกฎ คุณจะต้องจัดการงานต่าง ๆ เช่น การเปลี่ยนเส้นทาง HTTP เป็น HTTPS ส่วนหัวการตอบสนองด้านความปลอดภัย และการบล็อกตามภูมิศาสตร์ภายในโค้ดแอปพลิเคชันต้นทาง ซึ่งเพิ่มเวลาแฝงและทำให้ข้อกังวลด้านความปลอดภัยผูกติดกับตรรกะทางธุรกิจ กฎที่ขอบเครือข่ายทำงานได้เร็วกว่าและลดภาระของต้นทาง

การเปลี่ยนเส้นทาง HTTP เป็น HTTPS

กรณีการใช้งานกลไกกฎที่พบบ่อยที่สุดกรณีหนึ่งคือการบังคับใช้ HTTPS เมื่อไคลเอ็นต์ร้องขอเว็บไซต์ผ่าน HTTP กฎการเปลี่ยนเส้นทางที่ขอบเครือข่ายของ Front Door จะส่งการตอบสนอง 301 Moved Permanently (หรือ 302 Found) พร้อมชี้ไปยัง URL แบบ HTTPS ทันที โดยคำขอไม่จำเป็นต้องไปถึงต้นทาง วิธีนี้เร็วกว่าการเปลี่ยนเส้นทางที่ต้นทาง และช่วยให้มั่นใจว่าการรับส่งข้อมูลทั้งหมดได้รับการเข้ารหัสระหว่างส่ง กำหนดค่านี้เป็นการดำเนินการเปลี่ยนเส้นทางสำหรับคำขอที่เงื่อนไข RequestScheme มีค่าเท่ากับ HTTP

// Rules engine rule — redirect HTTP to HTTPS
// Match condition: RequestScheme Equals HTTP
// Action: URL Redirect
//   Redirect type: Moved (301)
//   Destination protocol: HTTPS
//   Destination host: {http.request.host}
//   Destination path: {http.request.uri.path}
//   Query string: {http.request.uri.querystring}

การเพิ่มส่วนหัวการตอบสนองด้านความปลอดภัย

เบราว์เซอร์สมัยใหม่รองรับส่วนหัว HTTP ด้านความปลอดภัยที่ช่วยป้องกันการโจมตีทั่วไป คุณสามารถเพิ่มส่วนหัวเหล่านี้ในการตอบสนองทั้งหมดโดยใช้การดำเนินการ Append response header ของกลไกกฎ โดยไม่ต้องแก้ไขเซิร์ฟเวอร์ต้นทาง ส่วนหัวสำคัญ ได้แก่ Strict-Transport-Security ซึ่งบังคับใช้ HTTPS ตามระยะเวลาที่กำหนด X-Content-Type-Options: nosniff ซึ่งป้องกันการเดาประเภท MIME X-Frame-Options: DENY ซึ่งป้องกันการขโมยการคลิก และ Content-Security-Policy ซึ่งจำกัดแหล่งที่มาของเนื้อหา การเพิ่มส่วนหัวเหล่านี้ที่ขอบเครือข่ายช่วยให้ใช้การตั้งค่าเดียวกันกับต้นทางทั้งหมด

// Rules engine — add security headers to all responses
// Action 1: Append response header
//   Header name: Strict-Transport-Security
//   Value: max-age=31536000; includeSubDomains
// Action 2: Append response header
//   Header name: X-Content-Type-Options
//   Value: nosniff
// Action 3: Append response header
//   Header name: X-Frame-Options
//   Value: DENY

การแทนที่การตั้งค่าแคชตามกฎ

กลไกกฎช่วยให้คุณแทนที่ TTL ของแคชเริ่มต้นสำหรับรูปแบบ URL ที่ระบุได้ ตัวอย่างเช่น คุณอาจต้องการแคช /static/images/* เป็นเวลา 30 วัน แต่แคชการตอบสนองของ /api/* เพียง 60 วินาที ใช้เงื่อนไขการจับคู่กับ RequestUri และการดำเนินการ Route configuration override เพื่อกำหนดระยะเวลาแคชแบบกำหนดเอง วิธีนี้ช่วยให้ควบคุมพฤติกรรมแคชได้อย่างละเอียด โดยไม่ต้องสร้างเส้นทางแยกหลายเส้นทางสำหรับเนื้อหาแต่ละประเภท

// Rules engine — cache API responses for 60 seconds
// Match condition: RequestUri BeginsWith /api/
// Action: Route configuration override
//   Cache: Enabled
//   Caching duration: 0 days, 0 hours, 1 minute
//   Query string caching: Include All

// Rules engine — cache static images for 30 days
// Match condition: RequestUri BeginsWith /static/images/
// Action: Route configuration override
//   Cache: Enabled
//   Caching duration: 30 days

การเขียน URL ใหม่ที่ขอบเครือข่าย

การดำเนินการเขียน URL ใหม่จะแก้ไข URL ของคำขอก่อนส่งต่อไปยังต้นทาง โดยไม่เปลี่ยน URL ที่ไคลเอ็นต์มองเห็น วิธีนี้มีประโยชน์สำหรับส่งคำขอจากโครงสร้าง URL หนึ่งไปยังเส้นทางที่แตกต่างกันของแบ็กเอนด์ ตัวอย่างเช่น เขียน /products/item/{id} เป็น /catalog/v2/products/{id} เพื่อรองรับการเปลี่ยนแปลง API ของแบ็กเอนด์โดยไม่ต้องแก้ไขลิงก์ของไคลเอ็นต์ การเขียน URL ใหม่เป็นการดำเนินการในกลไกกฎที่แก้ไข URL path โดยใช้การแทนที่สตริงหรือกลุ่มการจับคู่

กฎการกรองตามภูมิศาสตร์

การกรองตามภูมิศาสตร์ในระดับกลไกกฎช่วยให้คุณเปลี่ยนเส้นทางหรือบล็อกผู้ใช้จากบางประเทศ โดยอ้างอิงตำแหน่งทางภูมิศาสตร์ที่ได้จาก IP ของไคลเอ็นต์ ต่างจากการกรองตามภูมิศาสตร์ของ CDN ซึ่งส่ง 403 กลับมา การกรองตามภูมิศาสตร์ของกลไกกฎมีความยืดหยุ่นมากกว่า คุณสามารถเปลี่ยนเส้นทางประเทศที่ถูกบล็อกไปยังหน้าเริ่มต้นที่อธิบายการให้บริการในภูมิภาคนั้น หรือกำหนดเส้นทางประเทศบางแห่งไปยังกลุ่มต้นทางเฉพาะภูมิภาค เช่น ผู้ใช้ใน EU ไปยังต้นทางใน EU เพื่อให้สอดคล้องกับ GDPR การจับคู่ภูมิศาสตร์ของ RemoteAddress ใช้ฐานข้อมูล IP-to-country ของ MaxMind

การจัดการส่วนหัวคำขอ

กลไกกฎสามารถเพิ่ม เขียนทับ หรือลบส่วนหัวคำขอก่อนส่งต่อไปยังต้นทางได้ การใช้งานทั่วไปคือการเพิ่ม X-Forwarded-For หรือส่วนหัวแบบกำหนดเอง เช่น X-Front-Door-Id เพื่อให้ต้นทางทราบว่าคำขอมาจาก Front Door และสามารถตรวจสอบความถูกต้องได้ นอกจากนี้ คุณยังสามารถลบส่วนหัว Host เดิมแล้วแทนที่ด้วยชื่อโฮสต์ของต้นทาง ซึ่งสำคัญเมื่อต้นทางตรวจสอบส่วนหัว Host วิธีนี้ช่วยให้คุณควบคุมสิ่งที่เซิร์ฟเวอร์ต้นทางมองเห็นได้อย่างเต็มที่

การกำหนดเส้นทางตามส่วนหัวคำขอ

เงื่อนไขของกลไกกฎสามารถจับคู่กับค่าของส่วนหัวคำขอได้ ทำให้สร้างตรรกะการกำหนดเส้นทางที่ซับซ้อนได้ ตัวอย่างเช่น กำหนดเส้นทางคำขอที่มีส่วนหัว X-API-Version: 2 ไปยังกลุ่มต้นทางอื่นที่ใช้งาน API v2 ส่วนคำขอที่ไม่มีส่วนหัวดังกล่าวจะไปยังต้นทาง v1 วิธีนี้ช่วยให้ทำการกำหนดเวอร์ชัน API แบบ blue-greenที่ขอบเครือข่ายได้ โดยไม่ต้องใช้ชื่อโฮสต์แยกสำหรับ API แต่ละเวอร์ชัน การกำหนดเส้นทางตามส่วนหัวยังใช้สำหรับการทดสอบ A/B ด้วยการกำหนดเส้นทางตามคุกกี้กลุ่มผู้ใช้แบบกำหนดเอง

การบีบอัดการตอบสนองที่ขอบเครือข่าย

การบีบอัดการตอบสนองใน Front Door จะบีบอัดการตอบสนองที่เป็นข้อความ เช่น HTML, CSS, JavaScript และ JSON โดยใช้ gzip หรือ Brotli ก่อนให้บริการจาก PoPs การบีบอัดมีประสิทธิภาพสูงสุดกับชุด JS ขนาดใหญ่ และลดขนาดข้อมูลที่ถ่ายโอนได้สูงสุด 70% เปิดใช้การบีบอัดในการตั้งค่าเส้นทางและระบุประเภท MIME ที่ต้องการบีบอัด เนื้อหาที่บีบอัดแล้วจะถูกแคชในรูปแบบที่บีบอัดที่ PoP ดังนั้นเฉพาะคำขอแรกของแต่ละทรัพยากรเท่านั้นที่ทำให้เกิดการบีบอัด ส่วนคำขอถัดไปจะให้บริการไฟล์ที่บีบอัดและแคชไว้ได้ทันที

เกราะป้องกันต้นทาง

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

การทดสอบกฎด้วย Front Door Explorer

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

# Test HTTP-to-HTTPS redirect at the CDN/Front Door edge
curl -v -L http://myapp.azurefd.net/ 2>&1 | grep -E '< (HTTP|Location)'
# Expected output:
# < HTTP/1.1 301 Moved Permanently
# < Location: https://myapp.azurefd.net/

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า กลไกกฎของ Front Doorจัดการการเปลี่ยนเส้นทาง HTTP เป็น HTTPS ส่วนหัวการตอบสนองด้านความปลอดภัย และการแทนที่ TTL ของแคชที่ขอบเครือข่าย โดยไม่ต้องแก้ไขต้นทาง การเขียน URL ใหม่จะแก้ไขเส้นทางคำขอที่ส่งต่อไปยังต้นทางโดยไม่ให้ผู้ใช้สังเกตเห็น ขณะที่การเปลี่ยนเส้นทาง URL จะเปลี่ยน URL ที่ไคลเอ็นต์มองเห็น และเกราะป้องกันต้นทางช่วยลดภาระของต้นทางด้วยการรวมคำขอที่ไม่พบในแคชผ่านโหนดเกราะป้องกันระดับภูมิภาค บทถัดไปเราจะสำรวจ Azure AI Services เพื่อเพิ่มความอัจฉริยะให้กับแอปพลิเคชันของคุณ

คำถามที่พบบ่อย

บทเรียน “เพิ่มประสิทธิภาพด้วยกฎ CDN” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เพิ่มประสิทธิภาพด้วยกฎ CDN” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Azure Fundamentals ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เพิ่มประสิทธิภาพด้วยกฎ CDN”

ใช้กลไกกฎเพื่อเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS เพิ่มส่วนหัวความปลอดภัย และใช้การกรองตามภูมิศาสตร์เพื่อจำกัดการเข้าถึงเนื้อหาจากบางประเทศ คุณปฏิบัติ Azure Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Azure Fundamentals หรือไม่

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

บทเรียน “เพิ่มประสิทธิภาพด้วยกฎ CDN” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Azure Fundamentals นี้ได้ไหม

ได้ บทเรียน Azure Fundamentals ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. โปรไฟล์และปลายทาง Azure CDN
  2. Azure Front Door: การกระจายโหลดทั่วโลก
  3. ไฟร์วอลล์เว็บแอปพลิเคชันบน Front Door
  4. เพิ่มประสิทธิภาพด้วยกฎ CDN
← กลับไปที่ Azure Fundamentals