ការតភ្ជាប់៖ TCP, Port និង TLS

មាតិកា

  1. ពីអាសយដ្ឋាន ទៅការសន្ទនា
  2. Packet អាចបាត់បង់
  3. TCP៖ ការតភ្ជាប់ដែលអាចទុកចិត្តបាន
  4. Port នៅសងខាង
  5. ហេតុអ្វី HTTP ធម្មតាមិនមានសុវត្ថិភាព
  6. TLS៖ អក្សរ S នៅក្នុង HTTPS
  7. Certificate និងរូបសោ
  8. ការតភ្ជាប់នីមួយៗចំណាយពេល
  9. សាកល្បងដោយខ្លួនឯង

1. ពីអាសយដ្ឋាន ទៅការសន្ទនា

បន្ទាប់ពីជំពូកទី 3 browser ស្គាល់ IP address របស់ server ហើយ។ ឥឡូវវាត្រូវ និយាយ ជាមួយ server នោះពិតប្រាកដ — ហើយ HTTP ត្រូវការអ្វីដែលល្អជាង packet រាយៗដើម្បីនិយាយតាម។ វាត្រូវការ ការតភ្ជាប់ (connection)៖ ឆានែលពីរផ្លូវ ដែលអ្វីក៏ដោយដែលម្ខាងផ្ញើ មកដល់ម្ខាងទៀតពេញលេញ និងតាមលំដាប់។

ការកសាងវាត្រូវការពីរស្រទាប់ (layer) ដែលដាក់ជង់លើគ្នាដូចនេះ៖

 ┌──────────────────────────────┐
 │ HTTP     the actual request  │  Chapters 5–6
 ├──────────────────────────────┤
 │ TLS      encryption          │  This chapter
 ├──────────────────────────────┤
 │ TCP      reliable delivery   │  This chapter
 ├──────────────────────────────┤
 │ IP       packets + addresses │  Chapter 3
 └──────────────────────────────┘

Layer នីមួយៗខ្វល់តែពីការងាររបស់ខ្លួន ហើយទុកចិត្តលើ layer ខាងក្រោម។ HTTP មិនខ្វល់ថា byte មកដល់ដោយរបៀបណាទេ ហើយ IP ក៏មិនខ្វល់ថា byte ទាំងនោះមានន័យអ្វីដែរ។

2. Packet អាចបាត់បង់

IP តែម្នាក់ឯង មិនសន្យាអ្វីទាំងអស់។ នៅពេលទិន្នន័យរបស់អ្នកត្រូវបានបំបែកជា packet ហើយផ្ញើឆ្លងកាត់ router ដប់ប្រាំ៖

  • Packet ខ្លះអាច បាត់បង់ — router ដែលរវល់បោះវាចោល ឬការរំខានរបស់ Wi-Fi ធ្វើឲ្យវាខូច។
  • ខ្លះអាចមកដល់ ខុសលំដាប់ ព្រោះពួកវាធ្វើដំណើរតាមផ្លូវខុសៗគ្នា។
  • ខ្លះអាចមកដល់ ពីរដង។

សម្រាប់ការហៅជាវីដេអូ packet ដែលបាត់បង់គ្រាន់តែជាការរអាក់រអួលបន្តិចបន្តួច ហើយមិនអីទេ។ ប៉ុន្តែសម្រាប់ទំព័រ web វាមិនអាចទទួលយកបានទាល់តែសោះ។ បើ packet មួយនៅកណ្តាល HTML file បាត់ ទំព័រនោះនឹងខូច។

3. TCP៖ ការតភ្ជាប់ដែលអាចទុកចិត្តបាន

TCP — Transmission Control Protocol — ដោះស្រាយបញ្ហានេះ។ វាជា layer នៅលើ IP ដែលប្រែក្លាយ packet ដែលមិនអាចទុកចិត្តបាន ទៅជាស្ទ្រីម byte ដែលអាចទុកចិត្តបាន៖

  • វា ដាក់លេខ លើទិន្នន័យគ្រប់ដុំ ដូច្នេះអ្នកទទួលអាចរៀបវាឡើងវិញតាមលំដាប់។
  • អ្នកទទួលផ្ញើ acknowledgement ត្រឡប់មកវិញ៖ «ខ្ញុំទទួលបានអ្វីៗទាំងអស់រហូតដល់លេខ 5,000 ហើយ»។
  • អ្វីដែលមិនត្រូវបាន acknowledge ទាន់ពេល ត្រូវបាន ផ្ញើម្តងទៀត។
  • ទិន្នន័យស្ទួនត្រូវបានបោះចោល។

