Bagaimanakah internet berfungsi? Bahagian 1

Vous êtes-vous déjà demandé ce qui se passe lorsque vous cliquez sur un lien ? ? How The Internet Works vous emmène dans les coulisses du monde numérique, décomposant une technologie complexe en informations simples et succinctes. Des paquets de données aux serveurs et au-delà, découvrez la magie qui alimente votre expérience en ligne ! (Hook écrit avec l'aide de l'IA, parce que je ne peux pas :D)

Que se passe-t-il lorsque vous accédez à google.com ?

La touche "g" est enfoncée

Laissez-moi vous expliquer les actions physiques du clavier et les interruptions du système d'exploitation. Lorsque vous appuyez sur la touche "g", le navigateur enregistre l'événement, déclenchant les fonctions de saisie semi-automatique. En fonction de l'algorithme de votre navigateur et que vous soyez en mode normal ou privé/incognito, diverses suggestions apparaissent dans une liste déroulante sous la barre d'URL.

Ces suggestions sont généralement hiérarchisées et triées en fonction de facteurs tels que votre historique de recherche, vos favoris, les cookies et les recherches Internet populaires. Au fur et à mesure que vous continuez à taper « google.com », de nombreux processus s'exécutent en arrière-plan et les suggestions s'affinent à chaque frappe. Le navigateur peut même prédire « google.com » avant que vous ayez fini de taper.

Parcourir les séquences de saisie semi-automatique

La touche "entrée" touche le fond

Pour établir un point de départ, considérons la touche Entrée d'un clavier lorsqu'elle atteint le bas de sa course. À ce moment, un circuit électrique dédié à la touche Entrée est fermé (soit mécaniquement, soit capacitivement), permettant à un petit courant de circuler dans les circuits logiques du clavier. Ce circuit analyse l'état de chaque interrupteur à clé, filtre le bruit électrique provenant de la fermeture rapide de l'interrupteur (anti-rebond) et traduit l'action en un code clé, dans ce cas, le nombre entier 13. Le contrôleur du clavier code ensuite ce code clé pour la transmission. à l'ordinateur. Aujourd'hui, cela se fait presque toujours via une connexion Universal Serial Bus (USB) ou Bluetooth, bien que les anciens systèmes utilisaient PS/2 ou ADB.

Dans le cas d'un clavier USB :

