摘要：第一個(gè)問(wèn)題從輸入到瀏覽器接收的過(guò)程中發(fā)生了什么事情從觸屏到首先是輸入，大部分人的第一反應(yīng)會(huì)是鍵盤，不過(guò)為了與時(shí)俱進(jìn)，這里將介紹觸摸屏設(shè)備的交互。

第一個(gè)問(wèn)題：從輸入 URL 到瀏覽器接收的過(guò)程中發(fā)生了什么事情？
從觸屏到 CPU

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

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

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

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

左邊是處理器，右邊是觸摸屏控制器，中間的 SDA 和 SCL 連線就是 I2C 總線接口。
CPU 內(nèi)部的處理

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

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

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

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

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

另外其實(shí)我也是剛開(kāi)始學(xué)習(xí) CPU 芯片的實(shí)現(xiàn)，所以就不在這誤人子弟了，感興趣的讀者請(qǐng)閱讀本節(jié)后面推薦的書籍。
CPU 到操作系統(tǒng)內(nèi)核

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

shell@flo:/ $ cat /proc/interrupts

        CPU0

17: 0 GIC dg_timer
294: 1973609 msmgpio elan-ktf3k
314: 679 msmgpio KEY_POWER

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

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

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

130|shell@flo:/ $ getevent -lt /dev/input/event0
[ 414624.658986] EV_ABS ABS_MT_TRACKING_ID 0000835c
[ 414624.659017] EV_ABS ABS_MT_TOUCH_MAJOR 0000000b
[ 414624.659047] EV_ABS ABS_MT_PRESSURE 0000001d
[ 414624.659047] EV_ABS ABS_MT_POSITION_X 000003f0
[ 414624.659078] EV_ABS ABS_MT_POSITION_Y 00000588
[ 414624.659078] EV_SYN SYN_REPORT 00000000
[ 414624.699239] EV_ABS ABS_MT_TRACKING_ID ffffffff
[ 414624.699270] EV_SYN SYN_REPORT 00000000

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

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

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

就這樣，我們解答了第一個(gè)問(wèn)題，不過(guò)由于時(shí)間有限，這里省略了很多細(xì)節(jié)，想進(jìn)一步學(xué)習(xí)的讀者推薦閱讀以下書籍。
擴(kuò)展學(xué)習(xí)

《計(jì)算機(jī)體系結(jié)構(gòu)》
《計(jì)算機(jī)體系結(jié)構(gòu)：量化研究方法》
《計(jì)算機(jī)組成與設(shè)計(jì)：硬件/軟件接口》
《編碼》
《CPU自制入門》
《操作系統(tǒng)概念》
《ARMv7-AR 體系結(jié)構(gòu)參考手冊(cè)》
《Linux內(nèi)核設(shè)計(jì)與實(shí)現(xiàn)》
《精通Linux設(shè)備驅(qū)動(dòng)程序開(kāi)發(fā)》
第二個(gè)問(wèn)題：瀏覽器如何向網(wǎng)卡發(fā)送數(shù)據(jù)？
從瀏覽器到瀏覽器內(nèi)核

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

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

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

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

HTTP 請(qǐng)求的發(fā)送

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

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

DNS 查詢其實(shí)是基于 UDP 來(lái)實(shí)現(xiàn)的，這里我們通過(guò)一個(gè)具體例子來(lái)了解它的查找過(guò)程，以下是使用 dig +trace fex.baidu.com 命令得到的結(jié)果（省略了一些）：
可以看到這是一個(gè)逐步縮小范圍的查找過(guò)程，首先由本機(jī)所設(shè)置的 DNS 服務(wù)器(8.8.8.8)向 DNS 根節(jié)點(diǎn)查詢負(fù)責(zé) .com 區(qū)域的域務(wù)器，然后通過(guò)其中一個(gè)負(fù)責(zé) .com 的服務(wù)器查詢負(fù)責(zé) baidu.com 的服務(wù)器，最后由其中一個(gè) baidu.com 的域名服務(wù)器查詢 fex.baidu.com 域名的地址。

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

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

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

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

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

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

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

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