មុនពេលផ្ញើទិន្នន័យណាមួយ ភាគីទាំងពីររៀបចំការតភ្ជាប់ជាមួយការផ្លាស់ប្តូរសារយ៉ាងរហ័សមួយ ហៅថា three-way handshake៖

 Client                         Server
   │ ── SYN ──────────────────▶   │   "Can we talk?"
   │ ◀────────────── SYN-ACK ──   │   "Yes, can you hear me?"
   │ ── ACK ──────────────────▶   │   "Yes. Let's go."
   │                              │
   │ ══ data flows both ways ══   │

សម្រាប់កម្មវិធីរបស់អ្នក អ្វីៗទាំងអស់នេះមើលមិនឃើញទេ។ ដូចដែលជំពូក Input/Output នៃស៊េរី របៀបដែលកុំព្យូទ័រដំណើរការ បាននិយាយ ការតភ្ជាប់បណ្តាញមើលទៅដូចជា file មួយ៖ អ្នកសរសេរ byte ចូលម្ខាង ហើយអានវាចេញនៅម្ខាងទៀត។ TCP ធ្វើការងារពិបាកនៅខាងក្រោម។

(TCP មានបងប្អូនមួយឈ្មោះ UDP ដែលរំលងការងារធានាភាពអាចទុកចិត្តបានទាំងអស់ ដើម្បីល្បឿន — ប្រើសម្រាប់អ្វីៗដូចជា ការហៅជាវីដេអូ ហ្គេម និងការរក DNS។ បណ្តាញសម្រាប់អ្នកអភិវឌ្ឍន៍ ប្រៀបធៀបទាំងពីរនេះយ៉ាងលម្អិត។)

4. Port នៅសងខាង

នៅក្នុងជំពូកទី 2 អ្នកបានស្គាល់ port៖ លេខដែលជ្រើសរើសថាតើកម្មវិធីណាមួយនៅលើ server ដែលអ្នកចង់បាន។ https ប្រើ 443 ហើយ http ប្រើ 80។

ប៉ុន្តែការតភ្ជាប់មួយមាន port នៅ សងខាង។ Browser របស់អ្នកក៏ទទួលបាន port មួយដែរ — port បណ្តោះអាសន្នចៃដន្យមួយ ដែលប្រព័ន្ធប្រតិបត្តិការរបស់អ្នកជ្រើសរើស ដូចជា 52814។ ដូច្នេះការតភ្ជាប់មួយត្រូវបានកំណត់អត្តសញ្ញាណដោយរបស់បួនយ៉ាង៖

 your IP : your port   ⇄   server IP : server port
 192.168.1.23:52814    ⇄   185.199.108.153:443

នោះហើយជារបៀបដែល browser មួយអាចបើកការតភ្ជាប់រាប់សិបទៅ server តែមួយក្នុងពេលតែមួយ និងរបៀបដែលកុំព្យូទ័ររបស់អ្នកដឹងថាការឆ្លើយតបនីមួយៗជារបស់ tab ណា៖ ការតភ្ជាប់នីមួយៗមាន port ខុសគ្នានៅខាងអ្នក។

នៅលើ server process របស់ web server សុំប្រព័ន្ធប្រតិបត្តិការឲ្យ listen លើ port 443។ នៅពេលការតភ្ជាប់មួយមកដល់ port នោះ OS ប្រគល់វាទៅ process នោះ។ មានតែ process មួយប៉ុណ្ណោះដែលអាច listen លើ port មួយក្នុងពេលតែមួយ — នោះហើយជាមូលហេតុដែលអ្នកទទួលបាន error ដូចជា EADDRINUSE ឬ «port is already allocated» នៅពេលអ្នកចាប់ផ្តើម dev server ទីពីរលើ port 3000។

5. ហេតុអ្វី HTTP ធម្មតាមិនមានសុវត្ថិភាព