• Le clavier est alimenté par une alimentation de 5 V fournie via la broche 1 du contrôleur hôte USB de l'ordinateur.
• Le code clé généré par la pression sur la touche est stocké dans un registre interne appelé « point final ».
• Le contrôleur hôte USB interroge ce « point de terminaison » environ toutes les 10 ms (l'intervalle minimum défini par le clavier), récupérant le code clé stocké.
• Le code clé est envoyé au moteur d'interface série USB (SIE), où il est converti en un ou plusieurs paquets USB conformément au protocole USB.
• Ces paquets sont transmis sur les lignes D et D (les deux broches du milieu) à un débit maximum de 1,5 Mb/s, car le clavier est classé comme « appareil à faible vitesse » (selon les normes USB 2.0).
• Le contrôleur USB hôte de l'ordinateur décode ce signal série et le pilote du périphérique d'interface humaine (HID) interprète la pression sur la touche. Enfin, l'événement clé est transmis à la couche d'abstraction matérielle du système d'exploitation. Diagramme de séquence

Dans le cas d'un clavier virtuel (comme sur les appareils à écran tactile) :

• Lorsque l'utilisateur touche un écran tactile capacitif, une petite quantité de courant est transférée à son doigt. Cette interaction perturbe le champ électrostatique de la couche conductrice de l’écran, créant une chute de tension au point de contact.
• Le contrôleur d'écran détecte cela et déclenche une interruption, signalant les coordonnées du toucher.
• Le système d'exploitation alerte alors l'application actuellement active qu'un événement de presse s'est produit au sein de son interface graphique, généralement sur un bouton du clavier virtuel.
• L'application de clavier virtuel déclenche une interruption logicielle, qui informe le système d'exploitation d'un événement « touche enfoncée ».
• L'application ciblée reçoit cette notification et traite la pression sur la touche en conséquence. Diagramme de séquence décrivant la même chose

Incendies d'interruption [Pas pour les claviers USB]

Pour les claviers non USB, tels que ceux utilisant des connexions existantes (par exemple, PS/2), le clavier signale une interruption via sa ligne de demande d'interruption (IRQ). Cette IRQ est mappée sur un vecteur d'interruption (un nombre entier) par le contrôleur d'interruption du système. Le CPU consulte l'Interrupt Descriptor Table (IDT), qui relie chaque vecteur d'interruption à une fonction correspondante appelée gestionnaire d'interruption, fournie par le noyau du système d'exploitation.

Apabila sampukan dicetuskan, CPU menggunakan vektor sampukan untuk mengindeks ke dalam IDT dan melaksanakan pengendali sampukan yang sesuai. Proses ini menyebabkan CPU beralih ke mod kernel, membenarkan sistem pengendalian menguruskan acara penekan kekunci.

Mesej WM_KEYDOWN Dihantar ke Apl (Pada Windows)

Apabila kekunci Enter ditekan, pengangkutan Peranti Antaramuka Manusia (HID) menghantar acara turun kekunci kepada pemacu KBDHID.sys, yang menukar data penggunaan HID kepada kod imbasan. Dalam kes ini, kod imbasan ialah VK_RETURN (0x0D), mewakili kekunci Enter. Pemacu KBDHID.sys kemudiannya berkomunikasi dengan pemacu KBDCLASS.sys (pemandu kelas papan kekunci), yang menguruskan semua input papan kekunci dengan selamat. Sebelum meneruskan, isyarat mungkin melalui mana-mana penapis papan kekunci pihak ketiga yang dipasang pada sistem, walaupun ini juga berlaku dalam mod kernel.

Seterusnya, Win32K.sys mula bermain, menentukan tetingkap yang sedang aktif dengan menggunakan GetForegroundWindow() API. Fungsi ini mendapatkan semula pemegang tetingkap (hWnd) aplikasi aktif, seperti bar alamat penyemak imbas. Pada ketika ini, "pam mesej" Windows memanggil SendMessage(hWnd, WM_KEYDOWN, VK_RETURN, lParam). Parameter lParam mengandungi bitmask yang menyediakan maklumat tambahan tentang tekanan kekunci, termasuk:

• Ulangan kiraan (iaitu 0 dalam kes ini),
• Kod imbasan (yang mungkin khusus OEM tetapi biasanya standard untuk VK_RETURN),
• Bendera kekunci lanjutan (menunjukkan sama ada kekunci pengubah suai seperti Alt, Shift atau Ctrl turut ditekan, yang tidak ditekan).

API SendMessage menyusun baris gilir mesej untuk pemegang tetingkap tertentu. Kemudian, fungsi pemprosesan mesej utama sistem (dikenali sebagai WindowProc) yang diberikan kepada tetingkap (hWnd) mengambil dan memproses mesej dalam baris gilir.

Tetingkap aktif dalam kes ini ialah kawalan edit dan fungsi WindowProcnya mempunyai pengendali mesej yang bertindak balas kepada peristiwa WM_KEYDOWN. Pengendali menyemak parameter ketiga (wParam) yang diluluskan oleh SendMessage, mengiktiraf bahawa nilainya ialah VK_RETURN, dan dengan itu menentukan bahawa pengguna telah menekan kekunci Enter. Ini mencetuskan respons yang sesuai untuk aplikasi.

NSEvent KeyDown Dihantar ke Apl (Pada OS X)

Apabila kekunci ditekan pada OS X, isyarat gangguan mencetuskan peristiwa dalam pemacu papan kekunci Kit I/O (sambungan kernel atau "kext"). Pemacu ini menterjemah isyarat perkakasan ke dalam kod kunci. Kod kunci kemudiannya dihantar ke WindowServer, yang menguruskan antara muka pengguna grafik.

WindowServer menghantar acara tekan kekunci ke aplikasi yang sesuai (seperti yang aktif atau mendengar) dengan menghantarnya melalui port Mach mereka, di mana ia diletakkan ke dalam acara beratur. Aplikasi dengan keistimewaan yang sewajarnya boleh mengakses baris gilir acara ini dengan memanggil fungsi mach_ipc_dispatch.

Kebanyakan aplikasi mengendalikan proses ini melalui gelung acara utama NSApplication, yang bertanggungjawab untuk memproses input pengguna. Apabila acara itu adalah tekan kekunci, ia diwakili sebagai NSEvent jenis NSEventTypeKeyDown. Aplikasi kemudian membaca acara ini dan bertindak balas dengan sewajarnya, mencetuskan sebarang kod yang berkaitan dengan tindakan menekan kekunci berdasarkan kod kunci yang diterima.

Pelayan Xorg Mendengar Kod Kunci (Pada GNU/Linux)

Apabila kekunci ditekan dalam persekitaran grafik menggunakan pelayan X, pelayan X menggunakan pemacu evdev (peranti acara) untuk menangkap acara penekanan kekunci. Kod kekunci daripada papan kekunci fizikal kemudiannya dipetakan semula menjadi kod imbasan menggunakan peta kekunci dan peraturan khusus pelayan X.

Setelah pemetaan selesai, pelayan X memajukan kod imbasan yang terhasil ke pengurus tetingkap (seperti DWM, Metacity, i3, dll.). Pengurus tetingkap, seterusnya, menghantar watak atau acara utama ke tetingkap yang sedang difokuskan. API grafik tetingkap fokus memproses acara ini dan memaparkan simbol yang sepadan dalam medan yang sesuai, menggunakan fon yang betul, berdasarkan kekunci yang ditekan.

Aliran ini memastikan bahawa aksara dipaparkan dengan betul dalam antara muka aplikasi aktif, melengkapkan interaksi menekan kekunci daripada perkakasan kepada output grafik.

Parse URL

Apabila pelayar menghuraikan URL (Pencari Sumber Seragam), ia mengekstrak komponen berikut:

• Protokol: "http" Penyemak imbas memahami bahawa ini menggunakan Hyper Text Transfer Protocol untuk berkomunikasi dengan pelayan.
• Sumber: "/" Ini menunjukkan bahawa penyemak imbas harus mendapatkan semula halaman utama (indeks) tapak web, kerana laluan / biasanya merujuk kepada akar atau halaman utama pelayan.

Setiap komponen ini membantu penyemak imbas mentafsir dan mengambil sumber yang diingini daripada web.

URL인가요, 아니면 검색어인가요?

프로토콜(예: 'http')이나 유효한 도메인 이름이 제공되지 않으면 브라우저는 주소 표시줄의 텍스트를 잠재적인 검색어로 해석합니다. 브라우저는 이를 URL로 해석하는 대신 텍스트를 기본 웹 검색 엔진으로 전달합니다.

대부분의 경우 브라우저는 검색어에 특수 식별자를 추가하여 요청이 브라우저의 URL 표시줄에서 발생했음을 나타냅니다. 이를 통해 검색 엔진은 이러한 검색을 적절하게 처리하고 우선순위를 지정하여 상황에 따른 결과의 관련성을 높일 수 있습니다.

이 프로세스는 브라우저가 웹사이트로 직접 이동해야 하는지 아니면 입력한 텍스트를 기반으로 검색 결과를 제공해야 하는지 결정하는 데 도움이 됩니다.

호스트 이름에서 비ASCII 유니코드 문자 변환

• 브라우저는 호스트 이름에서 ASCII 범위를 벗어나는 문자, 특히 a-z, A-Z, 0-9, - 또는 .. 세트에 없는 문자를 검사합니다.
• 이 경우 호스트 이름은 google.com이며 ASCII 문자만 포함하므로 변환이 필요하지 않습니다. 그러나 호스트 이름에 ASCII가 아닌 문자가 있는 경우 브라우저는 Punycode 인코딩을 적용하여 호스트 이름을 유효한 ASCII 표현으로 변환합니다. 이 프로세스를 통해 호스트 이름의 모든 문자가 네트워크 프로토콜에 의해 올바르게 처리될 수 있습니다.

HSTS 목록 확인

브라우저는 먼저 사전 로드된 HSTS(HTTP Strict Transport Security) 목록을 확인합니다. 이 목록에는 HTTPS를 통해서만 액세스하도록 명시적으로 요청한 웹사이트가 포함되어 있습니다.

요청한 웹사이트가 이 목록에 있으면 브라우저는 자동으로 HTTP 대신 HTTPS를 사용하여 요청을 보냅니다. 해당 웹사이트가 HSTS 목록에 없으면 HTTP를 통해 초기 요청이 전송됩니다.

웹사이트는 사전 로드된 목록에 포함되지 않고도 HSTS를 구현할 수 있다는 점에 유의하는 것이 중요합니다. 이러한 경우 사용자가 처음으로 HTTP 요청하면 HTTPS를 통해서만 후속 요청을 보내도록 브라우저에 지시하는 응답이 반환됩니다. 그러나 이 초기 HTTP 요청으로 인해 사용자가 다운그레이드 공격에 노출될 수 있으며, 공격자가 요청을 가로채서 암호화되지 않은 상태로 유지하도록 할 수 있습니다. 이 취약점으로 인해 최신 웹 브라우저에 HSTS 목록이 포함되어 애초에 안전하지 않은 연결이 설정되는 것을 방지하여 사용자 보안을 강화합니다.

DNS 조회

브라우저는 도메인이 이미 캐시에 있는지 확인하여 DNS 조회 프로세스를 시작합니다. (Google Chrome에서 DNS 캐시를 보려면 chrome://net-internals/#dns로 이동하세요.)

캐시에서 도메인을 찾을 수 없는 경우 브라우저는 gethostbyname 라이브러리 함수(구체적인 기능은 운영 체제에 따라 다를 수 있음)를 호출하여 호스트 이름 확인을 수행합니다.

1. 로컬 호스트 파일 확인:

   • gethostbyname 함수는 먼저 운영 체제에 따라 위치가 다른 로컬 호스트 파일을 참조하여 호스트 이름을 확인할 수 있는지 확인합니다. 이 파일은 호스트 이름을 IP 주소에 매핑하는 간단한 텍스트 파일로, DNS에 쿼리하지 않고도 빠른 확인을 제공할 수 있습니다.

2. DNS 서버 요청:

   • 호스트 이름이 캐시되지 않고 호스트 파일에서 찾을 수 없는 경우 브라우저는 네트워크 스택에 구성된 DNS 서버에 요청을 보냅니다. 이 서버는 일반적으로 로컬 라우터 또는 ISP의 캐싱 DNS 서버로, 이전에 확인된 이름을 저장하여 향후 요청 속도를 높입니다.

3. DNS 서버용 ARP 프로세스:

   • DNS 서버가 동일한 서브넷에 있는 경우 네트워크 라이브러리는 ARP(주소 확인 프로토콜) 프로세스에 따라 DNS 서버의 IP 주소를 확인하여 요청이 로컬 네트워크 내에서 올바르게 전달되도록 합니다.
   • DNS 서버가 다른 서브넷에 있는 경우 네트워크 라이브러리는 대신 요청을 적절한 서브넷으로 라우팅하는 중개자 역할을 하는 기본 게이트웨이 IP에 대한 ARP 프로세스를 따릅니다.

이 체계적인 접근 방식을 통해 브라우저는 도메인 이름을 IP 주소로 효율적으로 확인하여 원하는 웹사이트에 대한 연결을 설정할 수 있습니다. 먼저 캐시를 확인하고 로컬 호스트 파일을 사용하여 마지막으로 DNS 서버에 쿼리함으로써 브라우저는 호스트 이름 확인에 소요되는 시간을 최소화합니다.

시퀀스 다이어그램

Processus ARP

Afin d'envoyer une diffusion ARP (Address Resolution Protocol), la bibliothèque de pile réseau a besoin de deux informations clés : l'adresse IP cible qui doit être recherchée et l'adresse MAC de l'interface qui sera utilisée pour envoyer sur la diffusion ARP.

Vérification du cache ARP :

Le cache ARP est d'abord vérifié pour une entrée correspondant à l'adresse IP cible. Si une entrée existe, la fonction bibliothèque renvoie le résultat au format :
IP cible = MAC.

Si l'entrée n'est pas dans le cache ARP :

S'il n'y a aucune entrée pour l'adresse IP cible, les étapes suivantes sont prises :

• La table de routage est consultée pour déterminer si l'adresse IP cible se trouve sur l'un des sous-réseaux répertoriés dans la table de routage locale.
  • S'il est trouvé, la bibliothèque utilise l'interface associée à ce sous-réseau.
  • Sinon, la bibliothèque utilise par défaut l'interface qui se connecte à la passerelle par défaut.
• L'adresse MAC de l'interface réseau sélectionnée est ensuite récupérée.

  Envoi de la demande ARP :

La bibliothèque réseau construit et envoie une requête ARP de couche 2 (couche liaison de données du modèle OSI) au format suivant : Requête ARP :

• Mac de l'expéditeur : interface:mac:adresse:ici
• IP de l'expéditeur : interface.ip.goes.here
• MAC cible : FF:FF:FF:FF:FF:FF (diffusion)
• IP cible : target.ip.goes.here

En fonction de la configuration matérielle entre l'ordinateur et le routeur, le comportement de la requête ARP varie :

Directement connecté :

Si l'ordinateur est directement connecté au routeur, le routeur répondra avec une réponse ARP (voir ci-dessous).

Moyeu:

Si l'ordinateur est connecté à un hub, le hub diffusera la requête ARP depuis tous ses autres ports. Si le routeur est connecté au même « fil », il répondra par une réponse ARP (voir ci-dessous).

Changer:

Si l'ordinateur est connecté à un commutateur, le commutateur vérifiera sa table CAM/MAC locale pour identifier le port dont l'adresse MAC est interrogée. Si le commutateur n'a aucune entrée pour l'adresse MAC, il rediffusera la requête ARP vers tous les autres ports. Si le commutateur a une entrée dans sa table MAC/CAM, il enverra la requête ARP uniquement au port qui a l'adresse MAC correspondante.

• Si le routeur est sur le même « fil », il répondra avec une réponse ARP (voir ci-dessous).

Réponse ARP :

La réponse ARP aura le format suivant :

Expéditeur MAC : cible:mac:adresse:ici

IP de l'expéditeur : target.ip.goes.here

MAC cible : interface:mac:adresse:ici

IP cible : interface.ip.goes.here

Maintenant que la bibliothèque réseau a obtenu l'adresse IP soit du serveur DNS, soit de la passerelle par défaut, elle peut reprendre son processus DNS :

1. Le client DNS établit une connexion socket au port UDP 53 sur le serveur DNS, en utilisant un port source supérieur à 1023.
2. Si la taille de la réponse dépasse la limite UDP, TCP sera utilisé à la place pour accueillir une réponse plus grande.
3. Si le serveur DNS local ou du FAI ne dispose pas des informations demandées, il lancera une recherche récursive, interrogeant une hiérarchie de serveurs DNS jusqu'à ce que le SOA (Start of Authority) soit atteint, moment auquel la réponse est renvoyée.

Ouverture d'une Socket

Une fois que le navigateur reçoit l'adresse IP du serveur de destination, il la combine avec le numéro de port spécifié dans l'URL (où HTTP par défaut est le port 80 et HTTPS le port 443). Le navigateur appelle ensuite la fonction de bibliothèque système nommée socket, demandant un flux de socket TCP à l'aide de AF_INET ou AF_INET6 et SOCK_STREAM.

Traitement de la couche de transport :

• Cette requête est d'abord traitée par la couche Transport, où un segment TCP est créé. Le port de destination est ajouté à l'en-tête et un port source est choisi dans la plage de ports dynamique du noyau (comme spécifié par ip_local_port_range sous Linux).

Traitement de la couche réseau :

• Ce segment est ensuite envoyé à la couche réseau, qui l'enveloppe dans un en-tête IP supplémentaire. Les adresses IP du serveur de destination et de la machine actuelle sont insérées pour former un paquet.

Traitement de la couche de liaison :

• Le paquet arrive ensuite à la couche liaison, où un en-tête de trame est ajouté. Cet en-tête comprend l'adresse MAC de la NIC (Network Interface Card) de la machine ainsi que l'adresse MAC de la passerelle (routeur local). Si le noyau ne connaît pas l'adresse MAC de la passerelle, il doit diffuser une requête ARP pour la retrouver.

À ce stade, le paquet est prêt à être transmis via l'une des méthodes suivantes :

• Ethernet
• Wi-Fi
• Réseau de données cellulaires

Pour la plupart des connexions Internet domestiques ou de petites entreprises, le paquet passera depuis votre ordinateur, éventuellement via un réseau local, puis via un modem (Modulateur/Démodulateur). Ce modem convertit les 1 et les 0 numériques en un signal analogique adapté à la transmission via des connexions téléphoniques, par câble ou sans fil. À l'autre extrémité de la connexion, un autre modem reconvertit le signal analogique en données numériques pour le traitement par le prochain nœud de réseau, où les adresses d'origine et de destination seraient analysées plus en détail.

En revanche, les grandes entreprises et certaines connexions résidentielles plus récentes utiliseront des connexions fibre optique ou Ethernet directes, permettant aux données de rester numériques et d'être transmises directement au nœud de réseau suivant pour traitement.

Finalement, le paquet atteindra le routeur gérant le sous-réseau local. À partir de là, il continuera à voyager vers les routeurs frontières du système autonome (AS), à traverser d’autres AS et finalement à arriver au serveur de destination. En cours de route, chaque routeur extrait l'adresse de destination de l'en-tête IP et l'achemine vers le tronçon suivant approprié. Le champ de durée de vie (TTL) dans l'en-tête IP est décrémenté de un pour chaque routeur qui le traite. Le paquet sera abandonné si le champ TTL atteint zéro ou si le routeur actuel n'a pas d'espace dans sa file d'attente (ce qui peut se produire en raison d'une congestion du réseau).
Ce processus d'envoi et de réception se produit plusieurs fois suivant le flux de connexion TCP :

1. Le client choisit un numéro de séquence initial (ISN) et envoie un paquet au serveur avec le bit SYN défini pour indiquer qu'il définit l'ISN.
2. Le serveur reçoit le SYN et, s'il est d'accord, effectue les opérations suivantes :
   • Choisit son propre numéro de séquence initial.
   • Définit le bit SYN pour indiquer qu'il choisit son ISN.

3. Copie le (client ISN 1) dans son champ ACK et ajoute l'indicateur ACK pour indiquer qu'il accuse réception du premier paquet.

4. Le client accuse réception de la connexion en envoyant un paquet qui :

   • Augmente son propre numéro de séquence.
   • Augmente le numéro d'accusé de réception du destinataire.
   • Définit le champ ACK.

5. Transfert de données : Les données sont transférées comme suit :

   • Lorsqu'un côté envoie N octets de données, il augmente son numéro de séquence (SEQ) de ce nombre.
   • Lorsque l'autre côté accuse réception de ce paquet (ou d'une chaîne de paquets), il envoie un paquet ACK avec la valeur d'accusé de réception (ACK) égale à la dernière séquence reçue de l'autre côté.