另外，因?yàn)?HTTP 請(qǐng)求是純文本格式的，所以在 TCP 的數(shù)據(jù)段中可以直接分析 HTTP 的文本，如果發(fā)現(xiàn)。。。
Socket 在內(nèi)核中的實(shí)現(xiàn)

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

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

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

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

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

不多細(xì)說(shuō)了
第三個(gè)問(wèn)題：數(shù)據(jù)如何從本機(jī)網(wǎng)卡發(fā)送到服務(wù)器？
從內(nèi)核到網(wǎng)絡(luò)適配器(Network Interface Card)

前面說(shuō)到調(diào)用 Socket API 后內(nèi)核會(huì)對(duì)數(shù)據(jù)進(jìn)行底層協(xié)議棧的封裝，接下來(lái)啟動(dòng) DMA 控制器，它將從內(nèi)存中讀取數(shù)據(jù)寫入網(wǎng)卡。

以 Nexus 5 為例，它使用的是博通 BCM4339 芯片通信，接口采用了 SD 卡一樣的 SDIO，但這個(gè)芯片的細(xì)節(jié)并沒(méi)有公開(kāi)資料，所以這里就不討論了。
連接 Wi-Fi 路由

Wi-Fi 網(wǎng)卡需要通過(guò) Wi-Fi 路由來(lái)與外部通信，原理是基于無(wú)線電，通過(guò)電流變化來(lái)產(chǎn)生無(wú)線電，這個(gè)過(guò)程也叫「調(diào)制」，而反過(guò)來(lái)無(wú)線電可以引起電磁場(chǎng)變化，從而產(chǎn)生電流變化，利用這個(gè)原理就能將無(wú)線電中的信息解讀出來(lái)就叫「解調(diào)」，其中單位時(shí)間內(nèi)變化的次數(shù)就稱為頻率，目前在 Wi-Fi 中所采用的頻率分為 2.4 GHz 和 5 GHz 兩種。

在同一個(gè) Wi-Fi 路由下，因?yàn)椴捎玫念l率相同，同時(shí)使用時(shí)會(huì)發(fā)生沖突，為了解決這個(gè)問(wèn)題，Wi-Fi 采用了被稱為 CSMA/CA 的方法，簡(jiǎn)單來(lái)說(shuō)就是在傳輸前先確認(rèn)信道是否已被使用，沒(méi)有才發(fā)送數(shù)據(jù)。

而同樣基于無(wú)線電原理的 2G/3G/LTE 也會(huì)遇到類似的問(wèn)題，但它并沒(méi)有采用 Wi-Fi 那樣的獨(dú)占方案，而是通過(guò)頻分(FDMA)、時(shí)分(TDMA)和碼分(CDMA)來(lái)進(jìn)行復(fù)用，具體細(xì)節(jié)這里就不展開(kāi)了。

以小米路由為例，它使用的芯片是 BCM 4709，這個(gè)芯片由 ARM Cortex-A9 處理器及流量(Flow)硬件加速組成，使用硬件芯片可以避免經(jīng)過(guò)操作系統(tǒng)中斷、上下文切換等操作，從而提升了性能。

路由器中的操作系統(tǒng)可以基于 OpenWrt 或 DD-WRT 來(lái)開(kāi)發(fā)的，具體細(xì)節(jié)我不太了解，所以就不展開(kāi)了。

因?yàn)閮?nèi)網(wǎng)設(shè)備的 IP 都是類似 192.168.1.x 這樣的內(nèi)網(wǎng)地址，外網(wǎng)無(wú)法直接向這個(gè)地址發(fā)送數(shù)據(jù)，所以網(wǎng)絡(luò)數(shù)據(jù)在經(jīng)過(guò)路由時(shí)，路由會(huì)修改相關(guān)地址和端口，這個(gè)操作稱為 NAT 映射。

最后家庭路由一般會(huì)通過(guò)雙絞線連接到運(yùn)營(yíng)商網(wǎng)絡(luò)的。
運(yùn)營(yíng)商網(wǎng)絡(luò)內(nèi)的路由

