เมื่อเข้าสู่ URL สิ่งที่เกิดขึ้นกับพื้นหลัง

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

บทความนี้จะศึกษาในเชิงลึกมากขึ้นว่าจะเกิดอะไรขึ้นในพื้นหลังเมื่อคุณป้อน URL ~

1. ก่อนอื่นคุณต้องป้อน URL ที่ต้องการในเบราว์เซอร์ : 2. เบราว์เซอร์ค้นหาที่อยู่ IP ของชื่อโดเมน

ขั้นตอนแรกในการนำทางคือการค้นหาที่อยู่ IP โดยการเข้าถึงชื่อโดเมน กระบวนการค้นหา DNS มีดังนี้:

การแคชเบราว์เซอร์ - เบราว์เซอร์แคช DNS บันทึกเป็นระยะเวลาหนึ่ง ที่น่าสนใจคือระบบปฏิบัติการไม่ได้บอกเบราว์เซอร์ถึงเวลาในการเก็บบันทึก DNS ดังนั้นเบราว์เซอร์ที่แตกต่างกันจะเก็บเวลาที่กำหนดด้วยตนเอง (ตั้งแต่ 2 นาทีถึง 30 นาที) System Cache - หากไม่พบบันทึกที่ต้องการในแคชเบราว์เซอร์เบราว์เซอร์จะทำการโทรระบบ (GethostbyName ใน Windows) สิ่งนี้ช่วยให้คุณได้รับเร็กคอร์ดในแคชระบบ เราเตอร์แคช - ถัดไปคำขอแบบสอบถามก่อนหน้านี้จะถูกส่งไปยังเราเตอร์ซึ่งโดยทั่วไปจะมีแคช DNS ของตัวเอง ISP DNS Cache - สิ่งต่อไปที่ต้องตรวจสอบคือเซิร์ฟเวอร์ที่ ISP Caches DNS นี่คือที่พบบันทึกแคชที่สอดคล้องกันโดยทั่วไป การค้นหาแบบเรียกซ้ำ-เซิร์ฟเวอร์ DNS ของ ISP ของคุณเริ่มต้นด้วยเซิร์ฟเวอร์ชื่อโดเมนจากเซิร์ฟเวอร์ชื่อโดเมนระดับบนสุด. com ไปจนถึงเซิร์ฟเวอร์ชื่อโดเมนของ Facebook โดยทั่วไปจะมีชื่อโดเมนในเซิร์ฟเวอร์ชื่อโดเมน. com ในแคชของเซิร์ฟเวอร์ DNS ดังนั้นกระบวนการจับคู่กับเซิร์ฟเวอร์ระดับบนสุดจึงไม่จำเป็น

การค้นหาแบบเรียกซ้ำ DNS แสดงในรูปด้านล่าง:

DNS ค่อนข้างกังวลนั่นคือชื่อโดเมนทั้งหมดเช่น wikipedia.org หรือ facebook.com ดูเหมือนว่าสอดคล้องกับที่อยู่ IP แยกต่างหาก โชคดีที่มีหลายวิธีในการกำจัดคอขวดนี้:

Loop DNS เป็นวิธีแก้ปัญหาเมื่อส่งคืน IP หลายครั้งเมื่อค้นหา DNS ตัวอย่างเช่น facebook.com จริง ๆ แล้วสอดคล้องกับที่อยู่ IP สี่แห่ง ตัวโหลดบาลานซ์เป็นอุปกรณ์ฮาร์ดแวร์ที่รับฟังที่อยู่ IP เฉพาะและส่งต่อคำขอเครือข่ายไปยังเซิร์ฟเวอร์คลัสเตอร์ โดยทั่วไปบางไซต์ขนาดใหญ่ใช้ตัวโหลดบาลานซ์ประสิทธิภาพสูงราคาแพงนี้ Geographic DNS ช่วยเพิ่มความสามารถในการปรับขนาดโดยการแมปชื่อโดเมนไปยังที่อยู่ IP ที่แตกต่างกันหลายแห่งตามตำแหน่งทางภูมิศาสตร์ของผู้ใช้ วิธีนี้เซิร์ฟเวอร์ที่แตกต่างกันไม่สามารถอัปเดตสถานะการซิงโครไนซ์ได้ แต่มันก็ดีมากในการแมปเนื้อหาคงที่ Anycast เป็นเทคโนโลยีการกำหนดเส้นทางที่แมปโฮสต์ทางกายภาพหลายแห่งด้วยที่อยู่ IP ข้อเสียเปรียบเพียงอย่างเดียวคือโปรโตคอล ANYCAST และ TCP ไม่ได้ปรับตัวดีดังนั้นพวกเขาจึงไม่ค่อยใช้ในโซลูชันเหล่านั้น

เซิร์ฟเวอร์ DNS ส่วนใหญ่ใช้ ANYCAST เพื่อรับการค้นหา DNS ที่มีประสิทธิภาพและต่ำ

3. เบราว์เซอร์ส่งคำขอ HTTP ไปยังเว็บเซิร์ฟเวอร์

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

