Show HN: คอมพิวเตอร์มาถึงเซิร์ฟเวอร์ของฉันได้อย่างไร?

 (how-did-i-get-here.net)
4 คะแนน โดย GN⁺ 2023-12-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อผู้เข้าชมเปิดเว็บไซต์ เซิร์ฟเวอร์จะรัน traceroute ไปยัง IP สาธารณะนั้น เพื่อแสดงเส้นทางที่แพ็กเก็ตเดินทางผ่านเราเตอร์และเครือข่ายแบบข้อความสด
  • เครื่องมือภายในชื่อ ktr จะค่อยๆ เพิ่มค่า TTL ของแพ็กเก็ต ICMP เพื่อรวบรวมการตอบกลับข้อผิดพลาดจากแต่ละฮอป พร้อมกับดึงข้อมูลเครือข่ายของแต่ละฮอปไปพร้อมกัน
  • การอัปเดตหน้าจอไม่ได้ทำด้วย JavaScript แต่ทำโดยค่อยๆ ส่ง HTML และ CSS ผ่าน HTTP response ที่เปิดค้างไว้ จึงทำให้ผลลัพธ์ค่อยๆ ปรากฏขึ้นระหว่างที่หน้าเว็บกำลังโหลด
  • เส้นทางที่แสดงคือการนำ reverse traceroute ที่ส่งจากเซิร์ฟเวอร์ไปยัง IP ของผู้เข้าชมมาสลับลำดับ จึงอาจไม่ตรงกับเส้นทางจริงทั้งหมดเนื่องจากความต่างของการเราต์แบบไป-กลับ
  • เส้นทางบนอินเทอร์เน็ตถูกสร้างขึ้นจาก BGP peering ระหว่างระบบอัตโนมัติ (AS) และการกระจายตารางเราต์ โดยทราฟฟิกจะเคลื่อนที่ผ่านเครือข่ายที่เชื่อมต่อถึงกัน

traceroute แบบปรับเฉพาะบุคคลที่ถูกสร้างใหม่ทุกครั้งที่เข้า

  • ข้อความสีเขียวด้านบนของหน้าไม่ใช่ตัวอย่างที่บันทึกไว้ล่วงหน้า แต่เป็น traceroute ที่สร้างขึ้นสดๆ ให้เหมาะกับผู้เข้าชมระหว่างที่เว็บไซต์กำลังโหลด
  • traceroute จะแสดงการเดินทางของคอมพิวเตอร์ของผู้เข้าชมหรือแพ็กเก็ตของมันผ่านอินเทอร์เน็ตเพื่อมาถึงเซิร์ฟเวอร์ที่โฮสต์เว็บไซต์นี้
  • เส้นทางตัวอย่างเริ่มจากเราเตอร์ของผู้เข้าชม ผ่านเครือข่ายของ ISP ผ่านหลายเครือข่าย แล้วเข้าสู่เครือข่ายภายในของ Hetzner ก่อนถึงเซิร์ฟเวอร์
    • เราเตอร์ตัวแรกอาจไม่ตอบ ping ซึ่งเป็นเรื่องปกติหากอยู่หลังเราเตอร์สาธารณะหรือ VPN
    • อาจมี (no response) ปรากฏขึ้นระหว่างทาง และไม่ใช่ทุกเซิร์ฟเวอร์ที่จะตอบกลับเสมอ
  • ชื่ออย่าง core3.sto.hetzner.com คือผลจากการทำ reverse DNS lookup กับ IP 213.239.252.74 ที่ได้จาก traceroute เพื่อแปลงให้อ่านง่ายสำหรับมนุษย์
    • ชื่อ reverse DNS มักมีไว้เพื่อช่วยการดีบักเป็นหลัก และหลายครั้งก็ไม่ได้แมปกลับไปยัง IP เดิม

