http connection lifecycle

วงจรชีวิตการเชื่อมต่อ HTTP

สารบัญ

• แรงจูงใจ
• แบบจำลอง OSI
• การเชื่อมต่อ
  • ขั้นตอนที่ 1: แยกวิเคราะห์ URL
  • ขั้นตอนที่ 2: DNS (การแก้ไขที่อยู่)
  • ขั้นตอนที่ 3: สร้างแพ็กเก็ต TCP/IP
  • ขั้นตอนที่ 4: การเชื่อมต่อกับเกตเวย์ (ARP)
  • ขั้นตอนที่ 5: เราเตอร์และ NAT
  • ขั้นตอนที่ 6: การกำหนดเส้นทางผ่านอินเทอร์เน็ต
  • ขั้นตอนที่ 7: การจับมือ 3 ทาง
  • ขั้นตอนที่ 8: การจับมือ TLS
  • ขั้นตอนที่ 9: การประมวลผลคำขอ
  • ขั้นตอนที่ 10: ปิดการเชื่อมต่อ
• อ้างอิง

แรงจูงใจ

ในการสัมภาษณ์ด้านเทคนิคหรืออย่างอื่น คำถามที่ถามบ่อยคือจะเกิดอะไรขึ้นเมื่อคุณพิมพ์ URL ลงในเบราว์เซอร์ จะเกิดอะไรขึ้นเบื้องหลังเมื่อคุณท่องเว็บไซต์? วงจรชีวิตการเชื่อมต่อ HTTP โดยทั่วไปเกี่ยวข้องกับอะไร ฉันจะตอบคำถามเหล่านี้อย่างสุดความสามารถ

แบบจำลอง OSI

ก่อนที่จะดำดิ่งลงสู่กระบวนการเชื่อมต่อ เรามาดูโมเดล OSI พื้นฐานกันก่อน (โมเดล Open Systems Interconnection) โมเดล OSI เป็นโมเดลเชิงแนวคิดที่สร้างมาตรฐานการสื่อสารระหว่างสองระบบ - ระบบหนึ่งที่คำขอเกิดขึ้น (ไคลเอ็นต์) และอีกระบบหนึ่งที่ตอบสนองคำขอและส่งการตอบกลับ (เซิร์ฟเวอร์) ตารางด้านล่างแสดงคุณลักษณะที่สำคัญบางประการของแต่ละเลเยอร์

เลขที่	ชั้น	ฮาร์ดแวร์	การทำงาน	โปรโตคอล/แอป	เพิ่มเติม
7	แอปพลิเคชัน	เซิร์ฟเวอร์/พีซี	แอพพลิเคชั่น, ส่วนต่อประสานกับผู้ใช้	HTTP, SMTP, DNS	ส่วนหัว L7
6	การนำเสนอ	เซิร์ฟเวอร์/พีซี	จัดการการเข้ารหัสและการเปลี่ยนแปลงไวยากรณ์	เจเพ็ก, MP3	ส่วนหัว L6
5	การประชุม	เซิร์ฟเวอร์/พีซี	การรับรองความถูกต้อง สิทธิ์ เซสชัน	SCP, กำหนดการระบบปฏิบัติการ	ส่วนหัว L5
4	ขนส่ง	ไฟร์วอลล์	การส่งมอบแบบครบวงจร การควบคุมข้อผิดพลาด	TCP, UDP	ส่วนหัว L4
3	เครือข่าย	เราเตอร์	การกำหนดที่อยู่เครือข่าย การกำหนดเส้นทาง การสลับ	ไอพี	ส่วนหัว L3
2	ลิงค์ข้อมูล	สวิตช์	Addr ทางกายภาพ การตรวจจับข้อผิดพลาด การไหล	อีเธอร์เน็ต, เฟรมรีเลย์	L2 เฮดเดอร์/รถพ่วง
1	ทางกายภาพ	สายเคเบิ้ล	บิตที่ถ่ายโอนผ่านเครือข่ายฟิสิคัล	การประเมินผลกระทบสิ่งแวดล้อม/TIA	ส่วนหัว L1

การเชื่อมต่อ

ขั้นตอนที่ 1: แยกวิเคราะห์ URL

ทันทีที่คุณพิมพ์ URL ลงในเบราว์เซอร์และกดปุ่ม Enter/return เบราว์เซอร์ (หรือไคลเอ็นต์ใดๆ สำหรับเรื่องนั้น) จะแยกวิเคราะห์ URL [1] เพื่อแยกส่วนประกอบที่สำคัญออกมา URL ตัวอย่างได้รับด้านล่าง:

