ความล่าช้ามากเมื่อดึงหน้าจากเว็บไซต์เฉพาะ

ฉันมีปัญหาดังต่อไปนี้: เมื่อฉันดึงหน้าจากHackageฉันได้รับความล่าช้ามาก (ประมาณ 30 วินาที) คำขอเพิ่มเติมนั้นเร็ว แต่ถ้าฉันไม่เชื่อมต่อกับมันภายในสองสามนาทีปัญหาก็จะกลับมา

สิ่งที่น่าสนใจเกี่ยวกับปัญหานี้คือ:

• มันเฉพาะกับไซต์นี้โดยเฉพาะ (แฮ็กเกจ) - ฉันไม่ได้รับปัญหาที่คล้ายกันกับเว็บไซต์อื่น ๆ (และฉันเยี่ยมชมค่อนข้างน้อย);
• มันดูเหมือนจะเฉพาะเจาะจงกับ ISP ของฉัน - เมื่อฉันเชื่อมต่อจากที่อื่น ๆ ก็ไม่มีปัญหาเช่นนั้น

• ไม่เกี่ยวข้องกับ DNS หรือปัญหาการเชื่อมต่อ - อันที่จริงแล้วการเชื่อมต่อ TCP นั้นถูกสร้างขึ้นอย่างรวดเร็ว เป็นการตอบสนอง HTTP ที่ใช้เวลานานเกินไปดังที่เห็นได้จากตัวอย่างการจับแพ็คเก็ตตัวอย่างต่อไปนี้:

    1 0.000000000 192.168.1.101 -> 66.193.37.204 TCP 66 41518 > http [SYN] Seq=0 Win=13600 Len=0 MSS=1360 SACK_PERM=1 WS=16
    2 0.205708000 66.193.37.204 -> 192.168.1.101 TCP 66 http > 41518 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1440 SACK_PERM=1 WS=128
    3 0.205759000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=1 Ack=1 Win=13600 Len=0
    4 0.205846000 192.168.1.101 -> 66.193.37.204 HTTP 158 GET /packages/hackage.html HTTP/1.1 
    5 0.406461000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [ACK] Seq=1 Ack=105 Win=5888 Len=0
    6 28.433860000 66.193.37.204 -> 192.168.1.101 TCP 1494 [TCP segment of a reassembled PDU]
    7 28.433904000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=1441 Win=16480 Len=0
    8 28.434211000 66.193.37.204 -> 192.168.1.101 HTTP 1404 HTTP/1.1 200 OK  (text/html)
    9 28.434228000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=2791 Win=19360 Len=0
   10 28.434437000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [FIN, ACK] Seq=105 Ack=2791 Win=19360 Len=0
   11 28.635146000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [FIN, ACK] Seq=2791 Ack=106 Win=5888 Len=0
   12 28.635191000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=106 Ack=2792 Win=19360 Len=0
  

  (การจับแพ็คเก็ตในรูปแบบ pcap-ng ) curl http://hackage.haskell.org/packages/hackage.htmlจับภาพนี้แสดงให้เห็นว่าสิ่งที่เกิดขึ้นในช่วงที่เรียบง่าย

มันไม่สำคัญว่าฉันอยู่หลังเราเตอร์ - มันเหมือนกันเมื่อฉันเชื่อมต่อโดยตรง ประเภทการเชื่อมต่อคือ PPPoE

ฉันทำซ้ำปัญหาบนคอมพิวเตอร์ 3 เครื่องที่ใช้ Linux และ Windows

จะวินิจฉัยปัญหาดังกล่าวได้อย่างไร?

"30 วินาที" และ "หลังจากสองนาที" เป็นตัวสั่นตายสำหรับปัญหา DNS สำหรับฉัน

หากเราสมมติว่าหน้าเว็บที่คุณกำลังเชื่อมต่อนั้นทำอะไรเช่นแบบสอบถาม DNS บน IP ที่เชื่อมต่อและแบบสอบถามนั้นล้มเหลวด้วยเหตุผลบางอย่างคุณจะเห็น:

• การเชื่อมต่อ TCP เกือบจะทันทีเนื่องจากเซิร์ฟเวอร์ไม่ทำการตรวจสอบ DNS
• สคริปต์ที่ทำงานแบบสอบถามของ DNS และได้รับการติด
• หลังจาก 30 วินาทีการหมดเวลาเริ่มต้นจะหมดอายุและสคริปต์จะดำเนินต่อไป (ตอนนี้คุณเป็น "ไม่ทราบ")
• ในการสืบค้นที่ตามมา DNS เชิงลบยังคงถูกแคชและขั้นตอนที่ 1 จะถูกส่งต่อไปในเวลาไม่นาน
• หลังจากการหมดเวลาเชิงลบหมดอายุ (RFC 2308) และนั่นคือสิ่งใด ๆ ระหว่าง 2 ถึง 5 นาทีจะมีการออกแบบสอบถามใหม่ในการเชื่อมต่อครั้งถัดไปและเรื่องราวจะทำซ้ำ

... และนี่คืออาการที่คุณกำลังอธิบาย