ktr และ traceroute ที่ใช้ ICMP

  • เว็บไซต์นี้ใช้โปรแกรม traceroute ภายในชื่อ ktr
    • ซอร์สโค้ดของเว็บไซต์ก็เปิดเผยไว้บน GitHub
    • ktr สามารถสตรีมผลลัพธ์แบบเรียลไทม์พร้อมกับค้นหาข้อมูลของแต่ละฮอปไปพร้อมกัน
  • ในการเราต์บนอินเทอร์เน็ต คอมพิวเตอร์หรือเราเตอร์ที่จัดการแพ็กเก็ตจะเลือกอุปกรณ์ถัดไปสำหรับส่งต่อ และกระบวนการนี้จะดำเนินต่อไปจนกว่าจะถึงเราเตอร์ที่ส่งตรงไปยังปลายทางได้
  • การทำงานของ ktr ใช้ ICMP
    • ICMP เป็นโปรโตคอลที่ออกแบบมาเพื่อส่งข้อมูลสำหรับการวินิจฉัยบนอินเทอร์เน็ต
    • อุปกรณ์ที่เชื่อมต่ออินเทอร์เน็ตเกือบทั้งหมดรองรับ ICMP
  • ฟิลด์ TTL (time to live) ของแพ็กเก็ต ICMP ไม่ใช่เวลา แต่เป็นค่าถอยหลังนับ
    • ทุกครั้งที่เราเตอร์ส่งต่อแพ็กเก็ต ICMP จะต้องลด TTL ลง 1
    • เมื่อ TTL กลายเป็น 0 เราเตอร์จะหยุดส่งต่อแพ็กเก็ต และส่งข้อความผิดพลาดกลับไปยัง IP ต้นทางเดิมว่าเกินจำนวนฮอปสูงสุดแล้ว
  • traceroute จะส่งแพ็กเก็ต ICMP ที่เพิ่มค่า TTL ทีละขั้น เช่น 1, 2, 3 เพื่อรวบรวมการตอบกลับข้อผิดพลาดจากแต่ละฮอป
    • แพ็กเก็ตข้อผิดพลาดมีข้อมูลสำหรับการวินิจฉัย เช่น IP address ของอุปกรณ์ที่ส่งข้อผิดพลาดนั้น
    • ทำให้สามารถติดตามเส้นทางโดยประมาณของแพ็กเก็ตผ่านอินเทอร์เน็ตได้

หน้าจอที่ดูเหมือนเรียลไทม์โดยไม่ใช้ JavaScript

  • หน้านี้ทำงานได้แม้ในสถานะที่ ปิดการใช้งาน JavaScript
    • จากมุมมองของเบราว์เซอร์ เว็บไซต์ดูเหมือนกำลังโหลดอย่างช้าๆ
    • แต่สำหรับผู้ใช้ มันดูเหมือน traceroute กำลังปรากฏขึ้นแบบเรียลไทม์
  • เมื่อมีการเชื่อมต่อ เซิร์ฟเวอร์จะรับ HTTP request ที่มาจาก IP address ของผู้เข้าชม และเริ่มรัน traceroute ไปยัง IP นั้นทันที
  • จากนั้นเซิร์ฟเวอร์จะส่งส่วนต้นของ HTTP response ออกไปก่อน แล้วคงการเชื่อมต่อไว้
    • ktr จะส่งอัปเดต traceroute มายังเซิร์ฟเวอร์
    • เซิร์ฟเวอร์จะเรนเดอร์ HTML ที่เกี่ยวข้องแล้วส่งไปยังคอมพิวเตอร์ของผู้เข้าชม
    • เมื่อ traceroute จบ จึงค่อยส่งข้อความที่เหลือและเนื้อหาเว็บไซต์ แล้วปิดการเชื่อมต่อ
  • สาเหตุที่บรรทัด traceroute ดูเหมือนค่อยๆ อัปเดตจากด้านบนแทนที่จะเป็นด้านล่าง มาจาก การแทรกบล็อก CSS
    • โดยปกติแล้วหน้าเว็บสามารถโหลดไปข้างหน้าได้เท่านั้น
    • ทุกครั้งที่อัปเดตการแสดง traceroute จะมีการแทรก CSS เพื่อซ่อนการแสดงผลก่อนหน้าไปพร้อมกัน
    • เพราะเบราว์เซอร์เรนเดอร์ CSS ระหว่างโหลด หน้าจอจึงดูเหมือนถูกแก้ไขไปตามเวลา

ข้อจำกัดของ reverse traceroute

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