https://www.google.com/search?q=cats

ที่นี่เราแค่ค้นหาแมวบน Google จาก URL ข้างต้น https:// คือโปรโตคอล, google.com คือโฮสต์บน www (อินเทอร์เน็ต), /search คือพารามิเตอร์เส้นทาง และ ?q=cats คือพารามิเตอร์สตริงการสืบค้น ซึ่งแสดงว่าเรากำลังค้นหา Google สำหรับแมว [ 2].

ขั้นตอนที่ 2: DNS (การแก้ไขที่อยู่)

ขณะนี้เนื่องจากเบราว์เซอร์มีความรู้เกี่ยวกับโฮสต์ที่พยายามเข้าถึง ในกรณีนี้คือ google.com ก็จะพยายามรับที่อยู่ IP ที่เกี่ยวข้อง โดเมนเช่น ' .com' หรือ ' .org' ถูกสร้างขึ้นเพื่อให้เราจดจำได้ง่าย แต่สำหรับเบราว์เซอร์ที่จะส่งคำขอจริงเพื่อบอกว่า google.com นั้นจำเป็นต้องมีที่อยู่ IP ของโฮสต์ การแก้ไข DNS ช่วยให้เราได้รับข้อมูลที่อยู่ IP สำหรับชื่อโดเมนที่กำหนด DNS อยู่บน Application layer (L7) จากตารางด้านบน

ขั้นตอนในการแก้ไข DNS:

• ขั้นแรกเบราว์เซอร์จะตรวจสอบแคชของเบราว์เซอร์ในเครื่องเพื่อดูว่ามีการจับคู่ชื่อโดเมนกับที่อยู่ IP อยู่แล้วหรือไม่ ทุกบันทึกใน DNS มีค่า TTL และบันทึกจะถูกเก็บไว้ในแคชเท่านั้นจนกว่าจะถึงเวลาหมดอายุของ TTL หลังจากนั้นจึงต้องดึงข้อมูลบันทึกอีกครั้ง
• หากไม่มีบันทึกอยู่ในแคชของเบราว์เซอร์ ตัวแก้ไข DNS จะตรวจสอบแคชระดับระบบปฏิบัติการ ระบบปฏิบัติการจะเก็บแคชการแก้ไข DNS ของตัวเองไว้สำหรับเว็บไซต์ที่เพิ่งถูกท่องโดยไคลเอนต์ต่างๆ (เช่น เบราว์เซอร์) บนเครื่องนั้น บนเครื่องคอมพิวเตอร์ของคุณ สามารถตรวจสอบแคช DNS ได้โดยใช้คำสั่ง $ ipconfig /displaydns บน windows หรือ $ log stream --predicate 'process == "mDNSResponder"' --info บน mac/linux
• หากบันทึกไม่อยู่ในแคชของระบบปฏิบัติการ จะมีการตรวจสอบเพื่อดูว่ามีบันทึก DNS อยู่ในแคชที่ผู้ให้บริการอินเทอร์เน็ต (ISP) ดูแลอยู่หรือไม่
• หากไม่มีบันทึกอยู่ในแคชระดับ ISP จะมีการสอบถามไปยังเซิร์ฟเวอร์ DNS ผ่านทางอินเทอร์เน็ต ในกรณีนี้ เนื่องจากการสืบค้นถูกกำหนดเส้นทางนอกเครือข่ายท้องถิ่น จะต้องผ่านกระบวนการของ ARP (และ NATting) และการกำหนดเส้นทางเครือข่ายจริงตามที่อธิบายไว้ด้านล่าง การสืบค้น DNS อาจเป็นประเภท Recursive (เซิร์ฟเวอร์สืบค้นซ้ำจนกว่าจะพบคำตอบ), Iterative (รับโฮสต์ที่ดีที่สุดในการสืบค้นซึ่งอาจไม่ใช่คำตอบสุดท้าย) หรือ Non-Recursive (โดยที่ DNS รู้คำตอบที่ส่งคืนทันที) . แบบสอบถามถูกสร้างขึ้นบนโปรโตคอล UDP บนพอร์ต 53
  • หากแบบสอบถามเป็นแบบเรียกซ้ำ ตัวแก้ไข DNS จะเข้าสู่เซิร์ฟเวอร์ Root DNS ก่อน เซิร์ฟเวอร์รูทจะส่งคืนที่อยู่ IP ของเนมเซิร์ฟเวอร์ TLD
  • ขณะนี้มีการสอบถามกับเซิร์ฟเวอร์ TLD (เซิร์ฟเวอร์โดเมนระดับบนสุด) ที่นี่ .com , .org ฯลฯ เป็นชื่อโดเมนระดับบนสุด ชื่อ TLD จะส่งคืนที่อยู่ IP ของเซิร์ฟเวอร์ชื่อที่มีสิทธิ์
  • เนมเซิร์ฟเวอร์ที่เชื่อถือได้จะมีที่อยู่ IP ที่สอดคล้องกับชื่อโดเมน