6. Fermeture de la connexion : Pour fermer la connexion :

   • Le côté initiant la fermeture envoie un paquet FIN.
   • L'autre côté accuse réception du paquet FIN et envoie son propre FIN.
   • Le côté initiateur reconnaît le FIN de l’autre côté avec un ACK.

Ouverture d'une Socket : Diagramme de Séquence

Jabat Tangan TLS

• Komputer klien menghantar mesej ClientHello ke pelayan, yang termasuk versi Transport Layer Security (TLS), senarai algoritma sifir yang tersedia dan kaedah pemampatan.
• Sebagai tindak balas, pelayan membalas dengan mesej ServerHello yang menentukan versi TLS, sifir yang dipilih, kaedah mampatan yang dipilih dan sijil awam pelayan yang ditandatangani oleh Pihak Berkuasa Sijil (CA). Sijil ini mengandungi kunci awam yang akan digunakan oleh pelanggan untuk menyulitkan baki jabat tangan sehingga kunci simetri boleh dipersetujui.
• Pelanggan mengesahkan sijil digital pelayan terhadap senarai CA yang dipercayainya. Jika kepercayaan boleh diwujudkan berdasarkan CA, pelanggan menjana rentetan bait rawak pseudo dan menyulitkan rentetan ini menggunakan kunci awam pelayan. Bait rawak ini akan digunakan untuk menentukan kunci simetri.
• Pelayan menyahsulit bait rawak menggunakan kunci peribadinya dan menggunakan bait ini untuk menjana salinan kunci induk simetrinya sendiri.
• Pelanggan menghantar mesej Selesai kepada pelayan, menyulitkan cincang penghantaran yang telah berlaku sehingga ke tahap ini dengan kunci simetri.
• Pelayan menjana cincangnya sendiri dan kemudian menyahsulit cincang yang dihantar oleh pelanggan untuk mengesahkan bahawa ia sepadan. Jika cincang sepadan, pelayan menghantar mesej Selesai sendiri kembali kepada pelanggan, yang turut disulitkan dengan kunci simetri.
• Dari sudut ini, sesi TLS menghantar data aplikasi (HTTP) yang disulitkan dengan kunci simetri yang dipersetujui.

