Apabila anda memasukkan URL, apa sebenarnya yang berlaku dalam pengeluaran halaman background_HTML/Xhtml_Web

Sebagai pembangun perisian, anda mesti mempunyai pemahaman hierarki yang lengkap tentang cara aplikasi web berfungsi Ini juga termasuk teknologi yang digunakan oleh aplikasi ini: pelayar, HTTP, HTML, pelayan web, Pemprosesan keperluan dan sebagainya.

Artikel ini akan melihat dengan lebih mendalam tentang perkara yang berlaku di latar belakang apabila anda memasukkan URL~

1. Pertama, anda perlu memasukkan URL dalam penyemak imbas :

2. Penyemak imbas mencari alamat IP nama domain

Langkah pertama dalam navigasi adalah untuk mengetahui alamat IP nama domain yang dilawati. Proses carian DNS adalah seperti berikut:

Cache Penyemak Imbas – Penyemak imbas cache rekod DNS untuk satu tempoh masa. Menariknya, sistem pengendalian tidak memberitahu pelayar berapa lama untuk menyimpan rekod DNS, jadi pelayar yang berbeza akan menyimpan masa tetap (antara 2 minit hingga 30 minit). Cache sistem – Jika rekod yang diperlukan tidak ditemui dalam cache penyemak imbas, penyemak imbas akan membuat panggilan sistem (gethostbyname dalam Windows). Ini akan memperoleh rekod dalam cache sistem. Cache penghala – Seterusnya, permintaan pertanyaan sebelumnya dihantar ke penghala, yang biasanya mempunyai cache DNS sendiri. Cache DNS ISP – Perkara seterusnya yang perlu diperiksa ialah pelayan tempat ISP menyimpan DNS. Rekod cache yang sepadan biasanya boleh didapati di sini. Carian Rekursif – Pelayan DNS ISP anda melakukan carian rekursif bermula dengan pelayan nama, daripada pelayan nama peringkat atas .com kepada pelayan nama Facebook. Secara amnya, cache pelayan DNS akan mengandungi nama domain dalam pelayan nama domain .com, jadi proses pemadanan dengan pelayan peringkat atas tidak diperlukan.

Carian rekursif DNS ditunjukkan dalam rajah di bawah:

Satu perkara yang membimbangkan tentang DNS ialah keseluruhan nama domain seperti wikipedia.org atau facebook.com hanya kelihatan sepadan dengan satu alamat IP. Nasib baik, terdapat beberapa cara untuk menghapuskan kesesakan ini:

DNS Kitaran ialah penyelesaian apabila berbilang IP dikembalikan semasa carian DNS. Sebagai contoh, Facebook.com sebenarnya sepadan dengan empat alamat IP. Pengimbang beban ialah peranti perkakasan yang mendengar pada alamat IP tertentu dan memajukan permintaan rangkaian ke pelayan berkelompok. Sesetengah tapak besar biasanya menggunakan pengimbang beban yang mahal dan berprestasi tinggi ini. DNS Geografi meningkatkan kebolehskalaan dengan memetakan nama domain kepada berbilang alamat IP berbeza berdasarkan lokasi geografi pengguna. Dengan cara ini pelayan yang berbeza tidak dapat mengemas kini keadaan penyegerakan, tetapi ia bagus untuk memetakan kandungan statik. Anycast ialah teknologi penghalaan yang memetakan satu alamat IP kepada berbilang hos fizikal. Lalat dalam salap ialah Anycast tidak menyesuaikan diri dengan baik dengan protokol TCP, jadi ia jarang digunakan dalam penyelesaian tersebut.

Kebanyakan pelayan DNS menggunakan Anycast untuk carian DNS kependaman rendah yang cekap.

3. Penyemak imbas menghantar permintaan HTTP ke pelayan web

Oleh kerana halaman dinamik seperti halaman utama Facebook akan tamat tempoh dengan cepat atau pun serta-merta dalam cache penyemak imbas selepas dibuka, tidak syak lagi ia tidak boleh dibaca daripadanya.

Jadi, penyemak imbas akan menghantar permintaan berikut ke pelayan di mana Facebook berada:

GET http://facebook.com/ HTTP/1.1<br> Accept: application/x-ms-application, Apabila anda memasukkan URL, apa sebenarnya yang berlaku dalam pengeluaran halaman background_HTML/Xhtml_Web/jpeg, application/xaml+xml, [...]<br> User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]<br> Accept-Encoding: gzip, deflate<br> Connection: Keep-Alive<br> Host: facebook.com<br> Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