HTTP ផ្ញើអ្វីៗទាំងអស់ជា អក្សរធម្មតា (plain text)។ ចាំពីជំពូកទី 3 ថា packet របស់អ្នកឆ្លងកាត់ router ជាច្រើនដែលអ្នកមិនបានគ្រប់គ្រង៖ Wi-Fi នៅហាងកាហ្វេរបស់អ្នក ក្រុមហ៊ុនផ្តល់សេវាអ៊ីនធឺណិតរបស់អ្នក បណ្តាញនៅប្រទេសផ្សេងៗ។ ជាមួយ HTTP ធម្មតា ណាមួយក្នុងចំណោមពួកវា អាច៖

  • អាន អ្វីៗទាំងអស់៖ ទំព័រដែលអ្នកចូលមើល form ដែលអ្នក submit ពាក្យសម្ងាត់របស់អ្នក cookie របស់អ្នក។
  • កែប្រែ អ្វីៗ៖ បញ្ចូលពាណិជ្ជកម្ម ប្តូរ file ទាញយកទៅជា malware កែប្រែទំព័រដែលអ្នកឃើញ។
  • ក្លែងខ្លួន ជា site នោះ ហើយអ្នកគ្មានវិធីដឹងឡើយ។

នៅលើ Wi-Fi សាធារណៈ ចំណុចទីមួយស្ទើរតែមិនត្រូវការជំនាញអ្វីសោះ។ នោះហើយជាមូលហេតុដែល web បានផ្លាស់ទៅ HTTPS ហើយហេតុអ្វី browser ឥឡូវសម្គាល់ទំព័រ HTTP ធម្មតាថា Not secure។

6. TLS៖ អក្សរ S នៅក្នុង HTTPS

HTTPS គឺគ្រាន់តែជា HTTP ដែលផ្ញើនៅខាងក្នុងការតភ្ជាប់ TLS។ TLS — Transport Layer Security (អ្នកនៅតែឮឈ្មោះចាស់របស់វា SSL) — ស្ថិតនៅចន្លោះ TCP និង HTTP ហើយផ្តល់ឲ្យអ្នកនូវការធានាបីយ៉ាង៖

ការធានាអត្ថន័យ
Encryptionអ្នកណាដែលនៅកណ្តាល ឃើញតែ byte ដែលច្របល់
Integrityបើនរណាម្នាក់កែប្រែ byte មួយតាមផ្លូវ វានឹងត្រូវបានរកឃើញ
Authenticationអ្នកពិតជាកំពុងនិយាយជាមួយ dara-sok.github.io មិនមែនអ្នកក្លែងបន្លំទេ

ភ្លាមៗបន្ទាប់ពី TCP handshake browser និង server ធ្វើ TLS handshake។ និយាយដោយខ្លី៖

  1. Browser និយាយសួស្តី ហើយរាយបញ្ជីវិធីសាស្ត្រ encryption ដែលវាគាំទ្រ។
  2. Server ឆ្លើយតបជាមួយជម្រើសរបស់វា និង certificate របស់វា — អត្តសញ្ញាណប័ណ្ណរបស់វា (ផ្នែកបន្ទាប់)។
  3. Browser ពិនិត្យ certificate នោះ។
  4. ភាគីទាំងពីរប្រើគណិតវិទ្យាដ៏ឆ្លាតវៃមួយចំនួន ដើម្បីព្រមព្រៀងគ្នាលើ key សម្ងាត់មួយ ដែលមានតែពួកគេទេដែលដឹង — ទោះបីជាអ្នកនៅកណ្តាលទាំងអស់បានឃើញការផ្លាស់ប្តូរសារទាំងមូលក៏ដោយ។
  5. ចាប់ពីពេលនោះតទៅ អ្វីៗទាំងអស់ — រួមទាំង HTTP request — ត្រូវបាន encrypt ជាមួយ key នោះ។

តើអ្វីនៅតែមើលឃើញចំពោះអ្នកនៅកណ្តាល? IP address domain name ដែលអ្នកកំពុងតភ្ជាប់ទៅ និងប្រហែល ប៉ុន្មាន ទិន្នន័យដែលផ្លាស់ទី និងនៅពេលណា។ អ្វីដែលត្រូវបានលាក់៖ path query string header (រួមទាំង cookie) និង body។ ដូច្នេះអ្នកណាម្នាក់នៅលើ Wi-Fi ហាងកាហ្វេរបស់អ្នក អាចឃើញថាអ្នកបានចូល github.com ប៉ុន្តែមិនឃើញថា repository ណា ឬអ្វីដែលអ្នកបានវាយនោះទេ។