$ dig google.com

; << >> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             180     IN      A       172.217.164.174

;; AUTHORITY SECTION:
google.com.             60552   IN      NS      ns1.google.com.
google.com.             60552   IN      NS      ns2.google.com.
google.com.             60552   IN      NS      ns3.google.com.
google.com.             60552   IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         60438   IN      A       216.239.32.10
ns1.google.com.         58273   IN      AAAA    2001:4860:4802:32::a
ns2.google.com.         60438   IN      A       216.239.34.10
ns2.google.com.         131763  IN      AAAA    2001:4860:4802:34::a
ns3.google.com.         163770  IN      A       216.239.36.10
ns3.google.com.         60541   IN      AAAA    2001:4860:4802:36::a
ns4.google.com.         75597   IN      A       216.239.38.10
ns4.google.com.         60541   IN      AAAA    2001:4860:4802:38::a

;; Query time: 13 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Mon Jun 24 12:20:50 PDT 2019
;; MSG SIZE  rcvd: 303

ขั้นตอนที่ 3: สร้างแพ็กเก็ต TCP/IP

ในแต่ละเลเยอร์ของโมเดล OSI ข้อมูลจะถูกเรียกว่าเป็น PDU (Packet Data Unit) ดังนั้นข้อมูลที่เลเยอร์แอปพลิเคชันจึงเรียกว่า L7 PDU โดยที่ข้อมูลที่เลเยอร์เครือข่ายเรียกว่า L3 PDU ในแต่ละเลเยอร์ จะมีการเพิ่มส่วนหัวของเลเยอร์ที่สอดคล้องกัน ส่วนหัวนำหน้าเนื้อหาและมีที่อยู่และข้อมูลอื่น ๆ ที่จำเป็นสำหรับการไปถึงจุดหมายปลายทางที่ตั้งใจไว้ ในทางกลับกันข้อมูลจะถูกส่งจากชั้นบนสุดลงล่าง ส่วนหัว L4, L3 และ L2 แสดงอยู่ด้านล่าง:

ขั้นตอนที่ 4: การเชื่อมต่อกับเกตเวย์ (ARP)

ก่อนที่แพ็กเก็ตจะถูกส่งไปยังอินเทอร์เน็ตเพื่อเข้าถึงเซิร์ฟเวอร์โดเมนของ Google ในที่สุด แพ็กเก็ตนั้นจะต้องถูกกำหนดเส้นทางผ่านเราเตอร์ก่อน เมื่อใดก็ตามที่อุปกรณ์จำเป็นต้องเชื่อมต่อกับอุปกรณ์อื่น (ในกรณีนี้คือเราเตอร์ในเครื่อง) อุปกรณ์จะต้องมีที่อยู่ MAC (ที่อยู่ฮาร์ดแวร์) ของอุปกรณ์นั้น แต่เครื่องท้องถิ่นรู้ได้อย่างไรว่าเราเตอร์เป็นเส้นทางเริ่มต้น ข้อมูลนี้ได้มาผ่านเส้นทางเริ่มต้นที่ตั้งค่าตามอินเทอร์เฟซภายในเครื่องท้องถิ่น คุณสามารถตรวจสอบเส้นทางเริ่มต้นได้โดยใช้คำสั่ง $ ifconfig

ที่อยู่ IP ใช้เพื่อค้นหาอุปกรณ์บนเครือข่าย ในขณะที่ที่อยู่ MAC ใช้เพื่อระบุอุปกรณ์จริง โปรโตคอล ARP ใช้เพื่อรับที่อยู่ MAC ของอุปกรณ์ โดยให้ความรู้เกี่ยวกับที่อยู่ IP ที่นี่เราจะถือว่าเครื่องที่ร้องขอได้รับที่อยู่ IP แล้ว (ทั้งแบบคงที่หรือผ่านโปรโตคอล DHCP)

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