ระบบอัตโนมัติและการค้นหา WHOIS

  • “เครือข่าย” ที่ปรากฏใน traceroute หมายถึง ระบบอัตโนมัติ (AS)
    • AS คือกลุ่มของเราเตอร์และเซิร์ฟเวอร์ที่เชื่อมต่อกันภายในแบบส่วนตัว
    • โดยทั่วไปมักเป็นของบริษัทเดียวกัน
  • เจ้าของ AS เป็นผู้เลือกว่าจะเชื่อมต่อกับ AS อื่นใด และจึงเป็นผู้กำหนดรูปร่างของอินเทอร์เน็ต
    • ทราฟฟิกอินเทอร์เน็ตจะเคลื่อนที่ผ่าน AS ที่มี ข้อตกลง peering ระหว่างกัน
  • แม้อินเทอร์เน็ตจะดูเหมือนเครือข่ายเปิด แต่ในความเป็นจริงมันคือเครือข่ายของเครือข่ายที่บริษัทเป็นเจ้าของ และการเข้าถึงกับการควบคุมก็ขึ้นอยู่กับธุรกรรมทางการเงินและกระบวนการทางระบบ
  • หากต้องการมีระบบอัตโนมัติของตนเอง สามารถยื่นขอ ASN กับหนึ่งในห้า Regional Internet Registry (RIR) ได้
    • หากไม่มีบริษัทหนุนหลังหรือมีจุดเชื่อมต่ออินเทอร์เน็ตไม่เพียงพอ ก็มีโอกาสถูกปฏิเสธสูง
    • ตัวเลขอย่าง AS4766 ใน traceroute คือ ASN
  • ktr ใช้ โปรโตคอล WHOIS เพื่อดึงข้อมูล AS ที่เป็นเจ้าของ IP ของแต่ละฮอป
    • มีหลายองค์กรที่ติดตามว่า AS ใดครอบคลุม IP address ใดบ้าง
    • หลายองค์กรให้บริการค้นหา ASN ผ่าน WHOIS
  • PeeringDB ก็ถูกใช้เพื่อระบุข้อมูลของบริษัทเช่นกัน
    • PeeringDB มีข้อมูลของระบบอัตโนมัติประมาณ 1 ใน 3 ของทั้งหมด
    • ผลการค้นหาถูกนำมารวมกับ if statement หลายร้อยบรรทัดเพื่อสร้างคำอธิบายการผ่านเครือข่าย
  • ข้อกำหนดของโปรโตคอล WHOIS แทบไม่ได้กำหนดโครงสร้างไว้เลย
    • มันกำหนดเพียงว่าต้องสร้างการเชื่อมต่อ TCP ส่งข้อความค้นหา แล้วเซิร์ฟเวอร์ส่งข้อมูลกลับมาก่อนปิดการเชื่อมต่อ
    • โครงสร้างของคำตอบ WHOIS จริงๆ จึงใกล้เคียงกับธรรมเนียมที่ผู้ดูแลเซิร์ฟเวอร์ตั้งกันเอง และแม้แต่ชื่อฟิลด์ที่ต้องใช้ก็อาจต่างกัน เช่น origin, originas
    • parser ของ ktr จึงไม่ใช่ parser แบบเข้มงวด แต่ใกล้เคียงกับวิธีที่มนุษย์อ่านผล WHOIS แล้วมองหา ASN ที่ต้องการมากกว่า

BGP สร้างเส้นทางอินเทอร์เน็ตอย่างไร

  • เราเตอร์ที่ขอบเครือข่ายจะตัดสินใจว่าจะส่งแพ็กเก็ตไปยังเครือข่ายใดเป็นลำดับถัดไป และกระบวนการเดียวกันนี้จะเกิดซ้ำจนกว่าจะถึงเครือข่ายที่มีอุปกรณ์ปลายทางอยู่
  • เราเตอร์ขอบเหล่านี้แลกเปลี่ยนข้อมูลเกี่ยวกับเครือข่ายที่เชื่อมต่อถึงกันได้ผ่าน Border Gateway Protocol (BGP)
    • BGP คือโปรโตคอลที่สร้างรูปร่างของอินเทอร์เน็ต
    • ผู้ใช้ทั่วไปไม่สามารถพูด BGP ได้โดยตรง
  • BGP รุ่นแรกเริ่มถูกอธิบายไว้ใน RFC 1105 ที่เผยแพร่โดยวิศวกรของ Cisco และ IBM ในปี 1989
    • หลังจากต้นแบบ ARPANET ในปี 1969 ที่ข้อความถูกส่งได้เพียงบางส่วน มหาวิทยาลัย หน่วยงานรัฐบาล และบริษัทต่างๆ ก็เริ่มสร้างเครือข่ายของตนเองและเชื่อมต่อเข้าหากัน
    • ในปี 1990 มี BGP v2
    • ในปี 1994 BGP v4 ถูกกำหนดไว้ใน RFC 1654
    • BGP v4 ถูกปรับแก้และแพตช์ในปี 1995 และ 2006 และยังคงถูกใช้ในการเลือกเส้นทางของเครือข่ายที่เชื่อมต่อถึงกันบนอินเทอร์เน็ตยุคปัจจุบัน

