Learning AtlasIT Support → Cybersecurity
คลังบทอ่าน08.1 / พื้นฐานการทำงานของเว็บบทถัดไป
สารบัญบทอ่าน / Web Foundations / 08.1
02 · เข้าใจเครือข่ายและเว็บ · บท 08.1

Browser to Server

จากเบราว์เซอร์ถึงเซิร์ฟเวอร์

เริ่มจากพิมพ์ URL แล้วตามว่าชื่อถูกค้นอย่างไร คำขอถูกส่งไปไหน และคำตอบกลับมาอย่างไร

4 หัวข้อคำอธิบายในหน้านี้ภาพอธิบายและกลไกทีละส่วน
หัวข้อในบทนี้
ศัพท์ในบทนี้ · กดคำที่ขีดเส้นใต้ในเนื้อหาเพื่อดูความหมายได้ด้วย
API
ข้อตกลงวิธีที่โปรแกรมเรียกความสามารถหรือข้อมูลของอีกโปรแกรม
DNS
ระบบค้นข้อมูลของชื่อ เช่น IP ของชื่อโฮสต์
IP
ที่อยู่และโปรโตคอลส่ง packet ระหว่างเครือข่าย รุ่น IPv4 และ IPv6 มีรูปแบบต่างกัน
TCP
โปรโตคอลขนส่ง byte stream แบบมี connection ตรวจลำดับและส่งซ้ำตามกลไก
TLS
โปรโตคอลปกป้องช่องทางสื่อสารพร้อมการตรวจปลายทางตามแบบใช้งาน
HTTP
กฎคำขอกับคำตอบที่ใช้ในการสื่อสารเว็บ
HTTPS
HTTP บนช่องทางที่ปกป้องด้วย TLS
HTML
ภาษาโครงสร้างและความหมายของเอกสารเว็บ
CSS
กฎการแสดงผลและการจัดวางเว็บ
จากหลักการไปถึงกลไก

URL หนึ่งรายการต้องผ่านหลายบริการ

แยก URL เป็น scheme hostname port path และ query ก่อน แล้วตามคำขอหนึ่งรายการของเว็บ ในตัวอย่าง ผ่าน ถ้าไม่ใช้ connection หรือข้อมูลจาก cache เดิม ต้องหา เชื่อม TCP ทำ และส่ง ก่อนนำ response ไปแสดง หน้าเว็บหนึ่งอาจมีคำขอภาพ script และ เพิ่มอีกหลายรายการ

ข้อความหรือขั้นที่เกิดตามลำดับURL หนึ่งรายการต้องผ่านหลายบริการ
  1. URL + DNS

    example.org เป็นชื่อ ส่วน /search?q=it เป็นเป้าหมายงาน DNS ให้ข้อมูลของชื่อ ไม่สร้างหน้าเว็บ

  2. TCP

    เชื่อมบริการปลายทางตาม IP และพอร์ต จัดการ byte stream

  3. TLS

    ตรวจชื่อ อายุและ chain ของ certificate ตามความเชื่อถือ แล้วใช้กุญแจ session ปกป้องข้อมูล

  4. HTTP request

    Method path headers และ body ตามคำขอ แอปตรวจสิทธิ์และประมวลผล

  5. HTTP response

    Status headers body ส่งกลับ Browser อ่าน HTML CSS JS หรือข้อมูลที่ได้รับเพื่อแสดงผล

request กับ response บอกคนละอย่าง

Request · Browser → Server

GET /devices HTTP/1.1
Host: example.org
Accept: application/json

Method และ path เลือกงาน Headers บอกบริบท Body มีหรือไม่มีตามคำขอ

Response · Server → Browser

HTTP/1.1 200 OK
Content-Type: application/json

{"devices": []}

Status บอกผลคำขอ ชนิดเนื้อหาบอกวิธีอ่าน รายการว่างยังเป็น response ที่สำเร็จได้

ตัวอย่างรูปแบบ HTTP/1.1 หลังช่องทางพร้อม ไม่ใช่ wire format ของทุกเวอร์ชัน และไม่ได้แสดงทุก header ที่ระบบใช้งาน

HTTP ไม่จำเป็นต้องวิ่งบน TCP ทุกเวอร์ชันเปรียบเทียบ HTTPS ที่ใช้ TCP กับ HTTP/3 ที่ใช้ QUIC

HTTPS · HTTP/1.1 หรือ HTTP/2