• ขั้นแรกคอมพิวเตอร์จะตรวจสอบลิงก์ภายในที่เรียกว่าแคช ARP เพื่อดูว่ามีที่อยู่ MAC ของอุปกรณ์ที่ต้องการเชื่อมต่อหรือไม่ สามารถตรวจสอบตาราง ARP บนเทอร์มินัลของเครื่องโลคัลได้โดยใช้คำสั่ง arp -a
• หากไม่มีการแก้ไข ARP ในแคชในเครื่อง เครื่องต้นทางจะสร้างข้อความคำขอ Address Resolution Protocol (ARP) และส่ง IP และที่อยู่ MAC ของตัวเอง จากนั้นแหล่งที่มาจะถ่ายทอดข้อความคำขอ ARP ไปยังเครือข่ายท้องถิ่น
• แต่ละอุปกรณ์บน LAN ได้รับข้อความเนื่องจากเป็นการออกอากาศ อุปกรณ์แต่ละเครื่องจะเปรียบเทียบที่อยู่ IP ของตน และผู้ที่ไม่ตรงกันจะทิ้งแพ็กเก็ตโดยไม่มีการดำเนินการใดๆ อุปกรณ์ที่มีที่อยู่ IP ตรงกับที่อยู่ในคำขอจะสร้างข้อความตอบกลับ ARP พร้อมที่อยู่ MAC ของตัวเอง จากนั้นจะส่งข้อความตอบกลับและจะไม่ใช่การออกอากาศ แต่เป็นแบบผู้รับเดียว
• เครื่องต้นทางจะประมวลผลการตอบกลับ ARP จากปลายทาง โดยจะจัดเก็บที่อยู่ฮาร์ดแวร์ของผู้ส่งเป็นที่อยู่เลเยอร์ 2 ของปลายทาง จากนั้นอัปเดตแคช ARP

ขั้นตอนที่ 5: เราเตอร์และ NAT

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

route get default | grep gateway หรือ netstat -rn บน mac/linux หรือ ipconfig บน windows

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

ขั้นตอนที่ 6: การกำหนดเส้นทางผ่านอินเทอร์เน็ต

การเชื่อมต่อระหว่างไคลเอนต์และเซิร์ฟเวอร์ ในกรณีนี้เครื่องท้องถิ่นของคุณไปยังเซิร์ฟเวอร์ของ Google ใช้เวลากระโดดหลายครั้ง การกระโดดแต่ละครั้งโดยพื้นฐานแล้วจะเป็นเราเตอร์ตามเส้นทางไปยังปลายทาง เราเตอร์ที่นี่ช่วยส่งคำขอจากเครือข่ายหนึ่งไปยังอีกเครือข่ายหนึ่ง อุปกรณ์ทุกชิ้นที่อยู่ระหว่างทางมีที่อยู่ MAC (ที่อยู่ฮาร์ดแวร์) ซึ่งมีเอกลักษณ์เฉพาะตัวทั่วโลก

ขณะนี้เครื่องท้องถิ่นสร้างคำขอด้วยส่วนหัว L7 (HTTP), ส่วนหัว L4 (TCP), ส่วนหัว L3 (IP), ส่วนหัว L2 (ARP, ที่อยู่ MAC), ตัวอย่าง L2 (ลำดับการตรวจสอบเฟรม) และข้อมูลจริง เมื่อเราเตอร์ได้รับแพ็กเก็ต มันจะแยกส่วน ปรับเปลี่ยนส่วนหัว/ส่วนท้าย L2 และห่อหุ้มแพ็กเก็ตอีกครั้ง

ตอนนี้เราเตอร์ได้รับมันและเริ่มถอดรหัส มองเข้าไปในส่วนหัว L2 และดูว่า Mac ปลายทางมีไว้สำหรับตัวมันเอง ตอนนี้จะลบส่วนหัว L2 และดูที่ส่วนหัว L3 และเข้าใจว่าคำขอนี้ไม่ได้มีไว้สำหรับตัวมันเอง แต่สำหรับเซิร์ฟเวอร์ของ Google จากนั้นเราเตอร์จะลดค่า TTL ซึ่งอยู่ภายในส่วนหัว L3 ตอนนี้เราเตอร์จะดูตารางเส้นทางสำหรับเส้นทางที่เป็นไปได้ทั้งหมดที่เราเตอร์อื่นๆ จะโฆษณาไปยังเราเตอร์นี้ (ผ่าน RIP หรือ IGP) เกี่ยวกับวิธีการไปยังปลายทาง เราเตอร์ตัวหนึ่งจะทำ ARP เพื่อรับที่อยู่ MAC ของเราเตอร์ฮอปถัดไป หากไม่มีที่อยู่ MAC ในแคช