7. Certificate និងរូបសោ

Certificate គឺជា file តូចមួយ ដែលនិយាយជាសារសំខាន់ថា៖

«Public key នេះជារបស់ *.github.io។ មានសុពលភាពរហូតដល់ខែមីនាឆ្នាំក្រោយ។ ចុះហត្ថលេខាដោយ certificate authority មួយ។»

Certificate authority (CA) គឺជាស្ថាប័នមួយដែលពិនិត្យថាអ្នកពិតជាគ្រប់គ្រង domain មួយ មុនពេលចុះហត្ថលេខាលើ certificate សម្រាប់វា។ ប្រព័ន្ធប្រតិបត្តិការ និង browser របស់អ្នកភ្ជាប់មកជាមួយបញ្ជី CA ដែលពួកវាទុកចិត្តស្រាប់។ នៅពេល server បង្ហាញ certificate មួយ browser ពិនិត្យ៖

  • តើវាត្រូវបានចុះហត្ថលេខាដោយ CA ដែលខ្ញុំទុកចិត្តទេ?
  • តើឈ្មោះនៅលើវាត្រូវនឹង domain ដែលខ្ញុំបានស្នើសុំទេ?
  • តើវាផុតកំណត់ហើយឬនៅ?

បើការពិនិត្យណាមួយបរាជ័យ អ្នកនឹងទទួលបានការព្រមានពេញទំព័រ ដូចជា «Your connection is not private»។ សូមយកចិត្តទុកដាក់លើការព្រមានទាំងនោះ — នៅលើ site ដែលអ្នកមិនបានគ្រប់គ្រង កុំចុចរំលងវា។

ពីមុន certificate ត្រូវចំណាយលុយ។ សព្វថ្ងៃ Let's Encrypt ផ្តល់វាដោយឥតគិតថ្លៃ និងដោយស្វ័យប្រវត្តិ ហើយ host ដូចជា GitHub Pages, Vercel និង Cloudflare គ្រប់គ្រងវាជំនួសអ្នក។ គ្មានហេតុផលអ្វីដែល site ណាមួយត្រូវប្រើ HTTP ធម្មតាទៀតទេ។

ដែនកំណត់សំខាន់មួយ៖ រូបសោមានន័យថាការតភ្ជាប់មានភាពឯកជន មិនមែនមានន័យថា site នោះស្មោះត្រង់ទេ។ Site បោកប្រាស់មួយនៅ paypa1-login.com អាចមាន certificate ដែលមានសុពលភាពត្រឹមត្រូវទាំងស្រុងសម្រាប់ paypa1-login.com។ រូបសោប្រាប់អ្នកថា អ្នកណា ដែលអ្នកកំពុងនិយាយជាមួយ។ វានៅតែជាការងាររបស់អ្នក ក្នុងការពិនិត្យថាវាជាអ្នកដែលអ្នកចង់សំដៅដល់មែន។

8. ការតភ្ជាប់នីមួយៗចំណាយពេល

រាប់ចំនួន round trip — សារដែលត្រូវទៅដល់ server ហើយត្រឡប់មកវិញ — មុនពេល byte ដំបូងនៃទំព័ររបស់អ្នកមកដល់៖

 DNS lookup           ~1 round trip   (if not cached)
 TCP handshake         1 round trip
 TLS handshake         1 round trip   (TLS 1.3; older versions took 2)
 HTTP request          1 round trip

បើ server នៅសិង្ហបុរី ហើយ round trip នីមួយៗពីភ្នំពេញចំណាយពេល 40 millisecond នោះគឺប្រហែល 160 ms មុនពេលអ្វីមួយលេចឡើង។ បើ server នៅសហរដ្ឋអាមេរិក ដែលចំណាយពេល 250 ms ក្នុងមួយ round trip វាគឺមួយវិនាទីពេញ។

