同桌上课脱我小内内的在线观看_日本欧美一区二区三区视频_久久亚洲精品成人777大小说_最新版本68app安卓版

計算機(jī)牛人為你圖解：url與網(wǎng)站背后的關(guān)系責(zé)任編輯 :李飛    文章來源 :星翼創(chuàng)想(cctvsc.cn)    發(fā)布時間 :2015-10-12    閱讀次數(shù):4702

以前，人們?yōu)g覽網(wǎng)頁，經(jīng)常是通過搜索，或者是一些網(wǎng)址導(dǎo)航來點(diǎn)進(jìn)去。但現(xiàn)在，經(jīng)常上網(wǎng)的人，都應(yīng)該能記得住幾個網(wǎng)址了，他們也學(xué)會了在瀏覽器的地址欄里直接輸入網(wǎng)站的url來直接訪問網(wǎng)站。但往往沒有人會去研究為什么在瀏覽器里輸入url就能訪問網(wǎng)站呢？這是一個神奇而又復(fù)雜的過程，想知道url與網(wǎng)站背后的關(guān)系？通過閱讀深圳市星翼創(chuàng)想網(wǎng)絡(luò)科技有限公司（專業(yè)的網(wǎng)站建設(shè)公司）選摘的這篇文章，你就可以了解一些基礎(chǔ)的計算機(jī)只是了。萬一跟人談及這個，你的形象會瞬間變得高大上哦！

第一個問題：從輸入 URL 到瀏覽器接收的過程中發(fā)生了什么事情？

從觸屏到 CPU

首先是「輸入 URL」，大部分人的第一反應(yīng)會是鍵盤，不過為了與時俱進(jìn)，這里將介紹觸摸屏設(shè)備的交互。

觸摸屏一種傳感器，目前大多是基于電容(Capacitive)來實現(xiàn)的，以前都是直接覆蓋在顯示屏上的，不過最近出現(xiàn)了 3 種嵌入到顯示屏中的技術(shù)，第一種是 iPhone 5 的 In-cell，它能減小了 0.5 毫米的厚度，第二種是三星使用的 On-cell 技術(shù)，第三種是國內(nèi)廠商喜歡用的 OGS 全貼合技術(shù)。

當(dāng)手指在這個傳感器上觸摸時，有些電子會傳遞到手上，從而導(dǎo)致該區(qū)域的電壓變化，觸摸屏控制器芯片根據(jù)這個變化就能計算出所觸摸的位置，然后通過總線接口將信號傳到 CPU 的引腳上。

以 Nexus 5 為例，它所使用的觸屏控制器是 Synaptics S3350B，總線接口為 I2C，以下是 Synaptics 觸摸屏和處理器連接的示例：

左邊是處理器，右邊是觸摸屏控制器，中間的 SDA 和 SCL 連線就是 I2C 總線接口。

CPU 內(nèi)部的處理

移動設(shè)備中的 CPU 并不是一個單獨(dú)的芯片，而是和 GPU 等芯片集成在一起，被稱為 SoC（片上系統(tǒng)）。

前面提到了觸屏和 CPU 的連接，這個連接和大部分計算機(jī)內(nèi)部的連接一樣，都是通過電氣信號來進(jìn)行通信的，也就是電壓高低的變化，如下面的時序圖：

在時鐘的控制下，這些電流會經(jīng)過 MOSFET 晶體管，晶體管中包含 N 型半導(dǎo)體和 P 型半導(dǎo)體，通過電壓就能控制線路開閉，然后這些 MOSFET 構(gòu)成了 CMOS，接著再由 CMOS 實現(xiàn)「與」「或」「非」等邏輯電路門，最后由邏輯電路門上就能實現(xiàn)加法、位移等計算，整體如下圖所示（來自《計算機(jī)體系結(jié)構(gòu)》）：

除了計算，在 CPU 中還需要存儲單元來加載和存儲數(shù)據(jù)，這個存儲單元一般通過觸發(fā)器(Flip-flop)來實現(xiàn)，稱為寄存器。