เราเตอร์ยังเพิ่ม CRC ซึ่งจะไปยังตัวอย่าง L2 สิ่งนี้ช่วยให้เราเตอร์ตัวถัดไปทราบว่าไม่มีปัญหาในเส้นทางเกิดขึ้นซึ่งทำให้แพ็กเก็ตเสียหายข้ามสาย ถ้ามันเสียหาย มันจะดรอปเฟรม

ในกรณีนี้ เราเตอร์ได้แก้ไขส่วนหัว L2 และตัวอย่าง L2 แต่ไม่ได้สัมผัสกับส่วนหัว L3 ดังนั้นจึงไม่มีส่วนหัวอยู่ด้านบน

หมายเลขพอร์ตต้นทาง จะเป็นหมายเลขพอร์ตชั่วคราวและหมายเลขพอร์ตปลายทางจะเป็น 80

ขั้นตอนที่ 7: การจับมือ 3 ทาง

TCP - บริการสั่งซื้อที่เชื่อถือได้และเหมือนกัน สิ่งแรกที่เครื่องท้องถิ่นจะทำคือสร้างการจับมือสามทางกับเซิร์ฟเวอร์ Google ทันทีเนื่องจากรู้เส้นทางไปยังเซิร์ฟเวอร์ การสร้างการเชื่อมต่อช่วยในการสรุปตัวแปรสถานะบางอย่าง เช่น ขนาด MSS, หมายเลขลำดับเริ่มต้น, ประเภท ACK, ขนาดบัฟเฟอร์ ฯลฯ

ในกรณีนี้แหล่งที่มาและพอร์ตปลายทางในส่วนหัว TCP คือ 16 บิตดังนั้น 2^16 คือ 65535 พอร์ตต้นทางใช้เพื่อระบุแอปพลิเคชันไคลเอ็นต์ในขณะที่พอร์ตปลายทางใช้เพื่อระบุบริการหรือปีศาจที่ทำงานบนเว็บเซิร์ฟเวอร์

ไคลเอนต์ (เว็บเบราว์เซอร์) เลือกพอร์ตใด ๆ จาก 49152 - 65535 เพื่อให้แน่ใจว่าไม่มีแอปพลิเคชัน 2 ตัวที่ใช้พอร์ตเดียวกัน ที่อยู่พอร์ตพร้อมกับที่อยู่ IP เรียกว่าเป็นซ็อกเก็ต TCP พอร์ตปลายทางคือพอร์ต 80 ในแพ็กเก็ต IP

เริ่มต้นการสื่อสาร:

• ก่อนที่จะเริ่มสิ่งใด ไคลเอนต์ (เว็บเบราว์เซอร์) จะต้องดูว่ามีการเชื่อมต่อกับเว็บเซิร์ฟเวอร์หรือไม่ สำหรับสิ่งนี้ เราจำเป็นต้องกรอกพอร์ตต้นทาง พอร์ตปลายทาง IP ต้นทาง และ IP ปลายทาง ด้วยหมายเลขลำดับ = 0 หมายเลขลำดับถูกกำหนดโดยไคลเอ็นต์ แต่จำเป็นโดยเซิร์ฟเวอร์ หมายเลขการตอบรับถูกกำหนดโดยเซิร์ฟเวอร์ แต่ใช้โดยไคลเอนต์ ในขั้นตอนที่ 1 ไม่ได้ตั้งค่าฟิลด์ ACK เนื่องจากไม่มีอะไรต้องรับทราบ (SYN)
• ในขั้นตอนที่ 2 เมื่อเซิร์ฟเวอร์ตอบสนอง เซิร์ฟเวอร์จะพลิกพอร์ตต้นทางและปลายทาง ในการตอบสนองของเซิร์ฟเวอร์ จะใส่หมายเลขลำดับแบบสุ่มว่า = 1,000 และ ACK = 1 ในกรณีนี้ Sync ถูกตั้งค่าไว้ และแฟล็ก ACK (SYN, ACK) ก็เช่นกัน
• ในขั้นตอนที่ 3 เมื่อไคลเอนต์ตอบกลับ มันจะมีพอร์ตเดียวกันกับที่เป็นเซสชันเดียวกัน และตอนนี้จะ ACK สำหรับ SYN, ACK ของขั้นตอนที่ 2 หมายเลขลำดับจะเป็น 1 และหมายเลขการตอบรับ 1001