數(shù)據(jù)過(guò)雙絞線發(fā)送到運(yùn)營(yíng)商網(wǎng)絡(luò)后，還會(huì)經(jīng)過(guò)很多個(gè)中間路由轉(zhuǎn)發(fā)，讀者可以通過(guò) traceroute 命令或者在線可視化工具來(lái)查看這些路由的 ip 和位置。

當(dāng)數(shù)據(jù)傳遞到這些路由器后，路由器會(huì)取出包中目的地址的前綴，通過(guò)內(nèi)部的轉(zhuǎn)發(fā)表查找對(duì)應(yīng)的輸出鏈路，而這個(gè)轉(zhuǎn)發(fā)表是如何得到的呢？這就是路由器中最重要的選路算法了，可選的有很多，我對(duì)這方面并不太了解，看起來(lái)維基百科上的詞條列得很全。
主干網(wǎng)間的傳輸

對(duì)于長(zhǎng)線的數(shù)據(jù)傳輸，通常使用光纖作為介質(zhì)，光纖是基于光的全反射來(lái)實(shí)現(xiàn)的，使用光纖需要專門的發(fā)射器通過(guò)電致發(fā)光（比如 LED）將電信號(hào)轉(zhuǎn)成光，比起前面介紹的無(wú)線電和雙絞線，光纖信號(hào)的抗干擾性要強(qiáng)得多，而且能耗也小很多。

既然是基于光來(lái)傳輸數(shù)據(jù)，數(shù)據(jù)傳輸速度也就取決于光的速度，在真空中的光速接近于 30 萬(wàn)千米/秒，由于光纖包層(cladding)中的折射率(refractive index)為 1.52，所以實(shí)際光速是 20 萬(wàn)千米/秒左右，從首都機(jī)場(chǎng)飛往廣州白云機(jī)場(chǎng)的距離是 1967 千米，按照這個(gè)距離來(lái)算需要花費(fèi) 10 毫秒才能抵達(dá)。這意味著如果你在北京，服務(wù)器在廣州，等你發(fā)出數(shù)據(jù)到服務(wù)器返回?cái)?shù)據(jù)至少得等 20 毫秒，實(shí)際情況預(yù)計(jì)是 2- 3 倍，因?yàn)檫@其中還有各個(gè)節(jié)點(diǎn)路由處理的耗時(shí)，比如我測(cè)試了一個(gè)廣州的 IP 發(fā)現(xiàn)平均延遲為 60 毫秒。

這個(gè)延遲是現(xiàn)有科技無(wú)法解決的（除非找到超過(guò)光速的方法），只能通過(guò) CDN 來(lái)讓傳輸距離變短，或盡量減少串行的來(lái)回請(qǐng)求（比如 TCP 建立連接所需的 3 次握手）。
IDC 內(nèi)網(wǎng)

數(shù)據(jù)通過(guò)光纖最終會(huì)來(lái)到服務(wù)器所在的 IDC 機(jī)房，進(jìn)入 IDC 內(nèi)網(wǎng)，這時(shí)可以先通過(guò)分光器將流量鏡像一份出來(lái)方便進(jìn)行安全檢查等分析，還能用來(lái)進(jìn)行。。。

這里的帶寬成本很高，是按照峰值來(lái)結(jié)算的，以每月每 Gbps（注意這里指的是 bit，而不是 Byte）為單位，北京這邊價(jià)格在十萬(wàn)人民幣以上，一般網(wǎng)站使用 1G 到 10G 不等。

接下來(lái)光纖中的數(shù)據(jù)將進(jìn)入集群(Cluster)交換機(jī)，然后再轉(zhuǎn)發(fā)到機(jī)架(Rack)頂部的交換機(jī)，最后通過(guò)這個(gè)交換機(jī)的端口將數(shù)據(jù)發(fā)往機(jī)架中的服務(wù)器，可以參考下圖（來(lái)自 Open Compute）：

上圖左邊是正面，右邊是側(cè)面，可以看到頂部為交換機(jī)所留的位置。