HTTP · ความหมาย request / response
TLS · ปกป้องการสื่อสาร
TCP · byte stream
IP → link → สัญญาณ

HTTP/3

HTTP/3 · ความหมาย request / response
QUIC · streams + TLS 1.3 protection
UDP · datagrams
IP → link → สัญญาณ

QUIC เพิ่มกลไก reliable streams ของตนเอง การใช้ UDP จึงไม่ได้หมายความว่าแอปส่งแบบไม่มีการรับรองทั้งหมด Connection negotiation, cache และ connection เดิมอาจทำให้ลำดับเปิดเว็บต่างจากภาพสอนครั้งแรก

/3 ใช้ QUIC แทน จึงไม่ควรใช้ภาพนี้กับทุกเวอร์ชันโดยไม่อ่านบริบท 404 แสดงว่าได้รับคำตอบ HTTP ที่ไม่พบทรัพยากร ไม่ใช่ยืนยันสายขาด 200 หมายถึงคำขอนั้นสำเร็จตาม HTTP แต่ body หรือ JavaScript ยังทำให้หน้าจอผิดได้ ปกป้องช่องทาง ไม่รับรองความน่าเชื่อถือของผู้ขาย

01 / 04

เบราว์เซอร์ ที่อยู่เว็บ และโดเมนBrowser, URL and Domain · 08.1.1

Browser เป็นโปรแกรมใช้เว็บ URL ระบุทรัพยากร Domain เป็นชื่อที่ใช้ในที่อยู่นั้น

เบราว์เซอร์เป็นโปรแกรมที่อ่านเอกสารเว็บและแสดงผล URL เป็นที่อยู่ของทรัพยากรหนึ่งชิ้น ส่วน domain เป็นชื่อของโฮสต์ แยก scheme, hostname, port, path และ query ก่อน จึงจะรู้ว่าร้องขออะไรจากที่ไหน

เทียบหน้าที่เพื่อไม่สับสน
•Scheme

วิธีเชื่อมต่อ

•Host

ปลายทางที่ต้องค้น IP

•Path / query

ทรัพยากรและค่าที่แอปใช้

ใน https://example.org/search?q=network นั้น บอกวิธีเชื่อม example.org บอกโฮสต์ /search บอกเส้นทาง และ q เป็นค่าที่ส่งให้แอป หน้าเว็บเดียวอาจดึงภาพและข้อมูลจากหลาย URL

ที่มาของหัวข้อนี้ · 1 รายการ

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

02 / 04

จากค้นชื่อถึงคำขอเว็บDNS to HTTP Request · 08.1.2

Browser ค้นชื่อผ่าน DNS แล้วสื่อสารกับบริการเว็บเพื่อส่ง HTTP request

เมื่อไม่มีคำตอบที่ใช้ได้ในแคช เครื่องค้น ของชื่อเว็บผ่าน แล้วจึงเชื่อมปลายทาง สำหรับ แบบ จะตั้ง TCP และ ก่อนส่ง ส่วน HTTP/3 ใช้ QUIC ที่รวมหน้าที่ต่างออกไป

อ่านภาพตามลำดับการทำงาน
01Resolve

ได้ IP จากชื่อ

02Connect

สร้างช่องทางสื่อสารที่เหมาะ

03Request / render

ร้องขอแล้วแสดงผล

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

ที่มาของหัวข้อนี้ · 1 รายการ

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

เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม

03 / 04

วิธีร้องขอ สถานะ และส่วนหัวHTTP Methods, Status and Headers · 08.1.3

Method ระบุการกระทำ Status บอกผล Headers เก็บข้อมูลประกอบของคำขอและคำตอบ

request มี method, เป้าหมาย, headers และอาจมี body GET ใช้ร้องขอ representation POST ส่งข้อมูลให้ทรัพยากรประมวลผล response มี status, headers และอาจมี body โดย headers อธิบายชนิดเนื้อหา แคช หรือการยืนยันตัวตน

เทียบหน้าที่เพื่อไม่สับสน
•Method

สิ่งที่ขอให้บริการทำ

•Status

ผลของคำขอนั้น

•Headers / body

ข้อมูลกำกับและเนื้อหา

200 หมายถึงคำขอนั้นสำเร็จ 401 ต้องยืนยันตัวตน 403 ปฏิเสธ 404 ไม่พบเป้าหมาย และ 5xx คือปัญหาด้านเซิร์ฟเวอร์ การได้ 200 แต่หน้าจอว่างอาจเป็น JavaScript หรือข้อมูลใน body ไม่ใช่เครือข่ายเสีย