ด้วยสามขั้นตอนข้างต้น TCP handshake จะประสบความสำเร็จระหว่างไคลเอนต์และเซิร์ฟเวอร์ และทั้งสองได้ตกลงตามกฎทั่วไปสำหรับการถ่ายโอนข้อมูลแล้ว

ขั้นตอนที่ 8: การจับมือ TLS

หลังจากการแฮนด์เชค TCP การแฮนด์เชค TLS จะเกิดขึ้นหากคุณเชื่อมต่อกับเว็บไซต์ที่ปลอดภัย ด้วยการจับมือ TLS ลูกค้าและเซิร์ฟเวอร์ยอมรับข้อกำหนดทั่วไปของการสื่อสารที่ปลอดภัย

• คอมพิวเตอร์ไคลเอนต์ส่งข้อความ ClientHello ไปยังเซิร์ฟเวอร์ด้วยเวอร์ชัน Transport Layer Security (TLS) รายการอัลกอริธึมการเข้ารหัสและวิธีการบีบอัดที่พร้อมใช้งาน
• เซิร์ฟเวอร์ตอบกลับด้วยข้อความ ServerHello ไปยังไคลเอนต์ด้วยเวอร์ชัน TLS, การเข้ารหัสที่เลือก, วิธีการบีบอัดที่เลือก และใบรับรองสาธารณะของเซิร์ฟเวอร์ที่ลงนามโดย CA (ผู้ออกใบรับรอง) ใบรับรองประกอบด้วยคีย์สาธารณะที่ไคลเอ็นต์จะใช้ในการเข้ารหัสการจับมือที่เหลือจนกว่าจะสามารถตกลงคีย์แบบสมมาตรได้
• ไคลเอนต์ตรวจสอบใบรับรองดิจิทัลของเซิร์ฟเวอร์กับรายการ CA ที่เชื่อถือได้ หากสามารถสร้างความเชื่อถือตาม CA ได้ ไคลเอนต์จะสร้างสตริงไบต์แบบสุ่มหลอกและเข้ารหัสสิ่งนี้ด้วยกุญแจสาธารณะของเซิร์ฟเวอร์ ไบต์สุ่มเหล่านี้สามารถใช้เพื่อกำหนดคีย์สมมาตรได้
• เซิร์ฟเวอร์ถอดรหัสไบต์แบบสุ่มโดยใช้คีย์ส่วนตัว และใช้ไบต์เหล่านี้เพื่อสร้างสำเนาคีย์หลักแบบสมมาตรของตัวเอง
• ไคลเอนต์ส่งข้อความเสร็จสิ้นไปยังเซิร์ฟเวอร์ โดยเข้ารหัสแฮชของการส่งข้อมูลจนถึงจุดนี้ด้วยคีย์สมมาตร
• เซิร์ฟเวอร์จะสร้างแฮชของตัวเอง จากนั้นถอดรหัสแฮชที่ไคลเอ็นต์ส่งเพื่อตรวจสอบว่าตรงกัน หากเป็นเช่นนั้น ระบบจะส่งข้อความที่เสร็จสิ้นแล้วไปยังไคลเอ็นต์ โดยเข้ารหัสด้วยคีย์สมมาตรด้วย

จากนี้ไป เซสชัน TLS จะส่งข้อมูลแอปพลิเคชัน (HTTP) ที่เข้ารหัสด้วยคีย์สมมาตรที่ตกลงกันไว้

ขั้นตอนที่ 9: การประมวลผลคำขอ

เซิร์ฟเวอร์ประมวลผลคำขอและส่งการตอบกลับที่เหมาะสม เมื่อคำขอมาถึงเซิร์ฟเวอร์บนพอร์ต 80 (HTTP) หรือพอร์ต 443 (HTTPS) เว็บเซิร์ฟเวอร์เช่น Apache หรือ Nginx จะรับฟังพอร์ต 443 จะจัดการการเชื่อมต่อของคำขอและกำหนดเส้นทางไปยังพอร์ตชั่วคราวอื่นที่บริการเว็บอยู่ วิ่ง.

ขั้นตอนที่ 10: ปิดการเชื่อมต่อ

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

อ้างอิง

[1]	มาตรฐาน URL

[2]	ส่วนประกอบหรือ URL