Proses jabat tangan ini mewujudkan sambungan selamat antara pelanggan dan pelayan, memastikan data yang dihantar melalui sambungan dilindungi daripada mencuri dengar dan mengganggu.

Jika Paket Digugurkan

Kadangkala, disebabkan kesesakan rangkaian atau sambungan perkakasan yang tidak berfungsi, paket TLS mungkin tercicir sebelum sampai ke destinasi terakhirnya. Dalam kes sedemikian, pengirim mesti memutuskan cara untuk bertindak balas. Algoritma yang mengawal tindak balas ini dikenali sebagai kawalan kesesakan TCP. Pelaksanaan khusus boleh berbeza-beza bergantung pada pengirim, dengan algoritma yang paling biasa ialah Kubik pada sistem pengendalian yang lebih baharu dan Reno Baharu pada banyak yang lain.

• Pelanggan memilih tetingkap kesesakan berdasarkan saiz segmen maksimum (MSS) sambungan.
• Untuk setiap paket yang diakui, tetingkap kesesakan bertambah dua kali ganda sehingga mencapai 'ambang permulaan perlahan.' Dalam sesetengah pelaksanaan, ambang ini adalah penyesuaian dan boleh berubah berdasarkan keadaan rangkaian.
• Setelah ambang permulaan perlahan dicapai, tetingkap meningkat secara tambahan untuk setiap paket yang diakui. Jika paket digugurkan, tetingkap berkurangan secara eksponen sehingga paket lain diakui.