DAPATKAN Permintaan ini mentakrifkan URL untuk dibaca: "http://facebook.com/". Penyemak imbas mentakrifkan dirinya sendiri (Ejen Pengguna pengepala), dan jenis respons yang ingin diterimanya (Terima danTerima-Pengekodan pengepala Sambungan Pengepala meminta pelayan untuk tidak menutup sambungan TCP untuk permintaan seterusnya.

Permintaan juga mengandungi kuki yang disimpan oleh penyemak imbas untuk nama domain tersebut. Seperti yang anda sedia maklum, kuki ialah kunci yang menjejaki status tapak web antara permintaan halaman. Dengan cara ini, kuki akan menyimpan nama pengguna log masuk, kata laluan yang diberikan oleh pelayan dan beberapa tetapan pengguna. Kuki disimpan dalam komputer klien sebagai fail teks dan dihantar ke pelayan dengan setiap permintaan.

Terdapat banyak alatan yang digunakan untuk melihat permintaan HTTP asal dan permintaan yang sepadan. Penulis lebih suka menggunakan fiddler, tetapi sudah tentu ada alat lain seperti FireBug. Perisian ini akan banyak membantu apabila mengoptimumkan tapak web anda.

除了获取请求，还有一种是发送请求，它常在提交表单用到。发送请求通过URL传递其参数(e.g.: http://robozzle.com/puzzle.aspx?id=85)。发送请求在请求正文头之后发送其参数。

像“http://facebook.com/”中的斜杠是至关重要的。这种情况下，浏览器能安全的添加斜杠。而像“http: //example.com/folderOrFile”这样的地址，因为浏览器不清楚folderOrFile到底是文件夹还是文件，所以不能自动添加 斜杠。这时，浏览器就不加斜杠直接访问地址，服务器会响应一个重定向，结果造成一次不必要的握手。 

4. facebook服务的永久重定向响应

图中所示为Facebook服务器发回给浏览器的响应：

HTTP/1.1 301 Moved Permanently<br> Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,<br> pre-check=0<br> Expires: Sat, 01 Jan 2000 00:00:00 GMT<br> Location: http://www.facebook.com/<br> P3P: CP="DSP LAW"<br> Pragma: no-cache<br> Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;<br> path=/; domain=.facebook.com; httponly<br> Content-Type: text/html; charset=utf-8<br> X-Cnection: close<br> Date: Fri, 12 Feb 2010 05:09:51 GMT<br> Content-Length: 0

服务器给浏览器响应一个301永久重定向响应，这样浏览器就会访问“http://www.facebook.com/” 而非“http://facebook.com/”。

为什么服务器一定要重定向而不是直接发会用户想看的网页内容呢？这个问题有好多有意思的答案。

其中一个原因跟搜索引擎排名有 关。你看，如果一个页面有两个地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎会认为它们是两个网站，结果造成每一个的搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是 什么意思，这样就会把访问带www的和不带www的地址归到同一个网站排名下。

还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。

5. 浏览器跟踪重定向地址

现在，浏览器知道了“http://www.facebook.com/”才是要访问的正确地址，所以它会发送另一个获取请求：

GET http://www.facebook.com/ HTTP/1.1<br> Accept: application/x-ms-application, Apabila anda memasukkan URL, apa sebenarnya yang berlaku dalam pengeluaran halaman background_HTML/Xhtml_Web/jpeg, application/xaml+xml, [...]<br> Accept-Language: en-US<br> User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]<br> Accept-Encoding: gzip, deflate<br> Connection: Keep-Alive<br> Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]<br> Host: www.facebook.com

头信息以之前请求中的意义相同。

6. 服务器“处理”请求

服务器接收到获取请求，然后处理并返回一个响应。

这表面上看起来是一个顺向的任务，但其实这中间发生了很多有意思的东西- 就像作者博客这样简单的网站，何况像facebook那样访问量大的网站呢！

Web 服务器软件
web服务器软件（像IIS和阿帕奇）接收到HTTP请求，然后确定执行什么请求处理来处理它。请求处理就是一个能够读懂请求并且能生成HTML来进行响应的程序（像ASP.NET,PHP,RUBY...）。

举 个最简单的例子，需求处理可以以映射网站地址结构的文件层次存储。像http://example.com/folder1/page1.aspx这个地 址会映射/httpdocs/folder1/page1.aspx这个文件。web服务器软件可以设置成为地址人工的对应请求处理，这样 page1.aspx的发布地址就可以是http://example.com/folder1/page1。

请求处理
请求处理阅读请求及它的参数和cookies。它会读取也可能更新一些数据，并讲数据存储在服务器上。然后，需求处理会生成一个HTML响应。

所 有动态网站都面临一个有意思的难点 -如何存储数据。小网站一半都会有一个SQL数据库来存储数据，存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案 有：sharding （基于主键值讲数据表分散到多个数据库中），复制，利用弱语义一致性的简化数据库。

委 托工作给批处理是一个廉价保持数据更新的技术。举例来讲，Fackbook得及时更新新闻feed，但数据支持下的“你可能认识的人”功能只需要每晚更新 （作者猜测是这样的，改功能如何完善不得而知）。批处理作业更新会导致一些不太重要的数据陈旧，但能使数据更新耕作更快更简洁。

7. 服务器发回一个HTML响应

图中为服务器生成并返回的响应：

HTTP/1.1 200 OK<br> Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,<br> pre-check=0<br> Expires: Sat, 01 Jan 2000 00:00:00 GMT<br> P3P: CP="DSP LAW"<br> Pragma: no-cache<br> Content-Encoding: gzip<br> Content-Type: text/html; charset=utf-8<br> X-Cnection: close<br> Transfer-Encoding: chunked<br> Date: Fri, 12 Feb 2010 09:05:55 GMT<br> <br> 2b3Tn@[...]

整个响应大小为35kB，其中大部分在整理后以blob类型传输。

内容编码头告诉浏览器整个响应体用gzip算法进行压缩。解压blob块后，你可以看到如下期望的HTML：

br /> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><br> 

lang="en" id="facebook" class=" no_js">



...

关于压缩，头信息说明了是否缓存这个页面，如果缓存的话如何去做，有什么cookies要去设置（前面这个响应里没有这点）和隐私信息等等。

请注意报头中把Content-type设置为“text/html”。报头让浏览器将该响应内容以HTML形式呈现，而不是以文件形式下载它。浏览器会根据报头信息决定如何解释该响应，不过同时也会考虑像URL扩展内容等其他因素。

8. 浏览器开始显示HTML

在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了：

9. 浏览器发送获取嵌入在HTML中的对象

在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。

下面是几个我们访问facebook.com时需要重获取的几个URL：

图片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…CSS 式样表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…

这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名，发送请求，重定向等等...

但 不像动态页面那样，静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯，而从缓存中直接读取。服务器的响应中包含了静态文件保存的期限 信息，所以浏览器知道要把它们缓存多长时间。还有，每个响应都可能包含像版本号一样工作的ETag头（被请求变量的实体值），如果浏览器观察到文件的版本 ETag信息已经存在，就马上停止这个文件的传输。

试着猜猜看“fbcdn.net”在地址中代表什么？聪明的答案是"Facebook内容分发网络"。Facebook利用内容分发网络（CDN）分发像图片，CSS表和JavaScript文件这些静态文件。所以，这些文件会在全球很多CDN的数据中心中留下备份。

静态内容往往代表站点的带宽大小，也能通过CDN轻松的复制。通常网站会使用第三方的CDN。例如，Facebook的静态文件由最大的CDN提供商Akamai来托管。

举例来讲，当你试着ping static.ak.fbcdn.net的时候，可能会从某个akamai.net服务器上获得响应。有意思的是，当你同样再ping一次的时候，响应的服务器可能就不一样，这说明幕后的负载平衡开始起作用了。

10. Penyemak imbas menghantar permintaan tak segerak (AJAX).

Di bawah bimbingan semangat hebat Web 2.0, pelanggan masih mengekalkan hubungan dengan pelayan selepas halaman dipaparkan.

Ambil fungsi sembang Facebook sebagai contoh Ia akan terus berhubung dengan pelayan untuk mengemas kini status rakan anda yang cerah dan kelabu tepat pada masanya. Untuk mengemas kini status rakan ini yang avatarnya menyala, kod JavaScript yang dilaksanakan dalam penyemak imbas akan menghantar permintaan tak segerak ke pelayan. Permintaan tak segerak ini dihantar ke alamat tertentu dan merupakan permintaan dapatkan atau hantar yang dibina secara program. Masih dalam contoh Facebook, pelanggan menghantar permintaan penerbitan ke http://www.facebook.com/ajax/chat/buddy_list.php untuk mendapatkan maklumat status dalam talian yang mana rakan anda berada dalam talian.

Apabila menyebut corak ini, kita mesti bercakap tentang "AJAX"--"JavaScript dan XML Asynchronous", walaupun tidak ada sebab yang jelas mengapa pelayan bertindak balas dalam format XML. Untuk contoh lain, untuk permintaan tak segerak, Facebook akan mengembalikan beberapa coretan kod JavaScript.

Antara lain, fiddler ialah alat yang membolehkan anda melihat permintaan tak segerak yang dihantar oleh penyemak imbas. Malah, anda bukan sahaja boleh menonton permintaan ini secara pasif, tetapi juga secara proaktif mengubah suai dan menghantarnya semula. Permintaan AJAX sangat mudah untuk diperdaya, yang benar-benar membuatkan pembangun permainan dalam talian yang mengekalkan skor sangat tertekan. (Sudah tentu, jangan berbohong kepada orang seperti itu~)

Fungsi sembang Facebook menyediakan kes masalah yang menarik mengenai AJAX: menolak data dari pelayan kepada pelanggan. Oleh kerana HTTP ialah protokol respons permintaan, pelayan sembang tidak boleh menghantar mesej baharu kepada klien. Sebaliknya, pelanggan perlu meninjau pelayan setiap beberapa saat untuk melihat sama ada ia mempunyai sebarang mesej baharu.

Tinjauan panjang adalah teknik yang menarik untuk mengurangkan beban pelayan apabila situasi ini berlaku. Jika pelayan tidak mempunyai mesej baharu apabila ditinjau, ia mengabaikan pelanggan. Apabila mesej baharu daripada klien diterima sebelum tamat masa berlalu, pelayan akan mencari permintaan yang belum selesai dan mengembalikan mesej baharu kepada klien sebagai respons.