以上這些概念都比較抽象，推薦閱讀「How to Build an 8-Bit Computer」這篇文章，作者基于晶體管、二極管、電容等原件制作了一個 8 位的計算機(jī)，支持簡單匯編指令和結(jié)果輸出，雖然現(xiàn)代 CPU 的實現(xiàn)要比這個復(fù)雜得多，但基本原理還是一樣的。

另外其實我也是剛開始學(xué)習(xí) CPU 芯片的實現(xiàn)，所以就不在這誤人子弟了，感興趣的讀者請閱讀本節(jié)后面推薦的書籍。

從 CPU 到操作系統(tǒng)內(nèi)核

前面說到觸屏控制器將電氣信號發(fā)送到 CPU 對應(yīng)的引腳上，接著就會觸發(fā) CPU 的中斷機(jī)制，以 Linux 為例，每個外部設(shè)備都有一標(biāo)識符，稱為中斷請求(IRQ)號，可以通過 /proc/interrupts 文件來查看系統(tǒng)中所有設(shè)備的中斷請求號，以下是 Nexus 7 (2013) 的部分結(jié)果：

因為 Nexus 7 使用了 ELAN 的觸屏控制器，所以結(jié)果中的 elan-ktf3k 就是觸屏的中斷請求信息，其中 294 是中斷號，1973609 是觸發(fā)的次數(shù)（手指單擊時會產(chǎn)生兩次中斷，但滑動時會產(chǎn)生上百次中斷）。

為了簡化這里不考慮優(yōu)先級問題，以 ARMv7 架構(gòu)的處理器為例，當(dāng)中斷發(fā)生時，CPU 會停下當(dāng)前運(yùn)行的程序，保存當(dāng)前執(zhí)行狀態(tài)（如 PC 值），進(jìn)入 IRQ 狀態(tài)），然后跳轉(zhuǎn)到對應(yīng)的中斷處理程序執(zhí)行，這個程序一般由第三方內(nèi)核驅(qū)動來實現(xiàn)，比如前面提到的 Nexus 7 的驅(qū)動源碼在這里 touchscreen/ektf3k.c。

這個驅(qū)動程序?qū)⒆x取 I2C 總線中傳來的位置數(shù)據(jù)，然后通過內(nèi)核的 input_report_abs 等方法記錄觸屏按下坐標(biāo)等信息，最后由內(nèi)核中的input 子模塊將這些信息都寫進(jìn) /dev/input/event0 這個設(shè)備文件中，比如下面展示了一次觸摸事件所產(chǎn)生的信息：

 從操作系統(tǒng) GUI 到瀏覽器

前面提到 Linux 內(nèi)核已經(jīng)完成了對硬件的抽象，其它程序只需要通過監(jiān)聽 /dev/input/event0 文件的變化就能知道用戶進(jìn)行了哪些觸摸操作，不過如果每個程序都這么做實在太麻煩了，所以在圖像操作系統(tǒng)中都會包含 GUI 框架來方便應(yīng)用程序開發(fā)，比如 Linux 下著名的 X。

但 Android 并沒有使用 X，而是自己實現(xiàn)了一套 GUI 框架，其中有個 EventHub 的服務(wù)會通過 epoll 方式監(jiān)聽 /dev/input/ 目錄下的文件，然后將這些信息傳遞到 Android 的窗口管理服務(wù)(WindowManagerService)中，它會根據(jù)位置信息來查找相應(yīng)的 app，然后調(diào)用其中的監(jiān)聽函數(shù)（如 onTouch 等）。

就這樣，我們解答了第一個問題，不過由于時間有限，這里省略了很多細(xì)節(jié)。

第二個問題：瀏覽器如何向網(wǎng)卡發(fā)送數(shù)據(jù)？

從瀏覽器到瀏覽器內(nèi)核