Mekanisme kawalan kesesakan ini membantu mengoptimumkan prestasi dan kestabilan rangkaian, memastikan data boleh dihantar dengan cekap sambil meminimumkan kesan kehilangan paket.

Protokol HTTP

Jika penyemak imbas web yang digunakan dibangunkan oleh Google, bukannya menghantar permintaan HTTP standard untuk mendapatkan halaman, ia mungkin cuba merundingkan "naik taraf" daripada HTTP kepada protokol SPDY dengan pelayan.

Jika pelanggan menggunakan protokol HTTP dan tidak menyokong SPDY, ia menghantar permintaan kepada pelayan dalam format berikut:

GET / HTTP/1.1
Host: google.com
Connection: close
[other headers]

Di sini, [pengepala lain] merujuk kepada siri pasangan nilai kunci yang dipisahkan bertindih yang diformatkan mengikut spesifikasi HTTP dan dipisahkan oleh baris baharu tunggal. Ini mengandaikan bahawa penyemak imbas web bebas daripada pepijat yang melanggar spesifikasi HTTP dan ia menggunakan HTTP/1.1. Jika ia menggunakan versi yang berbeza, seperti HTTP/1.0 atau HTTP/0.9, ia mungkin tidak menyertakan pengepala Hos dalam permintaan.