以前這些交換機(jī)的內(nèi)部實(shí)現(xiàn)是封閉的，相關(guān)廠商（如思科、Juniper 等）會(huì)使用特定的處理器和操作系統(tǒng)，外界難以進(jìn)行靈活控制，甚至有時(shí)候需要手工配置，但這幾年隨著 OpenFlow 技術(shù)的流行，也出現(xiàn)了開(kāi)放交換機(jī)硬件(Open Switch Hardware)，比如 Intel 的網(wǎng)絡(luò)平臺(tái)，推薦感興趣的讀者建議看看它的視頻，比文字描述清晰多了。

需要注意的是，一般網(wǎng)絡(luò)書中提到的交換機(jī)都只具備二層（MAC 協(xié)議）的功能，但在 IDC 中的交換器基本上都具備三層（IP 協(xié)議）的功能，所以不需要有專門的路由了。

最后，因?yàn)?CPU 處理的是電氣信號(hào)，所以光纖中的光線需要先使用相關(guān)設(shè)備通過(guò)光電效應(yīng)將光信號(hào)轉(zhuǎn)成電信號(hào)，然后進(jìn)入服務(wù)器網(wǎng)卡。
服務(wù)器 CPU

前面說(shuō)到數(shù)據(jù)已經(jīng)到達(dá)服務(wù)器網(wǎng)卡了，接著網(wǎng)卡會(huì)將數(shù)據(jù)拷貝到內(nèi)存中（DMA），然后通過(guò)中斷來(lái)通知 CPU，目前服務(wù)器端的 CPU 基本上都是 Intel Xeon，不過(guò)這幾年出現(xiàn)了一些新的架構(gòu)，比如在存儲(chǔ)領(lǐng)域，百度使用 ARM 架構(gòu)來(lái)提升存儲(chǔ)密度，因?yàn)?ARM 的功耗比 Xeon 低得多。而在高性能領(lǐng)域，Google 最近在嘗試基于 POWER 架構(gòu)的 CPU 來(lái)開(kāi)發(fā)的服務(wù)器，最新的 POWER8 處理器可以并行執(zhí)行 96 個(gè)線程，所以對(duì)高并發(fā)的應(yīng)用應(yīng)該很有幫助。
擴(kuò)展學(xué)習(xí)

The Datacenter as a Computer
Open Computer
《軟件定義網(wǎng)絡(luò)》
《大話無(wú)線通信》

第四個(gè)問(wèn)題：服務(wù)器接收到數(shù)據(jù)后會(huì)進(jìn)行哪些處理？
為了避免重復(fù)，這里將不再介紹操作系統(tǒng)，而是直接進(jìn)入后端服務(wù)進(jìn)程，由于這方面有太多技術(shù)選型，所以我只挑幾個(gè)常見(jiàn)的公共部分來(lái)介紹。
負(fù)載均衡

請(qǐng)求在進(jìn)入到真正的應(yīng)用服務(wù)器前，可能還會(huì)先經(jīng)過(guò)負(fù)責(zé)負(fù)載均衡的機(jī)器，它的作用是將請(qǐng)求合理地分配到多個(gè)服務(wù)器上，同時(shí)具備具備防攻擊等功能。

負(fù)載均衡具體實(shí)現(xiàn)有很多種，有直接基于硬件的 F5，有操作系統(tǒng)傳輸層(TCP)上的 LVS，也有在應(yīng)用層(HTTP)實(shí)現(xiàn)的反向代理（也叫七層代理），接下來(lái)將介紹 LVS 及反向代理。

負(fù)載均衡的策略也有很多，如果后面的多個(gè)服務(wù)器性能均衡，最簡(jiǎn)單的方法就是挨個(gè)循環(huán)一遍(Round-Robin)，其它策略就不一一介紹了，可以參考 LVS 中的算法。

LVS

LVS 的作用是從對(duì)外看來(lái)只有一個(gè) IP，而實(shí)際上這個(gè) IP 后面對(duì)應(yīng)是多臺(tái)機(jī)器，因此也被成為 Virtual IP。

前面提到的 NAT 也是一種 LVS 中的工作模式，除此之外還有 DR 和 TUNNEL，具體細(xì)節(jié)這里就不展開(kāi)了，它們的缺點(diǎn)是無(wú)法跨網(wǎng)段，所以百度自己開(kāi)發(fā)了 BVS 系統(tǒng)。