前面提到操作系統(tǒng) GUI 將輸入事件傳遞到了瀏覽器中，在這過程中，瀏覽器可能會做一些預(yù)處理，比如 Chrome 會根據(jù)歷史統(tǒng)計來預(yù)估所輸入字符對應(yīng)的網(wǎng)站，比如輸入了「ba」，根據(jù)之前的歷史發(fā)現(xiàn) 90% 的概率會訪問「www.baidu.com 」，因此就會在輸入回車前就馬上開始建立 TCP 鏈接甚至渲染了，這里面還有很多其它策略，感興趣的讀者推薦閱讀  High Performance Networking in Chrome。

接著是輸入 URL 后的「回車」，這時瀏覽器會對 URL 進(jìn)行檢查，首先判斷協(xié)議，如果是 http 就按照 Web 來處理，另外還會對這個 URL 進(jìn)行安全檢查，然后直接調(diào)用瀏覽器內(nèi)核中的對應(yīng)方法，比如 WebView 中的 loadUrl 方法。

在瀏覽器內(nèi)核中會先查看緩存，然后設(shè)置 UA 等 HTTP 信息，接著調(diào)用不同平臺下網(wǎng)絡(luò)請求的方法。

 

需要注意瀏覽器和瀏覽器內(nèi)核是不同的概念，瀏覽器指的是 Chrome、Firefox，而瀏覽器內(nèi)核則是 Blink、Gecko，瀏覽器內(nèi)核只負(fù)責(zé)渲染，GUI 及網(wǎng)絡(luò)連接等跨平臺工作則是瀏覽器實現(xiàn)的

HTTP 請求的發(fā)送

因為網(wǎng)絡(luò)的底層實現(xiàn)是和內(nèi)核相關(guān)的，所以這一部分需要針對不同平臺進(jìn)行處理，從應(yīng)用層角度看主要做兩件事情：通過 DNS 查詢 IP、通過 Socket 發(fā)送數(shù)據(jù)，接下來就分別介紹這兩方面的內(nèi)容。

DNS 查詢

應(yīng)用程序可以直接調(diào)用 Libc 提供的 getaddrinfo() 方法來實現(xiàn) DNS 查詢。

DNS 查詢其實是基于 UDP 來實現(xiàn)的，這里我們通過一個具體例子來了解它的查找過程，以下是使用 dig +trace fex.baidu.com 命令得到的結(jié)果（省略了一些）：

可以看到這是一個逐步縮小范圍的查找過程，首先由本機(jī)所設(shè)置的 DNS 服務(wù)器(8.8.8.8)向 DNS 根節(jié)點(diǎn)查詢負(fù)責(zé) .com 區(qū)域的域務(wù)器，然后通過其中一個負(fù)責(zé) .com 的服務(wù)器查詢負(fù)責(zé) baidu.com 的服務(wù)器，最后由其中一個 baidu.com 的域名服務(wù)器查詢 fex.baidu.com 域名的地址。

可能你在查詢某些域名的時會發(fā)現(xiàn)和上面不一樣，最底將看到有個奇怪的服務(wù)器搶先返回結(jié)果。。。

 

這里為了方便描述，忽略了很多不同的情況，比如 127.0.0.1 其實走的是 loopback，和網(wǎng)卡設(shè)備沒關(guān)系；比如 Chrome 會在瀏覽器啟動的時預(yù)先查詢 10 個你有可能訪問的域名；還有 Hosts 文件、緩存時間 TTL(Time to live)的影響等。

通過 Socket 發(fā)送數(shù)據(jù)

有了 IP 地址，就可以通過 Socket API 來發(fā)送數(shù)據(jù)了，這時可以選擇 TCP 或 UDP 協(xié)議，具體使用方法這里就不介紹了，推薦閱讀 Beej’s Guide to Network Programming。