HTTP/1.1 mentakrifkan pilihan sambungan "tutup" untuk pengirim memberi isyarat bahawa sambungan akan ditutup selepas respons selesai. Contohnya:

Connection: close

Aplikasi HTTP/1.1 yang tidak menyokong sambungan berterusan MESTI menyertakan pilihan sambungan "tutup" dalam setiap mesej.

Selepas menghantar permintaan dan pengepala, penyemak imbas web menghantar satu baris baharu kosong kepada pelayan untuk menunjukkan bahawa kandungan permintaan telah lengkap.

Pelayan kemudian bertindak balas dengan kod respons yang menandakan status permintaan, berstruktur seperti berikut:

200 OK
[response headers]

Ini diikuti dengan satu baris baharu dan kemudian muatan yang mengandungi kandungan HTML www.google.com. Pelayan mungkin sama ada menutup sambungan atau, jika diminta oleh pengepala yang dihantar oleh klien, pastikan sambungan terbuka untuk digunakan semula dalam permintaan selanjutnya.

If the HTTP headers sent by the web browser contained sufficient information for the web server to determine whether the version of the file cached by the web browser has been unmodified since the last retrieval (for example, if the web browser included an ETagheader), the server may instead respond with:

304 Not Modified
[response headers]

This response will have no payload, and the web browser will retrieve the HTML from its cache.