คุณสามารถลองเรียกใช้แบบสอบถาม DNS จาก ISP อื่น (เช่น ISP2) บน IP ที่คุณได้รับจาก ISP1 ไม่ใช่หลักฐาน 100% แต่ฉันคาดว่ามีโอกาสสูงที่แบบสอบถามจะใช้เวลา 30 วินาทีจึงจะเสร็จสมบูรณ์ นั่นก็หมายความว่าเซิร์ฟเวอร์ ISP1 DNS จะมีปัญหาในการตอบแบบสอบถามจากภายนอก

สาเหตุที่เป็นไปได้อีกประการหนึ่งคือ DNS ของ ISP1 ที่ไฟร์วอลล์ถูกแฮกด้วยเหตุผลบางประการ (อาจผิดพลาด) (ในชุดของฉันเหตุผลก็คือ "netadmin ที่มีความสุขทริกเกอร์" และฉันสามารถตั้งชื่อได้) ในกรณีนั้นคุณจะมีเวลาในการวินิจฉัยที่ยากขึ้นมากสำหรับการทดสอบใด ๆ ผ่าน ISP2 จะไม่มีอะไรผิดปกติ คุณต้องเพิ่มสิ่งนี้ให้กับแฮ็ค

ปัญหาดูเหมือนว่ามีปัญหากับ "MTU" หากคุณ google "windows setting mtu" คุณควรจะได้คำตอบจำนวนมากซึ่งจะแสดงวิธีทดสอบทฤษฎีนี้และลด MTU ของคุณตามความเหมาะสม (ถ้าคุณใช้เราเตอร์ Linux ฉันสามารถสร้างคำสั่ง IPTables เพื่อทำสิ่งนี้ให้คุณแบบไดนามิก แต่ฉันไม่ "ทำ" Windows)

ฉันได้จับแพ็คเก็ตของคุณซ้ำซึ่งดูด้วยวิธีนี้ในตอนท้ายของฉัน:

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

ในระยะสั้นไม่มีเหตุผลสำหรับความล่าช้านี้เท่าที่เกี่ยวข้องกับอินเทอร์เน็ต สรุปได้ว่ามีปัญหากับ ISP ของคุณ

สิ่งที่คุณสามารถทำได้เพื่อ จำกัด โอกาสให้แคบลงคือ:

1. ลองเชื่อมต่อกับแพ็คเกจ Haskell.org อื่นและดูว่ามีความล่าช้าที่คล้ายกันหรือไม่
2. ลองใช้เราเตอร์อื่นจากสถานที่ของคุณกับคอมพิวเตอร์หลายเครื่องที่ใช้การ์ดเชื่อมต่อเครือข่ายที่แตกต่างกัน
3. ลองให้ใครสักคนในพื้นที่ของคุณที่ใช้ISP เดียวกันทำการเชื่อมต่อซ้ำ
4. ลองให้ใครสักคนในพื้นที่ของคุณที่ใช้ISP อื่นทำการเชื่อมต่อซ้ำ
5. ด้วยข้อมูลนี้หากคุณยังไม่มีคำอธิบายสำหรับความล่าช้านี้โปรดติดต่อฝ่ายสนับสนุนของ ISP ของคุณเพื่อสอบถามว่าเกิดอะไรขึ้น

[แก้ไข]

ฉันสังเกตเห็นว่า haskell.org ส่งETagดังนั้นจึงอธิบายได้ว่าทำไมการเข้าถึงครั้งแรกนั้นช้า แต่การเข้าถึงครั้งต่อไปนั้นเร็ว: เพราะตราบใดที่ ETag นั้นถูกต้องหน้าจริง ๆ แล้วมาจากแคชของเบราว์เซอร์ของคุณ

ส่วนที่แปลกนี่คือเหตุผลที่ ISP ไม่ช้าเมื่อส่งคำขอ ETag คำอธิบายอาจเป็นไปได้ว่าภายในระยะเวลาที่ จำกัด พวกเขาจะทำตามคำขอจากแคชของตัวเองแทนที่จะไปที่ haskell.org

ดูเหมือนว่าเซิร์ฟเวอร์มีปัญหา มันโหลดเร็วสำหรับฉัน หากต้องการทดสอบว่าเซิร์ฟเวอร์ไม่ชอบคุณให้ลองเข้าถึงจากพร็อกซีเช่น TOR หรือ HideMyAss.com ถ้ามันเร็วนั่นแสดงว่ามีปัญหาระหว่าง haskell.org กับบ้านของคุณ

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

การทดสอบอื่น: ล้างแคช DNS ของคุณ อาจเป็นการค้นหาที่อยู่ IP ของ haskell.org ใช้เวลานาน ipconfig /flushdns. ลองใช้ping hackage.haskell.orgจากบรรทัดคำสั่งเพื่อดูว่าต้องใช้เวลานานแค่ไหนในการค้นหาที่อยู่ IP

การทดสอบอื่น: เปิดเซสชันการท่องเว็บแบบส่วนตัวด้วย Chrome (และอื่น ๆ ) เพื่อหลีกเลี่ยงการส่งคุกกี้

การทดสอบอื่น: เปิด F12 ใน Chrome หรือ Opera ไปที่แท็บเครือข่ายแล้วไปที่ไซต์เพื่อดูเวลาสำหรับแต่ละทรัพยากร