เส้นทาง BGP, peering และตารางเราต์

  • border gateway ซึ่งเป็นเราเตอร์ที่ขอบของระบบอัตโนมัติ จะเก็บตารางเราต์ที่เป็นรายการเส้นทาง BGP ทั้งหมดที่มันรู้จัก
  • แต่ละเส้นทาง BGP จะระบุ เส้นทาง ASN ที่สามารถใช้เพื่อไปถึง AS ที่ควบคุมชุดของ IP address เฉพาะได้
  • เส้นทาง BGP ถูกสร้างขึ้นผ่านความสัมพันธ์แบบ peering ระหว่าง AS
    • เมื่อ border gateway ของสอง AS ทำ peer กัน ทราฟฟิกก็สามารถวิ่งระหว่างเราเตอร์ทั้งสองได้
    • และทั้งคู่จะแลกเปลี่ยนข้อมูลเส้นทาง BGP ที่ตนรู้เพื่อให้เป็นปัจจุบัน
  • ยกตัวอย่าง หาก Router A ของ AS0001 กับ Router B ของ AS0002 เชื่อมต่อกันทางกายภาพและต้องการทำ peering พวกมันจะแลกข้อความ BGP เพื่อสร้าง BGP session
    • Router A จะได้รู้ว่าหากต้องการไปยังเส้นทาง BGP ที่เริ่มต้นด้วย AS0002 ต้องผ่าน Router B
    • Router B ก็จะได้ข้อมูลในทิศทางกลับกันเช่นเดียวกัน
  • peer จะแชร์เส้นทางที่ตนรู้ผ่านกระบวนการ route advertisement
    • หาก Router A แจ้งเส้นทางทั้งหมดที่มันรู้ให้ Router B ทราบ Router B ก็จะเพิ่มเส้นทางที่เริ่มต้นด้วย AS0001 ลงในตารางเราต์ของตน
    • หาก peer รายอื่นของ Router A โฆษณาเส้นทางใหม่ Router A ก็จะส่งต่อข้อมูลนั้นให้ Router B ด้วย
  • เมื่อการโฆษณานี้แพร่กระจายไปทั่วเครือข่าย AS ทั้งหมด แต่ละ border gateway ก็จะรู้เส้นทาง AS path อย่างน้อยหนึ่งเส้นไปยัง IP ใดๆ บนอินเทอร์เน็ต
  • เมื่อเราเตอร์ต้องส่งแพ็กเก็ตไปยัง IP หนึ่ง มันจะค้นหาเส้นทางไปยัง AS ที่ควบคุม IP นั้นจากในตารางเราต์
    • จากนั้นจะใช้ heuristic หลายอย่างเพื่อเลือกเส้นทางที่ “ดีที่สุด”
    • heuristic เหล่านี้รวมถึงการหาเส้นทางที่สั้นที่สุด และการตั้งค่าความชอบหรือไม่ชอบแบบฮาร์ดโค้ดต่อ AS บางราย
    • แล้วเราเตอร์จะส่งแพ็กเก็ตไปยัง gateway router ที่ทำ peering กับ AS แรกในเส้นทางที่เลือกไว้

การอ่านผล traceroute ในมุมมองของ BGP

  • AS path ของ traceroute ตัวอย่างคือ AS4766 → AS201011 → AS24940
  • ณ จุดหนึ่ง แพ็กเก็ตได้มาถึงเราเตอร์ตัวหนึ่งของ AS4766 และเราเตอร์นั้นมี peering กับเราเตอร์ของ AS201011
    • เราเตอร์ตัดสินจากตารางเราต์ว่าปลายทาง IP สามารถเข้าถึงได้ผ่านเส้นทางที่เริ่มด้วย AS201011
    • จากนั้นจึงส่งแพ็กเก็ตต่อไปยังเราเตอร์ของ AS201011 ที่เชื่อมต่ออยู่
  • แม้อยู่ภายใน ASN เดียวกันก็อาจมีหลายฮอปได้
    • เช่นหกฮอปที่ผ่าน Hetzner Online เพราะ traceroute ไม่ได้แสดงเฉพาะเราเตอร์ขอบของ AS แต่แสดงเราเตอร์ทุกตัวที่แพ็กเก็ตเดินทางผ่าน
  • เราเตอร์ภายใน AS อาจให้ความสำคัญกับเส้นทางภายในมากกว่าเส้นทาง BGP ภายนอก หากรู้เส้นทางภายในที่มีประสิทธิภาพกว่า
    • เส้นทางภายในอาจถูกเรียนรู้ผ่าน internal BGP, โปรโตคอลเราต์ภายในอื่นๆ หรือการตั้งค่าแบบฮาร์ดโค้ด
  • ปัจจัยสำคัญที่กำหนดความสามารถในการเข้าถึงกันบนอินเทอร์เน็ตไม่ใช่ฮอปภายใน แต่คือ ข้อตกลง peering ระหว่าง AS ที่แตกต่างกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-06