ดังนั้นเบราว์เซอร์จะส่งคำขอไปยังเซิร์ฟเวอร์ที่ Facebook อยู่:

 รับ http://facebook.com/ http/1.1
 ยอมรับ: แอปพลิเคชัน/x-ms-application, image/jpeg, application/xaml+xml, [... ]
 ผู้ใช้ตัวแทน: Mozilla/4.0 (เข้ากันได้; MSIE 8.0; Windows NT 6.1; wow64; [... ]
 ยอมรับการเข้ารหัส: gzip, deflate
 การเชื่อมต่อ: Keep-Alive
 โฮสต์: facebook.com
 คุกกี้: datr = 1265876274-[... ]; locale = en_us; lsd = ww [... ]; c_user = 2101 [... ]

รับคำขอนี้กำหนด URL ที่จะอ่าน: http://facebook.com/ เบราว์เซอร์เองกำหนด (ส่วนหัว ของตัวแทนผู้ใช้ ) และประเภทของส่วนหัวที่สอดคล้องกัน ( ยอมรับ และ ยอมรับการเข้ารหัส ) ที่ต้องการยอมรับ ส่วนหัว การเชื่อมต่อ กำหนดให้เซิร์ฟเวอร์ไม่ต้องปิดการเชื่อมต่อ TCP สำหรับคำขอที่ตามมา

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

มีเครื่องมือมากมายที่จะดูคำขอ HTTP ดั้งเดิมและเครื่องมือที่เกี่ยวข้อง ผู้เขียนชอบที่จะใช้ Fiddler และแน่นอนว่ามีเครื่องมืออื่น ๆ เช่น Firebug ซอฟต์แวร์เหล่านี้สามารถช่วยได้มากเมื่อเพิ่มประสิทธิภาพเว็บไซต์

นอกเหนือจากการได้รับคำขอแล้วยังมีคำขออีกประเภทหนึ่งที่ส่งซึ่งมักใช้เมื่อส่งแบบฟอร์ม ส่งคำขอเพื่อส่งพารามิเตอร์ผ่าน URL (เช่น: http://robozzle.com/puzzle.aspx?id=85) ส่งคำขอส่งพารามิเตอร์หลังจากส่วนหัวของคำขอ

Slashes เช่น http://facebook.com/ เป็นสิ่งสำคัญ ในกรณีนี้เบราว์เซอร์สามารถเพิ่มสแลชได้อย่างปลอดภัย สำหรับที่อยู่เช่น http://example.com/folderorfile เนื่องจากเบราว์เซอร์ไม่ทราบว่า folderorfile เป็นโฟลเดอร์หรือไฟล์มันไม่สามารถเพิ่มสแลชโดยอัตโนมัติได้ ในเวลานี้เบราว์เซอร์จะเข้าถึงที่อยู่โดยตรงโดยไม่ต้องเฉือนและเซิร์ฟเวอร์จะตอบสนองต่อการเปลี่ยนเส้นทางส่งผลให้เกิดการจับมือกันที่ไม่จำเป็น

4. การตอบสนองการเปลี่ยนเส้นทางถาวรของบริการ Facebook

รูปภาพแสดงการตอบกลับที่ส่งกลับไปยังเบราว์เซอร์โดยเซิร์ฟเวอร์ Facebook:

 http/1.1 301 ย้ายอย่างถาวร
 Cache-Control: ส่วนตัว, ไม่เก็บ, ไม่มีแคช, ต้องทำการตรวจสอบ, โพสต์-ตรวจสอบ = 0,
 pre-check = 0
 หมดอายุ: SAT, 01 ม.ค. 2000 00:00:00 GMT
 สถานที่: http://www.facebook.com/
 P3P: CP = กฎหมาย DSP
 Pragma: ไม่มีแคช
 set-cookie: made_write_conn = ลบ; Expires = Thu, 12-Feb-2009 05:09:50 GMT;
 เส้นทาง =/; domain = .facebook.com; httponly
 ประเภทเนื้อหา: ข้อความ/html; charset = utf-8
 X-CNETCONT: ปิด
 วันที่: ศุกร์, 12 ก.พ. 2010 05:09:51 GMT
 ความยาวเนื้อหา: 0

เซิร์ฟเวอร์ตอบสนองต่อการตอบกลับการเปลี่ยนเส้นทางถาวร 301 เพื่อให้เบราว์เซอร์ไปที่ http://www.facebook.com/ แทนที่จะเป็น http://facebook.com/

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

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

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

5. เบราว์เซอร์ติดตามที่อยู่การเปลี่ยนเส้นทาง

ตอนนี้เบราว์เซอร์รู้ว่า http://www.facebook.com/ เป็นที่อยู่ที่ถูกต้องที่จะเข้าถึงดังนั้นมันจะส่งคำขอ GET อื่น:

 รับ http://www.facebook.com/ http/1.1
 ยอมรับ: แอปพลิเคชัน/x-ms-application, image/jpeg, application/xaml+xml, [... ]
 ยอมรับภาษา: en-us
 ผู้ใช้ตัวแทน: Mozilla/4.0 (เข้ากันได้; MSIE 8.0; Windows NT 6.1; wow64; [... ]
 ยอมรับการเข้ารหัส: gzip, deflate
 การเชื่อมต่อ: Keep-Alive
 คุกกี้: lsd = xw [... ]; c_user = 21 [... ]; X-Referer = [... ]
 โฮสต์: www.facebook.com

ข้อมูลส่วนหัวมีความหมายเช่นเดียวกับในคำขอก่อนหน้านี้

6. เซิร์ฟเวอร์จัดการคำขอ

เซิร์ฟเวอร์ได้รับคำขอดึงข้อมูลจากนั้นประมวลผลและส่งคืนการตอบกลับ

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

ซอฟต์แวร์เว็บเซิร์ฟเวอร์

ซอฟต์แวร์เว็บเซิร์ฟเวอร์ (เช่น IIS และ Apache) ได้รับคำขอ HTTP จากนั้นกำหนดว่าการประมวลผลคำขอใดจะดำเนินการเพื่อจัดการ การประมวลผลคำขอเป็นโปรแกรมที่สามารถอ่านคำขอและสร้าง HTML เพื่อตอบสนอง (เช่น ASP.NET, PHP, Ruby ... )

เพื่อให้ตัวอย่างที่ง่ายที่สุดการประมวลผลข้อกำหนดสามารถจัดเก็บไว้ในลำดับชั้นของไฟล์ที่แมปโครงสร้างที่อยู่ของไซต์ ที่อยู่เช่น http://example.com/folder1/page1.aspx จะแมปไฟล์/httpdocs/folder1/page1.aspx ซอฟต์แวร์เว็บเซิร์ฟเวอร์สามารถตั้งค่าให้เป็นคำขอที่เกี่ยวข้องกับการประมวลผลด้วยตนเองตามที่อยู่เพื่อให้ที่อยู่เผยแพร่ของหน้า 1.aspx สามารถเป็น http://example.com/folder1/page1

ขอการประมวลผล

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

เว็บไซต์ไดนามิกทั้งหมดต้องเผชิญกับความยากลำบากที่น่าสนใจ - วิธีการจัดเก็บข้อมูล ครึ่งหนึ่งของเว็บไซต์ขนาดเล็กจะมีฐานข้อมูล SQL เพื่อจัดเก็บข้อมูล การจัดเก็บข้อมูลจำนวนมากและ/หรือเว็บไซต์ที่เข้าชมอย่างหนักต้องหาวิธีบางอย่างในการจัดสรรฐานข้อมูลให้กับเครื่องหลายเครื่อง โซลูชันรวมถึง: การให้ข้อมูล (ขึ้นอยู่กับค่าคีย์หลักตารางข้อมูลจะกระจัดกระจายไปในฐานข้อมูลหลายฐานข้อมูล) การจำลองแบบและฐานข้อมูลที่ง่ายขึ้นซึ่งใช้ความสอดคล้องทางความหมายที่อ่อนแอ

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

7. เซิร์ฟเวอร์ส่งการตอบกลับ HTML กลับมา

ภาพคือการตอบกลับที่สร้างและส่งคืนโดยเซิร์ฟเวอร์:

 http/1.1 200 ตกลง
 Cache-Control: ส่วนตัว, ไม่เก็บ, ไม่มีแคช, ต้องทำการตรวจสอบ, โพสต์-ตรวจสอบ = 0,
 pre-check = 0
 หมดอายุ: SAT, 01 ม.ค. 2000 00:00:00 GMT
 P3P: CP = กฎหมาย DSP
 Pragma: ไม่มีแคช
 การเข้ารหัสเนื้อหา: GZIP
 ประเภทเนื้อหา: ข้อความ/html; charset = utf-8
 X-CNETCONT: ปิด
 การเข้ารหัสการถ่ายโอน: chunked
 วันที่: ศุกร์, 12 ก.พ. 2010 09:05:55 GMT
 2b3tn@[... ]

ขนาดการตอบสนองทั้งหมดคือ 35KB ซึ่งส่วนใหญ่จะถูกถ่ายโอนเป็นประเภทหยดหลังจากการเรียงลำดับ

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

 <! doctype html สาธารณะ -// w3c // dtd xhtml 1.0 เข้มงวด // en
 http://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd>
 <html xmlns = http: //www.w3.org/1999/xhtml xml: lang = en
 lang = en id = คลาส Facebook = no_js>
 <head>
 <meta http-equiv = เนื้อหาประเภทเนื้อหา = text/html; charset = utf-8 />
 <meta http-equiv = content-language content = en />
 -

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

โปรดทราบว่า ประเภทเนื้อหา ถูกตั้งค่าเป็น text/html ในส่วนหัว ส่วนหัวช่วยให้เบราว์เซอร์แสดงเนื้อหาการตอบกลับใน HTML แทนการดาวน์โหลดในรูปแบบไฟล์ เบราว์เซอร์จะตัดสินใจว่าจะตีความการตอบสนองตามข้อมูลส่วนหัวได้อย่างไร แต่จะพิจารณาปัจจัยอื่น ๆ เช่นเนื้อหาส่วนขยาย URL

8. เบราว์เซอร์เริ่มแสดง HTML

เมื่อเบราว์เซอร์ไม่ยอมรับเอกสาร HTML ทั้งหมดอย่างเต็มที่จะเริ่มแสดงหน้านี้:

9. เบราว์เซอร์ส่งไปรับวัตถุที่ฝังอยู่ใน HTML

เมื่อเบราว์เซอร์แสดง HTML มันจะสังเกตเห็นแท็กที่จำเป็นต้องได้รับเนื้อหาของที่อยู่อื่น ในเวลานี้เบราว์เซอร์จะส่งคำขอ GET เพื่อเรียกคืนไฟล์

นี่คือ URL บางส่วนที่เราจำเป็นต้องได้รับอีกครั้งเมื่อไปที่ Facebook.com:

รูปภาพ

http://static.ak.fbcdn.net/rsrc.php/z12e0/hash/8q2anwu7.gif

http://static.ak.fbcdn.net/rsrc.php/zbs5c/hash/7hwy7at6.gif

… ตารางสไตล์ CSS

http://static.ak.fbcdn.net/rsrc.php/z448z/hash/2plhh8s4n.css

http://static.ak.fbcdn.net/rsrc.php/zane1/hash/cvtutcee.css

… ไฟล์ JavaScript

http://static.ak.fbcdn.net/rsrc.php/zemoa/hash/c8yzb6ub.js

http://static.ak.fbcdn.net/rsrc.php/z6r9l/hash/cq2lgbs8.js

-

ที่อยู่เหล่านี้ทั้งหมดผ่านกระบวนการที่คล้ายกันกับการอ่าน HTML ดังนั้นเบราว์เซอร์จะค้นหาชื่อโดเมนเหล่านี้ใน DNS ส่งคำขอเปลี่ยนเส้นทาง ฯลฯ

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

พยายามเดาว่า fbcdn.net แสดงในที่อยู่หรือไม่? คำตอบที่ฉลาดคือเครือข่ายการกระจายเนื้อหา Facebook Facebook ใช้เครือข่ายการกระจายเนื้อหา (CDN) เพื่อแจกจ่ายไฟล์คงที่เช่นรูปภาพตาราง CSS และไฟล์ JavaScript ดังนั้นไฟล์เหล่านี้จะได้รับการสำรองในศูนย์ข้อมูล CDN หลายแห่งทั่วโลก

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

ตัวอย่างเช่นเมื่อคุณพยายาม ping static.ak.fbcdn.net คุณอาจได้รับการตอบกลับจากเซิร์ฟเวอร์ Akamai.net ที่น่าสนใจเมื่อคุณ ping อีกครั้งเซิร์ฟเวอร์การตอบสนองอาจแตกต่างกันซึ่งหมายความว่าการโหลดบาลานซ์เบื้องหลังฉากกำลังเริ่มทำงาน

10. เบราว์เซอร์ส่งคำขอแบบอะซิงโครนัส (AJAX)

นำโดย The Great Spirit of Web 2.0 ลูกค้ายังคงติดต่อกับเซิร์ฟเวอร์หลังจากการแสดงหน้าเสร็จสมบูรณ์

ใช้ฟังก์ชั่นการแชท Facebook เป็นตัวอย่างมันจะติดต่อกับเซิร์ฟเวอร์เพื่ออัปเดตสถานะเพื่อนที่สดใสและสีเทาของคุณในเวลาที่เหมาะสม ในการอัปเดตสถานะเพื่อนของอวตารเหล่านี้รหัส JavaScript ที่ดำเนินการในเบราว์เซอร์จะส่งคำขอแบบอะซิงโครนัสไปยังเซิร์ฟเวอร์ คำขอแบบอะซิงโครนัสนี้จะถูกส่งไปยังที่อยู่เฉพาะซึ่งเป็นการดึงหรือส่งคำขอส่งโปรแกรม หรือในตัวอย่าง Facebook ลูกค้าจะส่งคำขอไปที่ http://www.facebook.com/ajax/chat/buddy_list.php เพื่อรับข้อมูลสถานะที่ออนไลน์ในเพื่อนของคุณ

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

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

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

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