នេះហើយជាមូលហេតុដែល browser ខិតខំ ប្រើឡើងវិញ នូវការតភ្ជាប់។ នៅពេលការតភ្ជាប់ទៅ server មួយត្រូវបានបើក browser រក្សាវាឲ្យនៅរស់ ហើយផ្ញើ request បន្ទាប់ៗតាមរយៈវា ដោយរំលង DNS, TCP និង TLS ទាំងស្រុង។ កំណែថ្មីៗរបស់ HTTP រុញរឿងនេះបន្ថែមទៀត៖ HTTP/2 ផ្ញើ request ជាច្រើនក្នុងពេលតែមួយតាមការតភ្ជាប់តែមួយ ហើយ HTTP/3 បញ្ចូល TCP និង TLS handshake ទៅជាមួយ។ អ្នកនឹងឃើញ h2 ឬ h3 នៅក្នុង DevTools ហើយ request និង response នៅខាងក្នុង គឺដូចគ្នានឹងអ្វីដែលមាននៅក្នុងជំពូកពីរបន្ទាប់។

9. សាកល្បងដោយខ្លួនឯង

  1. មើលការតភ្ជាប់មួយបើកឡើង។ រត់៖

    curl -v -o /dev/null https://dara-sok.github.io/my-site/

    -v (verbose) បង្ហាញអ្វីដែល curl កំពុងធ្វើ ហើយ -o /dev/null បោះចោលទំព័រខ្លួនឯង ដើម្បីកុំឲ្យវាពេញអេក្រង់របស់អ្នក — /dev/null ដូចគ្នាពី មូលដ្ឋានគ្រឹះ Command Line។ នៅជិតខាងលើ អ្នកនឹងឃើញបន្ទាត់ដូចទាំងនេះ (កាត់ឲ្យខ្លី — របស់អ្នកនឹងខុសគ្នា)៖

    *   Trying 185.199.108.153:443...
* Connected to dara-sok.github.io (185.199.108.153) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* Server certificate:
*  subject: CN=*.github.io
*  expire date: …
*  subjectAltName: host "dara-sok.github.io" matched cert's "*.github.io"
*  SSL certificate verify ok.

    ផ្គូផ្គងបន្ទាត់នីមួយៗជាមួយជំពូកនេះ៖ IP ពី DNS, TCP តភ្ជាប់ទៅ port 443, TLS handshake និងការពិនិត្យ certificate ដូចដែល browser ធ្វើ។

  2. ពិនិត្យ certificate នៅក្នុង browser។ ចុចលើរូបតំណាងនៅខាងឆ្វេងនៃ address bar នៅលើ site HTTPS ណាមួយ បន្ទាប់មករកមើលព័ត៌មានលម្អិតនៃ certificate។ តើអ្នកណាជាអ្នកចេញវា? តើវាផុតកំណត់នៅពេលណា?

  3. មើលពេលវេលា។ នៅក្នុង DevTools → Network ចុចលើ request ទីមួយនៅលើទំព័រដែលអ្នកមិនទាន់បានចូលមើលថ្ងៃនេះ បន្ទាប់មកបើក tab Timing។ រក DNS Lookup, Initial connection និង SSL។ Reload ទំព័រ ហើយមើលម្តងទៀត — ពួកវាគួរតែបាត់ស្ទើរតែទាំងអស់ ព្រោះការតភ្ជាប់ត្រូវបានប្រើឡើងវិញ។

  4. សម្គាល់ការព្រមាន។ ចូលមើល http://neverssl.com (site មួយដែលនៅលើ HTTP ធម្មតាដោយចេតនា)។ តើ browser របស់អ្នកបង្ហាញអ្វីនៅក្នុង address bar?

ការតភ្ជាប់ត្រូវបានបើក និង encrypt រួចហើយ។ នៅក្នុងជំពូកបន្ទាប់ browser ទីបំផុតផ្ញើ request របស់វា។

មុនIP Address និង DNSបន្ទាប់HTTP Request

ទិញកាហ្វេជូនខ្ញុំ

ចូលចិត្តមេរៀននេះមែនទេ? សូមពិចារណាទិញកាហ្វេជូនខ្ញុំមួយកែវ ដើម្បីគាំទ្រការបង្កើតមាតិកាឥតគិតថ្លៃបន្ថែមទៀត!