ความคิดเห็นจาก Hacker News

  • สวัสดีครับ/ค่ะ ผม/ฉันชื่อ Lexi อายุ 17 ปี และช่วงนี้สิ่งที่สนใจคือการทำความเข้าใจให้ลึกขึ้นว่า คอมพิวเตอร์ทำงานอย่างไร แล้วนำเสนอสิ่งนั้นในรูปแบบใหม่ ๆ
    เมื่อไม่กี่เดือนก่อนผม/ฉันเปิดตัว https://cpu.land และการสนทนาที่เกี่ยวข้องอยู่ที่ https://news.ycombinator.com/item?id=37062422
    หลังจาก cpu.land ผม/ฉันรู้สึกกดดันมากว่าต้องสร้างผลงานชิ้นใหญ่อีกชิ้นหนึ่ง แต่ก็ไม่มีไอเดียที่รู้สึกสนใจเป็นพิเศษ เลยลองทำโปรเจกต์ส่วนตัวหลาย ๆ อย่างไปเรื่อย ๆ ระหว่างที่บังเอิญได้เรียนรู้วิธีการทำงานของอินเทอร์เน็ต ก็เลยสร้างโปรแกรม traceroute ที่สตรีมแบบเรียลไทม์ไปยังเว็บไซต์ขึ้นมาตั้งแต่ต้น
    ผม/ฉันไม่เคยเห็นรูปแบบแบบนี้บนเว็บมาก่อน และคิดว่ามันเป็นวิธีที่ค่อนข้างใหม่และเจ๋งในการทำให้โครงสร้างอินเทอร์เน็ตมองเห็นได้ เลยขัดเกลาและทำให้เป็นไซต์ที่สวยงาม
    ระหว่างนั้นผม/ฉันได้เรียนรู้เรื่องน่าสนใจมากมายเกี่ยวกับ BGP และโครงสร้างอินเทอร์เน็ต จึงรวมเครื่องมือ traceroute เข้ากับบทความที่แบ่งปันความรู้นั้น
    ตอนนี้ยังปรับแต่งอยู่เรื่อย ๆ และโค้ดคงต้องพังที่ไหนสักแห่งแน่ ๆ ถ้ามีข้อเสนอแนะก็อยากให้บอกกัน
    อีกอย่าง เหตุผลที่ใช้ Rust คือ แม้ผม/ฉันจะไม่ได้คิดว่าการเลือกภาษาโปรแกรมมิ่งสำคัญมากเป็นพิเศษ แต่ผม/ฉันอยากเขียนโปรแกรม low-level ที่เชื่อถือได้อย่างรวดเร็ว และชอบองค์ประกอบพื้นฐานด้านการจัดการข้อผิดพลาดของ Rust

    • ถ้าบอกว่า “ไม่เคยเห็นอะไรแบบนี้บนเว็บมาก่อน” ลองค้นหา looking glass bgp ดู จะเจอสิ่งที่คล้ายกัน
      หนึ่งในโปรแกรม CGI แรก ๆ ที่ผม/ฉันทำเมื่อเกือบ 30 ปีก่อน เป็นสคริปต์ Perl ที่ครอบ traceroute แล้วสตรีมผลลัพธ์ด้วย server push
      ของเก่ามักกลับมาใหม่ได้เสมอ แต่ถึงอย่างนั้นการนำเสนอของไซต์นี้ก็ทำได้ดีมาก
      สำหรับข้อมูลเพิ่มเติม IPv4 TTL ในทางกฎเกณฑ์แล้วเป็นหน่วยวินาที แต่ไม่มีเราเตอร์ตัวไหนกินเวลาเกิน 1 วินาที และค่าที่ลดลงขั้นต่ำคือ 1 จึงถูกใช้เป็นจำนวน hop โดยพฤตินัย ส่วน middlebox ที่อยากซ่อนตัวบางทีก็ไม่ลดค่าเลย
      อีกอย่าง Linux/Unix traceroute โดยค่าเริ่มต้นจะใช้ UDP ไปยังพอร์ตเลขสูงที่ปกติปิดอยู่สำหรับแพ็กเก็ต probe แทน ICMP เพราะในอดีต UDP มีโอกาสถูก drop หรือ filter น้อยกว่า ICMP
      การถามว่า traceroute ทำงานอย่างไรเป็นหนึ่งในคำถามสัมภาษณ์ แต่คนส่วนใหญ่ไม่รู้ และต่อให้รู้ก็ทำให้คุณค่าของคำถามลดลง ถามเรื่อง TCP/IP ไปเท่าไรก็มักมีหลายกรณีที่ไม่สามารถอนุมานจากหลักการพื้นฐานได้ และผม/ฉันมองว่าการดูว่ายังแก้โจทย์ออกได้ไหมเป็นคำถามแก้ปัญหาที่สมเหตุสมผล
      ตัวอย่าง: https://www.bgplookingglass.com/
      https://www.oreilly.com/openbook/cgi/ch06_06.html
    • เป็นโปรเจกต์ที่ยอดเยี่ยม มีข้อเสนอแนะจริงจังหนึ่งข้อกับข้อเสนอแนะเบา ๆ อีกหนึ่งข้อ
      สงสัยว่าถ้าใช้ TCP หรือ UDP แทน ICMP จะได้ผลลัพธ์ที่แม่นยำขึ้นไหม traceroute แบบดั้งเดิมก็มีตัวเลือก UDP และ mtr [1] ใช้ TCP หรือ UDP ได้ ส่วน tcptraceroute [2] ใช้ TCP ได้
      แล้วก็เหมาะมากที่จะใส่คำอ้างอิงจาก Talking Heads: “And you may ask yourself, well, how did I get here?” [3]
      [1] https://github.com/traviscross/mtr
      [2] https://linux.die.net/man/1/tcptraceroute
      [3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
    • ทำอะไรเจ๋ง ๆ ได้เยอะกว่าผม/ฉันตอนอายุ 17 มาก ถ้าดู “I, Robot” แล้วสนุก ก็ขอแนะนำ Stories of Your Life and Others ของ Ted Chiang ด้วย ภาพยนตร์ Arrival สร้างจากเรื่องหนึ่งในรวมเรื่องสั้นเล่มนี้
    • เป็นไซต์ที่ดีสำหรับอธิบาย traceroute มีประโยชน์มาก คิดว่าน่าจะใช้ตอนอธิบาย ประโยชน์ของ traceroute ให้ช่างเทคนิคหลายคนที่ฝึกให้ดูแลเครือข่ายบริษัทได้
      ทีนี้ถ้าหาวิธีให้ traceroute ทำงานที่แต่ละ hop ได้ ตั้งแต่เวิร์กสเตชันเครื่องหนึ่ง ผ่าน Cisco access switch ของบริษัท, core switch, อุโมงค์ BGP ไปยัง AWS transit gateway จนถึง routing table ของ VPC ของ EC2 instance ก็เรียกตัวเองว่าเป็นคนดูแลเครือข่ายได้แล้วมั้ง
    • เจ๋งดี เกร็งเลยว่าจะเห็นวงจร Tor ไหม
      น่าเสียดายที่มี node จำนวนมากเกินไปที่เมินแพ็กเก็ต traceroute เลยออกมาแค่เหมือน exit node ของผม/ฉันเชื่อมต่อกับ Linode และ Linode เชื่อมต่อกับคอมพิวเตอร์ของคุณ
      ใน traceroute แบบทิศทางไปข้างหน้าก็คล้ายกัน คือเราเตอร์ตอบกลับและเซิร์ฟเวอร์ตอบกลับ และถ้าโชคดีก็เห็น node ในเครือข่ายของ ISP ได้สักตัวหนึ่ง ที่เหลือถูกปิดไว้แน่นหนา

  • ถึงจะบอกว่า “BGP เป็นโปรโตคอลที่ทำให้อินเทอร์เน็ตมีรูปร่าง และไม่สามารถพูดคุยกับมันได้โดยตรง” แต่ในความเป็นจริง การที่บุคคลทั่วไปจะได้ ASN และพูด BGP นั้นง่ายจนน่าประหลาดใจ
    ถ้าการทำเครื่องมือแบบนี้น่าสนใจ ก็น่าลองทำดู ถ้าสนใจ ผม/ฉันเคยเขียนบทความแนะนำไว้ด้วย: https://qt.ax/asn

  • อันนี้ดูจะใกล้เคียงกับ เส้นทางย้อนกลับของวิธีที่เซิร์ฟเวอร์ของคุณไปถึงคอมพิวเตอร์ของผม/ฉัน มากกว่า “วิธีที่คอมพิวเตอร์ของผม/ฉันไปถึงเซิร์ฟเวอร์ของคุณ” การ routing สองทิศทางส่วนใหญ่น่าจะต่างกันพอสมควร

    • ในบทความมีส่วน Front to Back, Back to Front ที่พูดถึงเรื่องนี้จริง ๆ
      สรุปคือ จากประสบการณ์ของผม/ฉัน เครือข่ายที่ผ่านมักคล้ายกันมาก และไม่ว่าจะทิศทางไหน เนื้อหาก็เกี่ยวข้องและน่าสนใจ
    • ในยุค bang path การดูว่า bang path ของผู้ส่งกับ bang path สำหรับตอบกลับต่างกันแค่ไหน แล้วอนุมานว่าความแตกต่างของการเชื่อมต่อเครือข่ายแบบใดที่สร้าง ความไม่สมมาตร เป็นเรื่องสนุก

  • มีบทความวิจัยที่น่าสนใจเกี่ยวกับวิธีการทำงานของ traceroute สิ่งที่คนที่ไม่ได้อยู่สายเครือข่ายมักมองข้ามคือ traceroute ไม่จำเป็นต้อง สมมาตร เสมอไป เส้นทางขากลับอาจต่างกันได้
    https://archive.nanog.org/sites/default/files/traceroute-201...

    • วันนี้มีอินเทอร์เน็ตขัดข้องในอียิปต์จากปัญหาของ Telecom Egypt และ traceroute ไปยังปลายทางเดียวกันวิ่งผ่าน 8 เส้นทางที่ต่างกัน
      เรียกได้ว่าเป็นจำนวน ECMP ที่มากเป็นสองเท่าของที่เคยเห็นบนอินเทอร์เน็ตเลย
      และทราฟฟิกจากสำนักงานไคโรไปยังคอร์ในสหราชอาณาจักรกับทราฟฟิกทิศทางกลับก็วิ่งคนละเส้นทางกันด้วย London→Cairo เป็นทางตรงและยังมี packet loss จำนวนมาก แต่ Cairo→London ตอนนี้วิ่งผ่าน ntt และดูโอเค ถ้ายังไม่แก้ได้ภายในพรุ่งนี้ อาจต้องปรับ local preference
    • พบไม่บ่อยนัก แต่ data path เองก็อาจไม่สมมาตรได้ เช่นกรณี ดาวเทียมที่ใช้อัปลิงก์ภาคพื้นดิน
    • ขอบคุณ จะลองอ่านดู ความเป็นสองด้านนี้ผมก็พูดถึงไว้ในบทความแล้ว

  • บอกว่า “WHOIS เป็นโปรโตคอลที่น่าสนใจสำหรับการทำ parser” แต่ในความเป็นจริงแทบ เป็นไปไม่ได้
    คำตอบโดยพื้นฐานเป็นรูปแบบอิสระ และเซิร์ฟเวอร์อาจไม่ตอบกลับก็ได้ ผมก็เคยลองแล้ว เมื่อเทียบกับ 10 ปีก่อน สามารถทำ parser แบบเฉพาะกิจที่ใช้ได้กับที่อยู่หรือโดเมน 90% ได้ แต่ส่วนที่เหลือจัดการไม่ได้
    ทุกวันนี้แย่ลงกว่าเดิม และแทบทุกอย่างซ่อนอยู่หลังม่านคุ้มครองความเป็นส่วนตัวกันหมด อ้างว่าปกป้อง PII แต่เดิมเรคคอร์ด WHOIS ไม่ได้มีไว้เก็บข้อมูลส่วนบุคคล แต่มีไว้เก็บข้อมูลติดต่อของผู้ดูแลเครือข่าย
    ผมมองว่าเรื่องนี้เป็นความผิดของ ICANN เดิม ICANN มีกฎว่าเครือข่ายต้องให้บริการเซิร์ฟเวอร์ WHOIS สาธารณะ แต่ไม่ได้บังคับใช้ และตอนนี้ก็เลิกกฎนั้นไปแล้ว

    • WHOIS ควรมีอีเมล เบอร์โทรศัพท์ และที่อยู่จริงไม่ใช่หรือ? ถ้าเป็นบริษัทอาจไม่ใช่ PII แต่ถ้าเป็น WHOIS ของเว็บไซต์ส่วนบุคคล ผมไม่เห็นว่าจะถือว่าไม่ใช่ ข้อมูลส่วนบุคคล ได้อย่างไร
    • RDAP ใส่ข้อมูล WHOIS บางส่วนไว้ในรูปแบบ JSON ที่เครื่องอ่านได้ ไม่ใช่ทั้งหมด แต่ผมว่าดีกว่า
      เพียงแต่ไม่ใช่ทุกที่ที่รันเซิร์ฟเวอร์ RDAP ถ้า ICANN/IANA หรือใครสักคนบังคับเรื่องนี้ได้ก็คงดี
      ข้อมูลผู้ดูแลเครือข่ายก็อาจเป็น PII ได้ ข้อมูลของผมเป็น PII และเมื่อผมมีชื่อโดเมน การใส่ข้อมูลของผมลงใน WHOIS ก็คือการใส่ PII ลงใน WHOIS
      บริการคุ้มครองความเป็นส่วนตัวก็แค่ส่งต่อทุกอย่างมาให้ผม ยกเว้นสแปม
      ถ้าเป็นบริษัท ผมไม่เห็นเหตุผลดี ๆ ที่ควรอนุญาตให้ใช้บริการคุ้มครองความเป็นส่วนตัว แต่ก็ยังไม่ใช่ทุกโดเมนที่เป็นของบริษัทใหญ่
    • ตรงที่บอกว่าสามารถทำ parser แบบเฉพาะกิจให้ใช้ได้กับที่อยู่หรือโดเมน 90% แต่ส่วนที่เหลือยุ่งยาก ทุกวันนี้ generative AI อาจช่วยได้ไหม? แบบว่า “นี่คือ whois ช่วยดึงข้อมูลที่ฉันต้องการออกมาให้หน่อย” อะไรทำนองนั้น

  • แทนที่จะ trace ด้วย ICMP ECHO แยกต่างหาก อาจไปได้ไกลกว่านั้นอีกขั้นด้วยการใช้ การเชื่อมต่อ HTTP TCP ที่มีอยู่แล้วระหว่างเบราว์เซอร์ฝั่งไคลเอนต์กับเว็บเซิร์ฟเวอร์
    แบบนั้นจะผ่าน NAT ฝั่งไคลเอนต์หรือ stateful firewall ได้

    • น่าสนใจ อยากรู้ว่าถ้าเป็น traceroute จริง ๆ จะทำงานอย่างไร
    • สิ่งนั้นเรียกว่า parasitic traceroute

  • มีงานก่อนหน้านี้เกี่ยวกับ reverse traceroute
    https://research.cs.washington.edu/networking/astronomy/reve...
    บทความวิจัย: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
    วิดีโอ: http://www.usenix.org/multimedia/nsdi10katz-bassett

  • อีกเรื่องที่ควรรู้คือแพ็กเก็ตของ TCP session มักวิ่งผ่านอินเทอร์เน็ตด้วย เส้นทางไม่สมมาตร จากประสบการณ์ของผม สาเหตุที่พบบ่อยที่สุดคือกฎธุรกิจที่เกี่ยวกับต้นทุน และความผิดพลาดของคน
    ถ้าคิดถึงวิธีการทำงานของ IP เรื่องนี้ในตัวมันเองไม่ได้เป็นปัญหาอะไรเป็นพิเศษ แต่ทำให้เข้าใจ routing ได้ยากขึ้น

    • มีเรื่องเล่าสนุก ๆ เรื่องหนึ่ง
      Boise State University กับ University of Idaho เป็นมหาวิทยาลัยที่อยู่คนละปลายของรัฐ Idaho ฝั่งเหนืออย่าง UIdaho อยู่ใกล้ Spokane และการเชื่อมต่อส่วนใหญ่มาจาก Seattle ส่วน Boise อยู่ใกล้ฝั่ง Salt Lake จึงมักเชื่อมต่อผ่าน Portland หรือ Salt Lake City
      ตอนกลางของรัฐระหว่างสองมหาวิทยาลัยเป็นภูเขา จึงแทบไม่มีการเชื่อมต่อขนาดใหญ่ แต่เมื่อก่อน UofIdaho มีห้องเรียนทางไกลในพื้นที่ทางใต้ จึงมีวงจรเล็ก ๆ อยู่เส้นหนึ่ง
      ช่วงปลายยุค 90 มีอยู่ช่วงหนึ่ง วิศวกรเครือข่ายของ BSU กับวิศวกรของ UofI รู้ว่าทั้งคู่มีสวิตช์และอุปกรณ์ routing อยู่ในอาคารเดียวกัน จึงต่อสายอีเทอร์เน็ตระหว่างกัน
      ผลลัพธ์คือหายนะ เครือข่ายทั้งสองเริ่มประกาศ BGP ให้กันและกัน และการเชื่อมต่อนั้นก็ถูกประกาศออกไปทั่วอินเทอร์เน็ต จู่ ๆ ก็มีจุดกระโดดสั้นมากระหว่างเครือข่ายฝั่ง Seattle กับเครือข่ายฝั่ง Salt Lake City และวงจร T1 เส้นเล็กผู้น่าสงสารเส้นนั้นก็เต็มจนแน่นสนิท
      ที่น่าสนใจคือเป็นแบบนั้นแค่ทิศทางเดียว Boise ประกาศเส้นทาง แต่ Idaho ไม่ได้ประกาศ ทราฟฟิกจึงพังในทางปฏิบัติแค่ทิศทางเดียว
      แน่นอนว่าสายนั้นถูกถอดออก และหลายปีต่อมา ตอนผมทำงานที่ UofIdaho ก็เป็นที่รู้กันดีว่าเครือข่ายทั้งสองห้ามเชื่อมต่อกันอีกเด็ดขาด ที่ย้อนแย้งคือ ตอนนั้นผมกำลังทำโครงการติดตั้ง I2 ให้กับทั้งสองมหาวิทยาลัยอยู่

  • บนอุปกรณ์ของผมไม่เห็น ขั้นกลาง ระหว่างอุปกรณ์ของผมกับเซิร์ฟเวอร์เลย แจ้งไว้เป็นข้อมูลอ้างอิง

    • ใช่ ขอโทษด้วย Hacker News ทำให้เซิร์ฟเวอร์ค่อนข้างรับภาระหนัก
      กำลังแก้อยู่ตอนนี้ และหวังว่าจะทำงานได้ดีขึ้นเร็ว ๆ นี้ ระหว่างนี้เพิ่ม timeout ไว้แล้ว โหลดจะนานขึ้น แต่ควรทำงานได้ดีขึ้น
    • ถ้าไม่ได้ดู HN จากในดาต้าเซ็นเตอร์ของ Linode ก็อาจทำงานได้ดีกว่านี้ :P

  • mtr ก็ควรค่าแก่การพูดถึงเช่นกัน ผมใช้บ่อยกว่า traceroute มาก
    ช่วยวินิจฉัย packet loss ที่เกิดเป็นครั้งคราว และช่วยให้มองเห็นภาพรวมของเส้นทางในเชิงค่าเฉลี่ยได้
    บทความนี้ของ APNIC อธิบายรายละเอียดเพิ่มเติมเกี่ยวกับ mtr และวิธีอ่านผลลัพธ์ รวมถึงพูดถึงว่า MPLS อาจทำให้เส้นทางจริงดูคลุมเครือได้อย่างไร
    https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
    การ trace ด้วย UDP ก็มีประโยชน์ในบางครั้ง และก็ควรรู้ไว้ว่าหลาย router จะเลือก drop ICMP เมื่อมีโหลดสูง
    เป็นบทความที่ดี และสำนวนก็ยอดเยี่ยม