反向代理

反向代理是工作在 HTTP 上的，具體實(shí)現(xiàn)可以基于 HAProxy 或 Nginx，因?yàn)榉聪虼砟芾斫?HTTP 協(xié)議，所以能做非常多的事情，比如：

進(jìn)行很多統(tǒng)一處理，比如防攻擊策略、防抓取、SSL、gzip、自動(dòng)性能優(yōu)化等
應(yīng)用層的分流策略都能在這里做，比如對(duì) /xx 路徑的請(qǐng)求分到 a 服務(wù)器，對(duì) /yy 路徑的請(qǐng)求分到 b 服務(wù)器，或者按照 cookie 進(jìn)行小流量測(cè)試等
緩存，并在后端服務(wù)掛掉的時(shí)候顯示友好的 404 頁(yè)面
監(jiān)控后端服務(wù)是否異常
??

Nginx 的代碼寫得非常優(yōu)秀，從中能學(xué)到很多，對(duì)高性能服務(wù)端開(kāi)發(fā)感興趣的讀者一定要看看。
Web Server 中的處理

請(qǐng)求經(jīng)過(guò)前面的負(fù)載均衡后，將進(jìn)入到對(duì)應(yīng)服務(wù)器上的 Web Server，比如 Apache、Tomcat、Node.JS 等。

以 Apache 為例，在接收到請(qǐng)求后會(huì)交給一個(gè)獨(dú)立的進(jìn)程來(lái)處理，我們可以通過(guò)編寫 Apache 擴(kuò)展來(lái)處理，但這樣開(kāi)發(fā)起來(lái)太麻煩了，所以一般會(huì)調(diào)用 PHP 等腳本語(yǔ)言來(lái)進(jìn)行處理，比如在 CGI 下就是將 HTTP 中的參數(shù)放到環(huán)境變量中，然后啟動(dòng) PHP 進(jìn)程來(lái)執(zhí)行，或者使用 FastCGI 來(lái)預(yù)先啟動(dòng)進(jìn)程。

（等后續(xù)有空再多帶帶介紹 Node.JS 中的處理）
進(jìn)入后端語(yǔ)言

前面說(shuō)到 Web Server 會(huì)調(diào)用后端語(yǔ)言進(jìn)程來(lái)處理 HTTP 請(qǐng)求（這個(gè)說(shuō)法不完全正確，有很多其它可能），那么接下來(lái)就是后端語(yǔ)言的處理了，目前大部分后端語(yǔ)言都是基于虛擬機(jī)的，如 PHP、Java、JavaScript、Python 等，但這個(gè)領(lǐng)域的話題非常大，難以講清楚，對(duì) PHP 感興趣的讀者可以閱讀我之前寫的 HHVM 介紹文章，其中提到了很多虛擬機(jī)的基礎(chǔ)知識(shí)。
Web 框架(Framework)

如果你的 PHP 只是用來(lái)做簡(jiǎn)單的個(gè)人主頁(yè)「Personal Home Page」，倒沒(méi)必要使用 Web 框架，但如果隨著代碼的增加會(huì)變得越來(lái)越難以管理，所以一般網(wǎng)站都會(huì)會(huì)基于某個(gè) Web 框架來(lái)開(kāi)發(fā)，因此在后端語(yǔ)言執(zhí)行時(shí)首先進(jìn)入 Web 框架的代碼，然后由框架再去調(diào)用應(yīng)用的實(shí)現(xiàn)代碼。

可選的 Web 框架非常多，這里就不一一介紹了。
讀取數(shù)據(jù)

這部分不展開(kāi)了，從簡(jiǎn)單的讀寫文件到數(shù)據(jù)中間層，這里面可選的方案實(shí)在太多。
擴(kuò)展學(xué)習(xí)

《深入理解Nginx》
《Python源碼剖析》
《深入理解Java虛擬機(jī)》
《數(shù)據(jù)庫(kù)系統(tǒng)實(shí)現(xiàn)》

