Analisis proses daripada memasukkan URL kepada pemaparan pelayar akhir kandungan halaman

Persediaan

Apabila anda memasukkan URL (seperti www.coder.com) dalam penyemak imbas dan tekan Enter, perkara pertama yang dilakukan oleh penyemak imbas ialah mendapatkan kod Alamat IP, kaedah khusus adalah untuk menghantar paket UDP ke pelayan DNS, dan pelayan DNS akan mengembalikan IP coder.com Pada masa ini, pelayar biasanya cache alamat IP, supaya capaian seterusnya akan lebih cepat .

Sebagai contoh, dalam Chrome, anda boleh melihatnya melalui chrome://net-internals/#dns.

Dengan IP pelayan, penyemak imbas boleh memulakan permintaan HTTP, tetapi Permintaan/Respons HTTP mesti dihantar dan diterima pada "sambungan maya" TCP.

Untuk mewujudkan sambungan TCP "maya", TCP Postman perlu mengetahui 4 perkara: (IP tempatan, port tempatan, IP pelayan, port pelayan Sekarang ia hanya mengetahui IP tempatan dan IP pelayan , apa ada kaitan dengan dua port?

Port tempatan adalah sangat mudah Sistem pengendalian boleh menetapkan satu secara rawak kepada penyemak imbas. Port pelayan adalah lebih mudah Posmen TCP secara langsung.

Selepas tiga jabat tangan, sambungan TCP antara pelanggan dan pelayan diwujudkan! Akhirnya kami boleh menghantar permintaan HTTP.

Sebab sambungan TCP dilukis sebagai garis putus-putus adalah kerana sambungan ini adalah maya

Pelayan web

Permintaan HTTP GET melalui beribu-ribu batu dan dimajukan oleh berbilang penghala sebelum akhirnya sampai ke pelayan (paket HTTP mungkin dipecah-pecah dan dihantar oleh lapisan bawah, yang ditinggalkan).

Pelayan web perlu mula memproses Ia mempunyai tiga cara untuk mengendalikannya:

(1) Satu urutan boleh digunakan untuk memproses semua permintaan, dan hanya satu boleh diproses. pada masa yang sama Ini Strukturnya mudah dilaksanakan, tetapi ia boleh menyebabkan masalah prestasi yang serius.

(2) Anda boleh memperuntukkan proses/benang untuk setiap permintaan, tetapi apabila terdapat terlalu banyak sambungan, proses/benang sebelah pelayan akan menggunakan banyak sumber memori, dan penukaran proses/benang juga akan menyebabkan CPU terharu.

(3) Untuk menggunakan semula I/O, banyak pelayan web menggunakan struktur penggunaan semula Contohnya, semua sambungan dipantau melalui epoll Apabila status sambungan berubah (jika data boleh dibaca), hanya satu proses /thread digunakan untuk memproses sambungan Selepas pemprosesan, teruskan memantau dan menunggu perubahan status seterusnya. Dengan cara ini beribu-ribu permintaan sambungan boleh dikendalikan dengan sebilangan kecil proses/benang.

Kami menggunakan Nginx, pelayan web yang sangat popular, untuk meneruskan cerita berikut.

Untuk permintaan HTTP GET, Nginx menggunakan epoll untuk membacanya Seterusnya, Nginx perlu menentukan sama ada ini permintaan statik atau permintaan dinamik?

Jika ia adalah permintaan statik (fail HTML, fail JavaScript, fail CSS, gambar, dll.), anda mungkin boleh mengendalikannya sendiri (sudah tentu ia bergantung pada konfigurasi Nginx dan boleh dimajukan kepada pelayan cache lain), baca Fail yang berkaitan pada cakera keras tempatan dikembalikan terus.

Jika ia adalah permintaan dinamik yang perlu diproses oleh pelayan bahagian belakang (seperti Tomcat) sebelum ia boleh dikembalikan, maka ia perlu dimajukan kepada Tomcat Jika terdapat lebih daripada satu Tomcat dalam backend, maka seseorang itu perlu dipilih mengikut strategi tertentu.

Contohnya, Ngnix menyokong jenis berikut:

Tinjauan: ke hadapan ke pelayan hujung belakang satu demi satu mengikut urutan

Berat: tetapkan pemberat pada setiap hujung belakang pelayan , yang bersamaan dengan kebarangkalian pemajuan ke pelayan bahagian belakang.

ip_hash: Lakukan operasi cincang berdasarkan IP, dan kemudian cari pelayan untuk memajukannya Dalam kes ini, IP klien yang sama akan sentiasa dimajukan ke pelayan hujung belakang yang sama.

adil: Peruntukkan permintaan berdasarkan masa respons pelayan bahagian belakang dan utamakan tempoh masa respons.

Tidak kira algoritma mana yang digunakan, pelayan hujung belakang akhirnya dipilih, dan kemudian Nginx perlu memajukan Permintaan HTTP ke Tomcat hujung belakang, dan mengeluarkan HttpResponse kemudiannya dimajukan ke penyemak imbas.

Dapat dilihat bahawa Nginx memainkan peranan sebagai ejen dalam senario ini.

Pelayan Aplikasi

Permintaan Http akhirnya datang ke Tomcat, yang ditulis dalam Java dan boleh mengendalikan Kontena Servlet/JSP, kami kod berjalan dalam bekas ini.

Seperti pelayan web, Tomcat juga boleh memperuntukkan urutan untuk setiap permintaan untuk diproses, yang biasanya dikenali sebagai mod BIO (Mod I/O Menyekat).

Ia juga mungkin untuk menggunakan teknologi pemultipleksan I/O dan hanya menggunakan beberapa utas untuk mengendalikan semua permintaan, iaitu mod NIO.

Tidak kira kaedah yang digunakan, Permintaan Http akan diserahkan kepada Servlet untuk diproses, dan Servlet akan menukar Permintaan Http ke dalam format parameter yang digunakan oleh rangka kerja, dan kemudian mengedarkannya kepada Pengawal (jika Adakah anda menggunakan Spring) atau Tindakan (jika anda menggunakan Struts).

Selebihnya cerita adalah agak mudah (tidak, untuk pengekod, ia sebenarnya adalah bahagian yang paling rumit), iaitu untuk melaksanakan tambah, memadam, mengubah suai dan menyemak logik yang sering ditulis oleh pengekod dalam proses ini berkemungkinan besar untuk berinteraksi dengan cache, Pangkalan data dan komponen belakang lain berurusan antara satu sama lain dan akhirnya mengembalikan Respons HTTP Memandangkan butiran bergantung pada logik perniagaan, ia ditinggalkan.

Menurut contoh kami, Respons HTTP ini mestilah halaman HTML.

Kepulangan

Tomcat dengan gembira menghantar Respons Http kepada Ngnix.

Ngnix ​​juga berbesar hati untuk menghantar Respons Http ke penyemak imbas.

Bolehkah sambungan TCP ditutup selepas dihantar?

Jika anda menggunakan HTTP1.1, sambungan ini kekal hidup secara lalai, yang bermaksud ia tidak boleh ditutup

Jika anda menggunakan HTTP1.0, anda perlu menyemak yang sebelumnya Pengepala Permintaan HTTP. Tiada Sambungan:keep-alive Jika ada, ia tidak boleh dimatikan.

Pelayar berfungsi semula

Pelayar menerima Respons Http, membaca halaman HTML daripadanya dan mula bersedia untuk memaparkan halaman tersebut.

Walau bagaimanapun, halaman HTML ini mungkin merujuk sejumlah besar sumber lain, seperti fail js, fail CSS, imej, dsb. Sumber ini juga terletak di bahagian pelayan dan mungkin terletak di bawah nama domain lain, seperti static.coder.com.

Pelayar tiada pilihan selain memuat turunnya satu persatu Bermula daripada menggunakan DNS untuk mendapatkan IP, perkara yang telah dilakukan sebelum ini perlu dilakukan semula. Perbezaannya ialah tidak akan ada lagi campur tangan pelayan aplikasi seperti Tomcat.

Jika terdapat terlalu banyak sumber luaran yang perlu dimuat turun, penyemak imbas akan membuat berbilang sambungan TCP dan memuat turunnya secara selari.

Walau bagaimanapun, bilangan permintaan kepada nama domain yang sama pada masa yang sama tidak boleh terlalu banyak, jika tidak pelayan akan mempunyai terlalu banyak trafik dan tidak dapat ditanggung. Oleh itu, penyemak imbas perlu mengehadkan diri mereka Sebagai contoh, Chrome hanya boleh memuat turun 6 sumber secara selari di bawah Http1.1.

Apabila pelayan menghantar fail JS dan CSS ke penyemak imbas, ia akan memberitahu penyemak imbas apabila fail ini akan tamat tempoh (menggunakan Kawalan Cache atau Tamat Tempoh), dan penyemak imbas boleh Fail dicache secara tempatan Apabila fail yang sama diminta untuk kali kedua, jika ia tidak tamat tempoh, ia boleh diambil terus dari kawasan setempat.

Jika ia tamat tempoh, penyemak imbas boleh bertanya kepada pelayan sama ada fail itu telah diubah suai? (Berdasarkan Last-Modified dan ETag yang dihantar oleh pelayan terakhir), jika ia belum diubah suai (304 Not Modified), anda juga boleh menggunakan caching. Jika tidak pelayan akan menghantar semula fail terkini ke penyemak imbas.

Sudah tentu, jika anda menekan Ctrl+F5, permintaan GET akan dikeluarkan secara paksa, mengabaikan cache sepenuhnya.

Nota: Di bawah Chrome, anda boleh melihat cache melalui arahan chrome://view-http-cache/.

Kini penyemak imbas mendapat tiga perkara penting:

1.HTML, penyemak imbas mengubahnya menjadi Pokok DOM

2 CSS Rule Tree

3, ia boleh mengubah suai DOM Tree

Pelayar akan menjana apa yang dipanggil "Render Tree" melalui DOM Tree dan CSS Rule Tree, mengira setiap Kedudukan/saiz setiap elemen, reka letak, dan kemudian memanggil API sistem pengendalian untuk melukis Ini adalah proses yang sangat rumit dan tidak akan ditunjukkan di sini.

Setakat ini, kami akhirnya melihat kandungan www.coder.com dalam pelayar.

Atas ialah kandungan terperinci Analisis proses daripada memasukkan URL kepada pemaparan pelayar akhir kandungan halaman. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!