After parsing the HTML, the web browser (and server) repeats this process for every resource (image, CSS, favicon.ico, etc.) referenced in the HTML page. In these cases, instead of GET / HTTP/1.1, the request will be structured as:

GET /$(URL relative to www.google.com) HTTP/1.1

If the HTML references a resource on a different domain than www.google.com, the web browser returns to the steps involved in resolving the other domain, following all steps up to this point for that domain. The Host header in the request will be set to the appropriate server name instead of google.com.

HTTP Server Request Handling

The HTTPD (HTTP Daemon) server is responsible for handling requests and responses on the server side. The most common HTTPD servers include Apache and Nginx for Linux, as well as IIS for Windows.

1. Receiving the Request: The HTTPD server receives the incoming request from the client.
2. Breaking Down the Request: The server analyzes the request and extracts the following parameters:
   • HTTP Request Method: This could be one of several methods, including GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS, or TRACE. In the case of a URL entered directly into the address bar, the method will typically be GET.
   • Domain: In this case, the domain is google.com.
   • Requested Path/Page: Here, the requested path is /, indicating that no specific page was requested; thus, / is treated as the default path.
3. Verifying the Virtual Host: The server checks whether a Virtual Host is configured for google.com.
4. Method Verification: The server verifies that google.com can accept GET requests.
5. Client Permission Check: The server checks if the client is allowed to use this method based on criteria such as IP address, authentication, etc.
6. Request Rewriting: If the server has a rewrite module installed (such as mod_rewrite for Apache or URL Rewrite for IIS), it attempts to match the request against any configured rules. If a matching rule is found, the server rewrites the request according to that rule.
7. Content Retrieval: The server retrieves the content that corresponds to the request. In this case, it will typically default to the index file since the request path is /. While there are cases that can override this behavior, using the index file is the most common method.
8. File Parsing and Processing: The server parses the index file according to the designated handler. If Google is using PHP, for example, the server will utilize PHP to interpret the index file and stream the output back to the client.

By following these steps, the HTTPD server efficiently processes incoming requests and returns the appropriate responses to the client.

Browser

The primary functionality of a browser is to present the web resources you choose by requesting them from a server and displaying them in the browser window. The resource is typically an HTML document but may also include PDFs, images, or other types of content. The location of the resource is specified by the user using a URI (Uniform Resource Identifier).

The way a browser interprets and displays HTML files is defined by the HTML and CSS specifications, which are maintained by the W3C (World Wide Web Consortium), the standards organization for the web.

Browser user interfaces share many common features, including:

• An address bar for entering a URI
• Back and forward buttons for navigation
• Bookmarking options for saving favorite pages
• Refresh and stop buttons for refreshing or halting the loading of current documents
• A home button that takes you to your home page

Browser High-Level Structure

The components of a browser can be broken down as follows:

• Antara Muka Pengguna: Ini termasuk bar alamat, butang belakang/maju, menu penanda halaman dan mana-mana bahagian lain paparan penyemak imbas kecuali tetingkap tempat halaman yang diminta ditunjukkan.
• Enjin Pelayar: Enjin penyemak imbas bertindak sebagai jambatan antara antara muka pengguna dan enjin pemaparan, mengurus tindakan dan interaksi.
• Enjin Rendering: Bertanggungjawab untuk memaparkan kandungan yang diminta, enjin rendering menghuraikan HTML dan CSS, mengubah kandungan yang dihuraikan menjadi perwakilan visual pada skrin.
• Rangkaian: Komponen ini mengendalikan panggilan rangkaian, seperti permintaan HTTP, dan menggunakan pelaksanaan berbeza yang disesuaikan untuk pelbagai platform sambil menyediakan antara muka bebas platform.
• Ujung Belakang UI: Bahagian belakang UI bertanggungjawab untuk melukis widget asas seperti kotak kombo dan tetingkap. Ia mendedahkan antara muka generik yang tidak khusus untuk mana-mana platform dan bergantung pada kaedah antara muka pengguna sistem pengendalian.
• Enjin JavaScript: Enjin ini menghuraikan dan melaksanakan kod JavaScript, membenarkan kandungan dinamik dan interaktiviti dalam halaman web.
• Storan Data: Ini bertindak sebagai lapisan kegigihan, membolehkan penyemak imbas menyimpan pelbagai jenis data secara setempat, seperti kuki. Penyemak imbas juga menyokong mekanisme storan seperti localStorage, IndexedDB, WebSQL dan FileSystem.

Setiap komponen ini berfungsi bersama untuk mencipta pengalaman penyemakan imbas yang lancar, membolehkan pengguna mengakses dan berinteraksi dengan sumber web dengan cekap.

Penghuraian HTML

Enjin pemaparan mula mendapatkan semula kandungan dokumen yang diminta daripada lapisan rangkaian, biasanya dalam ketulan 8 kB. Tanggungjawab utama penghurai HTML ialah mengubah penanda HTML menjadi perwakilan berstruktur yang dikenali sebagai pepohon parse.

Pokok output, dirujuk sebagai "pokok parse," terdiri daripada hierarki elemen DOM (Model Objek Dokumen) dan nod atribut. DOM berfungsi sebagai perwakilan objek dokumen HTML, menyediakan antara muka untuk elemen HTML untuk berinteraksi dengan skrip luaran, seperti JavaScript. Akar pokok ini ialah objek "Dokumen", dan sebelum sebarang manipulasi skrip, DOM mengekalkan hampir satu sama lain surat-menyurat dengan penanda asal.

Algoritma Penghuraian

HTML tidak boleh dihuraikan dengan berkesan menggunakan penghurai tradisional atas ke bawah atau bawah atas atas beberapa faktor:

• Sifat Pemaaf Bahasa: HTML direka bentuk untuk berlembut dengan ralat sintaks, membenarkan penyemak imbas memaparkan kandungan walaupun penanda tidak berstruktur dengan sempurna.
• Toleransi Ralat Penyemak Imbas: Penyemak imbas dibina untuk mengendalikan kes biasa HTML tidak sah, memastikan pengguna mempunyai pengalaman berfungsi.
• Kemasukan Semula Proses Penghuraian: Dalam bahasa pengaturcaraan lain, sumber kekal tidak berubah semasa penghuraian. Walau bagaimanapun, dalam HTML, elemen dinamik (seperti teg yang mengandungi panggilan document.write()) boleh mengubah suai input semasa penghuraian, yang memerlukan pendekatan yang berbeza. Disebabkan cabaran ini, penyemak imbas menggunakan penghurai tersuai yang disesuaikan untuk HTML. Algoritma penghuraian diterangkan secara menyeluruh dalam spesifikasi HTML5 dan terdiri daripada dua peringkat utama: tokenisasi dan pembinaan pokok.

Tindakan Apabila Penghuraian Selesai

Setelah penghuraian selesai, penyemak imbas meneruskan untuk mengambil sumber luaran yang dipautkan ke halaman, seperti helaian gaya CSS, imej dan fail JavaScript. Pada ketika ini, penyemak imbas menandakan dokumen sebagai interaktif dan mula menghuraikan skrip yang berada dalam mod "tertunda", bermakna skrip tersebut bertujuan untuk dilaksanakan selepas dokumen dihuraikan sepenuhnya. Keadaan dokumen kemudiannya ditetapkan kepada "selesai" dan peristiwa "muatan" dicetuskan.

Yang penting, penyemak imbas tidak menjana ralat "Sintaks Tidak Sah" untuk halaman HTML. Sebaliknya, mereka membetulkan sebarang kandungan yang tidak sah secara automatik dan terus memproses dokumen, memastikan pengguna boleh melihat halaman web dengan gangguan yang minimum.

Tafsiran CSS

Proses tafsiran CSS melibatkan beberapa langkah utama:

• **Menghuraikan Fail CSS: **Pelayar menghuraikan fail CSS luaran, kandungan dalam