第五個(gè)問(wèn)題：服務(wù)器返回?cái)?shù)據(jù)后瀏覽器如何處理？
前面說(shuō)到服務(wù)端處理完請(qǐng)求后，結(jié)果將通過(guò)網(wǎng)絡(luò)發(fā)回客戶端的瀏覽器，從本節(jié)開(kāi)始將介紹瀏覽器接收到數(shù)據(jù)后的處理，值得一提的是這方面之前有一篇不錯(cuò)的文章 How Browsers Work，所以很多內(nèi)容我不想再重復(fù)介紹，因此將重點(diǎn)放在那篇文章所忽略的部分。
從 01 到字符

HTTP 請(qǐng)求返回的 HTML 傳遞到瀏覽器后，如果有 gzip 會(huì)先解壓，然后接下來(lái)最重要的問(wèn)題是要知道它的編碼是什么，比如同樣一個(gè)「中」字，在 UTF-8 編碼下它的內(nèi)容其實(shí)是「11100100 10111000 10101101」也就是「E4 B8 AD」，而在 GBK 下則是「11010110 11010000」，也就是「D6 D0」，如何才能知道文件的編碼？可以有很多判斷方法：

用戶設(shè)置，在瀏覽器中可以指定頁(yè)面編碼
HTTP 協(xié)議中
 中的 charset 屬性值
對(duì)于 JS 和 CSS
對(duì)于 iframe

如果在這些地方都沒(méi)指明，瀏覽器就很難處理，在它看來(lái)就是一堆「0」和「1」，比如「中文」，它在 UTF-8 下有 6 個(gè)字節(jié)，如果按照 GBK 可以當(dāng)成「涓枃」這 3 個(gè)漢字來(lái)解釋，瀏覽器怎么知道到底是「中文」還是「涓枃」呢？

不過(guò)正常人一眼就能認(rèn)出「涓枃」是錯(cuò)的，因?yàn)檫@ 3 個(gè)字太不常見(jiàn)了，所以有人就想到通過(guò)判斷常見(jiàn)字的方法來(lái)檢測(cè)編碼，典型的比如 Mozilla 的 UniversalCharsetDetection，不過(guò)這東東誤判率也很高，所以還是指明編碼的好。

這樣后續(xù)對(duì)文本的操作就是基于「字符」(Character)的了，一個(gè)漢字就是一個(gè)字符，不用再關(guān)心它究竟是 2 個(gè)字節(jié)還是 3 個(gè)字節(jié)。
外鏈資源的加載

（待補(bǔ)充，這里有調(diào)度策略）
JavaScript 的執(zhí)行

（后續(xù)再多帶帶介紹，推薦大家看 R 大去年整理的這個(gè)帖子，里面有非常多相關(guān)資料，另外我兩年前曾講過(guò) JavaScript 引擎中的性能優(yōu)化，雖然有些內(nèi)容不太正確了，但也可以看看）
從字符到圖片

二維渲染中最復(fù)雜的要數(shù)文字顯示了，雖然想想似乎很簡(jiǎn)單，不就是將某個(gè)文字對(duì)應(yīng)的字形(glyph)找出來(lái)么？在中文和英文中這樣做是沒(méi)問(wèn)題的，因?yàn)橐粋€(gè)字符就對(duì)應(yīng)一個(gè)字形(glyph)，在字體文件中找到字形，然后畫上去就可以了，但在阿拉伯語(yǔ)中是不行的，因?yàn)樗杏羞B體形式。

（以后續(xù)再多帶帶介紹，這里非常復(fù)雜）
跨平臺(tái) 2D 繪制庫(kù)

在不同操作系統(tǒng)中都提供了自己的圖形繪制 API，比如 Mac OS X 下的 Quartz，Windows 下的 GDI 以及 Linux 下的 Xlib，但它們相互不兼容，所以為了方便支持跨平臺(tái)繪圖，在 Chrome 中使用了 Skia 庫(kù)。

（以后再多帶帶介紹，Skia 內(nèi)部實(shí)現(xiàn)調(diào)用層級(jí)太多，直接講代碼可能不適合初學(xué)者）
GPU 合成