ที่มาของหัวข้อนี้ · 2 รายการ

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

เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม

04 / 04

การเชื่อมต่อเว็บปลอดภัยHTTPS, TLS and Certificates · 08.1.4

HTTPS ใช้ TLS ป้องกันการสื่อสาร ใบรับรองช่วยตรวจตัวตนปลายทางตามระบบความเชื่อถือ

ปกป้องการสื่อสารด้วยการเข้ารหัส ตรวจความถูกต้อง และยืนยันปลายทางตาม certificate เบราว์เซอร์ตรวจชื่อโฮสต์ อายุ certificate และ trust chain ก่อนใช้กุญแจของ session

อ่านภาพตามลำดับการทำงาน
01Identity

certificate ตรงชื่อและเชื่อถือได้

02Session keys

กุญแจปกป้องการเชื่อมครั้งนี้

03Protected traffic

ข้อมูลเดินทางถูกเข้ารหัสและตรวจความถูกต้อง

Certificate ออกให้ example.org ใช้ยืนยัน other.org ไม่ได้ วันเวลาบนเครื่องผิดก็ทำให้ตรวจอายุไม่ผ่าน เครื่องหมาย ไม่รับรองว่าคนขายน่าเชื่อถือหรือโปรแกรมปลอดช่องโหว่ แต่บอกการปกป้องช่องทางตามที่ตรวจได้

TLS Handshake and Application Data (สร้างความเชื่อถือก่อนส่งงาน)

ใน 1.3 แบบ full handshake ที่ยืนยัน server ด้วย certificate ClientHello กับ ServerHello ตกลงพารามิเตอร์และข้อมูลสำหรับสร้างกุญแจ จากนั้น server ให้ certificate และหลักฐานตาม handshake ผู้ตรวจต้องตรวจ chain ชื่อและเงื่อนไข รวมหลักฐานการครอบครองกุญแจตาม protocol ไม่รับเพียงไฟล์ certificate มองเห็นได้

เมื่อพร้อมจึงใช้กุญแจ traffic ปกป้อง application data การใช้ public key กับ signature และการสร้าง shared secrets ไม่ใช่เอา private key ส่งให้ browser ระบบมีรูปแบบ PSK/resumption และรายละเอียดที่ต่างจากภาพ full handshake นี้ error ต้องอ่านว่าไม่ผ่านชื่อ อายุ ความเชื่อถือ negotiation หรือช่วงใด ไม่กดข้ามแล้วถือว่าช่องทางยืนยันได้

ที่มาของหัวข้อนี้ · 2 รายการ

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

เอกสารหลักที่ใช้ตรวจแนวคิดเพิ่มเติม

เชื่อมความเข้าใจ

นำศัพท์มาเชื่อมกับงาน

ตัวอย่างให้เห็นภาพ

DNS สำเร็จยังไม่พอ เว็บอาจตอบ 404 เพราะทรัพยากรไม่มี หรือ 403 เพราะไม่ได้รับอนุญาต

สิ่งที่บทนี้เชื่อมไว้

เริ่มจากพิมพ์ URL แล้วตามว่าชื่อถูกค้นอย่างไร คำขอถูกส่งไปไหน และคำตอบกลับมาอย่างไร

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

บันทึกในเบราว์เซอร์นี้
บทเรียนที่เกี่ยวข้องและที่มาของบทอ่าน

transcript ที่เคยใช้ตรวจแนวคิดพื้นฐานและตัวอย่างบางส่วน: T0422 · 2.The Bits and Bytes of Computer Networking · T0413 · 2.The Bits and Bytes of Computer Networking คำอธิบายเป็นการเขียนใหม่ ไม่ใช่การแปลครบทุกประโยค ภาพและตัวอย่างเป็นการเรียบเรียงเพื่อเชื่อมความเข้าใจ

คำอธิบายหน้านี้เขียนใหม่ตามหัวข้อใน Atlas รายการด้านล่างเป็นชื่อ Video/Reading ที่เคยจับคู่ไว้ แสดงไว้ให้ตรวจที่มาของชื่อหัวข้อ และไม่รับรองว่าคอร์สสอนทุกส่วนของคำอธิบายนี้

MDN · Web development ↗