HTTP 常用的是 TCP 協(xié)議，由于 TCP 協(xié)議的具體細(xì)節(jié)到處都能看到，所以本文就不介紹了，這里談一下 TCP 的 Head-of-line blocking 問題：假設(shè)客戶端的發(fā)送了 3 個 TCP 片段(segments)，編號分別是 1、2、3，如果編號為 1 的包傳輸時丟了，即便編號 2 和 3 已經(jīng)到達(dá)也只能等待，因為 TCP 協(xié)議需要保證順序，這個問題在 HTTP pipelining 下更嚴(yán)重，因為 HTTP pipelining 可以讓多個 HTTP 請求通過一個 TCP 發(fā)送，比如發(fā)送兩張圖片，可能第二張圖片的數(shù)據(jù)已經(jīng)全收到了，但還得等第一張圖片的數(shù)據(jù)傳到。

為了解決 TCP 協(xié)議的性能問題，Chrome 團(tuán)隊去年提出了 QUIC 協(xié)議，它是基于 UDP 實現(xiàn)的可靠傳輸，比起 TCP，它能減少很多來回(round trip)時間，還有前向糾錯碼(Forward Error Correction)等功能。目前 Google Plus、 Gmail、Google Search、blogspot、Youtube 等幾乎大部分 Google 產(chǎn)品都在使用 QUIC，可以通過 chrome://net-internals/#spdy 頁面來發(fā)現(xiàn)。

雖然目前除了 Google 還沒人用 QUIC，但我覺得挺有前景的，因為優(yōu)化 TCP 需要升級系統(tǒng)內(nèi)核（比如 Fast Open）。

 

瀏覽器對同一個域名有連接數(shù)限制，大部分是 6，我以前認(rèn)為將這個連接數(shù)改大后會提升性能，但實際上并不是這樣的，Chrome 團(tuán)隊有做過實驗，發(fā)現(xiàn)從 6 改成 10 后性能反而下降了，造成這個現(xiàn)象的因素有很多，如建立連接的開銷、擁塞控制等問題，而像 SPDY、HTTP 2.0 協(xié)議盡管只使用一個 TCP 連接來傳輸數(shù)據(jù)，但性能反而更好，而且還能實現(xiàn)請求優(yōu)先級。

另外，因為 HTTP 請求是純文本格式的，所以在 TCP 的數(shù)據(jù)段中可以直接分析 HTTP 的文本，如果發(fā)現(xiàn)。。。

Socket 在內(nèi)核中的實現(xiàn)

前面說到瀏覽器的跨平臺庫通過調(diào)用 Socket API 來發(fā)送數(shù)據(jù)，那么 Socket API 是如何實現(xiàn)的呢？

以 Linux 為例，它的實現(xiàn)在這里 socket.c，目前我還不太了解，推薦讀者看看 Linux kernel map，它標(biāo)注出了關(guān)鍵路徑的函數(shù)，方便學(xué)習(xí)從協(xié)議棧到網(wǎng)卡驅(qū)動的實現(xiàn)。

底層網(wǎng)絡(luò)協(xié)議的具體例子

接下來如果繼續(xù)介紹 IP 協(xié)議和 MAC 協(xié)議可能很多讀者會暈，所以本節(jié)將使用 Wireshark 來通過具體例子講解，以下是我請求百度首頁時抓取到的網(wǎng)絡(luò)數(shù)據(jù)：

最底下是實際的二進(jìn)制數(shù)據(jù)，中間是解析出來的各個字段值，可以看到其中最底部為 HTTP 協(xié)議(Hypertext Transfer Protocol)，在 HTTP 之前有 54 字節(jié)(0×36)，這就是底層網(wǎng)絡(luò)協(xié)議所帶來的開銷，我們接下來對這些協(xié)議進(jìn)行分析。

在 HTTP 之上是 TCP 協(xié)議(Transmission Control Protocol)，它的具體內(nèi)容如下圖所示：

文章轉(zhuǎn)載請保留網(wǎng)址：http://cctvsc.cn/news/industry/1508.html