（以后續(xù)再多帶帶介紹，雖然簡(jiǎn)單來(lái)說(shuō)就是靠貼圖，但還得介紹 OpenGL 以及 GPU 芯片，內(nèi)容太長(zhǎng)）
擴(kuò)展學(xué)習(xí)

這節(jié)內(nèi)容是我最熟悉，結(jié)果反而因?yàn)檫@樣才想花更多時(shí)間寫好，所以等到以后再發(fā)出來(lái)好了，大家先可以先看看以下幾個(gè)站點(diǎn)：

Chromium
Mozilla Hacks
Surfin’ Safari

第六個(gè)問(wèn)題：瀏覽器如何將頁(yè)面展現(xiàn)出來(lái)？
前面提到瀏覽器已經(jīng)將頁(yè)面渲染成一張圖片了，接下來(lái)的問(wèn)題就是如何將這張圖片展示在屏幕上。
Framebuffer

以 Linux 為例，在應(yīng)用中控制屏幕最直接的方法是將圖像的 bitmap 寫入 /dev/fb0 文件中，這個(gè)文件實(shí)際上一個(gè)內(nèi)存區(qū)域的映射，這段內(nèi)存區(qū)域稱為 Framebuffer。

需要注意的是在硬件加速下，如 OpenGL 是不經(jīng)過(guò) Framebuffer 的。
從內(nèi)存到 LCD

在手機(jī)的 SoC 中通常都會(huì)有一個(gè) LCD 控制器，當(dāng) Framebuffer 準(zhǔn)備好后，CPU 會(huì)通過(guò) AMBA 內(nèi)部總線通知 LCD 控制器，然后這個(gè)控制器讀取 Framebuffer 中的數(shù)據(jù)，進(jìn)行格式轉(zhuǎn)換、伽馬校正等操作，最終通過(guò) DSI、HDMI 等接口發(fā)往 LCD 顯示器。
本文所忽略的內(nèi)容

為了編寫方便，前面的介紹中將很多底層細(xì)節(jié)實(shí)現(xiàn)忽略了，比如：

內(nèi)存相關(guān)
    堆，這里的分配策略有很多，比如 malloc 的實(shí)現(xiàn)
    棧，函數(shù)調(diào)用，已經(jīng)有很多優(yōu)秀的文章或書籍介紹了
    內(nèi)存映射，動(dòng)態(tài)庫(kù)加載等
    隊(duì)列幾乎無(wú)處不在，但這些細(xì)節(jié)和原理沒(méi)太大關(guān)系
各種緩存
    CPU 的緩存、操作系統(tǒng)的緩存、HTTP 緩存、后端緩存等等
各種監(jiān)控
    很多日志會(huì)保存下來(lái)以便后續(xù)分析

大綱：

瀏覽器查詢緩存，如果緩存存在跳到第9步

瀏覽器詢問(wèn)操作系統(tǒng)服務(wù)器的IP地址

操作系統(tǒng)做DNS查詢，返回IP地址給瀏覽器

瀏覽器打開(kāi)對(duì)服務(wù)器的TCP連接

瀏覽器通過(guò)TCP連接發(fā)送HTTP請(qǐng)求

瀏覽器接收HTTP響應(yīng)并且可能關(guān)掉TCP連接，或者是重新使用連接處理新請(qǐng)求（也就是keepalive）

瀏覽器檢查HTTP響應(yīng)是否為一個(gè)重定向（3xx 結(jié)果狀態(tài)碼 ），一個(gè)驗(yàn)證請(qǐng)求（401），錯(cuò)誤（4xx 5xx）等等，這些都是不同響應(yīng)的正常處理（2xx）

如果響應(yīng)可緩存，將存入緩存

瀏覽器解碼響應(yīng)（例如：如果它是gziped壓縮）

瀏覽器決定如何處理這些響應(yīng)（例如，它是HTML頁(yè)面，一張圖片，一段音樂(lè)）

瀏覽器展現(xiàn)響應(yīng)，對(duì)未知類型還會(huì)彈出下載對(duì)話框（現(xiàn)在一般不會(huì)彈出了，用戶對(duì)瀏覽器設(shè)置而定）